On Thu, 25 Jan 2024 06:39:56 GMT, Alexander Kriegisch <d...@openjdk.org> wrote:
>> 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 ... > > @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. @kriegaex I resolved this problem in Byteman by opening up the module of the target class to a module (dynamically) created by Byteman. The Instrumentation instance provided to the agent allows you to perform such an opens operation at runtime rather than on the command line. Byteman relies on an API provided by this module to create the lookups and hand them back for use in woven code. n.b. although this relies on the module exporting a public API, that API can be secured by requiring callers to pass a non-null Instrumentation instance i.e. to have agent capabilities. ------------- PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1909801331
