> De: "Rafael Winterhalter" <[email protected]> > À: "Remi Forax" <[email protected]> > Cc: "Rafael Winterhalter" <[email protected]>, "core-libs-dev" > <[email protected]>, "serviceability-dev" > <[email protected]> > 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:[email protected] | > [email protected] ] >: >>> De: "Rafael Winterhalter" < [ mailto:[email protected] | >>> [email protected] >>> ] > >>> À: "Remi Forax" < [ mailto:[email protected] | [email protected] ] > >>> Cc: "Rafael Winterhalter" < [ mailto:[email protected] | >>> [email protected] ] >, "core-libs-dev" < [ >>> mailto:[email protected] | [email protected] ] >, >>> "serviceability-dev" < [ mailto:[email protected] | >>> [email protected] ] > >>> 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:[email protected] | [email protected] ] >: >>>> ----- Mail original ----- >>>>> De: "Rafael Winterhalter" < [ mailto:[email protected] | >>>> > [email protected] ] > >>>>> À: "core-libs-dev" < [ mailto:[email protected] | >>>>> [email protected] ] >, "serviceability-dev" < [ >>>>> mailto:[email protected] | >>>> > [email protected] ] > >>>> > 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 ]
