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

[Rafael Winterhalter]

While the jlink feature might only be used by power users, there is no
guarantee that the users of these images are power users at the same degree
or is even understand the implications. For example, some team might use a
JVM-based server from a third-party vendor which is distributed as a jlink
image and deploy it in a production environment. The operations team is
monitoring deployed processes by different mechanisms. To monitor Java
applications, production teams typically use agent-based tooling that
reports certain metrics and a heart beat. If these metrics are not provided
by the agent, the environment considers the application to be
non-responsive, kills the process and restarts it. The development team is
therefore asked to enable the Java agent attachment for the server
application which they do however not control but the third-party vendor
which would now need to change their product in order to satisfy the
monitoring requirements of one of their customers what they did of course
not anticipate.

It is the exact purpose of a Java agent to allow the enhancement of a Java
application that is independent of a particular Java process. Therefore, it
should not be a decission bound to the creation or bundeling of the Java
application if such user-site monitoring is required. Instead, it should
always be possible to attach a Java agent for a standalone Java process.
Also, I cannot find any comment about the Java agent functionality to be
optional despite the mentioned change set:
https://docs.oracle.com/javase/8/docs/api/java/lang/instrument/package-summary.html
- Neither would anybody using the functionality expect it to be optional. I
work with agents everyday and this is the first time I hear it.

Finally, the major gain of not always bundeling the java.instrument module
with a jlink image is the reduced size. On my machine, excluding
java.instrument yields a difference of 131 kB. This is close to irrelevant
even when working with Docker images. Is this size reduction really worth
jeopardizing a feature that many people rely on? In the end, the base size
of an image is about 45 MB, I do not see how this reduction matters given
the sacrifice.

For all of these reasons, I see no good reason why the java.instrument
module should not be merged into the java.base module. Even in embedded
environments, if for example Android wanted to adopt the JPMS, the presense
of 5 more interfaces would not matter much even if there is no way of
attaching an agent and the libinstrument native code could still be
dropped. At the same time, agents would continue to work reliably for any
JVM process as most people expect it today and this important corner stone
of easy access to monitoring all JVM processes would still be guaranteed.

2017-05-19 10:22 GMT+02:00 Alan Bateman <Alan.Bateman at oracle.com>:

> 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/re
>> pository/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
>
>