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

Staffan Larsen staffan.larsen at oracle.com
Mon Jun 1 07:18:51 UTC 2015


Instead of hardcoding the field offsets, you can use InstanceKlass::find_field and fieldDescriptor::offset to find the offset at runtime. 


> On 31 maj 2015, at 13:43, Dmitry Samersoff <dmitry.samersoff at oracle.com> wrote:
> Everyone,
> Please take a look at new version of the fix.
> http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.10/
> Changes (to previous version) are in
> Finalizer.java and diagnosticCommand.cpp
> This version copy data from Map.Entry<> to array of
> FinalizerHistogramEntry instances then,
> VM prints content of this array.
> -Dmitry
> On 2015-05-28 21:06, Mandy Chung wrote:
>> On 05/28/2015 07:35 AM, Peter Levart wrote:
>>> Hi Mandy,
>>> On 05/27/2015 03:32 PM, Mandy Chung wrote:
>>>> 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.
>> Do you happen to know what libraries are the major contributors to these
>> millions of finalizers?
>> It has been strongly recommended to avoid finalizers (see Effective Java
>> Item 7).   I'm not surprised that existing code is still using
>> finalizers while we should really encourage them to migrate away from it.
>>> 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).
>> I also prefer writing in Java and writing less native code (much
>> simplified).  It's an interface that we have to agree upon and keep it
>> simple.  Having the returned Object[] as alternate String and int[] is a
>> reasonable compromise.
>> ReferenceQueue.java - you can move @SuppressWarning from the method to
>> just the field variable "rn"
>>     @SuppressWarnings("unchecked")
>>     Reference<? extends T> rn = r.next;
>> Finalizer.java
>>     It's better to rename printFinalizationQueue as it inspects the
>> finalizer reference queue (maybe getFinalizerHistogram?).  Can you move
>> this method to the end of this class and add the comment saying that
>> this is invoked by VM for jcmd -finalizerinfo support and @return to
>> describe the returned content.  I also think you can remove
>> @SuppressWarnings for this method.
>> Mandy
> -- 
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.

More information about the core-libs-dev mailing list