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

Peter Levart peter.levart at gmail.com
Thu May 28 14:35:14 UTC 2015

Hi Mandy,

On 05/27/2015 03:32 PM, Mandy Chung wrote:

On May 27, 2015, at 12:34 AM, Peter Levart <peter.levart at gmail.com> wrote:

Hi Dmitry, The jdk part looks OK (no great changes on this side from last webrev). Is there a particular reason why the return type of printFinalizayionQueue() method is Object[] and not Map.Entry<String, int[]>[] ? Taking it further - is it simpler to return String[] of all classnames including the duplicated ones and have the VM do the count? Are you concerned with the size of the String[]?

Yes, the histogram is much smaller than the list of all instances. There can be millions of instances waiting in finalizer queue, but only a few distinct classes. What could be done in Java to simplify things in native code but still not format the output is to convert the array of Map.Entry(s) into an Object[] array of alternating {String, int[], String, int[], .... }

Would this simplify native code for the price of a little extra work in Java? The sizes of old and new arrays are not big (# of distinct classes of finalizable objects in the queue).

For the hotspot part, I have a few reservations. You expect that the type of array elements will be HashMap.Node and that the key/value fields will be at fixed offsets. Is this even true for all architectures (32bit, 64bit +-UseCompressedOops)?

The type of HashMap entry is controlled by code in HashMap which has a long history of changes. Next time the implementation of HashMap changes, your code could break. Would it be possible to only use public API? To invoke methods on Map.Entry interface to obtain the key and value? Indeed, depending on the HashMap internal implementation is a bad idea. Mandy

Regards, Peter

Regards, Peter

On 05/26/2015 04:16 PM, Dmitry Samersoff wrote: Hi Everybody,

http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.09/ Please review updated webrev - printFinalizationQueue now returns and array of Map.Entry<String, int[])_ _and all formatting is done on VM side._ _-Dmitry_ _On 2015-05-21 02:07, Mandy Chung wrote:_ _On May 19, 2015, at 11:51 PM, Dmitry Samersoff_ _<dmitry.samersoff at oracle.com <mailto:dmitry.samersoff at oracle.com>> wrote:

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. The output and formatting should be done by jcmd. What you really need to get a peek on the finalizer queue and print the histogram. The VM has the heap histogram implementation. Have you considered leveraging that? 5: 1012 40480 java.lang.ref.Finalizer You can find the registered Finalizer instances. The downside is that icmd -finalizerinfo stops the world. I think it’s not unreasonable for this diagnostic command to be expensive like -heap command. Mandy

More information about the core-libs-dev mailing list