[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
From:       Staffan Larsen <staffan.larsen () oracle ! com>
Date:       2015-06-01 7:18:51
Message-ID: 37227441-B016-4A9A-B9CA-BE100E992C9A () oracle ! com
[Download RAW message or body]

Dmitry,

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

Thanks,
/Staffan

> On 31 maj 2015, at 13:43, Dmitry Samersoff <dmitry.samersoff@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.


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