RFR: 8350621: Code cache stops scheduling GC
Thomas Schatzl
tschatzl at openjdk.org
Mon Jul 7 18:57:41 UTC 2025
On Tue, 24 Jun 2025 08:52:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> >
> > However, the current logic that a young-gc can cancel a full-gc (`_codecache_GC_aggressive` in this case) also seems surprising.
>
> That's a different issue.
Actually most likely this is the issue for Parallel GC; that code is present only in older JDK versions before 25 (however other reasons like the `GCLocker` may also prevent these GCs), i.e. there should be no such issue in JDK 25 for Parallel GC.
The situation for Parallel GC is different for earlier versions, i.e. for backporting: it would require the changes for [JDK-8192647](https://bugs.openjdk.org/browse/JDK-8192647) and at least one other fix. There needs to be a cost/benefit analysis these are rather intrusive changes.
@ajacob:
> I considered a few different options before making this change:
>
> 1. Always call Universe::heap()->collect(...) without making any check (the GC impl should handle the situation)
> 2. Fix all GCs implementation to ensure _unloading_threshold_gc_requested gets back to false at some point (probably what is supposed to happen today)
> 3. Change CollectedHeap::collect to return a bool instead of void to indicate if GC was run or scheduled
I had a spin at the (imo correct) fix for 2 - fix G1 `collect()` logic.
Here's a diff: https://github.com/openjdk/jdk/compare/master...tschatzl:jdk:submit/8350621-code-cache-mgmt-hang?expand=1
What do you think?
Thanks,
Thomas
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23656#issuecomment-3035131232
More information about the hotspot-compiler-dev
mailing list