JVMTI and instrumentation

[Michael Rasmussen]

On 2 December 2015 at 11:45, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 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).

That is basically the case, I'm trying to avoid having to add -Xpatch etc
arguments to the commandline, so I only have one argument (-agentlib/path)
and then the native code takes care of everything. The idea is to generate
the patch directory from the native code and then tell the VM to load from
there, which has been working fine so far in JDK6-8. Doing it like that,
greatly simplifies it for the user, not having to add weird arguments to
the JVM, as well as not having to run a seperate process first to generate
the patch.

A further question for JVMTI in this regard:
ClassFileLoadHook callback seems to not be called before VMInit anymore?
I know the documentation is vague on this point, only specifying that
it may be sent in primordial phase; but for previous JDK versions, this
event is sent for all classes being loaded, even java.lang.Object; where
as on jdk9, the first class I get event for, is what I'm trying to load
in my VMInit callback.



> 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.

Yes, when being redefined; but for the initial load/transformation, this
argument is null, since the class obviously hasn't been defined yet, but
the module in which it's being loaded should be (disregarding java.base
classes being loaded before module system is initialized, since this is
before premain, thus before you can add a instrumentation transformer).

/Michael

On 2 December 2015 at 11:45, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 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