Determining "GC" memory area size

[Glyn Normington]

Thanks Aleksey, Zhenghu, and Yumin: that's very helpful. I'll start another
thread on what I believe is an additional requirement for JEPS 8182070.

Regards,
Glyn

On Fri, Nov 10, 2017 at 9:45 PM, yumin qi <yumin.qi at gmail.com> wrote:

> 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
>>>
>>>
>>>
>


-- 
Regards,
Glyn