Hotspot loves PHP.reboot

[Thomas Wuerthinger]

On 08.09.2011 21:47, John Rose wrote:
> On Sep 8, 2011, at 4:57 AM, Thomas Wuerthinger wrote:
>
>> Why not the following code pattern? Does it generate too many bytecodes?
>
> That's a reasonable alternative.
>
> It generates data movement bytecodes O(L * M), where L is the average 
> number of live values at deopt points and M is the number of deopt 
> points.  The quadratic exponent on bytecode size bothers me, at least 
> a little.

But with a specialized DeoptimizeException that automatically captures 
the values of the local variables and operand stack at the JVM-level (in 
fillInStackTrace), there would not be any data movement bytecodes at 
all. It would require a 1-1 correspondance between scripting language 
local variables and Java bytecode local variables, but would both be 
efficient to generate and performant at run time. The information could 
be captured for all stack frames between the throwing method and the 
catching method. Here an example for a scripting method that performs 
a+b and is guessed to not overflow.

Object add(int a, int b) {
    try {
          return fastPathAdd(a, b);
     } catch(DeoptimizationException e) {
         Integer local1 = e.getTopFrame().getLocalAt(0);
         Integer local2 = e.getTopFrame().getLocalAt(1);
         return slowPathAdd(local1, local2);
     }
}

int fastPathAdd(int a, int b) {
    if (canOverflow(a, b)) throw new DeoptimizationException();
    return a + b;
}

Object slowPathAdd(Object a, Object b) {
   // ... generic add implementation ...
}


- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110909/a18c8b38/attachment.html