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.
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
