On 09.09.2011 01:21, John Rose wrote:
On Sep 8, 2011, at 4:06 PM, Thomas Wuerthinger wrote:
Here an example for a scripting method that performs a+b and is
guessed to not overflow.
Your example is simplified by the fact that, in the handler, there is
only one possible deopt point. What if there are two?
E.g., what if your code is: add(a,b,c) := a+b+c .
The example could be any complex scripting function. So let's consider
the following method:
function sumUp(n) {
var sum=0;
for (var i=0; i<n; ++i) sum += i;
return sum;
}
That would transform into:
int sumUpFastPath(int n) {
int sum = 0;
for (int i=0; i<n; i = safeAdd(i, 1)) sum = safeAdd(sum, i);
return sum;
}
int safeAdd(int a, int b) {
if (addWouldOverflow(a, b)) throw new DeoptimizationException();
return a + b;
}
The two deoptimization points are distinguished by the different Java
bci at the calls to safeAdd. For each of those points, there must be a
slow-path continuation. While generating the bytecodes for the method
sumUpFastPath, one can also generate a mapping from
exception-bci=>slowpath-entry-point. Such a slowpath-entry-point could
either be an interpreter loop method (started with the current locals
and scripting code position) or a lazily generated generic OSR version
of the scripting function.
So the code could look like:
Object sumUpGeneric(int n) {
try {
return sumUpFastPath(n);
} catch(DeoptimizationException e) {
StackFrame f = e.getStackFrame("sumUpFastPath");
ScriptingPosition p = map.get(f.bci());
return invokeInterpreter(sumUpMethod, p, f.getLocals(),
f.getExpressionStack());
}
}
The operand stack and locals manipulation in the generated bytecodes
must exactly match the manipulations done by the scripting interpreter,
but I think that it is possible to align those (although there might be
some complexity due to the fact that certain value types require more
than 1 stack slot). The safeAdd method could be intrinsified to
deoptimize to the Java interpreter. So, in case an overflow occurs,
there would be a two-level deoptimization: Java optimized code => Java
interpreter (which now actually throws the DeoptimizationException) =>
Scripting language interpreter.
- thomas
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
