+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