+PrintInlining falsly? says: never executed
Thomas.Rodriguez at Sun.COM
Thu Dec 3 11:17:07 PST 2009
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?
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
>>>>> 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):
> The complete hsdis outputs are in the log folder.
More information about the hotspot-compiler-dev