try/catch
in [Java Programming]
|
Next: localhost:9080
From: jan V on 14 Sep 2005 15:37 > Isn't this the kind of behaviour that gives programmers a bad name? What? Expecting to work with professional colleagues? ;-) The description of the behaviour outlined was greatly simplified... of course there are plenty of times when I would first ask people to give me some rational reason, or a technically valid explanation, but all too often making such reasonable, polite requests is greeted with frowns.. , also very often the reason given is technically flawed, and the person making the flawed statement refuses to accept the technically correct view, so eventually one stops being reasonable and stops asking for justification. I would have thought that's only normal human behaviour. > 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..
From: Chris Smith on 14 Sep 2005 16:17 jan V <nul(a)nul.be> wrote: > > On the other hand, as you mention, it's possible that the JIT is > > choosing an implementation of try/catch that requires work when > > entering/exiting a try block. > > 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)? No, I can't. Nevertheless, it is not prohibited by any specification, and I'm not familiar with all existing computer architectures; I can't therefore say whether it ever happens or not. I *DID* say that it's unlikely, which you then chose to ignore. I can't explain that decision of yours either. That said, though... > 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. 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. -- www.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation
From: Thomas Hawtin on 14 Sep 2005 16:27 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 -- Unemployed English Java programmer http://jroller.com/page/tackline/
From: Joan on 14 Sep 2005 18:10 "jan V" <nul(a)nul.be> wrote in message news:IZ_Ve.194075$OO.10660911(a)phobos.telenet-ops.be... >> Isn't this the kind of behaviour that gives programmers a bad >> name? > > What? Expecting to work with professional colleagues? ;-) > > The description of the behaviour outlined was greatly > simplified... of > course there are plenty of times when I would first ask people > to give me > some rational reason, or a technically valid explanation, but > all too often > making such reasonable, polite requests is greeted with > frowns.. , also very > often the reason given is technically flawed, and the person > making the > flawed statement refuses to accept the technically correct > view, so > eventually one stops being reasonable and stops asking for > justification. I > would have thought that's only normal human behaviour. > >> 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.
From: Bent C Dalager on 14 Sep 2005 18:52
In article <1126725341.740797.53650(a)z14g2000cwz.googlegroups.com>, Sanjay <sanjay.chittar(a)gmail.com> wrote: >Well I just wanted to add another point here. > >With whatever I have read, I think the real performance hit would be >(if at all it is substantial), could be when the exception is thrown. Not when it is thrown so much as when it is created, since . . . > > ( . . . ) >This could be a performance hit since VM has to gather the stack trace >information. .. . . it needs to create a stack trace at that time. Actual throwing and catching is comparably cheap. Or so I've read somewhere anyway <g> (Which is, I realise, what you probably meant to say in the first place.) However, if this is correct and if the computation is sufficiently expensive that it might conceivably be measurable, there really ought to be a way to turn off stack traces in exceptions. Most of the time, you don't actually need the stack anyway. Cheers Bent D -- Bent Dalager - bcd(a)pvv.org - http://www.pvv.org/~bcd powered by emacs |