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

[Vladimir Kozlov]

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