Community
Participate
Working Groups
In Eclipse 3.0GA: Go to Window -> Preferences -> Java -> Compiler -> Compliance & Class Files. On this page there's a checkbox for having the Java compiler inlining finally blocks. I fail to see the point of this feature. I can see two cases: 1. The finally block is on a hot path once the code runs. The JVM sees this and inlines the finally block, at least for the hot catch blocks. Having it inlined in the cold catch blocks as well (which this feature does) is a waste of space and may pollute the CPU's code cache with junk. 2. The finally block in not on a hot path. Inlining it (which this feature does) is a waste of space and may pollute the CPU's code cache with junk. Is there a third option that I'm missing? The description of the option says that it leads to "larger class files" (correct) and "improved performance". Under what conditions have the inlined finally blocks actually lead to "improved performance"? If this (premature AFAICT) optimization actually yields a performance gain, a bug should be raised with the JVM vendor.
JSR202 describes this evolution. Basically, from 1.5 on, compilers are no longer supposed to generate bytecode instruction 'jsr' (jump subroutine) which is used for finally blocks. This instruction is giving headaches to VM implementors, so the VM specs are being evolved to deprecate this instruction (sadly for compilers which have to generate longer bytecode sequence due to inlining). I fully agree with your claim, but we have to comply. Note that space is bigger, but the file will load faster, since the verification process will be much faster... In preparation for this evolution, we added an option to our compiler for enabling this behavior so as for clients to measure its impact.
My previous should have said: "from target 1.5 on".
Cool. Thanks for the explanation.
