There has been an interesting thread lately in the jvm-languages Google group that I thought was worth bringing up. The thread concerns finding a better solution to artifical call frames, such as perhaps stack frame annotations. The idea is that many dynamic languages must introduce artificial call frames, purely to be able to recover the dynamic language’s stack trace. The thread was started by Charles Nutter based on JRuby, but it seems that this is a common issue from the discussion.

The solution discussed in thread concerns the ability to annotate both threads and stack frames with additional metadata. Doing so would allow the artificial call frame to go away and be replaced by metadata attached to the thread and/or stack frame, just riding along on the normal Java stack frame. It seems from the discussion that a number of JVM languages could benefit from this improvement.

Kelly Nawrocke mentioned that there is a similar proposal in the works for EcmaScript 4 based on the thesis by John Clements. This inspection allows inspection of all frames of the stack and the modification of annotations for any frame in the stack.

It appears that one of the key considerations is being able to maintain proper tail call optimization (something Java doesn’t have now, but which is being considered as a possibility via JSR 292 in Java 7). In the case of tail call optimization, it is necessary to reuse stack frames, so the key is to do something useful in this case. Read the links for more info.

I’m pretty sure that there are some interesting optimizations we could make in Terracotta based on this capability as well. For example, we must maintain some per-lock information for each nested lock and currently this gets pushed into some ThreadLocal stack data structures, but the information may fit more naturally as stack frame annotations where locks are acquired as you walk down the frame.

What would you do with the power of stack frame annotation?