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

[Vladimir Kozlov]

OK.

Vladimir

Christian Thalinger wrote:
> On Mar 18, 2011, at 5:51 PM, Vladimir Kozlov wrote:
>> I like these changes :) Thank you for doing this.
>>
>> Remove the assert. Why you got compile_id 0 for native wrapper?
> 
> That was before I commented the assert, I just assigned 0.
> 
> I just did an additional change: we can print the native wrapper after it was created and use the print_compilation method that takes an nmethod.  Then we can remove this version:
> 
>   static void  print_compilation(outputStream* st, methodOop method, int compile_id, const char* msg = NULL) {
> 
> webrev updated.
> 
> -- Christian
> 
>> 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 :-)
> 
>