On 07/12/2018 10:34 PM, mandy chung wrote:
It's indeed strange that no one reports this issue. I created:
https://bugs.openjdk.java.net/browse/JDK-8207200
Mandy: I moved the bug over to hotspot/gc, this is much more likely to
be a problem with how the GC calculates the sizes. I don't think there
is a bug in the serviceability layer, the JNI getMemoryUsage function
only summarizes the data it gets from the GC.
Thanks for creating the bug, we will follow up with Daniel.
Erik
Mandy
On 7/12/18 6:35 AM, Daniel Mitterdorfer wrote:
Hi,
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
exception:
java.lang.IllegalArgumentException: committed = 542113792 should be <
max = 536870912
at java.lang.management.MemoryUsage.<init>(MemoryUsage.java:166)
at sun.management.MemoryImpl.getMemoryUsage0(Native Method)
at sun.management.MemoryImpl.getHeapMemoryUsage(MemoryImpl.java:71)
at
org.elasticsearch.indices.breaker.HierarchyCircuitBreakerService.currentMemoryUsage(HierarchyCircuitBreakerService.java:246)
[...]
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.
Thanks,
Daniel
[jdk-mem-usage]
http://hg.openjdk.java.net/jdk-updates/jdk10u/file/142f0ed9ff5b/src/hotspot/share/services/management.cpp#l728
[JDK-8020530] https://bugs.openjdk.java.net/browse/JDK-8020530
[apache-ignite-workaround]
https://github.com/apache/ignite/blob/df4fd65a32/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L336-L346
[netbeans-bug] https://netbeans.org/bugzilla/show_bug.cgi?id=194733
