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