try/catch
in [Java Programming]
|
Next: localhost:9080
From: Wibble on 14 Sep 2005 21:05 Thomas Hawtin wrote: > jan V wrote: > >> >> Last time I poured over class file disassemblies, I noticed a distinct >> lack >> of any logic whatsoever inserted by the compiler to deal with >> *entering* a >> try block. To me this suggests that try blocks, of themselves, do not >> impose >> any performance hit whatsoever. My understanding of this stems from >> looking >> at classes many years ago.. maybe things have changed since then, in >> which >> case I'd like to see some evidence of this. > > > I'm sure I could come up with evidence that try/catch may significantly > hurt performance. I don't think it would get us anywhere though. > > The contents of class files do not necessarily imply the method of > execution. So evidence of what they contain is not evidence of how the > code is actually run. > > Tom Hawtin The basic rule you should follow in this situation is: While whatYourDoingHurtsTooMuch() increaseHowMuchYouChargeForIt();
From: Roedy Green on 15 Sep 2005 01:03 On 14 Sep 2005 07:15:59 -0700, "dmcreyno" <david.mcreynolds(a)gmail.com> wrote or quoted : >No one seems to be able to articulate exactly what problem is being >solved, just some vague references to performance which I find counter >intuitive. If a try clause causes the compiler to create a "protected" >section of code then more "trys" will lead to more "protected" sections >(protected: stack trace maintenance) and that souldn't be a good thing. He may just be reacting to the other extreme a single try catch (Exception e) for the entire application3. -- Canadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts.
From: jan V on 15 Sep 2005 04:33 > > Sorry to be picky about this, but can you give any evidence that any > > production JVM does anything on entering or leaving a try block (within a > > try-catch context, not a try-finally)? > > However, the JIT needs to somehow arrange for exception handling to work > in native machine code. How it does that is going to depend on the > processor architecture and stack frame setup used in native code on the > target machine. It may or may not involve emitting one or more machine > code instructions to enter a try block. You won't see any evidence of > this in bytecode, which is platform-independent. You've got a good point. I admit I wasn't thinking beyond vanilla JVM.. I hadn't thought of any JIT implications. But still, having done lots of assembler "in the old days", I still don't see why entering a try block would require any special machine code sequence. The way I see it is that it's the the throw event which triggers the logic which is going to cost you cycles. It's the implementation of the throw which will need to scan the exception tables etc.. and I still don't see how generating any special "here we're entering a try block code" code would make all the difference to the JIT performance of dealing with exceptions.
From: jan V on 15 Sep 2005 04:35 > >> If your spouse asks you to get a carton of milk on the way > >> home from > >> work do you insist s/he substantiate his/her reason? > > > > I think you're confuse software construction with keeping a > > man-woman > > relationship happy. I don't see any analogy.. > > It is the employee/employer relationship I was talking about. You were talking about spouses and cartons of milk. Re-read your own post!
From: Chris Uppal on 15 Sep 2005 04:34
Chris Smith wrote: > > Last time I poured over class file disassemblies, I noticed a distinct > > lack of any logic whatsoever inserted by the compiler to deal with > > *entering* a try block. To me this suggests that try blocks, of > > themselves, do not impose any performance hit whatsoever. My > > understanding of this stems from looking at classes many years ago.. > > maybe things have changed since then, in which case I'd like to see > > some evidence of this. > > > > If you can point me to any JVM instruction supporting your claim, that > > would be enough. ;-) > > You are looking in exactly the wrong place. > > Java bytecode is the input into a JIT compiler which generates native > machine code. The class file format separate exception handling into a > separate exception table, residing outside of the bytecode stream. The > entire format, including the exception table, acts as an intermediate > language. There's a point here. The hardest part (IMO) of implementing zero-cost exception handlers (the "zero" referring to the cost of entering/leaving a protected block) is generating the maps from IP indexes to handlers. The classfile format cleverly (this is one of the relatively few things I genuinely admire in the classfile format) requires that the compiler generate those maps, since that's the only way to express which code is protected by which block. (The spec could instead have bytecodes for entering/leaving protected zones -- as is the case with entering/leaving monitors -- but happily does not.) That means that for most reasonable JVM implementations -- whether naive interpreters or clever JITing systems -- there is very little reason not to provide actual zero-cost handlers. (Obviously a JIT will have to do more work to maintain the mappings than an interpreter, but they are much more complicated anyway, and I doubt if the /relative/ cost is significantly greater). In fact the only half-way reasonable implementation technique that would not be able to take advantage of the maps is an implementation based on translating the bytecodes into another high-level language that itself does not have zero-cost exception handling. Personally, I don't know of any realistic implementation that works that way, and I certainly doubt if any exist that are intended for production use. I suppose another circumstance where it might be difficult or impossible to implement zero-cost handlers would be a machine architecture that was so circumscribed that not even the lowest-level of machine-dependent programming would give you access to the runtime stack. Maybe such architectures exist, but -- again -- I don't personally know of any. -- chris |