DRAFT PROPOSAL Pot Pourri - Augmented Stack Traces, ServiceProvider annotation and processor, Enhanced For Loop utility class

Bruce Chapman & Barbara Carey cadenza at paradise.net.nz
Sat Mar 1 22:28:47 PST 2008


Charles Oliver Nutter wrote:
>
> I wonder if a general mechanism for decorating the stack could be part 
> of this? My understanding of exception handling performance is such 
> that handling the exception is actually the more expensive part; so I 
> would expect that handling and re-handling to augment the exception at 
> various levels would add more overhead. One thing I've often wanted is 
> a way to decorate the stack with additional information *ahead of 
> time* so that when/if an exception is raised that information can 
> automatically be attached. In my case, it's for JRuby, where we have a 
> "virtual" Ruby stack trace alongside the Java stack trace. It's not 
> useful for us to dump out the entire Java stack trace, since it 
> includes information about Java frames unrelated to the user's code. 
> And we can't just filter  the Ruby frames, because JRuby is mixed-mode 
> and some of those frames will be interpreted calls (and therefore be 
> identical to one another). A way to attach information to the current 
> frame (Thread.current.augmentFrame(Object)) and register a backtrace 
> handler (Thread.current.attachBacktraceCallback(...)) would provide a 
> way to attach useful arbitrary data to the call frame for many uses.
>
> Thoughts?
>
> - Charlie
>
Thanks for the comments.

I had initially though of a similar mechanism to that. See 
http://weblogs.java.net/blog/brucechapman/archive/2007/08/index.html

However that requires quite deep changes in the JVM and the JVM spec and 
probably the language.

My proposal can do similar with a little more effort from developers 
(over-use is probably to be discouraged so some effort is a good thing 
IMHO), with just a library change (albeit changes to Throwable and 
StackTraceElement which are pretty core), feasibility of actually doing 
it trumps performance :)

If my proposal made it into a future JDK release (it can't be done as an 
add on library) and was well accepted but performance was shown to be a 
problem, then a declarative approach to the augmenting data could be 
added to the JVM. later (maybe)

Performance wise some inital tests showed that avoiding filling in a new 
(reusable actually) stack trace in order to get the depth at which the 
augmentation should occur roughly doubled the performance, so that 
second stack trace chewed up quite a few horsepower.

Regards your ruby project, I think you should be able to grab the stack 
trace for an exception, and replace it with a manufactured stack trace, 
with manufactured stack trace elements. I have been successful in using 
this technique to augment stack traces (albeit I was suffixing the 
context info after the method name with inverted parenthesis around it 
to make it look like it was another item in the stack trace element.)

Bruce





More information about the challenge-discuss mailing list