RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
Ivan Walulya
iwalulya at openjdk.org
Mon Jun 30 09:45:44 UTC 2025
On Mon, 19 May 2025 06:00:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:
>> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 363:
>>
>>> 361: }
>>> 362:
>>> 363: bool ParallelScavengeHeap::check_gc_overhead_limit() {
>>
>> In main-line code, the method `check_gc_overhead_limit` is invoked by `PSScavenge::invoke` and `PSParallelCompact::invoke_no_policy` so that we can do the check after all the GCs. But now you only use `check_gc_overhead_limit` in `ParallelScavengeHeap::satisfy_failed_allocation`. I suspect whether it can check the gc overhead limit accurately.
>
>> so that we can do the check after all the GCs
>
> Well, not really. In the old impl, `GCOverheadChecker::check_gc_overhead_limit` calls `set_gc_overhead_limit_exceeded` only for full-gc.
>
> > But now you only use check_gc_overhead_limit in ParallelScavengeHeap::satisfy_failed_allocation. I suspect whether it can check the gc overhead limit accurately.
>
> I believe so. In the old impl, we don't check gc-overhead for explicit gcs. Only allocation-failure caused gcs are interesting, which all go through `satisfy_failed_allocation`.
>
>
> // Ignore explicit GC's. Exiting here does not set the flag and
> // does not reset the count.
> if (GCCause::is_user_requested_gc(gc_cause) ||
> GCCause::is_serviceability_requested_gc(gc_cause)) {
> return;
> }
`check_gc_overhead_limit` does more than `check`, can we find a more appropriate method name?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2174596366
More information about the hotspot-gc-dev
mailing list