Hi Kris,
Thank you for your suggestive comment.
I still have some unclear points, however, I understand
we have faced some difficulties to guarantee consistent
identity to the Klasses.
Both the perm-gen story and the GC-requiring memory story are
very interesting. I also found some interesting information
in your references (Yes, I could read the blog entry :-)
I hope we will be able to keep in touch.
Thank you,
Shinji
> Hi Shinji,
>
> Comments inline:
>
>
> On Fri, Mar 23, 2012 at 9:44 AM, Takao, Shinji
> <takao.shi...@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
> <http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/a142
> c
> 661f6b1/agent/src/share/classes/sun/jvm/hotspot/debugger/linux
> /LinuxAddress.ja> > va
> >
> >
> > On Thu, Mar 22, 2012 at 4:50 PM, Krystal Mok
> > <rednaxel...@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.shi...@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
> >
> >
> >
> >
> >
> >
>
>
>
>
>
