TraceTypeProfile as diagnostic option

[Vladimir Kozlov]

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