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