Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely

[Vladimir Kozlov]

I like these changes :) Thank you for doing this.

Remove the assert. Why you got compile_id 0 for native wrapper?

Thanks,
Vladimir

Christian Thalinger wrote:
> On Mar 17, 2011, at 7:19 PM, Tom Rodriguez wrote:
>>>> Native wrappers are never inlined.  That would be a intrinsic in the output you show above.  Intrinsic inlining should always have a bci though.
>>> Ahh, right, I mixed them.  When I'm already at it, should I change the intrinsic output too:
>>>
>>> Inlining intrinsic _min at bci:67 in sun.nio.cs.UTF_8$Encoder::encodeArrayLoop (489 bytes)
>>>
>>> to fit into the inlining tree?
>> I wouldn't mind that.  Something like the normal output but with "(intrinsic)" at the end?
> 
> Alright, I changed a lot more than I wanted to but now it seems much better and clearer, at least to me.
> 
> I removed nmethod::print_compilation completely (which was called from CompileTask::print_compilation) and moved all printing logic into CompileTask.
> 
> http://cr.openjdk.java.net/~twisti/7022998/
> 
> Some output looks a little different now, like instrinsics (as we talked about):
> 
>    1111    3             java.lang.String::lastIndexOf (68 bytes)
>                             @ 26   java.lang.Math::min (11 bytes)   (intrinsic)
> 
> To be able to remove some utterly complex code (the title code from nmethod::print_compilation), made_not_entrant and made_zombie messages are now printed and the end of the line (like all other status messages).  Additionally I added a status flag (e = not entrant, z = zombie):
> 
>    4006  150      z 4       java.lang.String::equals (88 bytes)   made zombie
>    4565  121      e 3       java.util.HashMap::get (79 bytes)   made not entrant
> 
> Type profile output looks like:
> 
>       @ 121   java.util.HashMap::addEntry (58 bytes)   inline (hot)
>        \-> TypeProfile (6020/6257 counts) = java/util/HashMap
> 
> or:
> 
>       @ 89   java.util.LinkedHashMap$Entry::recordAccess (35 bytes)   inline (hot)
>        \-> TypeProfile (13/131 counts) = java/util/LinkedHashMap$Entry
>        \-> TypeProfile (118/131 counts) = java/util/HashMap$Entry
> 
> Native wrapper compiles now look like this (I print a "-" instead of the compile level for tiered):
> 
>    2077    0     n  -       java.lang.System::nanoTime (0 bytes)   (static)
> 
> But the output might look a little odd since the native wrapper output may be between compile output and inline output looking like the native wrapper has an inlinee:
> 
>    2102   69        3       java.lang.CharacterDataLatin1::toUpperCaseEx (71 bytes)
>    2102    0     n  -       sun.misc.Unsafe::compareAndSwapInt (0 bytes)   
>                                @ 4   java.lang.CharacterDataLatin1::getProperties (11 bytes)
> 
> About the compile id for native wrappers, assign_compile_id has an assert:
> 
>   assert(!method->is_native(), "no longer compile natives");                                                                                                             
> 
> So either we remove that assert or we don't assign a compile id to native wrapper compiles.
> 
> Let me know what you think.
> 
> -- Christian
> 
> PS: The original bug fix is still in there :-)