RFR (M): 8207266: ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread
mandy.chung at oracle.com
Wed Aug 28 22:58:43 UTC 2019
The CSR proposes this method in java.lang.management.ThreadMXBean as a
Java SE feature.
Has this been discussed with the GC team to commit measuring current
thread's allocated bytes as Java SE feature? Can this be supported by
all JVM implementation? What is the overhead if this is enabled by
default? Does it need to be disabled? This metric is from TLAB that
might be okay. This needs advice/discussion with GC experts.
I see that CSR mentions it can be disabled and link to
isThreadAllocatedMemoryEnabled() and setThreadAllocatedMemoryEnabled()
methods but these methods are defined in com.sun.management.ThreadMXBean.
As Alan points out, current thread makes sense only in local VM
management. When this is monitored from a JMX client (e.g. jconsole to
connect to a running JVM, "currentThreadAllowcatedBytes" attribute is
the current thread in jconsole process which invoking Thread::currentThread?
On 8/28/19 12:22 PM, Hohensee, Paul wrote:
> Please review a performance improvement for
> ThreadMXBean.getThreadAllocatedBytes and the addition of
> JBS issue:https://bugs.openjdk.java.net/browse/JDK-8207266
> Previous email threads:
> The CSR is for adding ThreadMXBean.getCurrentThreadAllocatedBytes. I’d
> be great for someone to review it.
> I took Mandy’s advice and put the fast paths in the library code. I
> added a new JMM method GetOneThreadsAllocatedBytes that works the same
> as GetThreadCpuTime: it uses a thread_id value of zero to distinguish
> the current thread. On my Mac laptop, the result runs 47x faster for
> the current thread than the old implementation.
> The 3 tests intest/jdk/com/sun/management/ThreadMXBean all pass. I
> added code to ThreadAllocatedMemory.java to test
> getCurrentThreadAllocatedBytes as well as variations on
> getThreadAllocatedBytes(id). A submit repo job is in progress.
More information about the hotspot-gc-dev