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