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

[Takao, Shinji]

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