Hotspot loves PHP.reboot

[Thomas Wuerthinger]

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