[fpc-devel] RTL: high CPU load in heap manager

[Michael Van Canneyt]

On Tue, 11 Nov 2014, Sergei Gorelkin wrote:

> 11.11.2014 12:35, Jonas Maebe пишет:
>> On 11/11/14 10:28, Adriaan van Os wrote:
>>> Jonas Maebe wrote:
>>>> On 10/11/14 18:47, Karoly Balogh (Charlie/SGR) wrote:
>>>>> 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)?
>>>>
>>>> This was reported earlier too, but I couldn't reproduce it:
>>>> http://bugs.freepascal.org/view.php?id=18079 (especially comment 47405
>>>> by Sergei).
>>>
>>> I suggest to use cmem and compare the results.
>>>
>>> I will also note that malloc uses mremap
>>
>> 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.
>>
> 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.

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.