RFR: 8296125: Add a command line option to set a refresh rate of the OS cached metrics in Linux [v2]

[David Holmes]

On Wed, 2 Nov 2022 00:19:35 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

>> I would like to add a new command line product option:
>> -XX:OsCachedMetricsRefreshRate=value, -
>> where a value is times per second and is in the range [1; 1000000000].
>> 
>> It substitutes the hardcoded timeout of 20 ms between re-readings of the OS cached metrics introduced in [JDK-8232207](https://bugs.openjdk.org/browse/JDK-8232207) and allows to set this timeout (as a refresh rate) by a user at the launch time.
>> 
>> This option will be available only on Linux.
>> 
>> It can be used as followed:
>> java -XX:OsCachedMetricsRefreshRate=100 MyApp
>
> Olga Mikhaltsova has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Made the option (OsCachedMetricsRefreshRate) DIAGNOSTIC
>  - Moved oscontainer_cache_timeout() from os::Linux to OSContainer

> I see some comments about "polling being slow" so I just want to clarify that the issue is exactly the opposite.
> With -XX:OsCachedMetricsRefreshRate=1, the lowest possible setting here, this slows the timeout down to 1000ms (1 second). They do see some improvement with this but it's not sufficient.

So this proposed patch is not actually addressing the issue and serves no real purpose.

> The JDK feature to dynamically create compiler threads is querying the os for available memory to make a decision whether a new thread should be created or not

So in that case perhaps we need to revisit the policy being used to decide that?

And we should also look at the use of locking in os::available_memory, if contention is the issue. Though I'm surprised that we would consider creating dynamic compiler threads often enough to cause contention on the locks here. That would also suggest it is the locking that is sub-optimal (critical section[s] too long?).

-------------

PR: https://git.openjdk.org/jdk/pull/10918