RFR (M): 8006952: Slow VM due to excessive code cache freelist iteration

[Vladimir Kozlov]

Nils, you sent webrev for other bug fix.

Vladimir

On 1/30/13 7:43 AM, Nils Eliasson wrote:
> Thanks for the link, interesting background.
>
> Even if finding the largest block on the freelist is free, we would
> still have a misbehavior when the free heap block is less than 1,5M and
> the flushing begins to create a 1,5M freelist block.
>
> Unallocated memory is a good measurement if have some continuous memory
> in reserve for critical blobs. I am thinking of using the thresholds
> against unallocated memory, but forbidding nmethods from using the last
> 0,5M (MinimumFreeSpace) from the heap block. That would prevent the VM
> from fragmenting the last continuous memory space, and allow the VM to
> use all of the freelist.
>
> Like this:
> http://cr.openjdk.java.net/~neliasso/8002364/webrev.03
>
> //Nils
>
> Vladimir Kozlov skrev 2013-01-29 20:35:
>> Nils,
>>
>> You are reversing 7025742 fix. I would prefer to keep track of a
>> largest free block during allocation in CodeCache (by using ordered
>> list or other technique) to avoid scanning the list.
>>
>> Vladimir
>>
>> On 1/29/13 2:56 AM, Nils Eliasson wrote:
>>> Remove continuous free block requirement for code cache flushing and
>>> minimum free space.
>>>
>>> This causes a degenerate behavior when the VM are repeatedly flushing
>>> the code cache trying to free up a continuous 1,5M block. Since the
>>> freelist is fragmented a significant part of the code cache is kept
>>> unallocated. A significant amount of time is spent traversing the
>>> freelist holding the code cache lock or waiting for other threads doing
>>> the same.
>>>
>>> I don't see any reason for why a continuous block is required. Code
>>> cache flushing threshold (CodeCacheFlushingMinimumFreeSpace) is default
>>> 1,5M and code cache minimum threshold (CodeCacheMinimumFreeSpace) is
>>> 0,5M. Finding such a block on the freelist is often unrealistic, and has
>>> not any purpose. The largest nmethods are in the order of 250k, and they
>>> are not allocated when code cache is starting to run out. All critical
>>> adapters are small and will fit easily in the freelist or in the
>>> remaining heap space.
>>>
>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.02/
>>>
>>> Thanks,
>>> Nils Eliasson
>