Determining "GC" memory area size

Glyn Normington gnormington at pivotal.io
Fri Nov 10 17:06:11 UTC 2017


tl;dr: How is the size of the "GC" memory area (as reported by NMT)
determined?

The open source project I work on is running Java applications in Linux
containers which result in processes being killed when the container's
defined memory size, essentially in terms of pages of RAM, is exceeded.
When this happens, users don't get any reasonable feedback to know whether
the heap, metaspace, etc. is the problem and what to do about it.

We have two components which attempt to help with this situation:

1. Java memory calculator (
https://github.com/cloudfoundry/java-buildpack-memory-calculator)

This takes the container memory size together with an estimate of the
number of loaded classes and threads consumed by the application and sets
various JVM memory settings such as heap, metaspace, etc. The goal is to
prevent the JVM from using more memory than the container has available, so
that container OOM does not occur and if the JVM runs out of memory, it
does so in a diagnosable way.

2. jvmkill JVMTI agent (https://github.com/cloudfoundry/jvmkill)

When the JVM hits a resource exhaustion event, due either to lack of memory
or threads, this agent prints various diagnostics to help the user decide
what needs to be done to avoid the problem in future. If a threshold is
exceeded, the agent then kills the JVM, otherwise the agent returns to the
JVM and allows OutOfMemoryError to be thrown.

One of our users recently found (see [1] below for details) that the memory
calculator is not taking the "GC" memory area into account. Consequently, a
JVM can exceed the container's memory size which means the user doesn't get
any helpful diagnostics from either jvmkill or an OutOfMemoryError. Using
NMT, the user observed that "GC" memory seems to be about 5% of the heap
size for heaps of a few GB in size.

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.

-- 
Regards,
Glyn
PS. Apologies for cross-posting this from hotspot-gc-use - got no reply
there.


More information about the hotspot-dev mailing list