Summary:

• Job queue is enabled in docker.

• Docker's readme updated - removed all mentions of disabled job queue

• In docker environments a "cpu load detection fix" is in place which prevents detecting incorrect values of cpu load. If any thread asks for cpu load sooner than 100ms since the last time cpu was detected, an older snapshot (at most 100ms old) is returned instead of asking for current cpu. This has no noticeable impact on product or performance.

Queue polling returned back to original 100ms + implemented a fix to prevent threads asking for cpu load in parallel:

It looks good (same as in master where job queue is disabled).

When job queue is reconfigured to only poll cpu load once per 10s instead of 100ms the cpu visualization of performance log looks like this (two runs):

This confirms that JDK's detection is broken when multiple threads are asking for cpu load at the same time or too soon after each other.

It seems like enabling job queue affects system load detection - values of sysCpu in performance log change.
The JDK's implementation is here - method getCpuLoad(): https://github.com/openjdk/jdk17/blob/master/src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java

Is it possible that job queue's polling of cpu load every 100ms breaks JDK's detection?

Investigating by changing job queue from 100ms to 10s temporarily.

This is from master (java 17 but job queue still disabled):