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

[Alexander Kriegisch]

On Thu, 22 Apr 2021 21:50:45 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
>> 
>>   8200559: Java agents doing instrumentation need a means to define auxiliary classes
>
> Setting '-javaagent' is mainly an operations problem. Many build tools do
> not allow to declare a test dependency this way as the life cycles are not
> laid out for it, the internal repository location might be machine
> dependent, for example, and it's difficult to point to a specific folder
> and file reliably. In this case, I'd say it would be easier to specify a
> parameter in the sense of '-Djdk.attach.allowAttachSelf=true' as it is a
> static value. This would however only work for build tools that initiate a
> new VM for running tests which is not overly attractive for simple builds
> due to the overhead. Of course, Maven, Gradle and similar tools could set
> this parameter by default for their own JVM, that part is likely
> overcomeable but it will certainly create confusion about how to run
> libraries that are omnipresent today and make the JVM ecosystem less
> approachable.
> 
> What bothers me more is the tooling perspective for non-self-attached
> agents. For example, Aaeron offers a Java agent that adds plenty of debug
> logging to relevant lines of code. This affects method size and so forth,
> with Aaeron as a high-performance tool for banking and finance which is
> written very consciously with regards to the JIT, adding it directly was
> not feasible. Normally this logging is therefore thrown into a VM in
> retrospect, once an application starts failing and is already taken off the
> load balancer. For such a post-mortem, it would be rather annoying to
> realize that a JVM cannot be attached to with full capabilities if you
> forgot to set some flag. And often you did of course not consider the VM
> instance to fail, sometimes it takes months to get a JVM into this buggy
> state. This would be fairly inconvenient to face.
> 
> Therefore, I really hope that the dynamic attach from 'outside' the VM will
> survive without imposing limits and that rather the self-attachment problem
> will be targeted as such. When I mention a 'jdk.test' module in the Mockito
> context, I am also rather hoping to improve performance compared to
> convenience. The problem with '-Djdk.attach.allowAttachSelf=true' is that
> you still need to start a new VM etc. Since Java 9, running single tests
> with Mockito has for example become much slower compared to Java 8. Despite
> the startup performance improvements in the JVM. If one could avoid the
> location-bound '-javaagent:...', but get the Instrumentation instance
> directly, I think this would render a real performance improvement in
> actual execution scenarios.
> 
> Am Mi., 21. Apr. 2...

@raphw and everyone else, I apologise for commenting on an auto-closed issue, but I have no other way of contacting anyone, because neither do I have an account to comment on [JDK-8200559](https://bugs.openjdk.org/browse/JDK-8200559) nor am I a member in any other of the JDK development or "JVM rock star" circles for good reason: I simply have a very limited understanding of the topic at hand.

I am, however, the current maintainer and project lead of Eclipse AspectJ, and since JDK 16 the weaving agent requires `--add-opens java.base/java.lang=ALL-UNNAMED` along with `-javaagent:/path/to/aspectjweaver.jar` for the reason my predecessor Andy Clement has explained in [AspectJ bug 546305](https://bugs.eclipse.org/bugs/show_bug.cgi?id=546305), which is also linked to JDK-8200559. @mlchung was also involved in the discussion there.

Here, there has been a lot of discussion about Byte Buddy and Mockito. For AspectJ, which is widely used in the industry, not just in Spring but also in countless other productive contexts, there still is no solution to the problem that we need to instrument a target class to call an auxiliary class (generated by the agent) that does not have a Lookup object on the target class to begin with. The target class is still being transformed, i.e. not loaded yet, and hence we cannot look it up.

Is this case being considered? Can any of you advise me how to solve that problem? I am open for advice and hands-on chat, desktop sharing or audio/video call sessions.

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

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