RFR (M) 8186042: Optimize OopMapCache lookup

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Mon Aug 28 12:51:10 UTC 2017

Thanks Serguei for the re-review.


On 8/25/17 8:27 PM, serguei.spitsyn at oracle.com wrote:
> Hi Coleen,
> The update looks good to me.
> Thanks,
> Serguei
> On 8/25/17 07:05, coleen.phillimore at oracle.com wrote:
>> This was reviewed on hotspot-runtime-dev but it was noticed that the 
>> traversal of the interpreter's OopMapCache can be done outside of a 
>> safepoint by the graal compiler and by stack walking.   This would 
>> make reclamation of the "old" cached entries not safe.  I have 
>> disallowed use of the interpreter OopMapCache in this change by any 
>> calls outside of GC.   The OopMapCache is an optimization primarily 
>> (now exclusively) for GC root walking.
>> open webrev at http://cr.openjdk.java.net/~coleenp/8186042.02/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8186042
>> Retested with jck tests with -Xlog:interpreter+oopmap=debug, hotspot 
>> tier1 which includes the compiler AOT tests that failed, jvmti tests, 
>> and stack walking tests in the jdk.
>> Thanks,
>> Coleen
>> On 8/11/17 11:46 AM, coleen.phillimore at oracle.com wrote:
>>> 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-dev mailing list