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

Dmitry Samersoff dmitry.samersoff at oracle.com
Tue Jun 2 11:12:48 UTC 2015


Staffan,

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

Done. Please, see

http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.11

I put the function int get_filed_offset_by_name(Symbol*,Symbol*) to
oop.inline.hpp leaving a room for further cleanup because I found couple
of places in hotspot that implements mostly similar functionality.

-Dmitry

On 2015-06-01 10:18, Staffan Larsen wrote:
> 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.
> 


-- 
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 hotspot-gc-dev mailing list