JVMTI and instrumentation

[Alan Bateman]

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 
or -Xbootclasspath/a.

Is -Xpatch working for you? Can you use this in conjunction with 
-agentlib/-agentpath until there is further progress in this area.

-Alan