RFC: Adaptively resize heap at any GC/SoftMaxHeapSize for G1
thomas.schatzl at oracle.com
Tue Jul 7 09:54:11 UTC 2020
On 06.07.20 11:11, Thomas Schatzl wrote:
> On 05.07.20 18:21, Ruslan Synytsky wrote:
>> Unfortunately GC.heap_info and VM.info do not provide information about
>> COMMITTED heap. And jstat documentation
That is actually not true :) While looking into JDK-8248136, G1 actually
already prints committed heap with GC.heap_info.
E.g. on an application with -Xms64m -Xmx1024m the output is:
$ jcmd 30653 GC.heap_info
garbage-first heap total 519168K, used 315920K [0x00000000c0000000,
region size 1024K, 116 young (118784K), 23 survivors (23552K)
The "total" is "available" regions (i.e. ~committed) as explained in the
previous post (I kept the relevant part below).
This is probably the case since introduction of uncommit within the heap
in 8u40 (JDK-8038423).
> Sorry. However, VM.info prints the whole heap map with G1, i.e. for
> every region what type it is. For uncommitted regions, it does not print
> such a line in the "Heap regions" section...(*)(**) so you could count
> the lines and compare with what would be expected.
> (*) the | 0|0x0000000600000000, 0x0000000600400000,
> 0x0000000600400000|100%| O| |TAMS 0x0000000600400000,
> 0x0000000600000000| Untracked lines
> (**) that is not completely correct, it prints "available" regions, i.e.
> regions that the topmost layer of g1 thinks are there, but in some
> cases, this is not entirely correct. I.e. if page size is > region size,
> a region on one page may be "unavailable", but another is, but obviously
> in that case the whole page, i.e. the space for all two regions, are
> But you can reconstruct the data as the indices in that list are fixed.
> E.g. if VM.info shows you, assuming 1m region and 2m page size. When
> using small (4k) pages, this situation can't happen because region size
> is always > page size at least on x86:
> | 0| ...
> | 1| ...
> | 3| ...
> | 4| ...
> | 5| ...
> | 8| ...
> then the page 0 where region 0/1 are located is committed, page 1 where
> region 2/3 are located is committed (because g1 can't uncommit half
> pages obviously), page 2 where region 4/5 is committed, page 3 where
> regions 6/7 are NOT committed because both are missing, and so on.
> I hope this makes sense to you.
> While a somewhat cumbersome way to find this out, this works since
> jdk8u40 (implemented in JDK-8038423) iirc.
> I recently filed JDK-8248136 for improving the heap info output for G1.
More information about the hotspot-gc-dev