RFR(M,v7): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo (original) (raw)

Dmitry Samersoff dmitry.samersoff at oracle.com
Wed May 20 12:11:57 UTC 2015

Peter,

I see diagnostic commands mostly format their output in native code. > But for some of them (like this finalizer histogram) it would be nice > to have a Java wrapper for hotspot's outputStream.

I love to have an ability to write pure-java DCMD's without touching of hotspot code but it's a long term goal, out of scope of this fix.

Just a wrapper around hotspot output stream has a couple of underwear complications around memory management and error handling, so it should be a separate project.

-Dmitry

On 2015-05-20 14:44, Peter Levart wrote:

On 05/20/2015 10:42 AM, Dmitry Samersoff wrote: Peter,

What about creating a special package-private java.lang.ref.DiagnosticCommands class I'm not quite happy with current printFinalizationQueue method - love to have a way to print directly to DCMD pipe from Java rather than return a huge string to VM. But lang.ref.Finalizer is cached by VM (see SystemDictionary::Finalizerklass()) and is known as special i.e. check-when-modify-hotspot class. We don't plan to expand this DCMD so I'm reluctant to create a separate class for one simple static method - it adds extra cost of compiling/loading/care. -Dmitry Ok then. I see diagnostic commands mostly format their output in native code. But for some of them (like this finalizer histogram) it would be nice to have a Java wrapper for hotspot's outputStream. It wouldn't be difficult to create such a class with JNI bindings, but where should one put it? Into which module? Otherwise, the simplest unformated data structure to return from such a method is an Object[] where you have String/Integer objects intermingled in pairs. Returning a Map.Entry<String,int[]>[] is already more complicated to iterate and navigate in native code. Map<String,int[]> even more so. Regards, Peter On 2015-05-20 11:22, Peter Levart wrote:

On 05/20/2015 08:51 AM, Dmitry Samersoff wrote: Mandy,

However I have trouble for Finalizer.printFinalizationQueue method that doesn’t belong there. What are the other alternatives you have explored? Other alternatives could be to do all hashing/sorting/printing on native layer i.e. implement printFinalizationQueue inside VM. Both options has pros and cons - Java based solution requires less JNI calls and better readable but takes more memory. It might be better to return an array of Map.Entry<String, int[]> objects to VM rather than one huge string. -Dmitry Hi Dmitry, What about creating a special package-private java.lang.ref.DiagnosticCommands class which is then used as the home of static printFinalizationQueue method (and possible future diagnostic commands methods in the package). You could then expose a static package-private method from Finalizer: static void forEachEnqueued(Consumer> action) { queue.forEach(action); } ...and use it to implement the printFinalizationQueue. Regards, Peter

On 2015-05-20 05:54, Mandy Chung wrote: On May 18, 2015, at 5:17 AM, Dmitry Samersoff <dmitry.samersoff at oracle.com <mailto:dmitry.samersoff at oracle.com>> wrote: Please review updated version of the fix: http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.07/ Most important part of the fix provided by Peter Levart, so all credentials belongs to him. My apology for being late to the review. The subject line doesn’t catch my attention early enough :) I have to do further detail review tomorrow or so to follow the discussion and closely inspect the reference implementation. Just to give you a quick comment. I’m okay to add ReferenceQueue.forEach method at the first glance. However I have trouble for Finalizer.printFinalizationQueue method that doesn’t belong there. What are the other alternatives you have explored? Mandy

-- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia

More information about the core-libs-dev mailing list