[jdk25u-dev] RFR: 8370572: Cgroups hierarchical memory limit is not honored after JDK-8322420
Severin Gehwolf
sgehwolf at openjdk.org
Mon Dec 15 14:52:33 UTC 2025
On Mon, 15 Dec 2025 13:25:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>>> I understand you want a more defensive fix. But I don't think we want to diverge from mainline, really: this just creates another code shape that would be a headache for future maintenance and backports. Unless I don't see a hidden problem somewhere here?
>>
>> Mainline uses the same pattern, so there is no divergence:
>> https://github.com/openjdk/jdk/blob/629bf20f59f98a735ca22018ad00c93580aff5f3/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L164-L170
>
> I am confused. Isn't it visibly different code? What do you mean by "no divergence"? For me, no divergence means the code in this PR repeats what is/was mainline at some point. The version you have in this PR never existed in mainline, AFAICS: neither after JDK-8370573, nor after JDK-8365606. And if it did not existed, it means we have not tested it; that's the risk we are running into here.
The patch for JDK 25 won't be the same as in mainline at some point. This is nothing new when doing backports and needs to be evaluated on a case by case basis. In this case JDK-8292984 not being there in 25 makes the patch divergent. Just dragging in JDK-8292984 for sake of this fix doesn't strike me as a better risk/benefit balance. That's what it ultimately boils down to: Backport X patches as a dependency or do a reduced fix by rewriting some parts. IMO, rewriting some parts is the less risky approach for 25 and 21 that's why I've chosen this approach. It has been tested with the regression test written for that purpose.
With that said, I'd appreciate help in testing the patch if you have some means to test it outside the regression test.
-------------
PR Review Comment: https://git.openjdk.org/jdk25u-dev/pull/76#discussion_r2619747577
More information about the jdk-updates-dev
mailing list