Can GC implementations provide a cheap estimation of live set size?
Jaroslav Bachorík
jaroslav.bachorik at datadoghq.com
Thu Feb 11 17:29:32 UTC 2021
Hi Roman,
Thanks for your response. I checked ZGC implementation and, indeed, it
is very easy to get the liveness information just by extending
`ZStatHeap` class to report the last valid value of
`_at_mark_end.live`.
I am also able to get this info from Shenandoah, although my first
attempt still involves a safepointing VM operation since I need to
iterate over regions to get the liveness info for each of them and sum
it up. I think it is still an acceptable trade-off, though.
The next one in the queue is the Serial GC. My assumptions, based on
reading the code, are that for young gen 'live = used' at the end of
DefNewGeneration::collect() method and for old gen 'live = used -
slack' (slack is the cumulative size of objects considered to be alive
for the purpose of compaction although they are really dead - see
CompactibleSpace::scan_and_forward()). Does this sound reasonable?
I will post my findings for Parallel GC and G1 GC later.
Cheers,
-JB-
On Wed, Feb 10, 2021 at 11:34 AM Roman Kennke <rkennke at redhat.com> wrote:
>
> Hello Jaroslav,
>
> > In connection with https://bugs.openjdk.java.net/browse/JDK-8258431 I
> > am trying to figure out whether providing a cheap estimation of live
> > set size is something actually achievable across various GC
> > implementations.
> >
> > What I am looking at is piggy-backing on a concurrent mark task to get
> > the summary size of live objects - using the 'straight-forward'
> > heap-inspection like approach is prohibitively expensive.
>
> In Shenandoah, this information is already collected during concurrent
> marking. We currently don't print it directly, but we could certainly do
> that. I'll look into implementing it. I'll also look into exposing
> liveness info via JMX.
>
> I'm not quite sure about G1: that information would only be collected
> during mixed or full collections. I am not sure if G1 prints it, though.
>
> ZGC prints this under -Xlog:gc+heap:
>
> [6,502s][info][gc,heap ] GC(0) Mark Start
> Mark End Relocate Start Relocate End High
> Low
> [6,502s][info][gc,heap ] GC(0) Capacity: 834M (10%)
> 1076M (13%) 1092M (14%) 1092M (14%) 1092M (14%)
> 834M (10%)
> [6,502s][info][gc,heap ] GC(0) Free: 7154M (90%)
> 6912M (87%) 6916M (87%) 7388M (92%) 7388M (92%)
> 6896M (86%)
> [6,502s][info][gc,heap ] GC(0) Used: 834M (10%)
> 1076M (13%) 1072M (13%) 600M (8%) 1092M (14%)
> 600M (8%)
> [6,502s][info][gc,heap ] GC(0) Live: -
> 195M (2%) 195M (2%) 195M (2%) -
> -
> [6,502s][info][gc,heap ] GC(0) Allocated: -
> 242M (3%) 270M (3%) 380M (5%) -
> -
> [6,502s][info][gc,heap ] GC(0) Garbage: -
> 638M (8%) 606M (8%) 24M (0%) -
> -
> [6,502s][info][gc,heap ] GC(0) Reclaimed: -
> - 32M (0%) 614M (8%) -
> -
>
> I hope that is useful?
>
> Thanks,
> Roman
>
More information about the hotspot-jfr-dev
mailing list