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

[Vladimir Kozlov]

On 1/29/13 11:35 AM, Vladimir Kozlov wrote:
> 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.

And I agree that we should stop flashing if it is not successful after 
first (or second) iteration.

Thanks,
Vladimir

>
> 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