>From Thomas
(e.g., they could
use the Java expression stack as their own expression stack
implementation).
I believe that this is both used and necessary to create reasonable
performance implementation
of Smalltalk on the jvm. I do this in Rtalk today mapping the Smalltalk
stack to the jvm stack and then
use jvmti to get access to the stack when I need it. There are some
tradeoffs here with what can be
done vs a true Smalltalk stack but I don't see them as that critical(
mostly with the manipulations
of continuations).
It does bring up John's concern that with a debugger available security is
more difficult. The Smalltalk
I am referencing for my implementation converts the machine stack to
objects and back as necessary.
Perhaps this approach would give an opportunity to control visibility at a
fixed point. I believe this is in
line with some of this thread.
This brings up what I see as a larger requirement to fulfill the promise
of Smalltalk. In Smalltalk everything
is an object ( including the stack, heap, vm ...) which can be manipulated
from the application side at will.
Even to the extent of modifying the vm's behavior or the gc. Most of this
is possible if jvmti would be
available from the object side. Having a controlled access api would also
give a location where visibility
and security could be enforced.
regards
mark
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
