TraceTypeProfile as diagnostic option (original) (raw)

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Sep 11 14:59:48 PDT 2012

As Aleksey found, it is only about 100 bytes size increase. So I am fine if you convert it into diagnostic flag. I said we need to be careful in general case when the size increase could be much larger.

Vladimir

Nils Eliasson wrote:

What about changing it to an #ifndef EMBEDDED then? (or what the name may be...)

//N Vladimir Kozlov skrev 2012-09-10 19:22: We need to be careful here. It will increase product VM size (currently that code is under #ifndef PRODUCT) and embedded group will kill us for that. I think we should look on this case by case. You still can figure out that it is bimorphic call since they have the same bci (@ 4).

Vladimir Nils Eliasson wrote: AFAIK, all verbose/trace/debug-print output should be available in product builds behind flag + diagnostic. It is such a time saver when you can use it directly, it simplifies the code, and can be very helpful when debugging in situations where product builds are required.

//N Aleksey Shipilev skrev 2012-09-10 13:08: Hi,

First, let me describe the rationale. When I'm looking into the disassembly, I use this command line to dump the generated assembly: -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:+TraceTypeProfile -XX:+PrintCompilation -XX:+PrintInlining -XX:CICompilerCount=1 This generates arguably human-readable output in the form: for [each method]; do [PrintCompilation prints single compile record] [PrintInlining prints inlining tree] [PrintAssembly dumps the disassembly] done Soon enough I realize that bimorphic calls in inlining tree have arguably counter-intuitive form: 81 13 TestInline::doWork (56 bytes) @ 35 TestInline$DelegatingIterator::next (10 bytes) inline (hot) @ 4 java.util.ArrayList$Itr::next (66 bytes) inline (hot) @ 4 TestInline$DelegatingIterator::next (10 bytes) inline (hot) Naively-looking that might mean the $DelegatingIterator::next calls both next() methods in the code, but that is confusing because there is a single virtual call in the user code. Enabling -XX:+TraceTypeProfile helps a lot: @ 35 TestInline$DelegatingIterator::next (10 bytes) inline (hot) -> TypeProfile (128014/128014 counts) = TestInline$DelegatingIterator @ 4 java.util.ArrayList$Itr::next (66 bytes) inline (hot) @ 4 TestInline$DelegatingIterator::next (10 bytes) inline (hot) -> TypeProfile (29297/58595 counts) = TestInline$DelegatingIterator -> TypeProfile (29298/58595 counts) = java/util/ArrayList$Itr ...albeit being a bit misplaced. But here's the kicker: -XX:+TraceTypeProfile is only available in fastdebug build, and so I need to make additional step to figure this out. For my taste, tracing type profiles should instead be unlocked with -XX:+UnlockDiagnosticVMOptions. Are there any benefits of hiding this? If not, I would be happy to provide the patch bringing it on par with other diagnostic options. -Aleksey.

More information about the hotspot-compiler-dev mailing list