Re: 答复: Discussion about logging *Basic* statistic of evacuation failure
Thomas Schatzl
thomas.schatzl at oracle.com
Tue Dec 7 10:31:26 UTC 2021
Hi,
On 06.12.21 12:47, lihuaming (A) wrote:
>
>> I would like to step away from the term "Evacuation Failure" in the log messages - we will be using this mechanism for pinned region as well and I'm not really sure that using a term with "failure" in the name for something that is a regular non-exceptional occurrence.
>
> Agree, "Evacuation Failure" is not a good option. :)
>
>> "Remove Self Forwards" is fine.
>>
>> Here are some suggestions for the log messages:
>>
>> In-Place Evacuation (ms) // Not sure if this is an "evacuation"
>> // but "In-Place" Handling isn't really
>> // good.
>> In-Place Regions // Maybe these three could be reported
>> // in "Object Copy"? But is fine here
>> Self Forwarded Objects // too.
>> In-Place Live Bytes
>>
>> "In-Place Regions" might be split later in "Pinned regions" and "Evacuation Failed Regions" (which we might use instead of "In-Place Regions" already).
>
> Sure, we will need to distinguish between "pinned regions" and "evacuation failed regions", I think we need to do the same for objects and bytes.
>
>> Would be nice to have "Memory Usage" for the segments/allocators too here somewhere.
>
> Sure.
>
>> As for the sub-phases I prefer more specific terms to generic ones like "prepare", "process", "cleanup".
>>
>> Sort Self Forward Refs (ms) // Also not that good probably :)
>> Remove Self Forwards (ms) // Actual work
>> Reclaim Memory (ms)
>
> Agree.
>
> To summarize your suggestions:
> ```
> [11.094s][debug][gc,phases] GC(0) Remove Self Forwards Total (ms): Min: 785.3, Avg: 1694.0, Max: 2515.6, Diff: 1730.4, Sum: 54209.0, Workers: 32
I kind of dislike the "Total" here - this is already indicated by the
indentation.
> [11.094s][debug][gc,phases] GC(0) Memory Usage Segments(bytes): Min: xxx, Avg: xxx.8, Max: xxx, Diff: xxx, Sum: xxx, Workers: 32
> [11.094s][debug][gc,phases] GC(0) Memory Usage Sort (bytes): Min: xxx, Avg: xxx.8, Max: xxx, Diff: xxx, Sum: xxx, Workers: 32
Please drop the "(bytes)" unit - we do not do these for other statistics
showing memory usage as well. It makes these identifiers shorter too.
Also something like
Segments Memory
Sort Memory
is just fine.
> [11.094s][debug][gc,phases] GC(0) In-Place Regions: Min: 79, Avg: 79.0, Max: 79, Diff: 0, Sum: 79, Workers: 1
I think at this time we can use "[Evacuation ]Failed Regions", and worry
about the others when we're there.
> [11.094s][debug][gc,phases] GC(0) Self Forwarded Objects: Min: 220509, Avg: 773970.7, Max: 1188749, Diff: 968240, Sum: 24767061, Workers: 32
> [11.094s][debug][gc,phases] GC(0) In-Place Live Bytes: Min: 6271696, Avg: 23578654.8, Max: 36133240, Diff: 29861544, Sum: 754516952, Workers: 32
In-Place Bytes. It's obvious that they are live. Also move that one to
trace level as it does not seem too interesting - we do not do work that
is dependent on the memory the self-forwarded objects take.
> [11.094s][debug][gc,phases] GC(0) Sort Self Forward Refs (ms): Min: 59.6, Avg: 231.4, Max: 363.7, Diff: 304.1, Sum: 7405.2, Workers: 32
> [11.094s][debug][gc,phases] GC(0) Remove Self Forwards (ms): Min: 632.9, Avg: 1431.2, Max: 2145.8, Diff: 1513.0, Sum: 45799.8, Workers: 32
> [11.094s][debug][gc,phases] GC(0) Reclaim Memory (ms): Min: 0.4, Avg: 1.7, Max: 2.8, Diff: 2.4, Sum: 52.9, Workers: 32
> ```
>
>> But probably others have better ideas :) I will continue thinking about this.
>
> :)
So my current suggestion is this (I reordered them a bit - typically we
are more concerned with timing than memory consumption :P), including
the levels (with debug level the default):
In-Place Collection (ms) [I really do not like "Remove Self
Forwards Total" ;)]
Sort Self Forward Refs (ms)
Remove Self Forwards (ms)
Reclaim Memory (ms) [trace, probably not interesting
most of the time, and can be deducted by subtraction]
Evacuation Failed Regions
Self Forwarded Objects
Self Forwarded Bytes [trace]
Segments Memory [trace, depending on typical size]
Sort Memory [trace, depending on typical size]
We can always improve this later, so I'd maybe wait for another
suggestion for a day or so and then let's go ahead with this.
Thanks,
Thomas
More information about the hotspot-gc-dev
mailing list