RFR: 8057586: Explicit GC ignored if GCLocker is active [v3]
Albert Mingkun Yang
ayang at openjdk.org
Thu Mar 30 13:42:27 UTC 2023
On Thu, 30 Mar 2023 13:23:09 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:
>> 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.
I think the style in Serial 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.
True, but this is not a perf-critical method, be consistent (with other gcs) is more important, IMO.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1153276397
PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1153279504
More information about the hotspot-gc-dev
mailing list