RFR 8048268: G1 Code Root Migration performs poorly

[Mikael Gerdin]

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
>