Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Not a Bug
-
10.5, 10.6, 10.11, 11.1(EOL), 11.2(EOL), 11.4, 11.5(EOL), 11.6(EOL)
Description
The following patch:
https://github.com/MariaDB/server/commit/0c188d5efc452b576c46270e65b9db4746ee9dfe
Added TRASH_FREED_MEMORY as a CMAKE option.
It also set TRASH_FREED_MEMORY to AUTO, and thus enabled by default for all non-WIN32, non-VALGRIND and non-ASAN builds (including release builds).
This may result in a small performance loss in release/optimized builds, likely depending on how pronounced memory freeing is.
Sysbench seemed to give different outcomes depending on settings, even an increase of performance once for a high load run (which may have been be skewed due to disk access), though generally with negative outcomes in a range from -0.2% to -1.8% performance.
Attachments
Activity
I stand corrected. I had discussed this with another developer, and we had both missed the _DEBUG part in the CMAKE flags, as you say.
ELSEIF(TRASH_FREED_MEMORY MATCHES "AUTO" AND NOT WIN32 AND NOT WITH_VALGRIND AND NOT WITH_ASAN)
|
SET(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -DTRASH_FREED_MEMORY")
|
SET(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -DTRASH_FREED_MEMORY")
|
ENDIF()
|
I had checked CMakeCache.txt which does list the var, including for release builds, which would normally indicate it's usage, where it not for, indeed, the _DEBUG part.
//Fill freed memory with specific byte pattern. Will result in
|
// slower execution. Options are: ON OFF AUTO.
|
TRASH_FREED_MEMORY:STRING=AUTO
|
Thank you for the clarification. It seems the small performance loss was thus arbitrary.
That said, when building a debug build with the option specifically set to ON, the resulting debug build, even with -O0 (no optimizations) does not show any relevant symbol with nm ./mariadbd | grep -i trash. Any thoughts?
there are no symbols with "trash" in the name, grep to see how TRASH_FREED_MEMORY is used
It is not active in optimized builds, not by default at least.
CMAKE_CXX_FLAGS_DEBUG has no influence on any optimized builds, neither CMAKE_C_FLAGS_DEBUG