RFR [14]: 8232207: Linux os::available_memory re-reads cgroup configuration on every invocation

David Holmes david.holmes at oracle.com
Wed Oct 16 04:08:08 UTC 2019


On 16/10/2019 4:42 am, Severin Gehwolf wrote:
> On Tue, 2019-10-15 at 20:04 +0200, Claes Redestad wrote:
>>> Note that from an OpenShift perspective, config changes == container
>>> restart, ergo JVM restart. So there is no point in actually re-reading
>>> the limits.
>>
>> This is an interesting data point. I've always been curious where the
>> requirement originated that says the JVM container support must adjust
>> dynamically to container configuration changes?
> 
> I'm not sure where this comes from. Comments in JDK-8227006 have some
> details. With that said, it's entirely possible I don't have all the
> info/requirements at hand.
> 
>> If the typical scenario is a static configuration then perhaps that
>> would have been a better default. A fully adaptive mode (with the
>> overheads that comes) sounds like something that should be an opt-in.
> 
> +1 on fully adaptive mode should be opt-in.
> 
> IIRC, the premise was that "we cannot prove that the config stays
> static in all cases". Hence, the adaptive mode conclusion. I'm in no
> way in that court, though.

Yes the underlying cgroup functionality allows for dynamism. The fact 
some particular container framework chooses not to allow it is not 
something we know a-priori or can readily detect. Until container 
management APIs catch up we're stuck at assuming the worst-case - unless 
we add flags to choose otherwise.

David
-----

> 
> Thanks,
> Severin
> 


More information about the hotspot-runtime-dev mailing list