On Jul 7, 2008, at 3:42 AM, Steven Shaw wrote:
2008/6/24 John Rose <[EMAIL PROTECTED]>:
It would be great if we had really lightweight continuations, with
a JVM scheduler (Scheme calls them engines, I think) which keeps
running the next one. The part I can't see yet is how to make
stack-based and heap-based activation records play together
efficiently. (Maybe you JIT two versions of every method, with
inlining to remove overheads as usual?)
Is it disastrous for performance to heap allocated all activations?
It would be a long, hard job to make up the performance loss. Not
all JVMs (especially the small ones) could follow.
The immediate reuse of memory that stacks enable is very cache-
friendly, and we have to be friends with caches these days.
Perhaps it could be an JVM option. Perhaps activations could be
abstractly considered "heap allocated" and have the JVM stack
allocated when possible.
If you could get the escape events to happen infrequently, you could
do this, with stack-to-heap copying to occur only when required. In
such a design the eager allocation (if any) could be reduced to a one-
word handle object. Stack frames involving generators or closures
could skip directly into the heap. That suggests a "try to keep me
on the stack" bit in the bytecode.
You might want to combine groups of tightly-coupled methods into
stacklets served by one allocation.
A system which bounces things between stack and heap probably
requires lots of global analysis. To make that part of the JVM
architecture probably requires a new set of verifiable assertions
which a low-end JVM could use directly. (It would verify the
assertions transmitted in the bytecodes, rather than re-derive them
from scratch.) I don't think such a thing has been investigated yet.
Is the much research in this area?
I'm not aware of anything related to the JVM, but there's some good
fundamental stuff by Appel and Shao:
http://flint.cs.yale.edu/flint/publications/stack.html
-- John
_______________________________________________
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
