RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

[Alan Bateman]

On Fri, 26 Jan 2024 08:27:41 GMT, Alan Bateman <alanb at 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