[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR(M, v10): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo
From:       Dmitry Samersoff <dmitry.samersoff () oracle ! com>
Date:       2015-05-31 11:43:09
Message-ID: 556AF3CD.50900 () oracle ! com
[Download RAW message or body]

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.
[prev in list] [next in list] [prev in thread] [next in thread]