JVMTI and instrumentation

[Michael Rasmussen]

On 3 December 2015 at 14:08, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> I'm guessing you are working around some of this by adding to or
> patching java.base.
> (...)
> Is -Xpatch working for you? Can you use this in conjunction with
> -agentlib/-agentpath until there is further progress in this area.

Correct, at the moment I'm patching java.base, adding the support classes
that are used during primordial phase so they appear as part of java.base

As mentioned earlier, the purpose of our native agent is basically to
simplify all this for the user, so it takes care of generating the patch
(when needed), adding the patch to the VM, so the patched classes are
loaded, and finally attach a javaagent, which then does the actual
work for the rest of the uptime.
Having to tell the user to just add an -agentpath JVM option, is simpler
than having detailed instructions that differs from JVM version to JVM
version, or even vendor to vendor.

Doing the individual steps, by building the patch, and then running
with -javaagent and -Xpatch (tested with b86), I am currently able to
get this running. I can mention that the project in question is JRebel,
and with the above steps, I can successfully reload classes.

Also, a side note:
My comments in the original mail regarding AddToBootstrapClassLoaderSearch
not working as indended, seemed to stem from it being corrupted because
I was changing the "sun.boot.class.path" property as well. A quick glance
in the code made it look like it was an issue with an internal index that
pointed to where in the boot class path new stuff should be appended to,
but changing the property directly didn't update the index, so it got
corrupted when both were called -- but since that property is no longer
available that issue is kind of moot now. Although, I haven't tested or
looking into if changing the "jdk.boot.class.path.append" property directly
have the same corruption issues?

/Michael