On 07.09.2011 22:38, John Rose wrote:
> 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.
Why not the following code pattern? Does it generate too many bytecodes?
What about an exception that contains a *detailed* stack trace that
includes expression stack and local variables? That might solve the
issue of capturing the local variables altogether and provide a natural
way of expressing customized deoptimization.
Object l0, l1, l2, ...;
try {
...do fast path...
if (...constraint violated...) {
Object[] display = { l0, l1, l2, null, ... };
throw new DeoptExc(display);
}
return ...fast result...
} catch (DeoptExc ex) {
return backupInterpreter(ex, ex.display); // N.B. could throw
DeoptExc to caller also
}
So with the *detailed* stack trace it would read:
Object l0, l1, l2, ...;
try {
...do fast path...
if (...constraint violated...) throw new DeoptExc();
return ...fast result...
} catch (DeoptExc ex) {
return backupInterpreter(ex, ex.getLocalsAndStack()); // N.B.
could throw DeoptExc to caller also
}
That could also work nicely with "addWithoutOverflow(a, b) throws
DeoptExc". In the optimized code the catch block and the throw-statement
are both not present (based on the branch prediction analysis). So in
case of overflow the VM would first do a Java-level deoptimization. Then
the interpreter would throw the DeoptExc, which will then lead to the
scripting-level deoptimization.
- thomas
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
