RFR: 8350621: Code cache stops scheduling GC [v4]

Thomas Schatzl tschatzl at openjdk.org
Fri Jul 18 17:00:25 UTC 2025


On Fri, 18 Jul 2025 11:51:35 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
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into 8350621-code-cache-mgmt-hang
>  - * kbarrett-review
>  - Merge branch 'master' into 8350621-code-cache-mgmt-hang
>  - * more refactoring, comments
>  - * kbarrett review part 2 (slightly incomplete)
>  - * kbarrett review - 1
>  - * initial kbarrett refactoring
>  - * kbarret review:
>      - restructure code in `try_collect_concurrently`
>      - fix asserts - they only worked in the test because of whitebox being active
>      - fix comments
>    * threalmdoerr review:
>      - fix test to be more lenient
>  - * some whitespace fixes
>  - 8350621
>    
>    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,
>    stuck until the next code unloading (caused by e.g. a regular concurrent cycle being
>    triggered).
>    
>    Testing: tier1-5
>    
>    Thanks,
>      Thomas

Tier 1-5 rerun almost complete seems to be okay.

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

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


More information about the hotspot-gc-dev mailing list