JOL object header information

[serkan özal]

Hi Aleksey,
So +1 from my side for
1. Try to find SA jar in the classpath. (User may provide the sa-jdi.jar)    1.1. If couldn't be found, look at $JAVA_HOME/lib/sa-jdi.jar (as you offered)        1.1.1. If SA jar is available at there, use it        1.1.2. Throw exception, or display a warning message that some features of JOL is not supported because of non-existing SA library. Or use compisite sa-jdi.jar via JVM version aware classloader by printing a log message about because of minor version changes, somethings may be broken.    1.2. Use SA from classpath.2. Create a new process to attach current process with SA. (If current processes attaches itself as Instrumentation agent, current process hangs forever, because when SA agent is attached to a JVM process, JVM suspends attached process)3. Get data from current process with newly created process.4. Return result to current process (caller process) via pipe between processes (Input/Output Stream)
WDYT ?
Regards.

> Date: Mon, 15 Dec 2014 17:28:41 +0300
> From: aleksey.shipilev at oracle.com
> To: serkanozal86 at hotmail.com; jol-dev at openjdk.java.net
> Subject: Re: JOL object header information
> 
> 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.
>