ThreadMXBean::getCurrentThreadAllocatedBytes

[Markus Gaisbauer]

 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/f2b82f2b/attachment.html>