RFR 8048268: G1 Code Root Migration performs poorly

[Bengt Rutisson]

Hi Mikael,

Latest webrev looks good to me.

Bengt

On 2014-09-02 15:18, Mikael Gerdin wrote:
> Hi Thomas,
>
> On 2014-09-02 14:25, Thomas Schatzl wrote:
>> Hi,
>>
>>
>> On Tue, 2014-08-26 at 17:42 +0200, Mikael Gerdin wrote:
>>> Hi,
>>>
>>> In order to combat the spikes in code root migration times I suggest 
>>> that we
>>> reimplement the code cache remembered set using hash tables instead 
>>> of the
>>> current chunked array variant.
>> [...]
>>>
>>> This change depends on "JDK-8056084: Refactor Hashtable to allow
>>> implementations without rehashing support" since the remembered sets 
>>> are
>>> allocated and deallocated I needed to allow for deallocation of 
>>> instances of
>>> HashtableEntry and deallocation of freelist contents.
>>>
>>> Webrev: 
>>> http://cr.openjdk.java.net/~mgerdin/8048268/nm-hashtable/webrev/
>>> Buglink: https://bugs.openjdk.java.net/browse/JDK-8048268
>>>
>>> a note about g1RemSetSummary.cpp
>>> the code failed to update _max_code_root_mem_sz, so the code to list 
>>> the most
>>> expensive code root remset was broken.
>>
>> Looks good. One comment about naming of the
>> lock_add_strong_code_root/add_strong_code_root methods. Typically (I
>> think) when we provide both a method that requires existing locking and
>> one that does the locking itself (and calls the other method), we use
>> the combination XXX() and XXX_locked(), where the _locked() method is
>> the one that should only be called when the locks have been taken.
>>
>> The current naming (lock_add... and add...) is somewhat inconsistent
>> with other code. Do you mind fixing that?
>
> Sure.
> I've also fixed some other naming issues that Bengt brought up during 
> a code walkthrough.
>
> Incremental webrev at:
> http://cr.openjdk.java.net/~mgerdin/8048268/nm-hashtable/webrev.0_to_1/
>
> Full webrev at:
> http://cr.openjdk.java.net/~mgerdin/8048268/nm-hashtable/webrev.1/
>
> /Mikael
>
>>
>> Thanks,
>>    Thomas
>>