Hotspot loves PHP.reboot

[Thomas Wuerthinger]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110909/3ac3d463/attachment.html