RFR(S) 8229961: Assert failure in compiler/graalunit/HotspotTest.java

Tom Rodriguez tom.rodriguez at oracle.com
Tue Dec 10 20:24:46 UTC 2019


http://cr.openjdk.java.net/~never/8229961/webrev
https://bugs.openjdk.java.net/browse/JDK-8229961

The JVMCI InstalledCode object maintains a link back to the CodeBlob 
it's associated with.  In several places JVMCI extracts the CodeBlob* or 
nmethod* from the InstalledCode and the operates on it.  In most other 
cases where an nmethod is being examined there are external factors 
keeping it alive but in this case there aren't.  The actions of the 
concurrent sweeper can transition or potentially free the nmethod while 
it's being used.  Getting all the way to freeing would take a very 
adversarial schedule but JVMCI should provide more safety for the these 
code paths.

This fix adds an nmethodLocker to these usages and through careful use 
of locks attempts to ensure that the resulting locked nmethod is alive 
and locked when it's returned.  I had to modify some of the jtreg tests 
because they were badly abusing the InstalledCode API and violating some 
assumptions about the relationship between nmethods and their wrapper 
InstalledCode objects.

Testing was clean apart from a test compilation problem and existing 
issue.  I'm resubmitting with the fixed jtreg test.


More information about the hotspot-compiler-dev mailing list