JOL object header information

[serkan özal]

Hi Aleksey,
As you said SA is specific to its shipped JVM version.So I create a composite "sa-jdi.jar" that containts all sa-jdi jar files fro Java 6, 7 and 8 in different sub directories. Then I use them with a JVM version aware custom classloader as here:
https://github.com/serkan-ozal/jillegal/blob/master/src/main/java/tr/com/serkanozal/jillegal/util/compressedoops/hotspot/HotspotJvmAwareSaJdiClassLoader.java
https://github.com/serkan-ozal/jillegal/blob/master/src/main/java/tr/com/serkanozal/jillegal/util/compressedoops/hotspot/HotspotServiceabilityAgentBasedCompressedOopsInfoProvider.java
Currently, it handles only major versions of JDK distribution, not minors.
WDYT about this solution/workaround ?
I didn't send a patch for this stuff to JOL, since I am still not sure about is this approach is right or not ?
Regards.
--
Serkan ÖZAL 

> Date: Mon, 15 Dec 2014 17:10:38 +0300
> From: aleksey.shipilev at oracle.com
> To: jol-dev at openjdk.java.net
> Subject: Re: JOL object header information
> 
> Hi Rafael,
> 
> On 15.12.2014 16:03, Rafael Winterhalter wrote:
> > To be certain, I wrote a minor extension to JOL which allows to print more
> > detailed header information by something like:
> > 
> > ClassLayout layout = ClassLayout.parseClass(Foo.class).withDetailedHeader();
> > 
> > where each header value is then mapped to its content in JOL's tabular
> > overview instead of just printing "(object header)". My (minor)
> > modification can found here:
> > https://gist.github.com/raphw/7345bae62abd424fb040
> 
> Thanks! Not sure it belongs in JOL codebase though, see below:
> 
> > However, it seems like the layout JOL retrieves diverges from the layout
> > that is described in markOop.hpp - As one exemplary divergence, I found
> > that the identity hash code seems to reach one bit further than the
> > described 31 bit, e.g. when running
> 
> JOL deliberately back away from trying to parse the object metadata,
> because that would diverge from the current VM layout without warning.
> It is scary to replicate something written out in the HotSpot comments
> into the otherwise VM oblivious tools.
> 
> I still think the right way to do this is to involve the Serviceability
> Agent that ships with each VM version, and follows/queries the VM
> internals:
> http://mail.openjdk.java.net/pipermail/jol-dev/2014-September/000016.html
> 
> I admit, using the SA is PITA. For one, you can not attach to yourself,
> and therefore you need to fork out the VM to get this kind of data.
> Still, this is doable, and is more maintainable than trying to keep the
> JOL code in sync.
> 
> That also highlights the route to follow-up with hashcode sizes and
> such: SA is the source of truth, not the HotSpot comments.
> 
> Thanks,
> -Aleksey.
> 
>