RFR (M) 8186042: Optimize OopMapCache lookup

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Fri Aug 11 15:46:05 UTC 2017


Summary: Use lock free access to oopMapCache
Contributed-by: frederic.parain at oracle.com, coleen.phillimore at oracle.com

The OopMapCache::lookup() function took out a mutex to protect access 
between the GC threads that are running concurrently.  See bug for more 
info.   The function lookup() is run by multiple GC threads 
concurrently.  If there's a collision in the hashtable, this uses atomic 
cmpxchg to add the entry to a list to be cleaned up after the safepoint 
is over.   GC isn't doing lookup at that point.

This change is contributed by Frederic Parain, with some cleanup and 
logging from me.

open webrev at http://cr.openjdk.java.net/~coleenp/8186042.01/webrev
bug link https://bugs.openjdk.java.net/browse/JDK-8186042

Tested with RBT equivalent of nightly on linux x64.  Also ran dacapo 
with -Xint -Xlog:interpreter+oopmap=debug to verify.  This change also 
removes -XX:+TraceOopMapGeneration (not -XX:+TraceNewOopMapGeneration 
however) in favor of new logging.  A linked CSR request is pending.

Thanks,
Coleen



More information about the hotspot-runtime-dev mailing list