Le 06/11/2010 21:24, John Rose a écrit :
On Nov 6, 2010, at 11:38 AM, Rémi Forax wrote:
I've wanted to write that several times, so before doing something else,
I want to try to convince all VM hackers that they should stop doing
what they currently do and starts to implement a way to export
values from the VM stack into a Java object.
...
Yes, JVM languages should be able to do the "deoptimization trick". It works
great for the JVM itself.
Here is a bytecode shape that might make it possible to do so, without the API
you mentioned:
myfn(a,b,c) {
var i,j,k; // init to null if needed
try {
entry point of my fn...
... more stuff ...
... if (bail out #1) throw makeDeopt("cookie #1");
... more stuff ...
... if (bail out #2) throw makeDeopt("cookie #2");
... more stuff ...
return x;
} catch (MyDeopt deopt) {
return executeDeopt(deopt, new Object[]{ a, b, c, i, j, k });
}
}
Here, the cookies passed into the deopts are simple constants. This (probably)
simplifies data movement, since the complicated bundling is done once, at the
catch point. The local variable values could also be bundled up as arguments
to makeDeopt. The throws could be replaced by gotos, but JITs are more likely
to optimize the code the way you want if you use a throw (which the JIT will
probably guess as uncommon).
Would this work for you?
The problem of this pattern is that I haven't access to the stack value.
So I need to store all stack values into local variables.
a1 + a2 +a3 will be translated to
iload 1
iload 2
iadd
dup
istore 4 # stack position 1
iload 3
dup
istore 5 # stack position 2
etc...
This introduces maxstack supplementary local variables.
Not sure the JIT will love that.
I should try that to see the overhead.
Another problem here is where the executeDeopt guy should go.
Probably you want to fake up some AST interpreter state that expresses the
pending continuations (for enclosing expressions and callers of inlined
functions). Then the AST engine, after it digests the app. some more, can
generate new bytecodes.
Yes, that part already works in the runtime of PHP.reboot.
I create a continuation as a method handle. These method handle can be
stored
in an array and bound to the current method. In that case bail out #i mean
executing method_handle[i] in the catch block.
Another option would be to generate bytecodes with multiple entry points. This cannot be
directly expressed but could be encoded with a leading pseudo-BCI parameter, with a
switch at the entry point. Again, the above "i,j,k" structure would be needed.
And all the entry points would have to have a common functional type.
Here's an idea: For each byte-compiled method, compile the normal optimized version, and
also compile a "fallback" version which can be used in corner cases:
myfn(int bci, args[], locals[]) {
var a=args[0], ...;
var i=locals[0],j,k; // init to null if locals = null
try {
switch (bci) {
case 0:
entry point of my fn...
case 1:
... more stuff ...
... if (bail out #1) throw makeDeopt("cookie #1");
case 2:
... more stuff ...
... if (bail out #2) throw makeDeopt("cookie #2");
case 3:
... more stuff ...
return x;
}
} catch (MyDeopt deopt) {
return executeDeopt(deopt, new Object[]{ a, b, c, i, j, k });
}
}
The fallback could be used for type misses and untaken paths. It could also be
used for continuations (if your language has those). The advantage of a
pre-compiled fallback would be that you would reuse your bytecode compilation
analysis to improve more execution paths, not just the fastest. If that
doesn't matter, a AST-based fallback is perhaps easier to work with.
Usually, if there is a type miss or a taken untaken path :) the
generated bytecode will be dropt
(or at least not used anymore for the current trace).
So having a pre-compiled fallback is not interesting.
-- John
Rémi
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
