Hotspot loves PHP.reboot

[Rémi Forax]

On 09/07/2011 10:38 PM, John Rose wrote:
> On Sep 7, 2011, at 12:33 PM, Thomas Wuerthinger wrote:
>
>> This would probably also mean that the exception object created for 
>> capturing the slow-case program state needs to be escape-analyzed and 
>> removed in the optimized code that deoptimizes on overflow?
>
> Yes.  And in the case of user-defined deoptimization, the exception 
> object would encode the continuation required by the source language.
>
> (A continuation would be something like a source location or an AST 
> node, plus a map from local values to source variables.  The local 
> exception handler would package up the live local values into a 
> display that could be loaded into the backup interpreter.)
>
> This exception object would be live only on the exception path, and so 
> (as you say) could be built lazily from the JVM's debug info for EA.
>
> As we discussed at the JVM Language Summit, building user-level 
> deoptimization on top of JVM-level deoptimization should allow 
> non-Java languages to benefit from the same partial-compilation 
> tactics that Java enjoys.
>
> The nicest part is that the basic components are in place; we just 
> need to settle on effective patterns and tune up the associated JVM 
> optimizations.
>
> 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.

Locals is not the only problem, you have to track stack values too.
It's the combination of locals initialization, local variable creation
for storing stack values and supplementary exception handlers
(that's the main problem, or you have multiple handlers,
or you have one handler and a constant)
that slow down the fast path.

Also, in the catch block you can use invokedynamic to avoid
the object array creation at call site.


>
> If we had a benchmark that demonstrated the problems with such an 
> approach, we could file a bug to tune the optimizer for it.  The ideal 
> benchmark would not actually run the deoptimization path (except to 
> demonstrate correctness) but would measure the speed of the fast path, 
> and the impact of the deopt support on the fast path.  Integer 
> overflow is an obvious candidate for a rare deopt condition, and so 
> would a quasi-constant function binding (via a MutableCallsite).  A 
> tak or fib benchmark could demonstrate both.

Ok, let's try with fib.

>
> -- John

Rémi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110908/3a322352/attachment.html