On Fri, 26 Jan 2024 08:27:41 GMT, Alan Bateman <al...@openjdk.org> wrote:
>>> BB currently opens the jdk.internal.misc.Unsafe class to a module on a >>> seperate class loader that is not reachable outside an agent, using >>> Instrumentation. >> >> @raphw, may I ask how? Is there any sample code that is not connected to the >> BB code base with its nested classes, interfaces etc.? I know, that caters >> nicely to the fluent DSL BB provides, but to me it is just a maze of code >> that is hard to comprehend. > >> > BB currently opens the jdk.internal.misc.Unsafe class to a module on a >> > seperate class loader that is not reachable outside an agent, using >> > Instrumentation. >> >> @raphw, may I ask how? Is there any sample code that is not connected to the >> BB code base with its nested classes, interfaces etc.? I know, that caters >> nicely to the fluent DSL BB provides, but to me it is just a maze of code >> that is hard to comprehend. > > Agents should not be using the JDK's internal Unsafe. This needs to said in > the strongest possible terms. > > For the discussion, it would be useful to provide a brief summary on what > AspectJ is trying to do with this weaving. This PR was originally about load > time instrumentation defining auxiliary classes, as you might get at compile > time when compiling a source file containing more than one class.. I can't > tell from your comments here or in Eclipse 546305 if this is relevant to what > you are trying to do or not. It may even be better to start a new discussion > on serviceability-dev. > @AlanBateman, the AspectJ weaving agent creates an auxiliary class to > implement an "around" advice for a method, i.e. a method execution is > intercepted and the user has options to do something before optionally > calling the target method and then do something afterwards too. In doing so, > she can modify method arguments before calling the target method, then also > modify the result. Instead of calling the target method, she may also return > a result of the expected type instead. Before, after or instead of calling > the target method, she can also throw an exception. > > The target class is transformed in such a way to call the auxiliary class, > which necessitates the the aux-class to be in the same classloader as the > target class. But because the aux-class is defined while the target class is > still being transformed during class-loading, we cannot have any look-up > instance pointinmg to it yet. Right, this is what JDK-8200559 was originally about. Mandy and I discussed it several times and load-time instrumentation that defines auxiliary classes in the same run-time package is a reasonable addition. The more general request for an "unrestricted defineClass" conflicts with several ongoing efforts so we've had to kick that to touch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911716353
