Determining "GC" memory area size

[yumin qi]

Hi, Glyn
http://openjdk.java.net/jeps/8182070
Upon its implementation, Java can get information of container and
confiture its own parameters for running in the container, more container
friendly.

Yumin

On Fri, Nov 10, 2017 at 11:11 AM, Zhengyu Gu <zgu at redhat.com> wrote:

>
>
> On 11/10/2017 01:47 PM, Aleksey Shipilev wrote:
>
>> On 11/10/2017 06:06 PM, Glyn Normington wrote:
>>
>>> Can anyone here tell me how the GC memory area size is determined? If
>>> there
>>> is documentation, so much the better as we'd prefer not to depend on code
>>> details that might flux arbitrarily.
>>>
>>
>> NMT reports all allocations from GC code (with mtGC tag) as "GC". This
>> includes, notably, Java heap
>> itself, and all auxiliary GC data structures. If you grep the OpenJDK
>> source for "mtGC", you can get
>> the idea what allocations are tagged. Also, "detailed" NMT mode would
>> give you allocation stacks,
>> which can also give some insight what those particular allocated bits are
>> coming from.
>>
>
> Java heap actually is *not* tagged as GC memory, but Java heap.
>
> -Zhengyu
>
>
>> The size of GC data structures is dependent on GC in question (and, quite
>> probably, depends on GC
>> implementation *version*, with swings back and forth), and thus is not
>> trivially deducible. For
>> simpler collectors, like Serial and Parallel, it would probably be
>> dominated by Card Table (1/512-th
>> of heap size). In G1, it is most probably mark bitmaps (2/64-th of heap
>> size), plus other
>> fine-grained remembered sets (which might get large, but maybe there is a
>> high bound?). Etc.
>>
>> Thanks,
>> -Aleksey
>>
>>
>>