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