Dead code in jdk.internal.platform.Metrics?

Bob Vandette bob.vandette at
Wed Sep 18 17:15:46 UTC 2019

These internal methods were implemented in order to expose container metrics to 
via a public API.  I’ve filed JDK-8203359 and JDK-8199944 to add an MBean 
and JFR events that will expose these values.

JDK-8203359:  Java Flight Recorder (JFR) improvements for containers
JDK-8199944:  Add Container MBean to JMX

There are container tests that verify many of these methods.

Can you give me a list of the metrics that are not available under cgroupv2?


> On Sep 18, 2019, at 10:02 AM, Severin Gehwolf <sgehwolf at> wrote:
> Hi Bob,
> As you probably know, I'm looking at cgroups v2 support[0] in OpenJDK.
> When looking at[1] I see that many methods aren't used
> anywhere. Neither in tests nor in actual code. It looks like as if the
> interface has been modelled along the lines of the cgroups v1
> implementation. These methods are:
> -    public long getCpuUsage();
> -    public long[] getPerCpuUsage();
> -    public long getCpuUserUsage();
> -    public long getCpuSystemUsage();
> -    public double getCpuSetMemoryPressure();
> -    public long getMemoryMaxUsage();
> -    public long getMemoryUsage();
> -    public long getKernelMemoryFailCount();
> -    public long getKernelMemoryMaxUsage();
> -    public long getKernelMemoryUsage();
> -    public long getTcpMemoryFailCount();
> -    public long getTcpMemoryMaxUsage();
> -    public long getTcpMemoryUsage();
> -    public long getBlkIOServiceCount();
> -    public long getBlkIOServiced();
> They are essentially dead code. Note that not all of them would have an
> implementation in cgroups v2. With that in mind, does it actually make
> sense for the Metrics interface to define those? We could keep the
> implementations for cgroup v1 Metrics, but perhaps remove them from the
> interface? It seems the current Metrics interface defines too many
> methods for no good reason. Am I missing something? Thoughts?
> From the looks of it it wouldn't even require a CSR as
> jdk.internal.platform isn't an exported package.
> Here is an example patch removing them, and jdk docker container tests
> still pass:
> Thanks,
> Severin
> [0]
> [1]

More information about the core-libs-dev mailing list