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
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 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 serviceability-dev
mailing list