remote debugging Graal, and similar use cases

[Doug Simon]

On Aug 4, 2013, at 12:31 PM, Garcia Gutierrez Miguel Alfredo <miguelalfredo.garcia at epfl.ch> wrote:

> 
> After trying out different ways to debug a running Graal instance, two of them worked out of the box (summarized below) but a third didn't.
> 
> First what worked:
> 
>  (1) Ideal Graph Visualizer, which shows snapshots of choice indicated via Debug.dump
> 
>  (2) remote debug connection (e.g. from an IDE where breakpoints are set) to a running Graal vm, for example started with
> 
>      ./mx.sh unittest <your-unit-test-of-choice> @-Xdebug @-Xrunjdwp:server=y,transport=dt_socket,address=8000,suspend=y
> 
>      (Instead of unittest, one can launch a Java app of choice, the above is frequent use-case).

You can achieve this by using the -d global option to mx (I added -v as well so you see what -d translates to):

$ mx -v -d vm -version
/Users/dsimon/graal/jdk1.7.0_25/product/bin/java -graal -d64 -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000 -version
Listening for transport dt_socket at address: 8000

>      Looks like for the above to work one should import beforehand the .launch file created by "mx build" (I don't remember if the remote launch option is available before importing it).

The mx/eclipse-launches/attach-localhost-8000.launch file is actually created by "mx eclipseinit". The latter just happens to be run during "mx build" if you are building with the Eclipse compiler instead of javac.

>      The .launch file is imported into Eclipse via File > Import > Run/Debug > Launch configuration
>      After importing it, launch first the listener via the command-line above, then from Eclipse Run > Debug > Attach remote Java app
> 
> (3) A third approach didn't work, comments as to why are welcome:
> 
>  (3.a) First, I created an Eclipse debug configuration for a Java application.
>  (3.b) For that debug configuration, I specified an "Alternate JRE" as follows:
> 
>      ~/graal/jdk1.7.0_21/product/
> 
>  (3.c) added graal.jar (located in jre/lib of the product Graal JVM above)
> 
> However, the native methods needed by Graal aren't available. For example:
> 
>  java.lang.UnsatisfiedLinkError: com.oracle.graal.api.runtime.Graal.initializeRuntime()Lcom/oracle/graal/api/runtime/GraalRuntime;
> 
> Is this approach supposed to work, and if so what am I missing? (I realize that option (2) above already covers the same use-cases that one could exercise via (3), but still puzzled as to what's missing).

Hmm, I'm unable to reproduce this failure. When I create an alternate JRE, debugging works for me. One difference is that I don't explicitly add graal.jar to the JRE as the VM knows it is collocated with rt.jar. However, adding it to the JRE config shouldn't matter.

-Doug

> --
> Miguel Garcia
> Swiss Federal Institute of Technology
> EPFL - IC - LAMP1 - INR 328 - Station 14
> CH-1015 Lausanne - Switzerland
> http://lamp.epfl.ch/~magarcia/