On 4/23/08, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote: > > John Cowan wrote: > > On Tue, Apr 22, 2008 at 2:41 PM, Jon Harrop <[EMAIL PROTECTED]> wrote: > > > >> > 2) you are allocating a new exception every time; the optimization > >> > described here [1] works only if the exception is pre-allocated. > >> > [1] http://blogs.sun.com/jrose/entry/longjumps_considered_inexpensive > >> > >> I think that is not thread safe. Specifically, when the branch conveys > >> information (passed as arguments using a tail call, or embedded in the > >> exception) then you must use a locally allocated exception, right? > > > > Yes, you must. However, what makes allocating an exception expensive > > is the fillInStack method, which has to walk the JVM stack. If you > > override that in your exception class with a do-nothing method, then > > locally allocating exceptions is very cheap. > > > JRuby uses this technique since we frequently have flow-control > exceptions that contain different state. It's fast...very very fast. The > stack trace is basically *all* the cost, but John Rose's version also > eliminates the object allocation cost. For some of our exceptions we do > have a single instance.
I use exceptions like this too. I have an exception instance per thread held in thread local storage. I currently leave the fillInStack method alone so that the stack trace points to the creating location which has a comment saying that if you get here via a printed stack trace you have found a bug (As I should have caught it before you see it). As I only create one per thread it's not a significant performance hit. John Wilson --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
