+PrintInlining falsly? says: never executed
Ulf Zibis
Ulf.Zibis at gmx.de
Thu Dec 3 15:34:44 PST 2009
Tom, thanks for taking the time.
I'm afraid, your assumption is wrong.
In the mentioned log files, you can see clearly, that besides the ascii
path all other paths have been executed too. In
hsdis-MaxInlineSize=250_static-EUC_TW_C_d_b_codeToBuffer4$Decoder.decodeArrayLoop,.decode.log
refer to lines like:
EUC_TW_C_d_b_codeToBuffer4 65536 ASCII bytes in 162 ms decoded to
65536 chars
EUC_TW_C_d_b_fastLoop3 65536 ASCII bytes in 127 ms decoded to
65536 chars
EUC_TW_C_d_b_codeToBuffer4 65536 Plane0 bytes in 322 ms decoded to
32768 chars
EUC_TW_C_d_b_fastLoop3 65536 Plane0 bytes in 290 ms decoded to
32768 chars
EUC_TW_C_d_b_codeToBuffer4 65536 Plane2 bytes in 215 ms decoded to
16384 chars
EUC_TW_C_d_b_fastLoop3 65536 Plane2 bytes in 157 ms decoded to
16384 chars
...
-Ulf
Am 03.12.2009 20:17, Tom Rodriguez schrieb:
> I looked at that a bit but it's not very obvious to me what's happening. I suspect that's since the decode path is only used for nonascii that at the point it's getting compiled we haven't seen anything but ascii so the decode path doesn't appear to be used. Could that be it?
>
> tom
>
> On Nov 30, 2009, at 5:00 PM, Ulf Zibis wrote:
>
>
>> Am 01.12.2009 01:12, Tom Rodriguez schrieb:
>>
>>>>>> I get:
>>>>>> @ 180 sun.nio.cs.ext.EUC_TW_C_d_b_codeToBuffer4$Decoder::decode never executed
>>>>>> and
>>>>>> static sun/nio/cs/ext/EUC_TW_C_d_b_codeToBuffer4$Decoder.decode(BBI[C[II)Ljava/nio/charset/CoderResult;
>>>>>> interpreter_invocation_count: 10001
>>>>>> invocation_counter: 5001
>>>>>> backedge_counter: 1
>>>>>>
>>>>>>
>>>>> Where did this output come from? Was it printed at the time it was being checked for inlining?
>>>>>
>>>>>
>>>> I comes from -XX:PrintAssemblyOptions. Yes, it was printed at same time.
>>>>
>>>>
>>> I don't see how PrintAssemblyOptions could produce that output. I think those counts come from the CompileCommand=print option below and those are printed at the end of the run. So I'm guessing that at the point the compile was occurring decode actually hadn't been called.
>>>
>> I suspect, this had happened here, because the decode() method should have been executed as many times, as the JIT threshold for compiling the frequent branches of decodeArrayLoop().
>>
>>
>>> The can sometimes result from inlining. What was the whole inline tree? I think you'd have to look into the debugger to make sure.
>>>
>>>
>> You can find my sources here (in the test tree):
>> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/j7_EUC_TW/?rev=833
>>
>> The complete hsdis outputs are in the log folder.
>>
>> -Ulf
>>
>>
>>
>>
>
>
>
More information about the hotspot-compiler-dev
mailing list