TraceTypeProfile as diagnostic option

[Aleksey Shipilev]

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.