RFR: 8338440: Parallel: Improve fragmentation mitigation in Full GC

[Albert Mingkun Yang]

On Thu, 22 Aug 2024 22:28:04 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Extend `SplitInfo` to support more fine-grained splitting to mitigate the fragmentation issue during full GC. Added comments and diagrams in the process.
>> 
>> For easier review, it's best to start with `SplitInfo` and then proceed to see how it is constructed in `summarize_split_space` and consumed in `first_src_addr`. The accompanying diagrams should help create a clear mental image.
>> 
>> With this patch, the exec time of `runtime/ClassInitErrors/TestOutOfMemoryDuringInit.java` using Parallel drops from ~30s to ~8s, the same as other GCs, and gc-log shows similar number of GC cycles as well.
>> 
>> Test: tier1-8, systemgc micro bm, CacheStress, dacapo, specjbb2005, specjvm2008
>
> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 2271:
> 
>> 2269:         if (partial_obj_start == obj_start) {
>> 2270:           // This obj extends to next region.
>> 2271:           obj_end = partial_obj_end(next_region_start);
> 
> Question: We know the object start position in this branch. Why can't we use object size (in new line 2271) directly (like new line 2274 shown below)? Why is it not safe?
> 
> 
>           // Completely contained in this region; safe to use size().
>           obj_end = obj_start + cast_to_oop(obj_start)->size();

`size()` uses `klass`, which may lie in the next region (depending on the number of left words in this region), which can belong to another worker.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20590#discussion_r1728611288