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