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