any Graal-specific diagnostics flags? (deopt, re-compilation, and so on)

[Gilles Duboscq]

Hello Miguel,

On Tue, Feb 4, 2014 at 12:46 PM, Garcia Gutierrez Miguel Alfredo
<miguelalfredo.garcia at epfl.ch> wrote:
>
> A behavior the JIT exhibits for (unoptimized) Scala code is shown below (it's representative of methods taking a closure, aka the GoF Command Pattern in Java). I wanted to know if any Graal-specific flags exist to help diagnosing similar cases.
>
> Notes:
>   output from -XX:+PrintCompilation on JDK 7,
>   first sorted by method, then by compilation-task, then by timestamp.
>   an explanation of that JVM flag can be found at https://gist.github.com/rednaxelafx/1165804#file_notes.md
>
> time    c-task  method
> ----    ------  ------
> . . .
> 35358    4777    scala.collection.immutable.List::takeWhile (93 bytes)
> 47002    4777    scala.collection.immutable.List::takeWhile (93 bytes)   made not entrant
> 48419    4777    scala.collection.immutable.List::takeWhile (93 bytes)   made zombie
>
> 47357    5788    scala.collection.immutable.List::takeWhile (93 bytes)
> 48407    5788    scala.collection.immutable.List::takeWhile (93 bytes)   made not entrant
> 49596    5788    scala.collection.immutable.List::takeWhile (93 bytes)   made zombie
>
> 50804    6076    scala.collection.immutable.List::takeWhile (93 bytes)
> . . .
>
> A few questions:
>
>   (1) with Graal, can more detailed information be obtained (eg, what event triggers each invalidation, eg which subclass was loaded and so on)

If you are interested in uncommon traps (the compiled code itself asks
for deoptimization, and not because of, for example, class loading
invalidating CHA assumptions), you can use -XX:+TraceDeoptimization as
you suggest.

>
>   (2) counterpart to the previous question:
>
>       (2.a) each invalidation (eg of the method above) will invalidate all methods where it's been inlined (as per MethodContentsAssumption), right?

No, these messages are not about which Java methods are invalidated
but which nmethod (a compiled blob of code) are invalidated. The name
you see in the output is the root method of the compilation which
produced this nmethod.
Thus, the source of the invalidation is not necessarily because of the
method whose name is printed but it may be because of an other method
which was inlined in this first method.

>       (2.b) Are there flags to list those? (and thus estimate the impact of the ensuing recompilations)

Looking at the output of -XX:+PrintCompilation should tell you about
all nmethods being invalidated.

>
>   (3) any Graal-specific version of -XX:+TraceDeoptimization

This flag should work fine with Graal, we may just print a bit more
information than a normal HotSpot VM would using this flag (and even
more if you make a debug or fastdebug build).

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