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