TraceTypeProfile as diagnostic option

Vladimir Kozlov vladimir.kozlov at oracle.com
Mon Sep 10 10:22:36 PDT 2012


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