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

[Christian Thalinger]

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