Alex Miller lives in St. Louis. He writes code for a living and currently work for Terracotta Tech on the Terracotta open-source Java clustering product. Prior to Terracotta he worked at BEA Systems and was Chief Architect at MetaMatrix. His main language for the last decade has been Java, although Alex have been paid to program in several languages over the years (C++, Python, Pascal, etc). Alex has posted 43 posts at DZone. You can read more from them at their website. View Full User Profile

Stack frame annotation

01.20.2008
| 5356 views |
  • submit to reddit

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?

Published at DZone with permission of its author, Alex Miller.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Curt Cox replied on Mon, 2008/01/21 - 10:28pm

There are several requests on BugParade to add more information to StackTraceElement.  Here's one that I've annotated with references to others.

 

 "StackTraceElement doesn't contain Class objects but only the class names"

http://bugs.sun.com/view_bug.do?bug_id=4942697

 

While I favor generously granting these requests (along with all of the appropriate security checks and enhancements), I know it will never happen. 

 

Ash Mughal replied on Tue, 2011/12/27 - 1:33pm

The unwind information associated with each non-leaf function contains lots of useful meta-information about the structure of the stack. It provides information about the amount of stack space allocated, the location of saved non-volatile registers, and whether or not a frame register is used and what relation it has to the rest of the stack

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.