JVMTI and instrumentation

[Alan Bateman]

On 01/12/2015 22:08, Michael Rasmussen wrote:
> Are there any plans to support setting -Xpatch from JVMTI in OnLoad
> phase, or even setting the "jdk.launcher.patchdirs" system property,
> and have it take effect? (Also applies to the other module -X options)
>
> Agent_OnLoad should is still so early in the process that it should
> be possible to influence these things; but I assume agent support has
> been a very low priority?
>
>
> I'm trying to patch java.base, so trying to influence where classes are
> loaded from before module system is initialized in System.initPhase2()
>
> Tried setting "jdk.launcher.patchdirs", but got a JVMTI error that
> it wasn't available to set at that time, also tried adding -Xpatch,
> so the property was present, and then modifying it in OnLoad phase,
> but still didn't take effect (java.base classes were still loaded from
> original location, and not from patch location).

The JVM TI spec allows agents to change system properties in the OnLoad 
phase but it doesn't allow new properties to be added. So I assume the 
error you initially got was JVMTI_ERROR_NOT_AVAILABLE.

That said, you've discovered that java launcher communicates the value 
of -Xpatch to the VM via the undocumented/internal 
jdk.launcher.patchdirs property so if you have -Xpatch set on the 
command line then the agent can change that property value in the OnLoad 
phase. The problem, as you've found, is that this is after argument 
parsing where the -Xpatch handling for the boot loader is setup. You'll 
find that changing the value of this property in the OnLoad phase will 
set the patch directories for the modules defined to the app and 
extension class loaders, just not modules defined to the boot loader.

As to whether this a bug then I'm in two minds on this. Harold or Lois 
might want to jump in to say where it could be deferred to after the 
OnLoad phase. On the other hand, this is changing -Xpatch which doesn't 
seem a good idea and not intended.

Just to get more context, are you trying to avoid the -Xpatch option and 
have everything done by the agent so it's just a -agentlib option? If 
there really is a need for this then it might be something for a JVM TI 
extension function to add to the patch directories (adding so that it 
would work with multiple agents).

>
>
> Also, the JVMTI function AddToBootstrapClassLoaderSearch seems to be
> not functioning correctly at the moment. I'm currently using it to add
> the java part of my agent to the bootclasspath, for it to be loaded,
> but with current build of jigsaw, this doesn't seem to have the desired
> effect, calling it, adding my jar file there, doesn't allow me to
> find any classes present in the jar file using FindClass, even though
> I can see that it is being used (-verbose:class shows jar is opened)
I'm not aware of any issues here and I don't see any test failures in 
this area.

What package are the classes in? Just wondering if it's a package of a 
module defined to the boot loader, in which case it is correct behavior 
to ignore the classes in the JAR file.


>
> One further question; any plans of expanding java.lang.instrument.
> ClassFileTransformer, so the transform method has a Module argument,
> possibly via a default method, calling the existing transform method?
>
The transform method gives you the Class<?> of the class being redefined 
so you should be able to invoke getModule() on this to get the module.

-Alan