Attaching to a JVM image that does not include java.instrument

[Alan Bateman]

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