RFC: Adaptively resize heap at any GC/SoftMaxHeapSize for G1

[Thomas Schatzl]

Hi Ruslan,

On 06.07.20 11:11, Thomas Schatzl wrote:
> Hi,
> 
> 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
30653:
  garbage-first heap   total 519168K, used 315920K [0x00000000c0000000, 
0x0000000100000000)
   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).

Thanks,
   Thomas

> 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 
> committed.
> 
> 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.
> 
> Thanks,
>    Thomas