ThreadMXBean::getCurrentThreadAllocatedBytes

[Hohensee, Paul]

Given your requirements, and that my proposal is slower, yours is better. :)

There’s no technical reason why we can’t add what you’re asking for (and everyone who’s weighed in so far is in favor), but what do people think of adding the rest of the missing getCurrentThread* methods? These would be

getCurrentThreadInfo()
getCurrentThreadInfo(boolean lockedMonitors, boolean lockedSynchronizers)
getCurrentThreadInfo(int maxDepth)

Shall we add these to java.lang.management or com.sun.management? Since we’re doing major releases every 6 months, I’d say j.l.m, but it doesn’t matter to me one way or the other. Imo, getCurrentThreadAllocatedMemory() should go in com.sun.management because that’s where the *AllocatedMemory* methods are.

For getCurrentThreadAllocatedMemory(), you should add checks for isThreadAllocatedMemorySupported() and isThreadAllocatedMemoryEnabled().

Paul

From: Markus Gaisbauer <markus.gaisbauer at gmail.com>
Date: Monday, July 16, 2018 at 12:50 PM
To: "Hohensee, Paul" <hohensee at amazon.com>
Cc: "daniel.daugherty at oracle.com" <daniel.daugherty at oracle.com>, "serviceability-dev at openjdk.java.net" <serviceability-dev at openjdk.java.net>, "erik.osterlund at oracle.com" <erik.osterlund at oracle.com>, "robbin.ehn at oracle.com" <robbin.ehn at oracle.com>
Subject: Re: ThreadMXBean::getCurrentThreadAllocatedBytes

I saw Daniels comment too late, but using THREAD instead of JavaThread::current() indeed makes the new method again a bit simpler and faster (now 33 ns instead of 35 ns).

JVM_ENTRY(jlong, jmm_GetCurrentThreadAllocatedMemory(JNIEnv *env))
  return THREAD->cooked_allocated_bytes();
JVM_END

On Mon, Jul 16, 2018 at 9:42 PM Markus Gaisbauer <markus.gaisbauer at gmail.com<mailto:markus.gaisbauer at gmail.com>> wrote:
Hi,

Thank you for all the help.

​I added the code suggested by Paul and ran my small microbenchmark. The optimized getThreadAllocatedBytes now takes 57 ns if fed with the ID of the current thread. All calls that aren't for the current thread will be a bit slower. As far as I am concerned, adding this optimization probably doesn't hurt. In fact it would be awesome if this could be backported to Java 8.

But I am still strongly in favor of adding a special method just for the current thread:
* It is still faster (35 ns vs 57 ns)
* No heap memory is allocated by this method
* If this method is available, callers can always expect good (constant time) performance. On the other hand two versions would exist for getThreadAllocatedBytes. Library code would have to figure out somehow if this particular JVM has the slow or fast version. In my own use case, I would only want to get the metric if it is extremely fast. It's not worth the overhead, if it takes thousands of nanoseconds.

I wasn't aware of the existence of JavaThread::current() before. My new method in management.cpp could be simplified to this:

JVM_ENTRY(jlong, jmm_GetCurrentThreadAllocatedMemory(JNIEnv *env))
  return JavaThread::current()->cooked_allocated_bytes();
JVM_END

This code is not only simpler but also a bit faster. Each call now takes 35 ns instead of 37 ns.

Is there a technical reason why no new native methods should be added to ThreadImpl.java? I saw that getCurrentThreadCpuTime also uses this magic number 0 to indicate the current thread. Wouldn't it be cleaner to have two methods instead of using and checking a special number in Java/native code?

Best regards,
Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180716/86320dbd/attachment-0001.html>