RFR: 8323630: GenShen: Control thread may (still) ignore requests to start concurrent GC [v3]

[Y. Srinivas Ramakrishna]

On Fri, 12 Jan 2024 17:04:03 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> 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 very similar outcomes with respect to garbage collection. They differ 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. An 'explicit' request will also attempt to shrink the heap, but we could allow an 'implicit' request to do the same.
> 
> 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).

Thanks!

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/382#discussion_r1450750837