RFR: 8350621: Code cache stops scheduling GC

[Martin Doerr]

On Tue, 8 Jul 2025 15:03:27 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change to avoid CodeCache triggered GCs temporarily being ignored.
> 
> In particular, G1 does not make sure when its `collect()` method is called during a concurrent cycle, that a `Remark` pause that does code unloading etc. actually occurs after that request. This makes it so that some internal flag is not reset appropriately (via some callback to the caller). After this event, there will never be another attempt by the compiler threads to issue a garbage collection. The compiler threads are stuck until the next code unloading (caused by e.g. a regular concurrent cycle being triggered).
> 
> The [original PR](https://github.com/openjdk/jdk/pull/23656) also stated a similar with Parallel GC - however due to recent changes (https://bugs.openjdk.org/browse/JDK-8192647 and others) I do not think it is possible any more that the `collect()`call can silently be ignored. (I.e. gclocker could abort a full gc that is the only reason why code cache unloading and that callback will not occur as expected).
> 
> So for G1, the change makes the caller of `collect()` (i.e. the compiler thread) wait until that situation passes and retry. With that the compiler thread is sure that the callback the compiler threads are waiting for occurs. This does have the disadvantage that that compiler thread may not be available for compilation any more for a bit.
> 
> Testing: tier1-5, test case passing, failing before
> 
> Thanks,
>   Thomas

Good finding! I think it looks good, but it should get reviewed by G1 experts.
The test doesn't always pass. I've seen this once:

[12.943s][info ][codecache] Triggering aggressive GC due to having only 49.991% free memory
[12.944s][trace][gc       ] C1 CompilerThread3: Try Collect Concurrently (CodeCache GC Aggressive): attempt 1
[12.984s][debug][gc       ] GC(22) Allocated 2 survivor 0 old percent total 6.67% (10%)
[12.984s][info ][gc       ] GC(22) Pause Young (Concurrent Start) (CodeCache GC Aggressive) 4M->2M(32M) 39.712ms
[12.984s][info ][gc       ] GC(23) Concurrent Mark Cycle
[12.984s][trace][gc       ] C1 CompilerThread3: Try Collect Concurrently (CodeCache GC Aggressive): wait
[13.040s][info ][codecache] Code cache critically low; use aggressive aging
[13.040s][info ][gc       ] GC(23) Pause Remark 3M->3M(32M) 6.383ms
[13.052s][info ][gc       ] GC(23) Pause Cleanup 3M->3M(32M) 0.078ms
[13.052s][info ][gc       ] GC(23) Concurrent Mark Cycle 67.851ms
[13.052s][trace][gc       ] C1 CompilerThread3: Try Collect Concurrently (CodeCache GC Aggressive): complete after wait
[13.056s][info ][codecache] Triggering aggressive GC due to having only 49.854% free memory
[13.056s][trace][gc       ] C1 CompilerThread2: Try Collect Concurrently (CodeCache GC Aggressive): attempt 1
[13.094s][debug][gc       ] GC(24) Allocated 2 survivor 1 old percent total 10.34% (10%)
[13.095s][info ][gc       ] GC(24) Pause Young (Concurrent Start) (CodeCache GC Aggressive) 3M->2M(32M) 38.594ms
[13.095s][trace][gc       ] C1 CompilerThread2: Try Collect Concurrently (CodeCache GC Aggressive): wait
[13.095s][info ][gc       ] GC(25) Concurrent Mark Cycle
[13.149s][info ][codecache] No code cache pressure; don't age code
[13.149s][info ][gc       ] GC(25) Pause Remark 3M->3M(32M) 11.108ms
[13.163s][info ][gc       ] GC(25) Pause Cleanup 3M->3M(32M) 0.072ms
[13.163s][info ][gc       ] GC(25) Concurrent Mark Cycle 68.023ms
[13.163s][trace][gc       ] C1 CompilerThread2: Try Collect Concurrently (CodeCache GC Aggressive): complete after wait
Compiled 180 classes
Compilation done, compiled 200 classes

STDERR:
java.lang.RuntimeException: Could not find a CodeCache GC Threshold GC after finishing the concurrent cycle: expected true, was false

Seems like there are several ways the VM can take.

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

PR Comment: https://git.openjdk.org/jdk/pull/26189#issuecomment-3053106193