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