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

[Goetz Lindenmaier]

On Wed, 17 Apr 2024 16:52:54 GMT, Aleksey Shipilev <shade 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. See https://github.com/openjdk/jdk21u-dev/pull/477
>
> Actually, let's ask @tschatzl directly if he knows about any other dependencies that might break this patch in JDK 21, or some other caveats.

Hi @shipilev, I would assume  Thomas  checked this when he backported it, so that we see all follow ups anyways!

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

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