RFR: 8057586: Explicit GC ignored if GCLocker is active [v7]

[Thomas Schatzl]

On Tue, 18 Apr 2023 16:05:36 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/gcCause.hpp line 103:
>> 
>>> 101:             cause == GCCause::_wb_full_gc);
>>> 102:   }
>>> 103: 
>> 
>> Not exactly sure what "explict gc"s are, but I would expect something more like this:
>> 
>> Suggestion:
>> 
>>   inline static bool is_explicit_gc(GCCause::Cause cause) {
>>     return (is_user_requested_gc(cause) ||
>>             is_serviceability_requested_gc(cause) ||
>>             cause == GCCause::_wb_young_gc) ||
>>             cause == GCCause::_wb_full_gc);
>>   }
>> 
>> 
>> because serviceability gcs are also explicitly requested by the user (from command line), and I believe all whitebox gcs are "explicit". Maybe also "_allocation_profiler" and "wb_breakpoint" ones (not sure right now about these ones).
>> At least the serviceability ones shouldn't be eaten by gc locker either, but maybe there is no guarantee about them to actually occur.
>
> `is_explicit_full_gc`  which ones would fall in that category? Those are the only ones we are be interested in.

All but `GCCause::_wb_young_gc` from this list; everything that's triggered by the end user in some form (serviceability gcs are from jcmd typically, so they fit in imho). But after some discussion with you I found that all stw collectors always suppress young gcs that failed due to gclocker, so such a change does not really matter. Keep it as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1172332285