• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

FastException

 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't know how many of you follow the The Java Specialists Newsletter by Dr. Heinz M. Kabutz, but he had a neat tip from Geert Bevin, the architect behind RIFE.

For faster exception handling RIFE uses:

Kabutz tried to make an ever faster one:

The timings on a million throws work out like:

Cute, huh?
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Clever, and interesting. I'm not sure I like these techniques, in the sense that the biggest problem I experience with exceptions is that people foolishly lose the stack trace when logging (or they fail to log at all), when in fact the stack trace is often the most useful part. So I have some fear that if this catches on, performance-obsessed coders will make it even more likely that useful debugging info will be lost. Also it seems like this might make some people more prone to use exceptions for control flow in unexceptional circumstances. It's great that this minimizes performance problems, but it wouldn't help readability much. Still, there may be some applications & contexts where these techniques provide practical benefits that are worth the potential problems. (I'm tempted to look into the internals of RIFE just to see where this is actually used.) I just hope they don't catch on outside such (presumably rare) contexts.
 
Ranch Hand
Posts: 425
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Agreed that it's frightening thought to debug the issue without the stack trace. However things have gone too far. For example I don't feel it's necessary to have the complete stack trace. I don't bother to look at container classes in the stack trace and 95% of the time I guess most of us don't care where the call orginates but the offending line number and class details of the code we work on.

Take a look at this blog for a complete call stack here. This I believe is too much information and to great extent consume lot of memory. Down the line few years I guess this can be configured not to capture entire call stack expect on the business logic code which we develope.
[ June 29, 2006: Message edited by: Purushothaman Thambu ]
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah, it can get pretty hairy sometimes looking at it in the log. And obviously it takes more time to generate the trace, the deeper the call stack is. But do you really think the memory itself is an issue? Seems to me it's all in short-lived objects. Do people keep stack traces in memory long-term for some reason? OK, the memory used in the stack trace also needs to be collected later, but that's just adding to time, same as the original stack trace filling did.

I'm not sure there's a better way to handle this in Java as it's implemented though. Given a choice between too much info and not enough, I'd rather have too much - pretty much always. I suppose a reasonable default would be to capture only the stack frames between where it's thrown and where it's caught, with an option to get more if you explicitly request it. Doing that would seem to require JVM changes to add stack trace info as each frame is exited, rather than all at once at the beginning of the throw.

I suppose for logging purposes it would be possible to devise a method that would only log frames between throw and catch. That would have no effect on the time consumed populating the internal stack trace and later collecting it, of course - if anything that might almost double, for the implementation I'm thinking of. But seeing shorter stack traces would be kind of nice.
 
Purushoth Thambu
Ranch Hand
Posts: 425
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
System resources can be better spent rather than filling needless information. Yes it's true memory is not a "critical" issue.

Capturing stack frame of the application code sounds great and hope Sun does something about this. If we are suppose to log the stack frame releated to the application code I guess it 's overkill. Grepping throug the stack trace before logging at runtime doesn't go well with me I may slowdown the reponse chain. I perfer to clean up the log file externally.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[PT]: System resources can be better spent rather than filling needless information.

Agreed. The problem is, which parts are useful? It's true that the important part of a stack trace is often at the very top, and it's usually toward the top. I think it's always between where the exception was thrown and where it was caught, inclusive. I wouldn't want to narrow the range down any more than that though.

[PT]: Capturing stack frame of the application code sounds great and hope Sun does something about this. If we are suppose to log the stack frame releated to the application code I guess it 's overkill.

I'm not sure which part of this idea was great and which was overkill. Either way though, I doubt we'll see Sun do anything about this. Maybe if Java gets open-sourced it could happen. Most likely though, I think Java exceptions will remain as they are, for better or worse. Now what may happen in other languages, that's a whole different ball of wax...
 
Bartender
Posts: 9626
16
Mac OS X Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Has anyone ever written code where throwing exceptions would be a performance bottleneck?
This kind of thing really bugs me because I maintain an application where the author thought it would be a good idea to catch various exceptions and re-throw his custom exception but failed to include the cause or to chain the exception. Every time something new goes wrong I have to debug the error AND the exception handling
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Worse than that, Joe, I think the Java Specialist Newsletter said the author made FastException so he could use it to control program flow in situations that aren't "real" exceptions.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[Joe]: Has anyone ever written code where throwing exceptions would be a performance bottleneck?

Only while still in debug/test mode. That is, if there is a bottleneck there, it's just a side effect of a much more serious problem, in my experience.

[Stan]: I think the Java Specialist Newsletter said the author made FastException so he could use it to control program flow in situations that aren't "real" exceptions.

"As part of the continuations control in Java, they use exceptions to pass the control back to the client. Or something like that." Yeah, sounds bad. Though Dr. K doesn't sound too sure of the details here, so it may be a little premature to make a judgement here.
 
reply
    Bookmark Topic Watch Topic
  • New Topic