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