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