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

[Claes Redestad]

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)

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.

  Adhering to container / cgroup limits by default: great, tiny one-off
overhead.

  Adapting dynamically at runtime: questionable, cause for measurable
regressions (8232207, 8227006)

/Claes