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