RFR 8048268: G1 Code Root Migration performs poorly

[Thomas Schatzl]

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?

Thanks,
  Thomas