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_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
