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

[Alexander Kriegisch]

On Thu, 25 Jan 2024 13:33:10 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Requiring such an API opens the module to anybody, though, punching a hole into the module boundary.
>> 
>> 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. This also caters the need to inject utility classes from an agent before any class file transformer is triggered, to maintain a well-defined life-cycle.
>> 
>> Of course I'd prefer if there was a way to resolve a lookup from Instrumentation for a given class loader and for example a package-info class, however rendering the issue that packages might not exist (yet).
>
>> Requiring such an API opens the module to anybody, though, punching a hole into the module boundary.
> 
> How so? Any module created to print Lookups can easily rely on a shared secret to secure the API. Byteman employs a non-null Instrumentation object (a value which any agent ought to keep secret). However, it could just as easily have employed an arbitrary bit length hash key. The key can be used to initialize a module-private static long[] field of an API implementation class generated into the module i.e. the hole can actually be a keyhole in the shape of a key known only to the API client and implementation.

Thanks @adinn, @raphw for your feedback. I am not pretending to fully understand what you just explained or to have the slightest clue how to do what you suggested, but reading it for the second time since yesterday seems to make it clearer already. I guess, I cannot hope for a how-to with sample code. But I can immerse myself into the topic some more next time I have a vacant time box and look at Byte Buddy and Byteman source code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911208017