[jdk21u-dev] RFR: 8315503: G1: Code root scan causes long GC pauses due to imbalanced iteration

[Thomas Stuefe]

On Mon, 8 Apr 2024 20:00:14 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> I backport this for parity with 21.0.4-oracle.
> 
> I had to resolve 3 files:
> 
> src/hotspot/share/gc/g1/heapRegion.cpp
> Hunk #1 had to be resolved. "8140326: G1: Consider putting regions where evacuation failed into next collection set" is not in 21.
> It adds the "keep_tracked" argument.
> 
> src/hotspot/share/gc/g1/heapRegionRemSet.cpp
> Resolved hunk #2 because of "8140326: G1: Consider putting regions where evacuation failed into next collection set".
> Resolved hunk #4 because "8313202: MutexLocker should disallow null Mutexes" is not in 21
> (other Mutex class).
> 
> src/hotspot/share/gc/g1/heapRegionRemSet.cpp
> Resulved hunk #2, dual to hunk #2 in .cpp file.
> 
> Resolved hunks are in a commit of their own.
> 
> I include the two direct follow ups 
> 8317440: Lock rank checking fails when code root set is modified with the Servicelock held after JDK-8315503
> 8318720: G1: Memory leak in G1CodeRootSet after JDK-8315503
> 
> Both apply clean on top.
> 
> I'll backport the third follow-up
> 8323685: PrintSystemDictionaryAtExit has mutex rank assert
> as dependend backport on top of these. It also applies clean,
> but I think it is too large to merge it in here.

My fear when looking at the patch sequence was that Oracle probably did not test Shenandoah very thoroughly. I also did not particularly like the CLDG changes. And the patches have not had a lot of time to cook in mainline.

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

PR Comment: https://git.openjdk.org/jdk21u-dev/pull/476#issuecomment-2045636458