Hi,

We were profiling our code, and one RTL function regularly popped up in close to the top in the profiling list.

It's remove_freed_fixed_chunks(). Can someone explain to me under what condition this code is triggered very often and/or could take long to execute (there's a loop in there)?

Maybe we abuse the the heap manager, or there's room for improvement in the RTL, we would like to know.

We experienced his on ARM/Linux btw.

Charlie

Karoly Balogh wrote

Maybe we abuse the the heap manager,

As normal Strings reside on the heap and are automatically created and destroyed, maybe (as I was told lately) Short Strings are more efficient.

-Michael

This was reported earlier too, but I couldn't reproduce it: http://bugs.freepascal.org/view.php?id=18079 (especially comment 47405 by Sergei).

Jonas

I suggest to use cmem and compare the results.

I will also note that malloc uses mremap <http://man7.org/linux/man-pages/man2/mremap.2.html> on Linux only, rather than physically moving bytes around. This makes a very efficient realloc possible (on Linux only).

The Mach kernel of Mac OS X has vm_remap, but Apple is not smart enough to use it (as of OS X 10.8.5, the source code for malloc in OS X 10.9 is unknown).

Windows neither has a mremap nor a realloc, which implies that on every resize a new block has to be allocated, with all bytes physically moved to the new location, see <http://www.mgroeber.de/misc/windows_heap.html>. This makes realloc on Windows (with the system heap manager) extremely ineffcient.

Regards,

Adriaan van Os

None of that would explain the differences experienced in the referred bug report, because we don't use mremap-like functionality on any platform at this time. The issue there appears to be a corner case that makes the heap manager reformat/free/reallocate its internal heap blocks all the time on some systems, while on other systems it won't do that even though it's presented with exactly the same memory allocation/reallocation pattern.

Jonas

11.11.2014 12:35, Jonas Maebe пишет:

This behavior apparently depends on all memory serviced by memory manager, including blocks allocated (and maybe also freed) during RTL initialization. That's why it differs between targets, and that's why the issue 18079 was no longer reproducible after time. Most probably some (unrelated) change was made to RTL initialization code, which also changes the pattern in user code that is required to reproduce issue.

Regards,
Sergei

I have some code that - most likely - reproduces this. The exact same code sometimes takes less than a second to run, sometimes it takes around 20 seconds: It simply randomly allocates and deallocates blocks of memory of up to 1024 bytes. When I straced the code, I could see it was running mmap and mmunmap all the time.

I used this code to 'simulate' a fragmented heap before starting a timing of my "business code".

Michael.