RFC 8299037 Make UseContainerCpuShares true by default for JDK 8u 11u 17u
Ioi Lam
ioi.lam at oracle.com
Mon Dec 19 21:33:17 UTC 2022
On 12/19/2022 10:26 AM, Severin Gehwolf wrote:
> Thanks for starting this conversation, Ioi!
>
> On Mon, 2022-12-19 at 09:30 -0800, Ioi Lam wrote:
>> When JDK-8281181 was backported to 17u and 11u, some users reported
>> that their containerized workload experienced OOM.
>>
>> Although the fix in JDK-8281181 is technically "correct" as CPU
>> shares shouldn't be used to express a limit (see discussion in the
>> CSR JDK-8281571), unfortunately some workload had been configured
>> that way due to how the JDK historically mis-interpreted CPU shares.
>>
>> Introducing a significant behavioral change in an update release
>> probably isn't a good idea.
>>
>> The proposal is to change the default value of UseContainerCpuShares
>> from true to false, so users of update releases up to 17u will need
>> to opt into the new behavior.
> +1
>
> Provided this will be the way we go, it would require a new CSR, right?
>
>> In the next LTS release, the UseContainerCpuShares flag will have no
>> effect. The new behavior will always be used.
>>
>> (PS, since UseContainerCpuShares has been removed in JDK 21, we may
>> need to add it back as an obsolete flag to ease the transition from
>> 17u to 21).
> Yes, a decision would have to be made about this for JDK 21. We need
> some data as to what uses cases are out there which make re-introducing
> cpu shares compelling, though.
Agreed, since we have had only a few complaints since JDK-8281181 has
been shipped, perhaps most of the pain of the behavioral change has been
endured, even for the update releases.
I would encourage people report problems on this e-mail thread. This
will give us more data whether to proceed with the proposed change in
JDK-8299037.
Thanks
- Ioi
> Thanks,
> Severin
>
More information about the hotspot-runtime-dev
mailing list