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

Nils Eliasson nils.eliasson at oracle.com
Wed Jan 30 07:43:40 PST 2013


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



More information about the hotspot-compiler-dev mailing list