Compiled call version seems to be slower

[Tom Rodriguez]

On Nov 30, 2009, at 3:32 PM, Ulf Zibis wrote:

> Am 30.11.2009 19:10, Tom Rodriguez schrieb:
>>>>>>>> Additionally I'm wondering why the finally block is copy-and-pasted
>>>>>>>> for each separate return.
>>>>>>>> Is that as disired ?
>>>>>>>> 
>>>>>>>>              
>>>> Sorry about asking once more. Would it be so hard to avoid the 6-times redundancy of the finally block, or are there other reasons?
>>>>      
>>> Well, I guess no, but everyone is busy with more important stuff.  But
>>> hey, it's open source :-)
>>>    
>> 
>> The 6 copies of the finally block are there in the bytecodes.
> 
> Yes, you are right.
> 
>>  It's not something hotspot is creating.  A finally is executed on every return path so a copy of that code is needed at every return.  Conceivably javac could merge all the return paths through a single return with a single copy of the code but it doesn't do that.
> 
> So I should file a bug against javac ?

You could.  There's no reason not to.  Maybe from their perspective it makes mapping back to the original source harder since mapping the return bytecode back to the original wouldn't work the same.  Anyway, I doubt it's a near term path to happiness.

> 
>>  You could reshape your code to look like that if you wanted to avoid multiple copies.
>>  
> 
> Hm, any idea how to do that ß

You need to capture all possible return values into a local variable and return that in one place. You'll probably need to use a break to get out of the loop.  So a structure something like this:

int result = -1;
while (foo) {
  if (cond) {
    result = 1;
    break;
  }
  if (cond2) {
    result = 2;
    break;
  }
}
return result;

it's ugly so make sure it's worth it.  There are probably other ways of structuring it too.

tom

> 
> -Ulf
> 
>