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

Peter Levart peter.levart at gmail.com
Wed May 20 08:22:28 UTC 2015


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



More information about the core-libs-dev mailing list