TraceTypeProfile as diagnostic option

[Nils Eliasson]

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.
>>