Excessive "GC" memory area size [was: Re: Determining "GC" memory area size]
gnormington at pivotal.io
Wed Dec 13 09:39:33 UTC 2017
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?
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
>> 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
> 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).
More information about the hotspot-dev