RFR: 8323630: GenShen: Control thread may (still) ignore requests to start concurrent GC
William Kemper
wkemper at openjdk.org
Fri Jan 12 17:07:10 UTC 2024
On Fri, 12 Jan 2024 02:13:29 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:
>> A race condition exists in which the control thread may clear the `_requested_gc_cause` immediately after a mutator requests an explicit gc. When this happens, the control thread will no longer accept requests from the regulator to start concurrent GC cycles. The mutator thread will never wakeup, eventually the application will run out of memory or no progress will be made.
>>
>> The change here is intended to simplify the thread communication protocol by reducing the number of variables in play.
>
> src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 253:
>
>> 251: // Blow away all soft references on this cycle, if handling allocation failure,
>> 252: // either implicit or explicit GC request, or we are requested to do so unconditionally.
>> 253: if (generation == select_global_generation() && (alloc_failure_pending || implicit_gc_requested || explicit_gc_requested || ShenandoahAlwaysClearSoftRefs)) {
>
> Not a change you made, but why do we clear all soft refs if it's an implicit gc? Is memory pressure supposed to be very high here?
I don't really understand the value of having two code paths for implicit/explicit GCs. They both have the same outcome with respect to garbage collection. They differ only in what is logged and which policy counters get incremented (which is also only consumed by the end-of-process stats report). We could likely simplify this in a separate PR.
To answer your question though, I think the most common cause for an implicit GC would be a metaspace oom. Implicit GC is basically any cause that didn't come from a mutator or a heuristic. I think it would be better anyway for the policy to just report the number of GCs for each cause directly (similar to how degenerated points are tracked).
-------------
PR Review Comment: https://git.openjdk.org/shenandoah/pull/382#discussion_r1450713412
More information about the shenandoah-dev
mailing list