Hotspot loves PHP.reboot

[John Rose]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110908/03295cf6/attachment.html