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