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

[David Holmes]

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.

David

> 
> /Claes