RFR: 8316670: Remove effectively unused nmethodBucket::_count [v2]
Thomas Schatzl
tschatzl at openjdk.org
Fri Sep 22 07:39:12 UTC 2023
On Thu, 21 Sep 2023 23:41:02 GMT, Dean Long <dlong at openjdk.org> wrote:
>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>>
>> dlong review
>
> 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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/15863#discussion_r1333996791
More information about the hotspot-compiler-dev
mailing list