Improving the performance of stacktrace generation

Jason Zaugg jzaugg at gmail.com
Sun Jul 8 02:40:23 PDT 2012


On Sunday, July 8, 2012 12:03:34 AM UTC+2, Charles Oliver Nutter wrote:
>
> * Exceptions as non-exceptional or moderately-exceptional method results 
>
> In this case I'm specifically thinking about Ruby's tendency to 
> propagate errno values as exceptions; EAGAIN/EWOULDBLOCK for example 
> are thrown from nonblocking IO methods when there's no data available. 
>
> You will probably say "that's a horrible use for exceptions" and I 
> agree. But there are a couple reasons why it's nicer too: 
> - using return value sigils requires you to propagate them back out 
> through many levels of calls 
> - exception-handling is cleaner in code than having all your errno 
> handling logic spliced into regular program flow 
>
> In any case, the cost of generating a stack trace for potentially 
> every non-blocking IO call is obviously too high. In JRuby, we default 
> to having EAGAIN/EWOULDBLOCK exceptions not generate a stack trace, 
> and you must pass a flag for them to do so. The justification is that 
> these exceptions are almost always used to branch back to the top of a 
> nonblocking IO loop, so the backtrace is useless. 
>

That's also the approach used in Scala for non local returns from closures 
and breaks [1] [2].

-jason

[1] 
https://github.com/scala/scala/blob/master/src/library/scala/util/control/NoStackTrace.scala
[2] 
https://github.com/scala/scala/blob/master/src/library/scala/util/control/ControlThrowable.scala
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120708/03f40eeb/attachment-0001.html 


More information about the mlvm-dev mailing list