JVMTI and instrumentation
Alan.Bateman at oracle.com
Thu Dec 3 12:08:52 UTC 2015
On 03/12/2015 11:31, Michael Rasmussen wrote:
> Well, you've always had to be very careful loading classes before VMInit,
> you had to be really careful not to use things that wasn't initialized
> yet. I don't see why it was felt neccesary to completely block the CFLM
> events for these classes, making it hard to fully instrument the bootstrap
> classes without having to do it in two passes, and supplying -Xpatch.
> Also, last I checked, when java.base is defined in the VM, it's verified
> that only packages from java.base has been defined so far, and if not it
> is a fatal error; so even if someone tried to load a class outside of
> java.base, that verification would kick in, and the VM would halt.
> "Agents can use GetLoadedClasses function to generate the missed events"
> doesn't really solve the problem. Yes, you can retransform the classes
> afterwards, but that limits you to only change method bodies, thus cannot
> add members to the classes.
As I said, I think will be possible once there is support for "module
aware" agents. That piece just isn't there yet. It may require a new
capability or maybe a new JVM TI phase, it will minimally require at
least some specification changes. A module aware agent should be able to
deal with CFLH events for classes loaded early in the startup but
existing agents may not -- consider an agent that uses the CFLH to
instrument code today to call into its own supporting library. Even if
the supporting class could be loaded then it will fail immediately
because it won't be able to link to its super-type, not even
java.lang.Object because java.base has no exported packages in early
startup. I'm guessing you are working around some of this by adding to
or patching java.base.
> Considering you also recently removed the system property "sun.boot.class
> .path" (which is now live in the b94 build that just became available for
> download), it would be very appreciated if an option were added back to
> the JVM TI, so we have some way of either telling the VM to use this
> patch dir/jar/jimage, and also be able to get CFLH events for classes
> being loaded during primordial phase as well.
sun.boot.class.path is finally removed. It's value has been useless for
a long time but the actual removal required several steps. The removal
of this property shouldn't impact JVM TI AddToBootstrapClassLoaderSearch
Is -Xpatch working for you? Can you use this in conjunction with
-agentlib/-agentpath until there is further progress in this area.
More information about the jigsaw-dev