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