RFR: 8057586: Explicit GC ignored if GCLocker is active [v3]
Ivan Walulya
iwalulya at openjdk.org
Thu Mar 30 13:28:15 UTC 2023
On Thu, 30 Mar 2023 12:04:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:
>> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
>>
>> cleanup test
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2119:
>
>> 2117: if (counters_before.total_full_collections() != full_gc_count) {
>> 2118: return true;
>> 2119: }
>
> The other two GCs does this check inside the locker-scope. I don't think there's any practical diff -- why the inconsistency?
Only difference is "time" at which changes were made (Initially on G1), then also I couldn't decide which version is cleaner.
> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 556:
>
>> 554: VMThread::execute(&op);
>> 555:
>> 556: if (!VM_ParallelGCSystemGC::is_cause_full(cause) || op.full_gc_succeeded()) {
>
> Why `full_gc_succeeded` here? Doesn't the following `full_gc_count != total_full_collections` achieve the same purpose?
`full_gc_count != total_full_collections` is under locker-scope, so we can avoid that locking since we are sure at this point that gc_count was incremented.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1153258604
PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1153260399
More information about the hotspot-gc-dev
mailing list