RFR (S) 8222185: Shenandoah should report "committed" as capacity
Roman Kennke
rkennke at redhat.com
Tue Apr 9 16:14:55 UTC 2019
RFE:
> https://bugs.openjdk.java.net/browse/JDK-8222185
>
> Fix:
> http://cr.openjdk.java.net/~shade/8222185/webrev.01/
>
> Shenandoah resizes the heap by (un)committing the individual regions.
> Therefore, the true heap
> capacity is the "committed" size, not the maximum possible capacity.
> Currently, gc logs misreport
> the heap size, for example with -Xms1g -Xmx4g:
>
> GC(2) Concurrent marking 183M->183M(4096M) 2.243ms
>
> Notice "(4096M)", which is not the actual memory taken by committed
> heap. With this patch, we
> properly report the current capacity:
>
> GC(5) Concurrent marking (process weakrefs) 137M->137M(138M)
> 2.750ms
>
> I had to rewrite current uses: "capacity" -> "max_capacity" in
> heuristics, and "committed" ->
> "capacity" in monitoring code.
>
> Testing: hotspot_gc_shenandoah, eyeballing gc logs
Patch looks ok. I wonder if it would make sense to report max_capacity
too? On the other hand, it would then be sufficient to report it once
because it never changes.
Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20190409/55087daa/signature.asc>
More information about the hotspot-gc-dev
mailing list