RFR: 8266936: Add a finalization JFR event [v10]
coleenp at openjdk.java.net
Thu Oct 14 22:06:50 UTC 2021
On Thu, 14 Oct 2021 21:58:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>> "Since you remove entries on unloading, I don't see any reason to have any concurrent cleanup."
>> Thank you, that is true. The only concurrent work required will be to grow the table.
>> "You do however need in the lookup code, some code that doesn't find the InstanceKlass if !ik->is_loader_alive()"
>> A precondition is that the code doing the lookup hold the ClassLoaderDataGraph_lock or is at a safepoint. Is that still the case? Would not purge_unloaded() take out the InstanceKlass from the table, as part of unloading, before !ik->is_loader_alive() is published to the outside world?
> Ok, I see - grow the table.
> I'm not sure if you need to ask ik->is_loader_alive() or not, but I think you do. The InstanceKlass is removed from your table during class unloading but before that during concurrent class unloading, the class might not be alive while you look at it and concurrent class unloading hasn't gotten around to removing it yet. Since you save classes regardless of CLD, you have to check if it's alive. See classLoaderDataGraph.cpp ClassLoaderDataGraphIterator for example. The CLDG_lock only keeps the graph from not getting modified, but the classes in it might be dead.
That said, I don't see where you return an InstanceKlass in the table, which would need this check. Not in class_unloading_do because this follows the _unloading list.
More information about the hotspot-runtime-dev