RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
Albert Mingkun Yang
ayang at openjdk.org
Mon Jun 30 10:17:11 UTC 2025
On Mon, 30 Jun 2025 09:08:28 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:
>>> 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?
The only side-effect is mutating `_gc_overhead_counter`, which I believe is part of checking gc overhead limit. Do you have any names in mind?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2174712372
More information about the hotspot-gc-dev
mailing list