RFR: 8200559: Java agents doing instrumentation need a means to define auxilary classes

[forax at univ-mlv.fr]

> De: "Rafael Winterhalter" <rafael.wth at gmail.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Rafael Winterhalter" <winterhalter at openjdk.java.net>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>, "serviceability-dev"
> <serviceability-dev at openjdk.java.net>
> Envoyé: Vendredi 16 Avril 2021 18:41:26
> Objet: Re: RFR: 8200559: Java agents doing instrumentation need a means to
> define auxilary classes

> This would be a problem, however. Since there is currently no official way of
> defining a class, and since Java agents do not control the class loading order,
> if a class was loaded for the first time, you could for example not add a field
> with a type of an auxiliary class that you had planned to inject. A class being
> loaded is normally the first opportunity for a Java agent and if no witness
> class is available at this point, using a method handle is no option. Since it
> is difficult to know if such a witness class is available in the general case,
> it would also add quite a performance and managerial toll on agent authors. I
> would hope that an API equally convenient to today's unsafe options could be
> added.

I was thinking about adding a dummy class in the package you want to load classes. 

Anyway, you can also call ClassLoader.defineClass directly. Put the code that calls defineClass in a module and use Instrumentation.redefineModule() to open java.base to this module. 

Rémi 

> Am Fr., 16. Apr. 2021 um 18:35 Uhr schrieb < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] >:

>>> De: "Rafael Winterhalter" < [ mailto:rafael.wth at gmail.com | rafael.wth at gmail.com
>>> ] >
>>> À: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >
>>> Cc: "Rafael Winterhalter" < [ mailto:winterhalter at openjdk.java.net |
>>> winterhalter at openjdk.java.net ] >, "core-libs-dev" < [
>>> mailto:core-libs-dev at openjdk.java.net | core-libs-dev at openjdk.java.net ] >,
>>> "serviceability-dev" < [ mailto:serviceability-dev at openjdk.java.net |
>>> serviceability-dev at openjdk.java.net ] >
>>> Envoyé: Vendredi 16 Avril 2021 18:27:46
>>> Objet: Re: RFR: 8200559: Java agents doing instrumentation need a means to
>>> define auxilary classes

>>> Not by my understanding. A suitable lookup requires a loaded class for the
>>> package. A Java agent might however not provide a handle for a class that is
>>> not yet loaded. Or how would you suggest to approach this ?

>> yes, you need a witness class in the package you want to define a new class.
>> Apart if you load classes in the unamed module, you can not load a class in a
>> non existing package anyway (apart if you generate your own module-info),
>> so you need at least a dummy class to define a package, so you can use it to get
>> a Lookup.

>> Rémi

>>> Am Fr., 16. Apr. 2021 um 16:21 Uhr schrieb Remi Forax < [
>>> mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >:

>>>> ----- Mail original -----
>>>>> De: "Rafael Winterhalter" < [ mailto:winterhalter at openjdk.java.net |
>>>> > winterhalter at openjdk.java.net ] >
>>>>> À: "core-libs-dev" < [ mailto:core-libs-dev at openjdk.java.net |
>>>>> core-libs-dev at openjdk.java.net ] >, "serviceability-dev" < [
>>>>> mailto:serviceability-dev at openjdk.java.net |
>>>> > serviceability-dev at openjdk.java.net ] >
>>>> > Envoyé: Vendredi 16 Avril 2021 15:52:07
>>>>> Objet: RFR: 8200559: Java agents doing instrumentation need a means to define
>>>> > auxilary classes

>>>> > To allow agents the definition of auxiliary classes, an API is needed to allow
>>>> > this. Currently, this is often achieved by using `sun.misc.Unsafe` or
>>>> > `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from
>>>> > `sun.misc.Unsafe`.

>>>> You can already use Lookup.defineClass() + privateLookupIn() +
>>>> Instrumentation.redefineModule() for that ?

>>>> Rémi


>>>> > -------------

>>>> > Commit messages:
>>>> > - 8200559: Java agents doing instrumentation need a means to define auxiliary
>>>> > classes

>>>>> Changes: [ https://git.openjdk.java.net/jdk/pull/3546/files |
>>>> > https://git.openjdk.java.net/jdk/pull/3546/files ]
>>>>> Webrev: [ https://webrevs.openjdk.java.net/?repo=jdk&pr=3546&range=00 |
>>>> > https://webrevs.openjdk.java.net/?repo=jdk&pr=3546&range=00 ]
>>>>> Issue: [ https://bugs.openjdk.java.net/browse/JDK-8200559 |
>>>> > https://bugs.openjdk.java.net/browse/JDK-8200559 ]
>>>> > Stats: 185 lines in 4 files changed: 185 ins; 0 del; 0 mod
>>>>> Patch: [ https://git.openjdk.java.net/jdk/pull/3546.diff |
>>>> > https://git.openjdk.java.net/jdk/pull/3546.diff ]
>>>>> Fetch: git fetch [ https://git.openjdk.java.net/jdk |
>>>> > https://git.openjdk.java.net/jdk ] pull/3546/head:pull/3546

>>>>> PR: [ https://git.openjdk.java.net/jdk/pull/3546 |
>>>> > https://git.openjdk.java.net/jdk/pull/3546 ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210416/7b889bfe/attachment-0001.htm>