From david.holmes at oracle.com  Sun Jul  1 12:19:50 2018
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 1 Jul 2018 22:19:50 +1000
Subject: jmx-dev [11] RFR: 8205653:
 test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and
 RmiSslBootstrapTest.sh fail with handshake_failure
In-Reply-To: <687b7dd7-5be5-cfdb-c411-2cf4a7008b12@oracle.com>
References: <3e4af336-6863-4145-9dce-60b08ea64a79@default>
 <74fabdff-3523-49cc-5ac2-4b766c8bbb30@oracle.com>
 <5764f7f2-f0a7-4bf1-44dc-977953cc6cab@oracle.com>
 <06b1c50c-401c-4c50-9ddf-7876c0638e63@default>
 <687b7dd7-5be5-cfdb-c411-2cf4a7008b12@oracle.com>
Message-ID: <84c24bf6-05d6-3120-6f23-2483f51e3175@oracle.com>

On 29/06/2018 6:32 PM, Alan Bateman wrote:
> On 29/06/2018 09:22, Sibabrata Sahoo wrote:
>> May I get the approval from serviceability-dev at openjdk.java.net.
>>
> This a test only change to update the keystores and the list of 
> ciphers/protocols that the test uses. There's nothing serviceability 
> specific here so having a Reviewer from the security area should be okay 
> in the event that don't get a quick review on serviceability-dev list.

+1

I certainly can't comment on any of this keystore stuff.

David

> -Alan

From daniel.mitterdorfer at gmail.com  Thu Jul 12 12:57:01 2018
From: daniel.mitterdorfer at gmail.com (Daniel Mitterdorfer)
Date: Thu, 12 Jul 2018 14:57:01 +0200
Subject: jmx-dev committed > max in MemoryMXBean#getHeapMemoryUsage()
Message-ID: <CAJmnTFjUb1yMVyiYTVomQnHr2EXfijNA=dDC44k35PD2t5162w@mail.gmail.com>

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 above 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20180712/67f6b845/attachment.html>

From Alan.Bateman at oracle.com  Thu Jul 12 13:13:27 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 12 Jul 2018 14:13:27 +0100
Subject: jmx-dev committed > max in MemoryMXBean#getHeapMemoryUsage()
In-Reply-To: <CAJmnTFjUb1yMVyiYTVomQnHr2EXfijNA=dDC44k35PD2t5162w@mail.gmail.com>
References: <CAJmnTFjUb1yMVyiYTVomQnHr2EXfijNA=dDC44k35PD2t5162w@mail.gmail.com>
Message-ID: <97326910-2398-09bb-bea9-7f8709317d70@oracle.com>

probably best to ask this on serviceability-dev as it's more about the 
java.lang.management implementation rather than JMX.

On 12/07/2018 13:57, 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 above 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 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
>


From daniel.mitterdorfer at gmail.com  Thu Jul 12 13:30:48 2018
From: daniel.mitterdorfer at gmail.com (Daniel Mitterdorfer)
Date: Thu, 12 Jul 2018 15:30:48 +0200
Subject: jmx-dev committed > max in MemoryMXBean#getHeapMemoryUsage()
In-Reply-To: <97326910-2398-09bb-bea9-7f8709317d70@oracle.com>
References: <CAJmnTFjUb1yMVyiYTVomQnHr2EXfijNA=dDC44k35PD2t5162w@mail.gmail.com>
 <97326910-2398-09bb-bea9-7f8709317d70@oracle.com>
Message-ID: <CAJmnTFgdK_Ar8kgQ7KVeWY1Pa0-vO_SZQ=Zr_qEwu_PbK8iUfQ@mail.gmail.com>

Hi Alan,

to be honest, I was not sure either where to post it. I'll post it there
then, thanks.

Daniel

Am Do., 12. Juli 2018 um 15:12 Uhr schrieb Alan Bateman <
Alan.Bateman at oracle.com>:

> probably best to ask this on serviceability-dev as it's more about the
> java.lang.management implementation rather than JMX.
>
> On 12/07/2018 13:57, 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 above 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 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20180712/51c79976/attachment.html>