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

[David Holmes]

On 16/10/2019 10:07 pm, Claes Redestad wrote:
> On 2019-10-16 13:52, David Holmes wrote:
>> On 16/10/2019 6:42 pm, Claes Redestad wrote:
>>> On 2019-10-16 06:08, David Holmes wrote:
>>>>>> 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.
>>>
>>> No. What we *must* do is to not regress the platform for existing users
>>> and applications, and by making this assumption that the JVM should
>>> default to re-reading cgroup settings all the time, that's just what
>>> we've done. I now think we should treat this as the regression it is and
>>> make the behavior to adapt to a change in constraints an opt-in.
>>
>> There is no "regression" here. If you're running in a container then 
>> we have to report what the container settings are and they come from 
>> reading the cgroup information which can be dynamically updated. 
>> Unless we have something to tell us the information is static and can 
>> be cached we have no choice for correctly implementing the functionality.
>>
> 
> Wrong. I'm not running in a container: I'm seeing the overheads on any
> java program on all my Linux systems - no docker or anything involved.
> 
> So I'm paying a price for something I'm not using and need to add a flag
> to not have to pay that price (-XX:-UseContainerSupport)

Welcome to our world. As Bob said there is no effective way to detect an 
active container environment and an opt-in mechanism was not an option 
so you have to opt-out.

> Regardless: True dynamic adaptiveness needs much more than what's
> currently in place in the VM (and libraries). Instead now a lot of
> common use - with or without containers - is paying for that overhead
> with no upside.

Whether anything in the VM tries to be dynamically adaptive is a 
separate issue. This API is supposed to report the currently available 
memory - that's its job. What users (ie other software components) do 
what that information is up to them. In particular if/when we start 
reporting this through the MXBean the application may well want to do 
something more dynamic and adaptive.

So as I said earlier:

"Until container management APIs catch up we're stuck at assuming the 
worst-case - unless we add flags to choose otherwise."

So now you want to add a flag to choose otherwise and only update from 
the cgroup information periodically. Fine. If there is a general 
consensus from the folk who work with these container environments all 
the time that this is not likely to cause any problem due to most being 
effectively static anyway, then that's all well and good.

David
-----

> 
>   Adhering to container / cgroup limits by default: great, tiny one-off
> overhead.
> 
>   Adapting dynamically at runtime: questionable, cause for measurable
> regressions (8232207, 8227006)
> 
> /Claes