RFR(S) 8229961: Assert failure in compiler/graalunit/HotspotTest.java
Vladimir Kozlov
vladimir.kozlov at oracle.com
Tue Dec 10 22:14:21 UTC 2019
Looks good. Thank you for fixing JVMCI tests!
Vladimir
On 12/10/19 12:24 PM, Tom Rodriguez wrote:
> 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