Time to reconsider m:n or green threading options?

[John Rose]

On Jul 7, 2008, at 3:42 AM, Steven Shaw wrote:

> 2008/6/24 John Rose <John.Rose at sun.com>:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20080707/f861e8fe/attachment.html