committed > max in MemoryMXBean#getHeapMemoryUsage()

Daniel Mitterdorfer daniel.mitterdorfer at
Thu Jul 12 13:35:39 UTC 2018


while working on a change in Elasticsearch, I discovered an interesting
situation related to the implementation of jmm_getMemoryUsage (see
[jdk-mem-usage]). In one of the test runs, a test failed with the following

java.lang.IllegalArgumentException: committed = 542113792 should be <
max = 536870912
at Method)
at org.elasticsearch.indices.breaker.HierarchyCircuitBreakerService.currentMemoryUsage(

This happened on MacOS 10.12.6 with JDK 10 (build 10.0.1+10). The only JVM flags
specified where -Xms512M -Xmx512M. So far this failure occurred only once and I
could not reproduce it yet.

The values reported in the exception message are:

* "max": 536870912 = 512MB (exactly)
* "committed": 542113792 = 517MB (exactly), i.e. 5MB more than "max".

As the value of "max" is exactly what we have specified with -Xmx this indicates
to me that the problem seems to be the calculation of "committed".

As the value of "max" is exactly what we have specified with -Xmx it seems to
indicate that the problem is the calculation of "committed". I do not
understand under which conditions this can happen thus I post this to the
mailing list in case anybody has ideas what might cause this.

I plan to run further tests with JVM trace logging enabled
(-Xlog:gc*=trace,heap*=trace,tlab*=off:stdout:time,pid,tid,level,tags to be
precise) in the hope that this problem will occur again and I can provide logs
that help to debug / fix the problem.

Searching for that error message, there is [JDK-8020530] but that one is about
*non-heap* memory usage and has already been resolved a while ago. Several
sources (e.g. [apache-ignite-workaround] or [netbeans-bug]) seem to indicate
that this problem happened indeed in the wild but what I find odd is that I
could not find a single ticket in the OpenJDK bug tracker or a discussion on a
JDK mailing list about this problem.

I'd be glad to get any pointers on what might cause this or requests for
additional info that I need to provide to help analyze this problem.



More information about the serviceability-dev mailing list