7153375 "jmap -histo" should output a unique identifier with each line

[Krystal Mok]

Hi Shinji,

Comments inline:

On Fri, Mar 23, 2012 at 9:44 AM, Takao, Shinji
<takao.shinji at oss.ntt.co.jp>wrote:

> Hi Kris,
>
> Thank you for your suggestions.
> Yes, as you said, the hashCode() merely returns an address...
>
> 54     public int hashCode() {
> 55         // FIXME: suggestions on a better hash code?
> 56         return (int) addr;
> 57     }
>
> You mean, so to speak, if GCs (with compaction?) on
> perm gen never happen, this patch will work better,
> and removing perm gen will be bound to the same situation?
>
After the perm-gen removal work is complete, Klasses will no longer be
subject to GC, and I suppose they shouldn't have to move during their
lifetime.

Disabling class unloading gives you something similar, but not quite there
yet.

If you're on JDK6, HotSpot VM stores interned Strings (and the associated
char arrays) in the perm-gen. If perm-gen fills up, it'll trigger a full GC
which will collect the whole GC heap (including the perm-gen), and move
things around. Even if you use -Xnoclassgc or -XX:-ClassUnloading, it
doesn't mean perm-gen is not collected; it only ensures that all classes,
once loaded, never gets unloaded. When you have Strings and char[]'s in the
perm-gen, and when some of them are found to be dead in a full GC, the
Klasses are bound to be moved.

On JDK7+, a lot of the stuff have moved away from perm-gen already.
Interned Strings have moved back to normal Java heap, Symbols have moved
outside the GC heap. So disabling class unloading gives a better chance of
getting the Klasses "pinned", but that's not a hard guarantee.


> If you are planning to do so, I will wait for it.
>
> Ehehe...I don't work for Oracle and I'm not in a part of the perm-gen
removal project. Jon Masamitsu is the guy to talk to. [1]


> However, I wonder whether we can utilize the identity hash
> or not. I guess hashing the java mirror every time
> might cause a performance issue, but, for exapmle, a java
> option to switch on the function to do so seems useful,,,
> especially when we are in development phases of java programs.
>
> Identity hash code for Java objects are calculated at most once per
object; it's either never used (which is never calculated), or calculated
just once and cached, either in the object header (the mark word) or in a
lock record. Using the identity hash code is usually a low cost operation.
The bad news is, SA can't calculate the identity hash code for a Java
object on its own; if an object was never asked for its identity hash code
during the normal run, then it would have been never calculated by the VM,
and then SA will just return 0 for that case.

In other words, in order to able to use the identity hash code of a
java.lang.Class for tracking its identity in SA, every Class instance has
to be hash'd (by invoking its hashCode() or by System.identityHashCode()),
and that'll need some effort. The easiest way may be using a Java agent to
force hash all loaded classes, and new loaded classes as they're loaded.
But that's not a clear win. Using the identity hash code has other
implications. One of them is that the auxiliary memory that the GC needs
may grow bigger if you hash a lot of objects this way. Nakamura-san's blog
post demonstrates this behavior [2]; I'm sure you can read it :-)

I'm sorry but I haven't come up with any good way of tracking a class's
identity, yet. If only there's a way to track the identity of a class
loader...

- Kris

[1]:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-March/005441.html
[2]: http://www.nminoru.jp/~nminoru/diary/2012/02.html#20120218p1


> Thank you,
> Shinji
>
>
> > Oops, missed the link in the last mail:
> > [1]:
> > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/a142c
>
> 661f6b1/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.ja>
> va
> >
> >
> > On Thu, Mar 22, 2012 at 4:50 PM, Krystal Mok
> > <rednaxelafx at gmail.com> wrote:
> >
> >
> >       Hi Shinji,
> >
> >       This patch should work better after the work on
> > Permanent Generation removal is integrated into mainstream.
> > For now, though, it's not guaranteed to work: Klasses are
> > subject to GC, which could move around from time to time.
> >
> >       You're using hashCode() from the Klass, whichi
> > ultimately boils down to the value of an address in the
> > current implementation of SA. See [1] for example. It may
> > change from run to run if the object is moving.
> >
> >       It might have been better to use the identity hash code
> > of the Java mirror (the java.lang.Class instance) as the
> > "identifier". Too bad, that doesn't work with SA either; if
> > the Java mirror was never hash'd, SA won't be able to
> > calculate its identity hash code -- which is the case most of
> > the time.
> >
> >       - Kris
> >
> >       On Thu, Mar 22, 2012 at 3:50 PM, Takao, Shinji
> > <takao.shinji at oss.ntt.co.jp> wrote:
> >
> >
> >               Dear all,
> >
> >               As a trouble shooter of java programs, I have
> > been examinig
> >               heap object histograms for tracking down memory
> > leaks, and
> >               found an inconvenience in the histograms output
> > by jmap (-F) -histo.
> >               Please see the CR 7153375 for details.
> >
> >               And, I would like to show a quick fix for that.
> >               Please see the attached file (for openjdk8b27 hospot).
> >               I am not sure if it is the most appropriate way
> > to fix that,
> >               however, I am glad if it will be a meaningful
> > starting point.
> >
> >               I am quite new to this ML, so I appreciate your
> > assistance.
> >
> >               Regards,
> >               Shinji
> >
> >
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120323/dfd5fcd3/attachment.html