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 <hohen...@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.gaisba...@gmail.com> > *Date: *Monday, July 16, 2018 at 12:50 PM > *To: *"Hohensee, Paul" <hohen...@amazon.com> > *Cc: *"daniel.daughe...@oracle.com" <daniel.daughe...@oracle.com>, " > serviceability-dev@openjdk.java.net" <serviceability-dev@openjdk.java.net>, > "erik.osterl...@oracle.com" <erik.osterl...@oracle.com>, " > robbin....@oracle.com" <robbin....@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.gaisba...@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 > >
