8

I'm trying to run a program using jol with Java 9 but with no luck.

I have the following dependency in pom.xml:

<dependency>
    <groupId>org.openjdk.jol</groupId>
    <artifactId>jol-core</artifactId>
    <version>0.9</version>
</dependency>

The program is simple:

package org.example;

import org.openjdk.jol.vm.VM;

public class Example {
    public static void main(String[] args) throws Throwable {
        System.out.println(VM.current().details());
    }
}

Module descriptor:

module java9 {
    requires jol.core;
}

When I run the program from IDEA, I see the following output:

# WARNING: Unable to get Instrumentation. Dynamic Attach failed.
You may add this JAR as -javaagent manually, or supply -Djdk.attach.allowAttachSelf

I added -Djdk.attach.allowAttachSelf=true to the VM arguments in IDEA but it didn't help (still the same output).

P.S. I can run the program successfully from the classpath. Still, it is interesting how to run it from the module path.

ZhekaKozlov
  • 36,558
  • 20
  • 126
  • 155
  • It probably relies on reflecting over JDK internals which have been closed by the module system. Try `--add-opens java.base/java.util=ALL-UNNAMED` as per [this](https://stackoverflow.com/questions/41331515/is-jol-a-little-broken-under-java9) – Michael Oct 05 '17 at 10:19
  • @Michael thank you for linking to my question :) I don't think that this is related though... this was fixed in `0.7` – Eugene Oct 05 '17 at 10:31
  • Can you update the question to make it clear if it works as a module on the command line? As currently written it sounds like you are running it successfully on the command line when JOL is on the class path but that you trying it as a module when in the IDE, is that right? – Alan Bateman Oct 05 '17 at 14:49
  • @AlanBateman It runs fine if both jol-core.jar and my-program.jar are on the class path. It fails when they are on the module path. – ZhekaKozlov Oct 05 '17 at 17:28
  • 1
    In that case, the other comment about making use of JDK internals may be valid, the JDK does not open any packages to all modules, it only (and only temporarily) only its packages to code on the class path. Running with -Dsun.reflect.debugModuleAccessChecks=true might reveal something, otherwise bring it to jol-dev to discuss. – Alan Bateman Oct 05 '17 at 18:28

1 Answers1

3

Well, I tried debugging this a little further an found that the cause of the warning is InstrumentationSupport trying DYNAMIC_ATTACH on the application startup. The relevant section of dynamicAttach where the code actually makes use of the VirtualMachine is

String name = "com.sun.tools.attach.VirtualMachine";
try {
    // JDK 9+ makes this class available on class path
    vmClass = ClassLoader.getSystemClassLoader().loadClass(name);
...

The class is not loaded with initially resolved modules since its package is exported from jdk.attach module which is currently missing from the module descriptor. Hence you can update to using the module declarations as :

module java9 {    // module name 'joltrial' in output
    requires jol.core;
    requires jdk.attach;
} 

and then allow self-attach further using the VM option as:-

-Djdk.attach.allowAttachSelf=true

On executing the shared code [VM.current().details()], the output shall include details as -

/Library/Java/JavaVirtualMachines/jdk-9.0.1.jdk/Contents/Home/bin/java -Djdk.attach.allowAttachSelf=true "-javaagent:/Applications/IntelliJ IDEA 2017.3 CE EAP.app/Contents/lib/idea_rt.jar=53783:/Applications/IntelliJ IDEA 2017.3 CE EAP.app/Contents/bin" -Dfile.encoding=UTF-8 -p .../joltrial/target/classes:.../.m2/repository/org/openjdk/jol/jol-core/0.9/jol-core-0.9.jar -m joltrial/com.Sample
# WARNING: Unable to attach Serviceability Agent. Unable to attach even with module exceptions: [org.openjdk.jol.vm.sa.SASupportException: Sense failed., org.openjdk.jol.vm.sa.SASupportException: Sense failed., org.openjdk.jol.vm.sa.SASupportException: Sense failed.]
# Running 64-bit HotSpot VM.
# Using compressed oop with 3-bit shift.
# Using compressed klass with 3-bit shift.
# WARNING | Compressed references base/shifts are guessed by the experiment!
# WARNING | Therefore, computed addresses are just guesses, and ARE NOT RELIABLE.
# WARNING | Make sure to attach Serviceability Agent to get the reliable addresses.
# Objects are 8 bytes aligned.
# Field sizes by type: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]
# Array element sizes: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]

Process finished with exit code 0
Naman
  • 27,789
  • 26
  • 218
  • 353
  • Thank you. I added `requires jdk.attach`. Unfortunately, I still cannot make my app running. It is just hanging without any output. It is interesting that in debug mode (in IDEA) everything is fine – ZhekaKozlov Oct 24 '17 at 03:32
  • @ZhekaKozlov By unable to run the app, do you mean not able to print the VM details as mentioned in the code in question? Since I used the same code in IDEA to get it running. If that might matter, I am using 2017.3 EAP of IntelliJ IDEA. – Naman Oct 24 '17 at 03:33
  • Yes, it starts but does not print anything. I have to kill my app after that. – ZhekaKozlov Oct 24 '17 at 03:36
  • @ZhekaKozlov Are you sure there is no other configuration to the project that you are executing? Any other logs etc that you could capture possibly? – Naman Oct 24 '17 at 03:37
  • Thread dump says it is hanging on `ServiceabilityAgentSupport.java:242` – ZhekaKozlov Oct 24 '17 at 03:50
  • 1
    `agentProcess.waitFor()` ... ***Causes the current thread to wait, if necessary, until the process represented by this {@code Process} object has terminated.*** ...What are the `args` when you debug the code in the `senseAccess` are being evaluated to? Also, any other process already running for you by any chance that might make the current wait? – Naman Oct 24 '17 at 03:54
  • The args are `[C:/Program Files/Java/jdk-9/bin/java, -cp, , org.openjdk.jol.vm.sa.SenseAccessMain]`. The third arg is `""` which causes infinite `waitFor`. – ZhekaKozlov Oct 24 '17 at 04:04
  • Presumably, `jol` just does not handle the module path properly yet. It expects that everything is running from the class path. – ZhekaKozlov Oct 24 '17 at 04:07
  • Interestingly the third arg for me resolves into `"/Applications/IntelliJ IDEA 2017.3 CE EAP.app/Contents/lib/idea_rt.jar"`. Not sure why would they be different though. Maybe IDEA has something to look into? – Naman Oct 24 '17 at 04:13
  • For me, it resolves to `idea_rt.jar` if I run in debug mode. But it is empty if I run in non-debug mode. – ZhekaKozlov Oct 24 '17 at 04:16
  • @ZhekaKozlov Ya I got it from your previous message. That's why wondering if IDEA shall be involved in to investigate further into this. Since it works same for me in both debug and normal run mode. – Naman Oct 24 '17 at 04:17
  • 1
    I reported this to `jol` mailing list: http://mail.openjdk.java.net/pipermail/jol-dev/2017-October/000232.html – ZhekaKozlov Oct 24 '17 at 04:37