Compiled call version seems to be slower

Ulf Zibis Ulf.Zibis at gmx.de
Wed Nov 25 15:12:19 PST 2009


Am 23.11.2009 12:01, Christian Thalinger schrieb:
> On Sat, 2009-11-21 at 22:44 +0100, Ulf Zibis wrote:
>   
>> In my attached example -XX:+PrintAssembly outputs 2 versions for 
>> sun.nio.cs.ext.EUC_TW_C_d_b_codeToBuffer4$Decoder::decodeArrayLoop.
>>
>> The 1st one seems for call from compiled calling method, the 2nd for 
>> call from byte code interpreter.
>> Looking closer to the -XX:+PrintAssembly output, 1st version seems to
>> be 
>> slower, i.e. has more instructions in the loop code.
>>
>> Additionally I'm wondering why the finally block is copy-and-pasted
>> for 
>> each separate return.
>> Is that as disired ?
>>     
>
> I just had a quick glance at the code and it seems the second one has a
> better register allocation, for whatever reason.  And maybe (would need
> to look closer) basic block ordering is different.
>   

Additional question:
What does that mean in exact, that there are 2 little different compiler 
outputs for the same method?
Which of the 2 would actually run?

> -- Christian
>
> PS: It would be much easier when you would attach two files and give
> some hints (e.g. addresses) where the code is you're talking about.
>   

I'm not sure if I understand right. I had attached the java file and the 
PrintAssembly output, but got:
(but anyway, I CC:ed you so you should got the 2 files.)

Your mail to 'hotspot-compiler-dev' with the subject

    Compiled call version seems to be slower

Is being held until the list moderator can review it for approval.

The reason it is being held:

    Message body is too big: 314879 bytes with a limit of 100 KB


-Ulf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20091126/dabde37d/attachment.html 


More information about the hotspot-compiler-dev mailing list