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

Tom Rodriguez tom.rodriguez at oracle.com
Wed Dec 11 17:46:42 UTC 2019


Thanks!

tom

Vladimir Kozlov wrote on 12/10/19 2:14 PM:
> 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