JEP 271: Unified GC Logging - Second pre-review
bengt.rutisson at oracle.com
Mon Nov 9 09:23:28 UTC 2015
On 2015-11-07 17:10, Simone Bordet 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.
> 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.
Sorry, but I don't understand how using the value for the Old generation
to compute the promotion rate the way you describe it is any different
than using the overall heap usage. The overall heap usage is just
> 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
I see your point about using the same unit for both types of logging.
The reason I chose different units is that for the single line logging I
would like the values to be as compact as possible to avoid that the
line gets too long. For the more detailed logging we have more space and
can use better precision. My thinking was that if you are interested in
the details you could turn the more detailed logging on.
> Thanks !
More information about the hotspot-gc-dev