RFR (S) 8222185: Shenandoah should report "committed" as capacity

Zhengyu Gu zgu at redhat.com
Tue Apr 9 14:00:52 UTC 2019


Good to me.

-Zhengyu

On 4/9/19 9:55 AM, Aleksey Shipilev wrote:
> 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.243msGoo
> 
> 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
> 



More information about the hotspot-gc-dev mailing list