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

[Nils Eliasson]

http://cr.openjdk.java.net/~neliasso/8006952/webrev.04/

//N

Vladimir Kozlov skrev 2013-01-30 21:16:
> 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
>>