Improve root set used by hat

Keith Randall keith.randall at gmail.com
Wed Oct 7 19:04:07 PDT 2009


Here's a simpler patch that never makes Roots for these static fields in the
first place:

--- com/sun/tools/hat/internal/model/JavaStatic.java
***************
*** 57,64 ****
              id = ((JavaObjectRef)value).getId();
          }
          value = value.dereference(snapshot, field);
!         if (value.isHeapAllocated() &&
!             clazz.getLoader() == snapshot.getNullThing()) { // static
fields are only roots if they are in classes loaded by the root classloader.
              JavaHeapObject ho = (JavaHeapObject) value;
              String s = "Static reference from " + clazz.getName()
                         + "." + field.getName();
--- 57,63 ----
              id = ((JavaObjectRef)value).getId();
          }
          value = value.dereference(snapshot, field);
!         if (value.isHeapAllocated()) {
              JavaHeapObject ho = (JavaHeapObject) value;
              String s = "Static reference from " + clazz.getName()
                         + "." + field.getName();


On Wed, Oct 7, 2009 at 1:49 AM, Alan Bateman <Alan.Bateman at sun.com> wrote:

> A. Sundararajan wrote:
>
>> I agree. Static fields of classes loaded by non-bootstrap loaders should
>> not be part of root set.
>>
>> PS. I am not sure  if this is a bug with hat or with heap dumpers (the
>> hotspot built-in dumper and SA's dumper). I don't remember how "roots" is
>> filled. May be, these static fields should not be flagged as roots?
>>
>> -Sundar
>>
> At least for the built-in heap dumper, static fields aren't generated as
> roots (instead it's system classes and temporary placeholders in the
> dictionary that are generated to the dump as "sticky classes", to use a
> HPROF term). So I suspect this is more likely to be a jhat issue.
>
> -Alan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20091007/df985f9a/attachment.html 


More information about the serviceability-dev mailing list