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