JOL object header information

[Aleksey Shipilev]

Hi Serkan,

On 15.12.2014 17:17, serkan özal wrote:
> 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:

IDK what license those files are, and therefore I haven't looked there,
but I dig what you do.

> WDYT about this solution/workaround ?

I think that's the right route for at least compressed oops stuff.

Parsing object header would probably require running the actual SA code,
because the changing object header format will probably require modified
parsing code.

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

I do think that we need to ask the user to provide us with the concrete
sa-jdi.jar, load it, and either pull the constants from there, or even
run the SA code from there. We may even look around in $JAVA_HOME for
sa-jdi.jar.

Shipping sa-jdi.jar for "major" versions defies the purpose of having SA
to begin with: provide the interface to *current* VM, knowing SA is
synced up with all the mundane details of current VM code. It is wishful
thinking (and a maintenance nightmare) to presume the internal layout
would change only in major versions.

Thanks,
-Aleksey.