<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jul 7, 2008, at 3:42 AM, Steven Shaw wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">2008/6/24 John Rose <<a href="mailto:John.Rose@sun.com">John.Rose@sun.com</a>>:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div style=""><div>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?)</div> </div></blockquote><div><br>Is it disastrous for performance to heap allocated all activations?</div></div></blockquote><div><br></div>It would be a long, hard job to make up the performance loss. Not all JVMs (especially the small ones) could follow.</div><div><br></div><div>The immediate reuse of memory that stacks enable is very cache-friendly, and we have to be friends with caches these days.</div><div><br></div><blockquote type="cite">Perhaps it could be an JVM option. Perhaps activations could be abstractly considered "heap allocated" and have the JVM stack allocated when possible.<br></blockquote><br><div>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.</div><div><br></div><div>You might want to combine groups of tightly-coupled methods into stacklets served by one allocation.</div><div><br></div><div>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.</div><div><br></div><div><blockquote type="cite"><div class="gmail_quote"><div>Is the much research in this area?</div></div></blockquote><br></div><div>I'm not aware of anything related to the JVM, but there's some good fundamental stuff by Appel and Shao:</div><div> <a href="http://flint.cs.yale.edu/flint/publications/stack.html">http://flint.cs.yale.edu/flint/publications/stack.html</a></div><div><br></div><div>-- John</div></body></html>