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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
