Dead code in jdk.internal.platform.Metrics?
bob.vandette at oracle.com
Wed Sep 18 18:27:14 UTC 2019
> On Sep 18, 2019, at 11:05 AM, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> On Wed, 2019-09-18 at 10:15 -0700, Bob Vandette wrote:
>> 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
> Sure. Has there been any movement on them?
I need to have a discussion with the core-libs team when I get back. I may
pick up the JMX MBean work. This requires taking a look at other OS’s such as
Windows to see what could be provided for that platform. Your cgroupv2 work
is coming at a good time.
>> There are container tests that verify many of these methods.
> Like I said, I've run container tests with the patch below applied and
> they seem to pass. So IMO they're not covered by tests. Grepping
> through the code doesn't return anything either.
>> Can you give me a list of the metrics that are not available under
> Not an exhaustive list, but from a cursory initial assessment:
> - public long getMemoryMaxUsage();
> - public long getKernelMemoryFailCount();
> - public long getKernelMemoryMaxUsage();
> - public long getKernelMemoryUsage();
> - public long getTcpMemoryFailCount();
> - public long getTcpMemoryMaxUsage();
> - public long getTcpMemoryUsage();
The Kernel and Tcp metrics are not that critical but I wish they had MemoryMaxUsage.
That’s a useful metric for adjusting container memory limits.
>>> On Sep 18, 2019, at 10:02 AM, Severin Gehwolf <sgehwolf at redhat.com> wrote:
>>> Hi Bob,
>>> As you probably know, I'm looking at cgroups v2 support in OpenJDK.
>>> When looking at Metrics.java 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:
>>>  https://bugs.openjdk.java.net/browse/JDK-8230305
>>>  http://hg.openjdk.java.net/jdk/jdk/file/377f47ccc20b/src/java.base/share/classes/jdk/internal/platform/Metrics.java
More information about the core-libs-dev