RFO (Request for Opinion): 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

[Hohensee, Paul]

I’d like to get Maintainer guidance on whether this patch can be backported.

Issue: https://bugs.openjdk.java.net/browse/JDK-8185003
CSR: https://bugs.openjdk.java.net/browse/JDK-8185705

The patch has proven very useful in reducing profile overhead within Amazon, so we’d like to upstream it. The problem is that while the patch is purely additive (adds a new variant of dumpAllThreads for to java.lang.management.ThreadsMXBean), the j.l.m.ThreadMXBean interface is common to all JDK implementations, which strictly speaking means that all JDK implementations must implement it. In contrast, com.sun.management.ThreadMXBean, is “implementation specific”, so there’s no issue with strict additions to it. In mitigation, the default implementation is to throw an UnsupportedOperationException. The patched JDK passes the TCK.

In addition to its standalone utility, the patch increments JMM_VERSION to JDK 10.  JMM_VERSION is further updated to JDK 14 by


JDK-8231209<https://bugs.openjdk.java.net/browse/JDK-8231209>: [REDO] JDK-8207266 ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread

JDK-8231968<https://bugs.openjdk.java.net/browse/JDK-8231968>: getCurrentThreadAllocatedBytes default implementation s/b getThreadAllocatedBytes

These two patches have been backported to 11.0.9 and I’d like to backport them to 8u272 as well. The 11.0.9 backport had no problem because there were no updates to JMM_VERSION between 11 and 13 inclusive. I don’t believe 8231209/8231968 can be backported without backporting 8185003 first, because doing that seems to me to require creation of a new value of JMM_VERSION, because the result wouldn’t include the new dumpAllThreads method from 8185003. Code that queries JMM_VERSION might/would have to be changed to account for the new version, which is more of a compatibility issue than would be backporting 8185003 first. Hence this RFO.

Thanks,
Paul