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? > 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 > cgroupv2? 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(); Thanks, Severin > Bob. > > > > On Sep 18, 2019, at 10:02 AM, Severin Gehwolf <sgehw...@redhat.com> wrote: > > > > Hi Bob, > > > > As you probably know, I'm looking at cgroups v2 support[0] in OpenJDK. > > When looking at Metrics.java[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: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230305/remove_metrics_interface_methods.patch > > > > Thanks, > > Severin > > > > [0] https://bugs.openjdk.java.net/browse/JDK-8230305 > > [1] > > http://hg.openjdk.java.net/jdk/jdk/file/377f47ccc20b/src/java.base/share/classes/jdk/internal/platform/Metrics.java > >
