RFR: 8317809: Insertion of free code blobs into code cache can be very slow during class unloading [v3]

Thomas Schatzl tschatzl at openjdk.org
Fri Dec 1 09:15:08 UTC 2023


On Thu, 30 Nov 2023 10:34:37 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/classUnloadingContext.hpp line 63:
>> 
>>> 61: };
>>> 62: 
>>> 63: class DefaultClassUnloadingContext : public ClassUnloadingContext {
>> 
>> I don't understand why they need to be two classes, even after reading "These are the reason for the class hierarchy for...". The reference to future/other PR(s) in the description doesn't really help -- it's unclear what is *necessary* for the current PR and what is preparation for future PR(s).
>
> The base class is unnecessary for this change, but very nice to have for future changes. I'll just merge them for now, and separate them again later.

As explained in the now removed original description:


>These are the reason for the class hierarchy for `ClassUnloadingContext`: the goal is to ultimately have about this phasing (for G1):
>1. collect all dead CLDs, using the `register_unloading_class_loader_data` method *only*
>2. parallelize the stuff in `ClassLoaderData::unload()` in one way or another, adding them to the `complete_cleaning` >(parallel) phase.
>
>Particularly the split of `SystemDictionary::do_unloading` into "only" traversing the CLDs to find the dead ones and then in parallel process them in 2. above warrants a separate `ClassUnloadingContext` (to facilitate parallelism). 


I.e. the non-parallelized case does not need the necessary data structure complications and helper methods to do efficient parallel iteration. However as mentioned I removed the class hierarchy for this change as it's unnecessary for now; let's discuss this hierarchy separately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16759#discussion_r1411815090


More information about the hotspot-gc-dev mailing list