[jdk21u-dev] RFR: 8272364: Parallel GC adaptive size policy may shrink the heap below MinHeapSize

Daniel Hu duke at openjdk.org
Fri Nov 14 23:20:37 UTC 2025


On Fri, 14 Nov 2025 13:04:57 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

>> @GoeLin Ah, that's my bad. I assumed that given the subsequent test failures of [JDK-8272364](https://bugs.openjdk.org/browse/JDK-8272364), an atomic merge would be preferred. I can re-open with multiple PRs if that's better.
>> 
>> The justification for [JDK-8272364](https://bugs.openjdk.org/browse/JDK-8272364) is that the current behavior is incorrect, and the issue was significant enough to warrant a backport to 22. Moreover, the risk is comparatively low for hotspot backports, given the lack of bugtail (besides some failing tests). The only major risk I see is if 21 users are already reliant on the current incorrect behavior; if that's a main consideration, then this backport can be abandoned.
>
> Hi @cost0much,
> yes, the major concern of a backport is that it harms more use cases than it helps. This includes regressions, and as you argue these are unlikely here. But this also includes changes in behavior which is usually ignored in the risk assessment.
> 
> So is it possible that an application that runs with a smaller heap than configured goes OOM with your fix after updating?
> 
> And, for the positive side, do you have a specific use case where this fix is needed?

@GoeLin 
I believe that an application would only go OOM after this update if the user sets the MinHeapSize above their physical memory limit, relying on the current incorrect behavior. It's a possibility.

I don't know of any cases in which this fix is necessary, however. I'll close for now; if there's a future ask, I'll reopen the backport using the multiple PR method you've mentioned.

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

PR Comment: https://git.openjdk.org/jdk21u-dev/pull/2419#issuecomment-3535017131


More information about the jdk-updates-dev mailing list