Excessive "GC" memory area size [was: Re: Determining "GC" memory area size]

[Glyn Normington]

On the basis of the reply below, we have been thinking of estimating the
size of the "GC" memory area as a little more than (1/32) * heapSize.
However, running `java -version` with a 350m heap results in "GC" memory as
reported by NMT of over 17% of the heap size, so this estimate is way out.

If the analysis below is accurate, then given the number of GC threads is
10 (ParallelGCThreads=8, ConcGCThreads=2), can there be many more
taskqueues than GC threads?

Or is there another explanation for the additional "GC" size?

Thanks,
Glyn

[1] https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe

On Fri, Nov 10, 2017 at 7:05 PM, Zhengyu Gu <zgu at redhat.com> wrote:

> Hi Glyn,
>
>
>> 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.
>>
>>
> GC memory is mainly data structures used by GC runtime. It can be varied
> by collector used, size of the Java heap, the number of GC threads and etc.
> and, of course, the application itself.
>
> Some are *fixed* costs, which can be estimated. E.g. two marking bitmaps
> used by G1, each costs 1/64 of heap size (assuming default object
> alignment).
>
> Some are *semi-fixed*, e.g. taskqueue's fixed cost is about 1M for each
> queue on 64-bits VM, but it can overflow. And the number of task queues is
> proportional to the number of GC threads.
>
> Then there are factors from application itself,  such as object mutation
> rate, inter-generation/region references, etc.
>
>
> I don't see a single formula for estimating GC memory size. If you are
> using G1, the biggest overhead comes from 2 bitmaps (1/32 * heap size).
>
> Thanks,
>
> -Zhengyu
>
>
>
>


-- 
Regards,
Glyn