RFR: 8317350: Move code cache purging out of CodeCache::UnloadingScope

[Albert Mingkun Yang]

On Mon, 2 Oct 2023 12:56:27 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this refactoring that moves actual code cache flushing/purging out of `CodeCache::UnloadingScope`. Reasons:
> 
> * I prefer that a destructor does not do anything substantial - in some cases, 90% of time is spent in the destructor in that extracted method (due to https://bugs.openjdk.org/browse/JDK-8316959)
> * imho it does not fit the class which does nothing but sets/resets some code cache unloading behavior (probably should be renamed to `UnloadingBehaviorScope` too in a separate CR).
> * other existing methods at that level are placed out of that (or any other) scope object too - which is already the case for when doing concurrent unloading.
> * putting it there makes future logging of the various phases a little bit easier, not having `GCTraceTimer` et al. in various places.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

src/hotspot/share/gc/parallel/psParallelCompact.cpp line 2068:

> 2066: 
> 2067:     // Release unloaded nmethods's memory.
> 2068:     CodeCache::flush_unlinked_nmethods();

The fact that recycling resources for nmethods involves two steps, unlink and free-unlinked, seems an insignificant impl detail in this caller context. Can that be hidden away from the public API, e.g. `do_unloading` perform these two steps directly?

Is there a reason why `flush_unlinked_nmethods` is outside the scope?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16011#discussion_r1360667446