RFR: 8213565: Crash in DependencyContext::remove_dependent_nmethod

[Erik Österlund]

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