Hotspot loves PHP.reboot

[John Rose]

On Sep 7, 2011, at 12:33 PM, Thomas Wuerthinger wrote:

> This would probably also mean that the exception object created for capturing the slow-case program state needs to be escape-analyzed and removed in the optimized code that deoptimizes on overflow?

Yes.  And in the case of user-defined deoptimization, the exception object would encode the continuation required by the source language.

(A continuation would be something like a source location or an AST node, plus a map from local values to source variables.  The local exception handler would package up the live local values into a display that could be loaded into the backup interpreter.)

This exception object would be live only on the exception path, and so (as you say) could be built lazily from the JVM's debug info for EA.

As we discussed at the JVM Language Summit, building user-level deoptimization on top of JVM-level deoptimization should allow non-Java languages to benefit from the same partial-compilation tactics that Java enjoys.

The nicest part is that the basic components are in place; we just need to settle on effective patterns and tune up the associated JVM optimizations.

For example, at the Summit Remi pointed out an optimization problem associated with this pattern:

  Object l0, l1, l2, ...;
  l0 = l1 = l2 = ... null;  // these are required only for definite assignment in the catch body
  try {
    ...do fast path...
    if (...constraint violated...) throw new DeoptExc(...);
    return ...fast result...
  } catch (DeoptExc ex) {
    Object[] display = { l0, l1, l2, ... };
    return backupInterpreter(ex, display);  // N.B. could throw DeoptExc to caller also
  }

This problem is that the eager initializations of the various locals slow down the fast path.  (Did I get it right Remi?)  The register allocator should push them down into the catch body, and maybe even into the static debug info of the JVM.

If we had a benchmark that demonstrated the problems with such an approach, we could file a bug to tune the optimizer for it.  The ideal benchmark would not actually run the deoptimization path (except to demonstrate correctness) but would measure the speed of the fast path, and the impact of the deopt support on the fast path.  Integer overflow is an obvious candidate for a rare deopt condition, and so would a quasi-constant function binding (via a MutableCallsite).  A tak or fib benchmark could demonstrate both.

-- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110907/918bc601/attachment-0001.html