ThreadMXBean::getCurrentThreadAllocatedBytes

[Markus Gaisbauer]

Is there a chance that getCurrentThreadAllocatedBytes could still make it
into Java 11? Since it is a new API, and no existing code would change, at
least it seems low risk.

https://bugs.openjdk.java.net/browse/JDK-8207266 is currently unassigned.
What would be the next step?

Markus

On Mon, Jul 16, 2018 at 10:28 PM Hohensee, Paul <hohensee at amazon.com> wrote:

> 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> 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/20180815/07c5fc12/attachment.html>