JEP 271: Unified GC Logging - Second pre-review
kirk.pepperdine at gmail.com
Sat Nov 7 23:33:43 UTC 2015
> On Nov 7, 2015, at 5:10 PM, Simone Bordet <sbordet at webtide.com> wrote:
> 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.
Ok, let me suggest a format. This is all the information I need. Everything else is chatter.
>> [11.247s][info ][gc,heap ] GC#265 38912K->0K(2048K) 4096K->4096K(6144K) 68990K->73147K(131072K) 2993K->2993K(1056768K)
> 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.
agreed but these are easily derived for full STW collectors, a bitch for concurrent collectors are resets don’t report amounts released and young collections are consuming as the concurrent collection proceeds. I just extrapolate based on best guess in these case and that seems to work well enough
> 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.
Good point, Humongous is technically another region and it’s important to track with the G1.
> 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
I’ve asked for resolution in K. M is far to coarse IMO.
More information about the hotspot-gc-dev