+PrintInlining falsly? says: never executed

[Tom Rodriguez]

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
> 
> 
>