PrintSafepointStatistics (was Re: understanding GC logs)

[Y. S. Ramakrishna]

There should be a header line that tells you what each column represents. It
was in one of your earlier emails, see below:
(The column header is printed more frequently in later versions of the JVM
making interpretation easier; see also more on that below.)

On 08/04/11 10:34, Darji, Kinnari wrote:
> Ramki,
> I tried it one more time and my process came up fine. I see following logs in console log. Though I don't see anything on verbose GC logs. Is that proper output? If so, how do I interpret following logs?
> 
> Deoptimize                         [       8          0              0]          [     0     0     0]     [     0        0]          0
> Deoptimize                         [       9          0              0]          [     0     0     0]     [     0       26]          0
> Deoptimize                         [       9          0              0]          [     0     0     0]     [     0       46]          0
> Deoptimize                         [      13          0              0]          [     0     0     0]     [     0      860]          0
> Deoptimize                         [      13          0              0]          [     0     0     0]     [     0      714]          0
> Deoptimize                         [      15          0              0]          [     0     0     0]     [     0      760]          0
> Deoptimize                         [      15          0              0]          [     0     0     0]     [     0        0]          0
> Deoptimize                         [      15          0              0]          [     0     0     0]     [     1      310]          0
> GenCollectForAllocation            [      15          0              0]          [     0     0     0]     [    27      292]          0
> Deoptimize                         [      18          0              0]          [     0     0     0]     [     0      821]          0
> EnableBiasedLocking                [      30          0              0]          [     0     0     0]     [     1      355]          0
> BulkRevokeBias                     [      32          1              0]          [     0     0     0]     [     3     1905]          0
> RevokeBias                         [      32          0              1]          [     0     0     0]     [     3        9]          0
> RevokeBias                         [      31          0              2]          [     0     0     0]     [     0        4]          0
> RevokeBias                         [      30          0              0]          [     0     0     0]     [     1        1]          0
> RevokeBias                         [      29          0              0]          [     0     0     0]     [     2        7]          0
> RevokeBias                         [      28          0              1]          [     0     0     0]     [     2        2]          0
> BulkRevokeBias                     [      28          0              1]          [     0     0     0]     [     0        2]          0
> RevokeBias                         [      27          1              0]          [     0     0     0]     [     1        1]          0
> RevokeBias                         [      25          0              1]          [     0     0     0]     [     2        3]
> 
> Thank you
> Kinnari
> 

This here:-

...
>>      vmop_name               [threads: total initially_running wait_to_block] [time: spin block sync] [vmop_time  time_elapsed] page_trap_count

Unfortunately, this is not the easiest thing to interpret if you are not familiar
with the JVM safepoint protocol details (it's intended for extreme performance
tuning or troubleshooting); not only that, because the data is printed in "batches",
it's less than easy to align it with GC or other logging.
(Later versions (in hs20 or later) fixed this somewhat by providing a JVM timestamp
against each -- wherease above you need to reconstruct that info from the deltas, which is
a pain.) So my advice is to use a newer JVM if you can, and if you can't then
just rely on the less detailed, but easier to align,
+PrintGCApplication{Concurrent,Stopped}Time flags.

By the way, if the crash that you reported earlier does not in fact
happen, please make sure to tell the support engineering contacts, who
may contacted you off-list, so they can close off any ticket they may
have opened for your report.

thanks.
-- ramki
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use