RFR: 8317007: Add bulk removal of dead nmethods during class unloading [v5]

[Albert Mingkun Yang]

On Wed, 13 Dec 2023 11:23:54 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that bulk-removes dead nmethods for the STW collectors instead of unregistering nmethod by nmethod. This significantly speeds up the class unloading phase.
>>     
>> For G1, this is almost 100% the code that has been removed from the review for JDK-8315503.
>>     
>> For Serial and Parallel GC, the code is new.
>>     
>> This change does not try to improve the situation for concurrent collectors - this would at first glance require extending the scope of the `CodeCache_lock` which I did not want to do. See the CR for more details.
>>     
>> Also, no parallelism for Parallel GC: the existing data structure for code root remembered set is a linked list. There is in almost all cases no point in trying to parallelize what is basically a traversal of the linked list (with each element not having a lot of work to do). I filed JDK-8320067. There should already be a significant speedup with this change, as each `unregister_nmethod` call previously traversed the entire linked list to find that element (i.e. complexity reduction of O(n^2) -> O(n)).
>>     
>> One more comment:
>> 
>> *  So it would be possible to merge the `ScavengableNMethod::prune_nmethods_not_into_young` which removes elements from the code root sets that do no longer need to be remembered (due to object movement) with removing dead/unlinked nmethods. However, this would mean to put that class unloading code to the end of gc as during phase 1 the new locations which are relevant for pruning uninteresting code root remembered set entries did not move yet. I wanted to keep determining the unlinking nmethods and class/code unloading them together in the code, but I could be convinced to move it.
>>     
>> Testing: tier1-4
>> 
>> Depends on #16759, please review first.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wrong order of unregister and free code blobs after merge. Do not verify unlinked nmethods.

src/hotspot/share/code/nmethod.cpp line 1447:

> 1445: }
> 1446: 
> 1447: void nmethod::purge(bool free_code_cache_data, bool unregister_nmethod) {

When will `free_code_cache_data` be `false`? I thought with the sort-before-free patch, freeing is always delayed after purging.

src/hotspot/share/code/nmethod.cpp line 1469:

> 1467:   if (unregister_nmethod) {
> 1468:     assert(!free_code_cache_data, "must not free when postponing unregistering");
> 1469:     Universe::heap()->unregister_nmethod(this);

Could the impl of `unregister_nmethod` be `ShouldNotReachHere()` for GCs using bulk-removal?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16767#discussion_r1425299368
PR Review Comment: https://git.openjdk.org/jdk/pull/16767#discussion_r1425300615