----- Mail original ----- > De: "Alan Bateman" <alan.bate...@oracle.com> > À: "Rafael Winterhalter" <rafael....@gmail.com> > Cc: "jigsaw-dev" <jigsaw-dev@openjdk.java.net> > Envoyé: Vendredi 19 Mai 2017 10:22:04 > Objet: Re: Attaching to a JVM image that does not include java.instrument
> On 19/05/2017 08:08, Rafael Winterhalter wrote: > >> Hi Alan, >> >> I just retested with the most recent Java 9 snapshot and this is what >> I get: >> >> rafael@rafc:~/jdk9-test/greetingsapp$ ./bin/java >> -javaagent:/home/rafael/.m2/repository/sample-agent/sample-agent/1.0-SNAPSHOT/sample-agent-1.0-SNAPSHOT.jar >> -m com.greetings/com.greetings.Main >> Error occurred during initialization of VM >> Could not find agent library instrument on the library path, with >> error: libinstrument.so: cannot open shared object file: No such file >> or directory >> rafael@rafc:~/jdk9-test/greetingsapp$ ./bin/java --add-modules >> java.instrument >> -javaagent:/home/rafael/.m2/repository/sample-agent/sample-agent/1.0-SNAPSHOT/sample-agent-1.0-SNAPSHOT.jar >> -m com.greetings/com.greetings.Main >> Error occurred during initialization of VM >> Could not find agent library instrument on the library path, with >> error: libinstrument.so: cannot open shared object file: No such file >> or directory >> rafael@rafc:~/jdk9-test/greetingsapp$ ./bin/java --add-modules >> java.instrument -m com.greetings/com.greetings.MainError occurred >> during initialization of boot layer >> java.lang.module.FindException: Module java.instrument not found >> >> Do I understand you correctly that you expect the last outcome also as >> a result for the first command? > If the run-time image does not contain java.instrument then the error > for each of these cases should be like the last one ("Module > java.instrument not found"). We have it right for -Dcom.sun.management.* > and -XX:+EnableJVMCI but not -javaagent. The reason for the strange > error with -javaagent is because java agents are implemented as a JVM TI > agent that is loaded early in VM startup, long before the root modules > are resolved. I will create a bug for this. >> >> I argue that this outcome would still be rather suprising for most >> Java users. Many monitoring tools use Java agents to hook into Java >> processes and those tools have become omnipresent in most production >> environments. Also, it is very unlikely that a main application module >> would require the java.instrument module as it is only useful to Java >> agents. As a result, Java agents and the tooling that relies on them >> would stop working for the majority of jlink modules. Furthermore, the >> agent attachment also fails if a Javaagent does not require the >> Instrumentation interface what makes this problem even less intuitive. >> (The reason being the lack of libinstrument.) > The jlink user is a power user and so decides the modules and features > to include in the run-time image. > > If the jlink user doesn't select the VM type when creating the run-time > image then the attach mechanism will work (because it is compiled into > libjvm.so) and the troubleshooting tools should work fine. However some > features that are exposed via the attach mechanism may not be present, > specifically VirtualMachine.startManagementAgent and > VirtualMachine.startLocalManagementAgent will fail if module > jdk.management.agent is not included, and VirtualMachine.loadAgent will > fail if module java.instrument is not included. > > If the jlink user is targeting an embedded system or wants to create a > minimal image to put in a docker container then maybe they select the > minimal VM, in which case the serviceability features (including the VM > side of the attach mechanism) are not included. It gets harder again for > troubleshooting when additional jlink power options are used to strip > debug attributes. That's the trade-off. > > As I said, the goal has always been to allow someone create a run-time > image that only contains java.base. I'm not sure that subsuming > java.instrument into java.base is right. Introducing options to ask > jlink to exclude modules creates the potential for conflict on the > command line. One thing that jlink could do is emit a warning that the > resulting run-time image doesn't have the management and instrumentation > features, might that be the right balance. yes, that seems the right way to solve this issue. > >> >> On the above machine, a jlink image is incapable of starting despite >> the _JAVA_OPTIONS only specifying standard features that are >> guaranteed by the JVM independently of a specific VM vendor. > There isn't any guarantee, a point that was clarified in the > java.instrument spec in Java SE 8 (JDK-8006565). The motivation for the > clarification at the time was embedded deployments and the Compact > Profiles defined for Java SE 8 (compact1 and compact2 didn't include the > java.lang.instrument package). > > -Alan Rémi