RFR: 8316670: Remove effectively unused nmethodBucket::_count [v2]

[Thomas Schatzl]

On Fri, 22 Sep 2023 07:35:33 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/code/dependencyContext.cpp line 99:
>> 
>>> 97:   assert_lock_strong(CodeCache_lock);
>>> 98:   for (nmethodBucket* b = dependencies_not_unloading(); b != nullptr; b = b->next_not_unloading()) {
>>> 99:     if (nm == b->get_nmethod()) {
>> 
>> This search might not be useful anymore.  We could just add the record unconditionally.  Do we know how often we get duplicate entries (what's the typical value of "count" today)?
>
> That's an interesting question, but I would prefer to keep any kind of optimizations out of this cleanup.
> 
> I am currently investigating class/code cache unloading performance which seems highly dependent on the number of `nmethodBuckets` anyway, so I could investigate that a little.
> 
> However since the dominant part of class unloading (~80% of time) is removing all dependents (see the numbers in [JDK-8316581](https://bugs.openjdk.org/browse/JDK-8316581) and class unloading is (after some patches of mine) already the top time consumer; I am not completely clear about the exact cause though) I would prefer not adding to that.
> Also we do not know how much time this takes compared to other compilation tasks (if you have numbers, I would be interested), i.e. if it is worth actually optimizing this method.

With "Class unloading" I mean the `SystemDictionary::do_unloading()` call.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15863#discussion_r1333998796