G1 uses extra memory for RSets

Thomas Schatzl thomas.schatzl at oracle.com
Fri Sep 8 19:36:58 UTC 2017


Hi,

On Thu, 2017-09-07 at 18:18 +0000, Stanislav Levental wrote:
> Hello,
> 
> I have few questions regarding G1 RSets.
> 
> We are running java on a 30Gb machnie with Xmx=20Gb, howewer, java
> managed to use extra 7.5Gb above that 20Gb. According to NMT, the
> most significant sources of memory consumptions are:
> 
> Java Heap (reserved=20971520KB, committed=20971520KB)
>                             (mmap: reserved=20971520KB,
> committed=20971520KB) 
> 
> GC (reserved=3021667KB, committed=3021667KB)
>                             (malloc=2210659KB #61926090)
>                             (mmap: reserved=811008KB,
> committed=811008KB)
> 
> Internal (reserved=2358976KB, committed=2358976KB)
>                             (malloc=2358944KB #1205678)
>                             (mmap: reserved=32KB, committed=32KB)
> 

Note that with jdk10 (or whatever it's name will be) all remembered set
memory will be part of the "GC" source. [0]

> Assuming that most of the memory is claimed by G1, I've added an
> option to track what is RSet consumption stat is:
> 
> Current rem set statistics
>   Total per region rem sets sizes = 2803150K. Max = 2448K.
>          128K (  0.0%) by 13 Young regions
>           76K (  0.0%) by 7 Humonguous regions
>         8874K (  0.3%) by 898 Free regions
>      2794071K ( 99.7%) by 1642 Old regions
>    Static structures = 290K, free_lists = 11539K.
>     2878842478 occupied cards represented.
>             0 (  0.0%) entries by 13 Young regions
>            47 (  0.0%) entries by 7 Humonguous regions
>             0 (  0.0%) entries by 898 Free regions
>      2878842431 (100.0%) entries by 1642 Old regions
>     Region with largest rem set =
> 75:(O)[0x00000002e5800000,0x00000002e6000000,0x00000002e6000000],
> size = 2448K, occupied = 1687K.
>   Total heap region code root sets sizes = 114K.  Max = 29K.
>            0K (  0.2%) by 13 Young regions
>            0K (  0.1%) by 7 Humonguous regions
>           14K ( 12.2%) by 898 Free regions
>          100K ( 87.5%) by 1642 Old regions
>     3010 code roots represented.
>             0 (  0.0%) elements by 13 Young regions
>             0 (  0.0%) elements by 7 Humonguous regions
>             0 (  0.0%) elements by 898 Free regions
>          3010 (100.0%) elements by 1642 Old regions
>     Region with largest amount of code roots =
> 147:(O)[0x0000000309800000,0x000000030a000000,0x000000030a000000],
> size = 29K, num_elems = 1.
> , 0.6920868 secs]
> 
> Looks like half of this 7Gb extra is cards and bitmaps for RSet. So
> my questions are:
>  - Is there any information about internal implementation details
> available anywhere?

I could not find a publicly available accurate documentation of the
remembered set data structures.
So unfortunately, the sources are the only information (and of course
always accurate "documentation") available at this time.

> - Is there a way to estimate what overhead would be and how this is
> related to app memory footprint?

Recently on this very list a fairly accurate worst case estimation has
been attempted [1] (for 64 bit VMs).

If you have questions about that calculation, feel free to ask about
things that are unclear.

Another answer to a similar question a bit longer out gives ideas on
how to improve remembered set memory usage [2].

>  - In our app it's mostly strings and we are using strings
> deduplication, could it be the problem, since it creates extra
> references between regions, increasing footprint for RSet?

Could be, but would need verification. Try bumping heap region size to
32M too.

Thanks,
  Thomas

[0] https://bugs.openjdk.java.net/browse/JDK-8176571
[1] http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2017-August/0
02693.html
[2] http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2017-March/00
2640.html and http://mail.openjdk.java.net/pipermail/hotspot-gc-use/201
7-February/002609.html and http://mail.openjdk.java.net/pipermail/hotsp
ot-gc-use/2017-January/002574.html



More information about the hotspot-gc-use mailing list