> De: "Rafael Winterhalter" <rafael....@gmail.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Rafael Winterhalter" <winterhal...@openjdk.java.net>, "core-libs-dev" > <core-libs-dev@openjdk.java.net>, "serviceability-dev" > <serviceability-...@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:fo...@univ-mlv.fr | > fo...@univ-mlv.fr ] >: >>> De: "Rafael Winterhalter" < [ mailto:rafael....@gmail.com | >>> rafael....@gmail.com >>> ] > >>> À: "Remi Forax" < [ mailto:fo...@univ-mlv.fr | fo...@univ-mlv.fr ] > >>> Cc: "Rafael Winterhalter" < [ mailto:winterhal...@openjdk.java.net | >>> winterhal...@openjdk.java.net ] >, "core-libs-dev" < [ >>> mailto:core-libs-dev@openjdk.java.net | core-libs-dev@openjdk.java.net ] >, >>> "serviceability-dev" < [ mailto:serviceability-...@openjdk.java.net | >>> serviceability-...@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:fo...@univ-mlv.fr | fo...@univ-mlv.fr ] >: >>>> ----- Mail original ----- >>>>> De: "Rafael Winterhalter" < [ mailto:winterhal...@openjdk.java.net | >>>> > winterhal...@openjdk.java.net ] > >>>>> À: "core-libs-dev" < [ mailto:core-libs-dev@openjdk.java.net | >>>>> core-libs-dev@openjdk.java.net ] >, "serviceability-dev" < [ >>>>> mailto:serviceability-...@openjdk.java.net | >>>> > serviceability-...@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 ]
