JEP 271: Unified GC Logging - Second pre-review

[Simone Bordet]

Hi,

On Sat, Nov 7, 2015 at 12:24 PM, Kirk Pepperdine
<kirk.pepperdine at gmail.com> wrote:
> Hi Bengt,
>
> A couple of comments aimed at bulk and/or frequency trade-offs.
>
> [11.247s][info   ][gc          ] GC#265 GC young (G1 Evacuation Pause)
> 109M->71M(128M) (11.228s, 11.247s) 19.208ms
>
> with the exception of the pause time, this line seems redundant.
>
> [11.247s][info   ][gc,heap     ] GC#265 Eden: 38912K->0K(2048K)
> [11.247s][info   ][gc,heap     ] GC#265 Survivor: 4096K->4096K(6144K)
> [11.247s][info   ][gc,heap     ] GC#265 Old: 68990K->73147K(131072K)
> [11.247s][info   ][gc,metaspace] GC#265 Metaspace: 2993K->2993K(1056768K)
>
> can these 4 lines be combined?

Don't we also need some number to calculate the promoted bytes ?
I was doing this before using: promoted = total_young_delta - total_heap_delta.

With the above proposal, how would one know if the old generation
delta is entirely due to promotion or if there was some cleanup (e.g.
mixed GCs) that affected the old generation ?

For my use cases the 3 most important value I would like to easily
detect are the allocation rate, the promotion rate and the GC times.

Allocation rate is kind-of easy by looking at Eden, although this
would not account for humongous allocations. I would appreciate if it
was more precise, accounting for humongous allocations as well.
Promotion rate, I am not sure how to get it from what above, also
considering that total heap is in M while detailed generation is in K
(would be nicer they are in the same unit) so there could be important
inaccuracies.

Thanks !

-- 
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.