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

[Garcia Gutierrez Miguel Alfredo]

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)

  (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?
      (2.b) Are there flags to list those? (and thus estimate the impact of the ensuing recompilations)

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


Miguel


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