Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely
christian.thalinger at oracle.com
Fri Mar 18 09:18:07 PDT 2011
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.
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
@ 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.
PS: The original bug fix is still in there :-)
More information about the hotspot-compiler-dev