On Sep 8, 2011, at 5:35 PM, Thomas Wuerthinger wrote:
> The operand stack and locals manipulation in the generated bytecodes must
> exactly match the manipulations done by the scripting interpreter, but I
> think that it is possible to align those (although there might be some
> complexity due to the fact that certain value types require more than 1 stack
> slot). The safeAdd method could be intrinsified to deoptimize to the Java
> interpreter. So, in case an overflow occurs, there would be a two-level
> deoptimization: Java optimized code => Java interpreter (which now actually
> throws the DeoptimizationException) => Scripting language interpreter.
Got it. I had missed the meaning of your phrase "at the JVM-level (in
fillInStackTrace)". So the exception has an extra-heavy backtrace.
The backtrace amounts to a JVM continuation. Is there a way to do data hiding
so that the language runtime can only see locals that it has a right to observe?
That IMO is the problem with rich backtraces: They provide a very deep punch
into the JVM, which can be exploited (like reflection) to break across trust
boundaries.
I guess one answer is that we could trust language runtimes. I'd rather find a
more compartmentalized solution, hence my interest in patterns expressible in
current bytecodes.
-- John
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
