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.samers...@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.
