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

Goetz Lindenmaier goetz at openjdk.org
Wed Apr 10 06:28:14 UTC 2024


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.

I don't think this change is a risk for Shenandoah, The shared changes are minimal.
Also, as 22 is released including this change and with all the testing it needed to undergo, and next LTS is only 25 in 1.5 years, I don't think the test coverage will get substantial better.

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

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


More information about the jdk-updates-dev mailing list