RFR: 8213565: Crash in DependencyContext::remove_dependent_nmethod
Robbin Ehn
robbin.ehn at oracle.com
Fri Nov 23 15:26:55 UTC 2018
Looks good, thanks!
/Robbin
On 2018-11-23 16:16, Erik Österlund wrote:
> Hi,
>
> Here is an updated version with some minor adjustments based on feedback from
> Robbin Ehn.
>
> Incremental:
> http://cr.openjdk.java.net/~eosterlund/8213565/webrev.00_01/
>
> Full:
> http://cr.openjdk.java.net/~eosterlund/8213565/webrev.01/
>
> Thanks,
> /Erik
>
> On 2018-11-20 16:10, Erik Österlund wrote:
>> Ping.
>>
>> /Erik
>>
>> On 2018-11-12 23:02, Erik Österlund wrote:
>>> Hi,
>>>
>>> In my change 8209189, I moved a lot of code around relating to code cache
>>> unloading. Unfortunately, I failed to see that when making nmethods unloaded,
>>> and their dependents are flushed... they are not immediately removed.
>>> Instead, they are tagged to have stale entries, that are later cleaned during
>>> weak metadata cleaning of InstanceKlass. As for method handles, they leak
>>> instead, with some hacks to reduce the leaking by expunging entries while
>>> adding and removing.
>>>
>>> Obviously, with InstanceKlass cleanup and code cache unloading now
>>> possibly running in parallel after 8209189, things can go wrong. These two
>>> phases used
>>> to be separated by a "wait barrier" for the worker threads preventing that
>>> parallelism.
>>>
>>> The reason dependency contexts were not cleaned when they were found
>>> during code cache cleaning, is because it was not thread safe when code
>>> cache unloading was made parallel instead of serial. But now that we are
>>> implementing concurrent class unloading, we are going to need concurrent
>>> cleanup of dependency contexts anyway. Therefore I will propose a bug fix
>>> that fixes the problem in a way that works for both serial, parallel and
>>> concurrent class unloading.
>>>
>>> The solution is to during code cache unloading claim cleaning of
>>> encountered stale dependency contexts, and clean them straight away.
>>> Entries are unlinked in a lock-free fashion, and placed on a purge list that
>>> is walked and deleted during ClassLoaderDataGraph::purge(). This follows the
>>> thinking of first unlinking, then syncing all threads, and then purging.
>>>
>>> New accessors for the head and next links, hide is_unloading entries and
>>> helps unlinking them and putting them into the purge list.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~eosterlund/8213565/webrev.00/
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8213565
>>>
>>> Thanks,
>>> /Erik
>>
>
More information about the hotspot-dev
mailing list