RFR: 8214556: Crash in DependencyContext::remove_dependent_nmethod still happens

Erik Österlund erik.osterlund at oracle.com
Mon Dec 3 15:54:03 UTC 2018


Hi Vladimir,

Thanks for the review.

/Erik

On 2018-12-03 16:47, Vladimir Kozlov wrote:
> Good.
> 
> Thanks,
> Vladimir
> 
> On 12/3/18 7:29 AM, Erik Österlund wrote:
>> Hi,
>>
>> Unfortunately, even after 8213565, there are still crashes in 
>> DependencyContext::remove_dependent_nmethod.
>>
>> The claiming mechanism I used for dependency context cleanup used the 
>> safepoint counter as a clock source for monotonically inrcemented 
>> cleaning epochs. What I forgot for a moment while fixing this, is that 
>> VM operations may be coalesced into the same safepoint. If two GC 
>> operations run in the same safepoint, dependency context cleaning will 
>> only run for the first GC operation, not any subsequent one (the 
>> cleanup tasks will appear to have already been claimed), causing stale 
>> dependency contexts to remain with pointers to unloaded nmethods. This 
>> would cause very intermittent crashes in subsequent operations on 
>> those dependency contexts such as the crashes that have been observed.
>>
>> I fixed this by creating a stand-alone counter incremented each 
>> cleanup epoch, instead of using the safepoint counter for this.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8214556
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8214556/webrev.00/
>>
>> I have run this through tier1-6 on linux twice, I've also run tier1-3 
>> on all platforms twice, and another tier1 on windows. Having said 
>> that, it's a very intermittent bug... but at least I know this is 
>> wrong, can cause these crashes, and needs to be fixed.
>>
>> Thanks,
>> /Erik


More information about the hotspot-compiler-dev mailing list