From kubota.yuji at gmail.com Mon Jan 4 08:41:46 2016 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Mon, 4 Jan 2016 17:41:46 +0900 Subject: jcmd -help shows non-existent option Message-ID: Hi all, It's just typo level. The jcmd help messages include non-existent option as below. If no options are given, lists Java processes (same as -p). I confirmed the jcmd implementation, but could not find "-p". I think "-l" is correct. I write a patch from jdk9/dev/jdk (13406:f9919c0e0a18). Please review it. diff --git a/src/jdk.jcmd/share/classes/sun/tools/jcmd/Arguments.java b/src/jdk.jcmd/share/classes/sun/tools/jcmd/Arguments.java --- a/src/jdk.jcmd/share/classes/sun/tools/jcmd/Arguments.java +++ b/src/jdk.jcmd/share/classes/sun/tools/jcmd/Arguments.java @@ -119,7 +119,7 @@ System.out.println(" If the pid is 0, commands will be sent to all Java processes. "); System.out.println(" The main class argument will be used to match (either partially "); System.out.println(" or fully) the class used to start Java. "); - System.out.println(" If no options are given, lists Java processes (same as -p). "); + System.out.println(" If no options are given, lists Java processes (same as -l). "); System.out.println(" "); System.out.println(" PerfCounter.print display the counters exposed by this process "); System.out.println(" -f read and execute commands from the file "); diff --git a/test/sun/tools/jcmd/usage.out b/test/sun/tools/jcmd/usage.out --- a/test/sun/tools/jcmd/usage.out +++ b/test/sun/tools/jcmd/usage.out @@ -7,7 +7,7 @@ If the pid is 0, commands will be sent to all Java processes. The main class argument will be used to match (either partially or fully) the class used to start Java. - If no options are given, lists Java processes (same as -p). + If no options are given, lists Java processes (same as -l). PerfCounter.print display the counters exposed by this process -f read and execute commands from the file Thanks, Yuji From jaroslav.bachorik at oracle.com Mon Jan 4 09:05:09 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 4 Jan 2016 10:05:09 +0100 Subject: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <567A76BF.5090305@oracle.com> References: <567A76BF.5090305@oracle.com> Message-ID: <568A35C5.7020804@oracle.com> Gentle reminder ... On 23.12.2015 11:26, Jaroslav Bachorik wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 > Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 > > The test fails for IPv6 addresses since the RMI expects an IPv6 address > to be properly wrapped in '[]'. In addition to that the logic for > selecting IP addresses to bind is flawed - it does not check for IP > addresses of multiple adapters but for multiple IP addresses assigned to > 'localhost'. In combination with IPv4 & IPv6 this will cause the test to > attempt binding to IPv4 and IPv6 address of the same adapter > simultaneously and the test will fail. > > The fix adds the requested wrapping for IPv6 addresses and adjusts the > IP selection logic to iterate over distinct adapters first and prevent > IPv4 and IPv6 address of the same adapter being treated as two addresses > (for the purposes of the test). > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Mon Jan 4 10:20:28 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 4 Jan 2016 11:20:28 +0100 Subject: RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java Message-ID: <568A476C.6060101@oracle.com> Please, review the following simple change Issue : https://bugs.openjdk.java.net/browse/JDK-8143047 Webrev: http://cr.openjdk.java.net/~jbachorik/8143047/webrev.00 The patch removes the special path taken when jmxrmi.jar is present on the bootclasspath. There are two reasons for this cleanup: 1. Bootclasspath will not be available (or meaningful) in Jigsaw 2. We haven't been testing with an external jmxrmi.jar for ages - since JMX was included into JDK in JDK 5. The modified test is still passing. -JB- From Alan.Bateman at oracle.com Mon Jan 4 11:09:03 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 4 Jan 2016 11:09:03 +0000 Subject: jmx-dev RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: <568A476C.6060101@oracle.com> References: <568A476C.6060101@oracle.com> Message-ID: <568A52CF.7060707@oracle.com> On 04/01/2016 10:20, Jaroslav Bachorik wrote: > Please, review the following simple change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8143047 > Webrev: http://cr.openjdk.java.net/~jbachorik/8143047/webrev.00 > > The patch removes the special path taken when jmxrmi.jar is present on > the bootclasspath. There are two reasons for this cleanup: > 1. Bootclasspath will not be available (or meaningful) in Jigsaw > 2. We haven't been testing with an external jmxrmi.jar for ages - > since JMX was included into JDK in JDK 5. > > The modified test is still passing. Does the @summary line need to be updated to drop the mention of "when JMX is bundled"? Otherwise looks okay to me. -Alan From kubota.yuji at gmail.com Mon Jan 4 14:14:31 2016 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Mon, 4 Jan 2016 23:14:31 +0900 Subject: [PING] Potential infinite waiting at JMXConnection#createConnection Message-ID: Hi all, Could you please review this patch? Thanks, Yuji 2015-12-17 2:05 GMT+09:00 KUBOTA Yuji : > Hi all, > > If Shanliang cannot review, someone could review it? > > I reported this issue first at the below. > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-April/002152.html > http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-May/017241.html > > Hope this patch helps to community. > > Thanks, > Yuji > > 2015-12-10 22:40 GMT+09:00 KUBOTA Yuji : >> Hi Shanliang and all, >> >> Sorry my reply is too late. But, finally, I reproduced this issue by >> following test program! :) >> Could you please review test program and my patch ? >> >> The test program includes some files, but I do not have an account of >> openjdk, so I push it on icedtea server as below. >> >> http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/file/e31044f0804f >> >> The test program starts a simple sleep server program (JMXSSLServer) >> on external jdb process with a breakpoint at >> sun.security.ssl.ServerHandshaker.clientHello set. It then starts a >> client process (JMXSSLCient) which tries to connect the sleep/jdb >> process. >> ServerHandshaker.clientHello responds to the client hello message and >> sends SSL record back. By setting breakpont in that function, we can >> emulate this issue in which client keeps waiting SSL record from >> server. >> Now, JMXConnectorFactory.connect() ignores >> sun.rmi.transport.tcp.responseTimeout, so wait the response (SSL >> record) from server INFINITELY. Once my patch (jdk9.patch) was added, >> then the client will return 0 when the connection timeout happen by >> sun.rmi.transport.tcp.responseTimeout. >> And test program returns the client's return code. >> >> You can reproduce infinite waiting by the below. >> * hg clone http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/ >> * cd fixLoopAtJMXConnectorFactory/testProgram >> * set JAVA_HOME >> * mvn package >> * setting debugcontrol.properties if you need. >> * *NOTE* This test program will stop for "debugcontroltest.stop_time" ms. >> * ${JAVA_HOME}/bin/java -cp .:target/debugcontrol-1.0-SNAPSHOT.jar >> debugcontrol.DebugController >> >> * The result by JDK without my patch. >> The client throws java.net.ConnectException after sending quit to jdb. >> ------ >> [INFO] Server process args >> args[0] /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.fc23.x86_64/bin/jdb >> : >> : >> cli-out: [INFO] Service URL: service:jmx:rmi:///jndi/rmi://localhost:9876/jmxrmi >> ser-err: Set deferred breakpoint sun.security.ssl.ServerHandshaker.clientHello >> ser-out: >> ser-err: Breakpoint hit: "thread=RMI TCP Connection(2)-127.0.0.1", >> sun.security.ssl.ServerHandshaker.clientHello(), line=339 bci=0 >> ser-out: >> [INFO] sending quit to jdb >> ser-err: RMI TCP Connection(2)-127.0.0.1[1] >> cli-err: java.rmi.ConnectException: Connection refused to host: >> 127.0.0.1; nested exception is: >> cli-err: java.net.ConnectException: Connection refused >> cli-err: at >> sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619) >> cli-err: at >> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216) >> cli-err: at >> sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202) >> cli-err: at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:130) >> cli-err: at >> javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown >> Source) >> cli-err: at >> javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2432) >> cli-err: at >> javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:308) >> cli-err: at >> javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270) >> cli-err: at >> debugcontrol.client.JMXSSLClient.execute(JMXSSLClient.java:51) >> cli-err: at debugcontrol.client.JMXSSLClient.main(JMXSSLClient.java:34) >> cli-err: Caused by: java.net.ConnectException: Connection refused >> cli-err: at java.net.PlainSocketImpl.socketConnect(Native Method) >> cli-err: at >> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) >> cli-err: at >> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) >> cli-err: at >> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) >> cli-err: at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) >> cli-err: at java.net.Socket.connect(Socket.java:589) >> cli-err: at >> sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668) >> cli-err: at sun.security.ssl.SSLSocketImpl.(SSLSocketImpl.java:427) >> cli-err: at >> sun.security.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:88) >> cli-err: at >> javax.rmi.ssl.SslRMIClientSocketFactory.createSocket(SslRMIClientSocketFactory.java:121) >> cli-err: at >> sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613) >> cli-err: ... 9 more >> [INFO] Thu Dec 10 16:16:50 JST 2015 Client done. Result code: 2 >> [INFO] Client took 114462 msec. >> >> * By JDK 9 with my patch. >> The client got java.net.SocketTimeoutException after the connection >> timeout happen, then return 0. >> ------ >> [INFO] Server process args >> args[0] /workspace/jdk9-netdev-patch/build/linux-x86_64-normal-server-release/jdk/bin/jdb >> args[1] -classpath >> args[2] target/classes >> args[3] -J-Duser.language=en >> args[4] -Dcom.sun.management.jmxremote.port=9876 >> args[5] -Dcom.sun.management.jmxremote.password.file=jmxremote.password >> args[6] -Djavax.net.ssl.keyStore=jmx-test-cert.pkcs12 >> args[7] -Djavax.net.ssl.keyStoreType=pkcs12 >> args[8] -Djavax.net.ssl.keyStorePassword=changeit >> args[9] debugcontrol.server.JMXSSLServer >> ser-out: Initializing jdb ... >> ser-err: > Deferring breakpoint sun.security.ssl.ServerHandshaker.clientHello. >> ser-out: It will be set after the class is loaded. >> ser-err: > run debugcontrol.server.JMXSSLServer >> ser-err: Set uncaught java.lang.Throwable >> ser-out: Set deferred uncaught java.lang.Throwable >> ser-err: > >> ser-out: VM Started: [INFO] Server launched then sleep... >> [INFO] Client process args: >> args[0] /workspace/jdk9-netdev-patch/build/linux-x86_64-normal-server-release/jdk/bin/java >> args[1] -classpath >> args[2] target/classes >> args[3] -Duser.language=en >> args[4] -Djavax.net.ssl.trustStore=jmx-test-cert.pkcs12 >> args[5] -Djavax.net.ssl.trustStoreType=pkcs12 >> args[6] -Djavax.net.ssl.trustStorePassword=changeit >> args[7] -Dsun.rmi.transport.tcp.responseTimeout=1000 >> args[8] -Dsun.rmi.transport.tcp.handshakeTimeout=1000 >> args[9] debugcontrol.client.JMXSSLClient >> args[10] localhost >> args[11] 9876 >> cli-out: [INFO] Service URL: service:jmx:rmi:///jndi/rmi://localhost:9876/jmxrmi >> ser-err: Set deferred breakpoint sun.security.ssl.ServerHandshaker.clientHello >> ser-out: >> ser-err: Breakpoint hit: "thread=RMI TCP Connection(2)-127.0.0.1", >> sun.security.ssl.ServerHandshaker.clientHello(), line=356 bci=0 >> ser-out: >> cli-out: [INFO] Conglaturation. We got a timeout. >> [INFO] Thu Dec 10 15:54:39 JST 2015 Client done. Result code: 0 >> >> >> * My patch (no change from the reported) >> * http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/file/e31044f0804f/jdk9.patch >> ------ >> diff --git a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java >> b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java >> --- a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java >> +++ b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java >> @@ -224,6 +224,22 @@ >> out.writeByte(TransportConstants.SingleOpProtocol); >> } else { >> out.writeByte(TransportConstants.StreamProtocol); >> + >> + int usableSoTimeout = 0; >> + try { >> + /* >> + * If socket factory had set a non-zero timeout on its >> + * own, then restore it instead of using the property- >> + * configured value. >> + */ >> + usableSoTimeout = sock.getSoTimeout(); >> + if (usableSoTimeout == 0) { >> + usableSoTimeout = responseTimeout; >> + } >> + sock.setSoTimeout(usableSoTimeout); >> + } catch (Exception e) { >> + // if we fail to set this, ignore and proceed anyway >> + } >> out.flush(); >> >> /* >> @@ -231,9 +247,7 @@ >> * connection handshake; this also serves to guard against >> * non-JRMP servers that do not respond (see 4322806). >> */ >> - int originalSoTimeout = 0; >> try { >> - originalSoTimeout = sock.getSoTimeout(); >> sock.setSoTimeout(handshakeTimeout); >> } catch (Exception e) { >> // if we fail to set this, ignore and proceed anyway >> @@ -281,14 +295,7 @@ >> * that a remote method call is permitted to execute. >> */ >> try { >> - /* >> - * If socket factory had set a non-zero timeout on its >> - * own, then restore it instead of using the property- >> - * configured value. >> - */ >> - sock.setSoTimeout((originalSoTimeout != 0 ? >> - originalSoTimeout : >> - responseTimeout)); >> + sock.setSoTimeout(usableSoTimeout); >> } catch (Exception e) { >> // if we fail to set this, ignore and proceed anyway >> } >> >> Thanks, >> Yuji From jaroslav.bachorik at oracle.com Mon Jan 4 14:51:11 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 4 Jan 2016 15:51:11 +0100 Subject: [PING] Potential infinite waiting at JMXConnection#createConnection In-Reply-To: References: Message-ID: <568A86DF.2030609@oracle.com> Hi Yuji, On 4.1.2016 15:14, KUBOTA Yuji wrote: > Hi all, > > Could you please review this patch? Sorry for the long delay. Shanliang has not been present for some time and probably this slipped the attention of the others. However, core-libs mailing list might be more appropriate place to review this change since you are dealing with s.r.t.t.TCPChannel (http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/file/e31044f0804f/jdk9.patch) Regards, -JB- > > Thanks, > Yuji > > 2015-12-17 2:05 GMT+09:00 KUBOTA Yuji : >> Hi all, >> >> If Shanliang cannot review, someone could review it? >> >> I reported this issue first at the below. >> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-April/002152.html >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-May/017241.html >> >> Hope this patch helps to community. >> >> Thanks, >> Yuji >> >> 2015-12-10 22:40 GMT+09:00 KUBOTA Yuji : >>> Hi Shanliang and all, >>> >>> Sorry my reply is too late. But, finally, I reproduced this issue by >>> following test program! :) >>> Could you please review test program and my patch ? >>> >>> The test program includes some files, but I do not have an account of >>> openjdk, so I push it on icedtea server as below. >>> >>> http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/file/e31044f0804f >>> >>> The test program starts a simple sleep server program (JMXSSLServer) >>> on external jdb process with a breakpoint at >>> sun.security.ssl.ServerHandshaker.clientHello set. It then starts a >>> client process (JMXSSLCient) which tries to connect the sleep/jdb >>> process. >>> ServerHandshaker.clientHello responds to the client hello message and >>> sends SSL record back. By setting breakpont in that function, we can >>> emulate this issue in which client keeps waiting SSL record from >>> server. >>> Now, JMXConnectorFactory.connect() ignores >>> sun.rmi.transport.tcp.responseTimeout, so wait the response (SSL >>> record) from server INFINITELY. Once my patch (jdk9.patch) was added, >>> then the client will return 0 when the connection timeout happen by >>> sun.rmi.transport.tcp.responseTimeout. >>> And test program returns the client's return code. >>> >>> You can reproduce infinite waiting by the below. >>> * hg clone http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/ >>> * cd fixLoopAtJMXConnectorFactory/testProgram >>> * set JAVA_HOME >>> * mvn package >>> * setting debugcontrol.properties if you need. >>> * *NOTE* This test program will stop for "debugcontroltest.stop_time" ms. >>> * ${JAVA_HOME}/bin/java -cp .:target/debugcontrol-1.0-SNAPSHOT.jar >>> debugcontrol.DebugController >>> >>> * The result by JDK without my patch. >>> The client throws java.net.ConnectException after sending quit to jdb. >>> ------ >>> [INFO] Server process args >>> args[0] /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.fc23.x86_64/bin/jdb >>> : >>> : >>> cli-out: [INFO] Service URL: service:jmx:rmi:///jndi/rmi://localhost:9876/jmxrmi >>> ser-err: Set deferred breakpoint sun.security.ssl.ServerHandshaker.clientHello >>> ser-out: >>> ser-err: Breakpoint hit: "thread=RMI TCP Connection(2)-127.0.0.1", >>> sun.security.ssl.ServerHandshaker.clientHello(), line=339 bci=0 >>> ser-out: >>> [INFO] sending quit to jdb >>> ser-err: RMI TCP Connection(2)-127.0.0.1[1] >>> cli-err: java.rmi.ConnectException: Connection refused to host: >>> 127.0.0.1; nested exception is: >>> cli-err: java.net.ConnectException: Connection refused >>> cli-err: at >>> sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619) >>> cli-err: at >>> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216) >>> cli-err: at >>> sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202) >>> cli-err: at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:130) >>> cli-err: at >>> javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown >>> Source) >>> cli-err: at >>> javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2432) >>> cli-err: at >>> javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:308) >>> cli-err: at >>> javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270) >>> cli-err: at >>> debugcontrol.client.JMXSSLClient.execute(JMXSSLClient.java:51) >>> cli-err: at debugcontrol.client.JMXSSLClient.main(JMXSSLClient.java:34) >>> cli-err: Caused by: java.net.ConnectException: Connection refused >>> cli-err: at java.net.PlainSocketImpl.socketConnect(Native Method) >>> cli-err: at >>> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) >>> cli-err: at >>> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) >>> cli-err: at >>> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) >>> cli-err: at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) >>> cli-err: at java.net.Socket.connect(Socket.java:589) >>> cli-err: at >>> sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668) >>> cli-err: at sun.security.ssl.SSLSocketImpl.(SSLSocketImpl.java:427) >>> cli-err: at >>> sun.security.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:88) >>> cli-err: at >>> javax.rmi.ssl.SslRMIClientSocketFactory.createSocket(SslRMIClientSocketFactory.java:121) >>> cli-err: at >>> sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613) >>> cli-err: ... 9 more >>> [INFO] Thu Dec 10 16:16:50 JST 2015 Client done. Result code: 2 >>> [INFO] Client took 114462 msec. >>> >>> * By JDK 9 with my patch. >>> The client got java.net.SocketTimeoutException after the connection >>> timeout happen, then return 0. >>> ------ >>> [INFO] Server process args >>> args[0] /workspace/jdk9-netdev-patch/build/linux-x86_64-normal-server-release/jdk/bin/jdb >>> args[1] -classpath >>> args[2] target/classes >>> args[3] -J-Duser.language=en >>> args[4] -Dcom.sun.management.jmxremote.port=9876 >>> args[5] -Dcom.sun.management.jmxremote.password.file=jmxremote.password >>> args[6] -Djavax.net.ssl.keyStore=jmx-test-cert.pkcs12 >>> args[7] -Djavax.net.ssl.keyStoreType=pkcs12 >>> args[8] -Djavax.net.ssl.keyStorePassword=changeit >>> args[9] debugcontrol.server.JMXSSLServer >>> ser-out: Initializing jdb ... >>> ser-err: > Deferring breakpoint sun.security.ssl.ServerHandshaker.clientHello. >>> ser-out: It will be set after the class is loaded. >>> ser-err: > run debugcontrol.server.JMXSSLServer >>> ser-err: Set uncaught java.lang.Throwable >>> ser-out: Set deferred uncaught java.lang.Throwable >>> ser-err: > >>> ser-out: VM Started: [INFO] Server launched then sleep... >>> [INFO] Client process args: >>> args[0] /workspace/jdk9-netdev-patch/build/linux-x86_64-normal-server-release/jdk/bin/java >>> args[1] -classpath >>> args[2] target/classes >>> args[3] -Duser.language=en >>> args[4] -Djavax.net.ssl.trustStore=jmx-test-cert.pkcs12 >>> args[5] -Djavax.net.ssl.trustStoreType=pkcs12 >>> args[6] -Djavax.net.ssl.trustStorePassword=changeit >>> args[7] -Dsun.rmi.transport.tcp.responseTimeout=1000 >>> args[8] -Dsun.rmi.transport.tcp.handshakeTimeout=1000 >>> args[9] debugcontrol.client.JMXSSLClient >>> args[10] localhost >>> args[11] 9876 >>> cli-out: [INFO] Service URL: service:jmx:rmi:///jndi/rmi://localhost:9876/jmxrmi >>> ser-err: Set deferred breakpoint sun.security.ssl.ServerHandshaker.clientHello >>> ser-out: >>> ser-err: Breakpoint hit: "thread=RMI TCP Connection(2)-127.0.0.1", >>> sun.security.ssl.ServerHandshaker.clientHello(), line=356 bci=0 >>> ser-out: >>> cli-out: [INFO] Conglaturation. We got a timeout. >>> [INFO] Thu Dec 10 15:54:39 JST 2015 Client done. Result code: 0 >>> >>> >>> * My patch (no change from the reported) >>> * http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/file/e31044f0804f/jdk9.patch >>> ------ >>> diff --git a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java >>> b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java >>> --- a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java >>> +++ b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java >>> @@ -224,6 +224,22 @@ >>> out.writeByte(TransportConstants.SingleOpProtocol); >>> } else { >>> out.writeByte(TransportConstants.StreamProtocol); >>> + >>> + int usableSoTimeout = 0; >>> + try { >>> + /* >>> + * If socket factory had set a non-zero timeout on its >>> + * own, then restore it instead of using the property- >>> + * configured value. >>> + */ >>> + usableSoTimeout = sock.getSoTimeout(); >>> + if (usableSoTimeout == 0) { >>> + usableSoTimeout = responseTimeout; >>> + } >>> + sock.setSoTimeout(usableSoTimeout); >>> + } catch (Exception e) { >>> + // if we fail to set this, ignore and proceed anyway >>> + } >>> out.flush(); >>> >>> /* >>> @@ -231,9 +247,7 @@ >>> * connection handshake; this also serves to guard against >>> * non-JRMP servers that do not respond (see 4322806). >>> */ >>> - int originalSoTimeout = 0; >>> try { >>> - originalSoTimeout = sock.getSoTimeout(); >>> sock.setSoTimeout(handshakeTimeout); >>> } catch (Exception e) { >>> // if we fail to set this, ignore and proceed anyway >>> @@ -281,14 +295,7 @@ >>> * that a remote method call is permitted to execute. >>> */ >>> try { >>> - /* >>> - * If socket factory had set a non-zero timeout on its >>> - * own, then restore it instead of using the property- >>> - * configured value. >>> - */ >>> - sock.setSoTimeout((originalSoTimeout != 0 ? >>> - originalSoTimeout : >>> - responseTimeout)); >>> + sock.setSoTimeout(usableSoTimeout); >>> } catch (Exception e) { >>> // if we fail to set this, ignore and proceed anyway >>> } >>> >>> Thanks, >>> Yuji From jaroslav.bachorik at oracle.com Mon Jan 4 15:05:13 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 4 Jan 2016 16:05:13 +0100 Subject: jmx-dev RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: <568A52CF.7060707@oracle.com> References: <568A476C.6060101@oracle.com> <568A52CF.7060707@oracle.com> Message-ID: <568A8A29.60907@oracle.com> On 4.1.2016 12:09, Alan Bateman wrote: > > > On 04/01/2016 10:20, Jaroslav Bachorik wrote: >> Please, review the following simple change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8143047 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8143047/webrev.00 >> >> The patch removes the special path taken when jmxrmi.jar is present on >> the bootclasspath. There are two reasons for this cleanup: >> 1. Bootclasspath will not be available (or meaningful) in Jigsaw >> 2. We haven't been testing with an external jmxrmi.jar for ages - >> since JMX was included into JDK in JDK 5. >> >> The modified test is still passing. > Does the @summary line need to be updated to drop the mention of "when > JMX is bundled"? Otherwise looks okay to me. Not sure. With this change in place the test will not even try to detect the situation when JMX is not bundled with JDK. There is another test (jdk/test/javax/management/remote/mandatory/version/ImplVersionTest.java) with the same wording in the summary but not even trying to detest the standalone jmxrmi.jar. If you insist on changing the wording I would prefer changing both of these tests in one go, perhaps as a separate CR? -JB- > > -Alan From Alan.Bateman at oracle.com Mon Jan 4 15:25:39 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 4 Jan 2016 15:25:39 +0000 Subject: jmx-dev RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: <568A8A29.60907@oracle.com> References: <568A476C.6060101@oracle.com> <568A52CF.7060707@oracle.com> <568A8A29.60907@oracle.com> Message-ID: <568A8EF3.3000704@oracle.com> On 04/01/2016 15:05, Jaroslav Bachorik wrote: > : > > Not sure. With this change in place the test will not even try to > detect the situation when JMX is not bundled with JDK. > > There is another test > (jdk/test/javax/management/remote/mandatory/version/ImplVersionTest.java) > with the same wording in the summary but not even trying to detest the > standalone jmxrmi.jar. > > If you insist on changing the wording I would prefer changing both of > these tests in one go, perhaps as a separate CR? I just wanted to make the point that with the change then the @summary on the test doesn't make sense and it's the opportunity to align it with what the test does. Doing the other test as as separate issue is no problem. -Alan From eamonn at mcmanus.net Mon Jan 4 20:26:47 2016 From: eamonn at mcmanus.net (Eamonn McManus) Date: Mon, 4 Jan 2016 12:26:47 -0800 Subject: RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: <568A476C.6060101@oracle.com> References: <568A476C.6060101@oracle.com> Message-ID: I think this test should either be deleted or reduced to a simple check that the MBeanServerDelegate's ImplementationVersion attribute is equal to System.getProperty("java.runtime.version"). The whole business of starting up a separate process and checking things with security managers and so on is completely obsolete. ?amonn 2016-01-04 2:20 GMT-08:00 Jaroslav Bachorik : > Please, review the following simple change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8143047 > Webrev: http://cr.openjdk.java.net/~jbachorik/8143047/webrev.00 > > The patch removes the special path taken when jmxrmi.jar is present on the > bootclasspath. There are two reasons for this cleanup: > 1. Bootclasspath will not be available (or meaningful) in Jigsaw > 2. We haven't been testing with an external jmxrmi.jar for ages - since > JMX was included into JDK in JDK 5. > > The modified test is still passing. > > -JB- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Tue Jan 5 13:52:04 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 5 Jan 2016 14:52:04 +0100 Subject: RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: References: <568A476C.6060101@oracle.com> Message-ID: <568BCA84.2030401@oracle.com> On 4.1.2016 21:26, Eamonn McManus wrote: > I think this test should either be deleted or reduced to a simple check > that the MBeanServerDelegate's ImplementationVersion attribute is equal > to System.getProperty("java.runtime.version"). The whole business of > starting up a separate process and checking things with security > managers and so on is completely obsolete. I would leave this for SQE to decide. Removing the security manager part would change the semantics of the test. I would suggest dealing with this in a separate issue not to block the effort of removing references to 'sun.boot.class.path' for jigsaw. -JB- > > ?amonn > > 2016-01-04 2:20 GMT-08:00 Jaroslav Bachorik > >: > > Please, review the following simple change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8143047 > Webrev: http://cr.openjdk.java.net/~jbachorik/8143047/webrev.00 > > The patch removes the special path taken when jmxrmi.jar is present > on the bootclasspath. There are two reasons for this cleanup: > 1. Bootclasspath will not be available (or meaningful) in Jigsaw > 2. We haven't been testing with an external jmxrmi.jar for ages - > since JMX was included into JDK in JDK 5. > > The modified test is still passing. > > -JB- > > From Alan.Bateman at oracle.com Tue Jan 5 14:00:03 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Jan 2016 14:00:03 +0000 Subject: jmx-dev RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: <568BCA84.2030401@oracle.com> References: <568A476C.6060101@oracle.com> <568BCA84.2030401@oracle.com> Message-ID: <568BCC63.5030704@oracle.com> On 05/01/2016 13:52, Jaroslav Bachorik wrote: > On 4.1.2016 21:26, Eamonn McManus wrote: >> I think this test should either be deleted or reduced to a simple check >> that the MBeanServerDelegate's ImplementationVersion attribute is equal >> to System.getProperty("java.runtime.version"). The whole business of >> starting up a separate process and checking things with security >> managers and so on is completely obsolete. > > I would leave this for SQE to decide. Removing the security manager > part would change the semantics of the test. > > I would suggest dealing with this in a separate issue not to block the > effort of removing references to 'sun.boot.class.path' for jigsaw. Just to say that sun.boot.class.path is already removed in the jake forest. I created JDK-8143047 to re-examine this test as it looked like it was obsolete and could be deleted. So no urgently fixing this, it's not blocking anything. -Alan From jaroslav.bachorik at oracle.com Tue Jan 5 14:03:55 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 5 Jan 2016 15:03:55 +0100 Subject: jmx-dev RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: <568BCC63.5030704@oracle.com> References: <568A476C.6060101@oracle.com> <568BCA84.2030401@oracle.com> <568BCC63.5030704@oracle.com> Message-ID: <568BCD4B.5070402@oracle.com> On 5.1.2016 15:00, Alan Bateman wrote: > > > On 05/01/2016 13:52, Jaroslav Bachorik wrote: >> On 4.1.2016 21:26, Eamonn McManus wrote: >>> I think this test should either be deleted or reduced to a simple check >>> that the MBeanServerDelegate's ImplementationVersion attribute is equal >>> to System.getProperty("java.runtime.version"). The whole business of >>> starting up a separate process and checking things with security >>> managers and so on is completely obsolete. >> >> I would leave this for SQE to decide. Removing the security manager >> part would change the semantics of the test. >> >> I would suggest dealing with this in a separate issue not to block the >> effort of removing references to 'sun.boot.class.path' for jigsaw. > Just to say that sun.boot.class.path is already removed in the jake > forest. I created JDK-8143047 to re-examine this test as it looked like > it was obsolete and could be deleted. So no urgently fixing this, it's > not blocking anything. Ok. Thanks for the clarification. In this case I downgraded the task priority to P3. -JB- > > -Alan From jaroslav.bachorik at oracle.com Tue Jan 5 14:30:54 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 5 Jan 2016 15:30:54 +0100 Subject: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <568A35C5.7020804@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> Message-ID: <568BD39E.20305@oracle.com> On 4.1.2016 10:05, Jaroslav Bachorik wrote: > Gentle reminder ... > > On 23.12.2015 11:26, Jaroslav Bachorik wrote: >> Please, review the following test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 >> >> The test fails for IPv6 addresses since the RMI expects an IPv6 address >> to be properly wrapped in '[]'. In addition to that the logic for >> selecting IP addresses to bind is flawed - it does not check for IP >> addresses of multiple adapters but for multiple IP addresses assigned to >> 'localhost'. In combination with IPv4 & IPv6 this will cause the test to >> attempt binding to IPv4 and IPv6 address of the same adapter >> simultaneously and the test will fail. >> >> The fix adds the requested wrapping for IPv6 addresses and adjusts the >> IP selection logic to iterate over distinct adapters first and prevent >> IPv4 and IPv6 address of the same adapter being treated as two addresses >> (for the purposes of the test). >> >> Thanks, >> >> -JB- > From kubota.yuji at gmail.com Tue Jan 5 15:01:07 2016 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Wed, 6 Jan 2016 00:01:07 +0900 Subject: HSDB could not terminate when launched on CLI. In-Reply-To: <566FD944.4000002@oracle.com> References: <566FD944.4000002@oracle.com> Message-ID: Hi Dmitry, Thank you for your time. If you have a comment, please let me know. Thanks, Yuji 2015-12-15 18:11 GMT+09:00 Dmitry Samersoff : > Yuji, > > I'll take a look. > > -Dmitry > > On 2015-12-15 11:23, KUBOTA Yuji wrote: >> Hi all, >> >> When I ran HSDB by jhsdb on CLI i.e. without x11 display, HSDB could >> not terminate after throwing HeadlessException. >> >> HSDB starts WorkerThread before making the JFrame. If we run HSDB on >> CLI, HSDB throws HeadlessException when makes the JFrame. Thus, the >> WorkerThread has never shutdown, then HSDB can not terminate. >> >> ----- >> Exception in thread "main" java.awt.HeadlessException: >> No X11 DISPLAY variable was set, but this program performed an >> operation which requires it. >> at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:205) >> at java.awt.Window.(Window.java:535) >> at java.awt.Frame.(Frame.java:422) >> at javax.swing.JFrame.(JFrame.java:224) >> at sun.jvm.hotspot.HSDB.run(HSDB.java:140) >> at sun.jvm.hotspot.HSDB.main(HSDB.java:53) >> at sun.jvm.hotspot.SALauncher.runHSDB(SALauncher.java:167) >> at sun.jvm.hotspot.SALauncher.main(SALauncher.java:339) >> ## Waiting for the shutdown of WorkerThread forever... ### >> ----- >> >> I have created a patch from jdk9/dev/hotspot (changeset: >> 9625:de592ea5f7ba) as below. Please review it ! >> >> diff --git a/agent/src/share/classes/sun/jvm/hotspot/HSDB.java >> b/agent/src/share/classes/sun/jvm/hotspot/HSDB.java >> --- a/agent/src/share/classes/sun/jvm/hotspot/HSDB.java >> +++ b/agent/src/share/classes/sun/jvm/hotspot/HSDB.java >> @@ -137,15 +137,16 @@ >> return; >> } >> >> + // Make frame at first, then initialize agent. >> + frame = new JFrame("HSDB - HotSpot Debugger"); >> + frame.setSize(800, 600); >> + frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE); >> + >> agent = new HotSpotAgent(); >> workerThread = new WorkerThread(); >> attachMenuItems = new java.util.ArrayList(); >> detachMenuItems = new java.util.ArrayList(); >> >> - frame = new JFrame("HSDB - HotSpot Debugger"); >> - frame.setSize(800, 600); >> - frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE); >> - >> JMenuBar menuBar = new JMenuBar(); >> >> // >> >> >> Thanks, >> Yuji >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the source code. From eamonn at mcmanus.net Tue Jan 5 15:47:42 2016 From: eamonn at mcmanus.net (Eamonn McManus) Date: Tue, 5 Jan 2016 07:47:42 -0800 Subject: RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: <568BCA84.2030401@oracle.com> References: <568A476C.6060101@oracle.com> <568BCA84.2030401@oracle.com> Message-ID: OK. In that case I would suggest removing the checkVersion variable since it is now always true, along with the logic from ImplVersionCommand for when it is false. ?amonn 2016-01-05 5:52 GMT-08:00 Jaroslav Bachorik : > On 4.1.2016 21:26, Eamonn McManus wrote: > >> I think this test should either be deleted or reduced to a simple check >> that the MBeanServerDelegate's ImplementationVersion attribute is equal >> to System.getProperty("java.runtime.version"). The whole business of >> starting up a separate process and checking things with security >> managers and so on is completely obsolete. >> > > I would leave this for SQE to decide. Removing the security manager part > would change the semantics of the test. > > I would suggest dealing with this in a separate issue not to block the > effort of removing references to 'sun.boot.class.path' for jigsaw. > > -JB- > > >> ?amonn >> >> 2016-01-04 2:20 GMT-08:00 Jaroslav Bachorik >> >: >> >> Please, review the following simple change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8143047 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8143047/webrev.00 >> >> The patch removes the special path taken when jmxrmi.jar is present >> on the bootclasspath. There are two reasons for this cleanup: >> 1. Bootclasspath will not be available (or meaningful) in Jigsaw >> 2. We haven't been testing with an external jmxrmi.jar for ages - >> since JMX was included into JDK in JDK 5. >> >> The modified test is still passing. >> >> -JB- >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Tue Jan 5 17:33:52 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 5 Jan 2016 10:33:52 -0700 Subject: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ... In-Reply-To: <567A9183.1000900@oracle.com> References: <566ECDA6.1030404@oracle.com> <566FB3BB.4050709@oracle.com> <567000F9.2070603@oracle.com> <56700279.4000408@oracle.com> <56700531.8060701@oracle.com> <56724BE9.5060304@oracle.com> <567270F6.7030206@oracle.com> <567390D4.10307@oracle.com> <56754D74.80802@oracle.com> <567A25FC.7080109@oracle.com> <567A9183.1000900@oracle.com> Message-ID: <568BFE80.9040000@oracle.com> Happy New Year! > http://cr.openjdk.java.net/~igerasim/8145127/01/webrev/ src/os/windows/vm/os_windows.cpp L3923: Atomic::cmpxchg((jint)GetCurrentThreadId(), &process_exiting, 0); What's the return size of GetCurrentThreadId()? Are we down casting a larger size into a 'jint'? If so, that might allow more than one thread into this code when we only want one... Also please consider adding a comment above this line. Perhaps something like: // Atomically set process_exiting before the critical section // to increase the visibility between racing threads. L3998: if (portion_count > MAXIMUM_WAIT_OBJECTS) { L3999: portion_count = MAXIMUM_WAIT_OBJECTS; Wrong indent; should be two spaces relative to L3998. L4013: portion_count = handle_count - i; Please consider adding a comment for this error case. Perhaps something like: // Reset portion_count so we close the remaining // handles due to this error. L4030: if (OrderAccess::load_acquire(&process_exiting) != 0 && L4031: process_exiting != (jint)GetCurrentThreadId()) { L4032: while (true) { L4033: // Some other thread is about to call exit(), so we L4034: // don't let the current thread proceed to exit() or _endthreadex() The comment on L4033-4 is slightly misplaced now. It should be between L4031 and L4032. Thumbs up modulo the GetCurrentThreadId() return size question above. If that size is OK and you choose to make the comment changes, I don't need to see another webrev. Dan On 12/23/15 5:20 AM, Ivan Gerasimov wrote: > Thank you David for review! > > Sincerely yours, > Ivan > > On 23.12.2015 7:41, David Holmes wrote: >> Looks okay. >> >> Second review needed though. >> >> Thanks, >> David >> >> On 19/12/2015 10:28 PM, Ivan Gerasimov wrote: >>> >>> >>>>> We will suspend the current thread if two conditions are satisfied: >>>>> process_exiting != 0 and process_exiting != current thread id. >>>>> But, yes, pr_ex isn't really needed, as we can use process_exiting >>>>> directly. >>>>> >>>>> Here's the updated webrev: >>>>> http://cr.openjdk.java.net/~igerasim/8145127/01/webrev/ >>>> >>>> I still see pr_ex ?? >>>> >>> >>> Oops. >>> Forgot to 'hg qrefresh' before generating the webrev. >>> The webrev has just been updated in place. >>> >>> Sincerely yours, >>> Ivan >>> >> > From dmitry.samersoff at oracle.com Tue Jan 5 18:08:41 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 5 Jan 2016 21:08:41 +0300 Subject: HSDB could not terminate when launched on CLI. In-Reply-To: References: <566FD944.4000002@oracle.com> Message-ID: <568C06A9.1030000@oracle.com> Yuji, I'm on vacation till Jan 10, answer you next week. Sorry! Dmitry. On 2016-01-05 18:01, KUBOTA Yuji wrote: > Hi Dmitry, > > Thank you for your time. If you have a comment, please let me know. > > Thanks, > Yuji > > 2015-12-15 18:11 GMT+09:00 Dmitry Samersoff : >> Yuji, >> >> I'll take a look. >> >> -Dmitry >> >> On 2015-12-15 11:23, KUBOTA Yuji wrote: >>> Hi all, >>> >>> When I ran HSDB by jhsdb on CLI i.e. without x11 display, HSDB could >>> not terminate after throwing HeadlessException. >>> >>> HSDB starts WorkerThread before making the JFrame. If we run HSDB on >>> CLI, HSDB throws HeadlessException when makes the JFrame. Thus, the >>> WorkerThread has never shutdown, then HSDB can not terminate. >>> >>> ----- >>> Exception in thread "main" java.awt.HeadlessException: >>> No X11 DISPLAY variable was set, but this program performed an >>> operation which requires it. >>> at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:205) >>> at java.awt.Window.(Window.java:535) >>> at java.awt.Frame.(Frame.java:422) >>> at javax.swing.JFrame.(JFrame.java:224) >>> at sun.jvm.hotspot.HSDB.run(HSDB.java:140) >>> at sun.jvm.hotspot.HSDB.main(HSDB.java:53) >>> at sun.jvm.hotspot.SALauncher.runHSDB(SALauncher.java:167) >>> at sun.jvm.hotspot.SALauncher.main(SALauncher.java:339) >>> ## Waiting for the shutdown of WorkerThread forever... ### >>> ----- >>> >>> I have created a patch from jdk9/dev/hotspot (changeset: >>> 9625:de592ea5f7ba) as below. Please review it ! >>> >>> diff --git a/agent/src/share/classes/sun/jvm/hotspot/HSDB.java >>> b/agent/src/share/classes/sun/jvm/hotspot/HSDB.java >>> --- a/agent/src/share/classes/sun/jvm/hotspot/HSDB.java >>> +++ b/agent/src/share/classes/sun/jvm/hotspot/HSDB.java >>> @@ -137,15 +137,16 @@ >>> return; >>> } >>> >>> + // Make frame at first, then initialize agent. >>> + frame = new JFrame("HSDB - HotSpot Debugger"); >>> + frame.setSize(800, 600); >>> + frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE); >>> + >>> agent = new HotSpotAgent(); >>> workerThread = new WorkerThread(); >>> attachMenuItems = new java.util.ArrayList(); >>> detachMenuItems = new java.util.ArrayList(); >>> >>> - frame = new JFrame("HSDB - HotSpot Debugger"); >>> - frame.setSize(800, 600); >>> - frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE); >>> - >>> JMenuBar menuBar = new JMenuBar(); >>> >>> // >>> >>> >>> Thanks, >>> Yuji >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the source code. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.fuchs at oracle.com Tue Jan 5 18:25:11 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 5 Jan 2016 19:25:11 +0100 Subject: Review of JDK-6659240 - Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFactory In-Reply-To: <56839E8D.3010706@oracle.com> References: <2072ed8f-585c-4c1c-b036-c97775636db1@default> <56839E8D.3010706@oracle.com> Message-ID: <568C0A87.8050208@oracle.com> On 30/12/15 10:06, Jaroslav Bachorik wrote: > On 28.12.2015 18:01, Sharath Ballal wrote: >> Hi, >> >> Kindly review the changes for bug >> https://bugs.openjdk.java.net/browse/JDK-6659240 >> >> Webrev: >> http://cr.openjdk.java.net/~jbachorik/sponsorship/6659240/webrev.00/ > > Looks good! Hi, What is {@code MBeanServerConnector} interface? Is that a typo - and should that be {@code MBeanServerConnection} ? If so then maybe some further rewording could be in order.. best regards, -- daniel > > -JB- > >> >> CCC request for the same is being raised in parallel. >> >> -Sharath Ballal >> > From kubota.yuji at gmail.com Wed Jan 6 00:20:35 2016 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Wed, 6 Jan 2016 09:20:35 +0900 Subject: HSDB could not terminate when launched on CLI. In-Reply-To: <568C06A9.1030000@oracle.com> References: <566FD944.4000002@oracle.com> <568C06A9.1030000@oracle.com> Message-ID: Dmitry, Thank your reply on vacation. Have a good time :) Thanks, Yuji 2016-01-06 3:08 GMT+09:00 Dmitry Samersoff : > Yuji, > > I'm on vacation till Jan 10, answer you next week. > > Sorry! > Dmitry. > > > On 2016-01-05 18:01, KUBOTA Yuji wrote: >> Hi Dmitry, >> >> Thank you for your time. If you have a comment, please let me know. >> >> Thanks, >> Yuji >> >> 2015-12-15 18:11 GMT+09:00 Dmitry Samersoff : >>> Yuji, >>> >>> I'll take a look. >>> >>> -Dmitry >>> >>> On 2015-12-15 11:23, KUBOTA Yuji wrote: >>>> Hi all, >>>> >>>> When I ran HSDB by jhsdb on CLI i.e. without x11 display, HSDB could >>>> not terminate after throwing HeadlessException. >>>> >>>> HSDB starts WorkerThread before making the JFrame. If we run HSDB on >>>> CLI, HSDB throws HeadlessException when makes the JFrame. Thus, the >>>> WorkerThread has never shutdown, then HSDB can not terminate. >>>> >>>> ----- >>>> Exception in thread "main" java.awt.HeadlessException: >>>> No X11 DISPLAY variable was set, but this program performed an >>>> operation which requires it. >>>> at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:205) >>>> at java.awt.Window.(Window.java:535) >>>> at java.awt.Frame.(Frame.java:422) >>>> at javax.swing.JFrame.(JFrame.java:224) >>>> at sun.jvm.hotspot.HSDB.run(HSDB.java:140) >>>> at sun.jvm.hotspot.HSDB.main(HSDB.java:53) >>>> at sun.jvm.hotspot.SALauncher.runHSDB(SALauncher.java:167) >>>> at sun.jvm.hotspot.SALauncher.main(SALauncher.java:339) >>>> ## Waiting for the shutdown of WorkerThread forever... ### >>>> ----- >>>> >>>> I have created a patch from jdk9/dev/hotspot (changeset: >>>> 9625:de592ea5f7ba) as below. Please review it ! >>>> >>>> diff --git a/agent/src/share/classes/sun/jvm/hotspot/HSDB.java >>>> b/agent/src/share/classes/sun/jvm/hotspot/HSDB.java >>>> --- a/agent/src/share/classes/sun/jvm/hotspot/HSDB.java >>>> +++ b/agent/src/share/classes/sun/jvm/hotspot/HSDB.java >>>> @@ -137,15 +137,16 @@ >>>> return; >>>> } >>>> >>>> + // Make frame at first, then initialize agent. >>>> + frame = new JFrame("HSDB - HotSpot Debugger"); >>>> + frame.setSize(800, 600); >>>> + frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE); >>>> + >>>> agent = new HotSpotAgent(); >>>> workerThread = new WorkerThread(); >>>> attachMenuItems = new java.util.ArrayList(); >>>> detachMenuItems = new java.util.ArrayList(); >>>> >>>> - frame = new JFrame("HSDB - HotSpot Debugger"); >>>> - frame.setSize(800, 600); >>>> - frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE); >>>> - >>>> JMenuBar menuBar = new JMenuBar(); >>>> >>>> // >>>> >>>> >>>> Thanks, >>>> Yuji >>>> >>> >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the source code. > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Wed Jan 6 04:25:34 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Jan 2016 14:25:34 +1000 Subject: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ... In-Reply-To: <568BFE80.9040000@oracle.com> References: <566ECDA6.1030404@oracle.com> <566FB3BB.4050709@oracle.com> <567000F9.2070603@oracle.com> <56700279.4000408@oracle.com> <56700531.8060701@oracle.com> <56724BE9.5060304@oracle.com> <567270F6.7030206@oracle.com> <567390D4.10307@oracle.com> <56754D74.80802@oracle.com> <567A25FC.7080109@oracle.com> <567A9183.1000900@oracle.com> <568BFE80.9040000@oracle.com> Message-ID: <568C973E.6030404@oracle.com> On 6/01/2016 3:33 AM, Daniel D. Daugherty wrote: > Happy New Year! And to you :) > > > http://cr.openjdk.java.net/~igerasim/8145127/01/webrev/ > > src/os/windows/vm/os_windows.cpp > L3923: Atomic::cmpxchg((jint)GetCurrentThreadId(), > &process_exiting, 0); > What's the return size of GetCurrentThreadId()? Are we It is a DWORD so 32-bit. Cheers, David ----- > down casting a larger size into a 'jint'? If so, that > might allow more than one thread into this code when we > only want one... > > Also please consider adding a comment above this line. > Perhaps something like: > > // Atomically set process_exiting before the critical section > // to increase the visibility between racing threads. > > L3998: if (portion_count > MAXIMUM_WAIT_OBJECTS) { > L3999: portion_count = MAXIMUM_WAIT_OBJECTS; > Wrong indent; should be two spaces relative to L3998. > > L4013: portion_count = handle_count - i; > Please consider adding a comment for this error case. > Perhaps something like: > // Reset portion_count so we close the remaining > // handles due to this error. > > L4030: if (OrderAccess::load_acquire(&process_exiting) != 0 && > L4031: process_exiting != (jint)GetCurrentThreadId()) { > L4032: while (true) { > L4033: // Some other thread is about to call exit(), so we > L4034: // don't let the current thread proceed to exit() or > _endthreadex() > The comment on L4033-4 is slightly misplaced now. It > should be between L4031 and L4032. > > > Thumbs up modulo the GetCurrentThreadId() return size question > above. If that size is OK and you choose to make the comment > changes, I don't need to see another webrev. > > Dan > > > On 12/23/15 5:20 AM, Ivan Gerasimov wrote: >> Thank you David for review! >> >> Sincerely yours, >> Ivan >> >> On 23.12.2015 7:41, David Holmes wrote: >>> Looks okay. >>> >>> Second review needed though. >>> >>> Thanks, >>> David >>> >>> On 19/12/2015 10:28 PM, Ivan Gerasimov wrote: >>>> >>>> >>>>>> We will suspend the current thread if two conditions are satisfied: >>>>>> process_exiting != 0 and process_exiting != current thread id. >>>>>> But, yes, pr_ex isn't really needed, as we can use process_exiting >>>>>> directly. >>>>>> >>>>>> Here's the updated webrev: >>>>>> http://cr.openjdk.java.net/~igerasim/8145127/01/webrev/ >>>>> >>>>> I still see pr_ex ?? >>>>> >>>> >>>> Oops. >>>> Forgot to 'hg qrefresh' before generating the webrev. >>>> The webrev has just been updated in place. >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>> >> > From david.holmes at oracle.com Wed Jan 6 06:36:19 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Jan 2016 16:36:19 +1000 Subject: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing In-Reply-To: <567AAEE7.1060806@gmail.com> References: <56742B46.9050106@gmail.com> <56793FE2.5090106@oracle.com> <5679FD8D.2090201@gmail.com> <567A2121.1060504@oracle.com> <567AAEE7.1060806@gmail.com> Message-ID: <568CB5E3.6080105@oracle.com> Pinging the serviceability tracing experts please! David On 24/12/2015 12:25 AM, Yasumasa Suenaga wrote: > Hi David, > >>> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). >> >> That is not likely to be an option - it would likely be far too >> disruptive to the initialization sequence. > > Agree. Thus I choose 2. > >> We will have to wait for the tracing experts to have a good look at >> this. > > I'm waiting that the tracing experts join this discussion. > > > Thanks, > > Yasumasa > > > On 2015/12/23 13:20, David Holmes wrote: >> Hi Yasumasa, >> >> On 23/12/2015 11:49 AM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>> I've added callstack when JVM crashed: >>> https://bugs.openjdk.java.net/browse/JDK-8145788?focusedCommentId=13880225&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13880225 >> >> Thanks for that. >> >>> This crash occurrs in Arguments::apply_ergo() in Threads::create_vm(). >>> apply_ergo() calls before JavaThread initialization. >>> >>> I think that TraceEvent can avoid crash with two approach: >>> >>> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). >> >> That is not likely to be an option - it would likely be far too >> disruptive to the initialization sequence. >> >>> 2. Avoid crash at TraceEvent when it is called before JavaThread initialization. >> >> Or don't call it at all. >> >> We will have to wait for the tracing experts to have a good look at >> this. We end up in code that is not expecting to be run before more of >> the VM is initialized, so we have to look at what else may be being >> assumed and then decide whether to handle the situation or avoid it. >> >> Thanks, >> David >> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2015/12/22 21:19, David Holmes wrote: >>>> On 19/12/2015 1:50 AM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> I encountered JVM crash when I passed -XX:+EnableTracing. >>>>> >>>>> I checked core image, it crashed in EventBooleanFlagChanged::writeEvent() >>>>> which is called by Arguments::apply_ergo() because thread had not been >>>>> initialized. (JVM seems to log changing GC algorithm to G1.) >>>> >>>> This seems like a logic error to me - something is trying to happen too >>>> early during VM initialization. We need to look at exactly what we are >>>> trying to do here, not just work around the crash. >>>> >>>> David >>>> ----- >>>> >>>>> writeEvent() uses ResourceMark. Default constructor of ResourceMark uses >>>>> ResourceArea in current thread. So ResourceMark in writeEvent() should >>>>> pass valid ResourceArea. >>>>> >>>>> I think this issue is in traceEventClasses.xsl . >>>>> However, my environment (GCC 5.3.1 on Fedora23) cannot build it because >>>>> -Werror=maybe-uninitialized was occurred. >>>>> So I also fixed them together. >>>>> >>>>> I've uploaded webrev. Could you review it? >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8145788/webrev.00/ >>>>> >>>>> I'm jdk9 committer, however I cannot access JPRT. >>>>> So I need a sponsor. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> From jaroslav.bachorik at oracle.com Wed Jan 6 10:21:49 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 6 Jan 2016 11:21:49 +0100 Subject: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials Message-ID: <568CEABD.8000603@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8145919 Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.00 On AArch64 machines running multiple test rounds involving SSL connections in rapid succession leads to error during SSL handshake. The fix is attempting to workaround this by inserting an arbitrary delay between the test rounds on AArch64 platform. The fix has been verified and makes the test pass reliably. Thanks, -JB- From jaroslav.bachorik at oracle.com Wed Jan 6 11:00:30 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 6 Jan 2016 12:00:30 +0100 Subject: RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: References: <568A476C.6060101@oracle.com> <568BCA84.2030401@oracle.com> Message-ID: <568CF3CE.6010806@oracle.com> On 5.1.2016 16:47, Eamonn McManus wrote: > OK. In that case I would suggest removing the checkVersion variable > since it is now always true, along with the logic from > ImplVersionCommand for when it is false. Done. Also updated the test summary wording as suggested by Alan: http://cr.openjdk.java.net/~jbachorik/8143047/webrev.01 -JB- > > ?amonn > > 2016-01-05 5:52 GMT-08:00 Jaroslav Bachorik > >: > > On 4.1.2016 21:26, Eamonn McManus wrote: > > I think this test should either be deleted or reduced to a > simple check > that the MBeanServerDelegate's ImplementationVersion attribute > is equal > to System.getProperty("java.runtime.version"). The whole business of > starting up a separate process and checking things with security > managers and so on is completely obsolete. > > > I would leave this for SQE to decide. Removing the security manager > part would change the semantics of the test. > > I would suggest dealing with this in a separate issue not to block > the effort of removing references to 'sun.boot.class.path' for jigsaw. > > -JB- > > > ?amonn > > 2016-01-04 2:20 GMT-08:00 Jaroslav Bachorik > > >>: > > Please, review the following simple change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8143047 > Webrev: http://cr.openjdk.java.net/~jbachorik/8143047/webrev.00 > > The patch removes the special path taken when jmxrmi.jar is > present > on the bootclasspath. There are two reasons for this cleanup: > 1. Bootclasspath will not be available (or meaningful) in > Jigsaw > 2. We haven't been testing with an external jmxrmi.jar for > ages - > since JMX was included into JDK in JDK 5. > > The modified test is still passing. > > -JB- > > > > From david.holmes at oracle.com Wed Jan 6 11:19:24 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Jan 2016 21:19:24 +1000 Subject: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials In-Reply-To: <568CEABD.8000603@oracle.com> References: <568CEABD.8000603@oracle.com> Message-ID: <568CF83C.7050804@oracle.com> On 6/01/2016 8:21 PM, Jaroslav Bachorik wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8145919 > Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.00 > > On AArch64 machines running multiple test rounds involving SSL > connections in rapid succession leads to error during SSL handshake. I can't see how this could be CPU specific. This is more likely an OS issue or an issue with the network hardware/environment of the test machines. David > The fix is attempting to workaround this by inserting an arbitrary delay > between the test rounds on AArch64 platform. The fix has been verified > and makes the test pass reliably. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Wed Jan 6 11:23:31 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 6 Jan 2016 12:23:31 +0100 Subject: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials In-Reply-To: <568CF83C.7050804@oracle.com> References: <568CEABD.8000603@oracle.com> <568CF83C.7050804@oracle.com> Message-ID: <568CF933.8000508@oracle.com> On 6.1.2016 12:19, David Holmes wrote: > On 6/01/2016 8:21 PM, Jaroslav Bachorik wrote: >> Please, review the following test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8145919 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.00 >> >> On AArch64 machines running multiple test rounds involving SSL >> connections in rapid succession leads to error during SSL handshake. > > I can't see how this could be CPU specific. This is more likely an OS > issue or an issue with the network hardware/environment of the test > machines. Test is failing on AArch64 linux - various machines. I did more than 20 runs on the test infrastructure and the test is consistently failing on AArch64, no matter which machine takes up the job. I don't have a separate standalone AArch64 hardware to cross-check. Therefore I went down the path of the most obvious solution ... -JB- > > David > >> The fix is attempting to workaround this by inserting an arbitrary delay >> between the test rounds on AArch64 platform. The fix has been verified >> and makes the test pass reliably. >> >> Thanks, >> >> -JB- From Alan.Bateman at oracle.com Wed Jan 6 15:04:11 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Jan 2016 15:04:11 +0000 Subject: jmx-dev RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: <568CF3CE.6010806@oracle.com> References: <568A476C.6060101@oracle.com> <568BCA84.2030401@oracle.com> <568CF3CE.6010806@oracle.com> Message-ID: <568D2CEB.7010906@oracle.com> On 06/01/2016 11:00, Jaroslav Bachorik wrote: > On 5.1.2016 16:47, Eamonn McManus wrote: >> OK. In that case I would suggest removing the checkVersion variable >> since it is now always true, along with the logic from >> ImplVersionCommand for when it is false. > > Done. Also updated the test summary wording as suggested by Alan: > http://cr.openjdk.java.net/~jbachorik/8143047/webrev.01 @summary looks okay now - thanks! -Alan From eamonn at mcmanus.net Wed Jan 6 15:18:56 2016 From: eamonn at mcmanus.net (Eamonn McManus) Date: Wed, 6 Jan 2016 07:18:56 -0800 Subject: jmx-dev RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: <568D2CEB.7010906@oracle.com> References: <568A476C.6060101@oracle.com> <568BCA84.2030401@oracle.com> <568CF3CE.6010806@oracle.com> <568D2CEB.7010906@oracle.com> Message-ID: Looks good to me (emcmanus) too. ?amonn 2016-01-06 7:04 GMT-08:00 Alan Bateman : > > > On 06/01/2016 11:00, Jaroslav Bachorik wrote: > >> On 5.1.2016 16:47, Eamonn McManus wrote: >> >>> OK. In that case I would suggest removing the checkVersion variable >>> since it is now always true, along with the logic from >>> ImplVersionCommand for when it is false. >>> >> >> Done. Also updated the test summary wording as suggested by Alan: >> http://cr.openjdk.java.net/~jbachorik/8143047/webrev.01 >> > @summary looks okay now - thanks! > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Thu Jan 7 10:06:31 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 7 Jan 2016 02:06:31 -0800 (PST) Subject: Review of JDK-6659240 - Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFactory In-Reply-To: <56839E8D.3010706@oracle.com> References: <2072ed8f-585c-4c1c-b036-c97775636db1@default> <56839E8D.3010706@oracle.com> Message-ID: <2140e74a-c99f-4131-ad0c-b6b05e06fc46@default> Hi, CCC request is approved with some changes (http://ccc.us.oracle.com/6659240). Following is the link with the modifications: http://cr.openjdk.java.net/~jbachorik/sponsorship/6659240/webrev.01/ Kindly review the same. -Sharath Ballal -----Original Message----- From: Jaroslav Bachorik Sent: Wednesday, December 30, 2015 2:36 PM To: serviceability-dev at openjdk.java.net Subject: Re: Review of JDK-6659240 - Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFactory On 28.12.2015 18:01, Sharath Ballal wrote: > Hi, > > Kindly review the changes for bug > https://bugs.openjdk.java.net/browse/JDK-6659240 > > Webrev: http://cr.openjdk.java.net/~jbachorik/sponsorship/6659240/webrev.00/ Looks good! -JB- > > CCC request for the same is being raised in parallel. > > -Sharath Ballal > From daniel.fuchs at oracle.com Thu Jan 7 14:12:35 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 7 Jan 2016 15:12:35 +0100 Subject: Review of JDK-6659240 - Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFactory In-Reply-To: <2140e74a-c99f-4131-ad0c-b6b05e06fc46@default> References: <2072ed8f-585c-4c1c-b036-c97775636db1@default> <56839E8D.3010706@oracle.com> <2140e74a-c99f-4131-ad0c-b6b05e06fc46@default> Message-ID: <568E7253.9000801@oracle.com> Hi, 524 * An application remotely accessing the platform MXBeans using 525 * proxy should prepare to catch {@code UndeclaredThrowableException} as if 526 * accessing with the {@code MBeanServerConnector} interface. I find this text confusing. 1. It's not clear what the {@code MBeanServerConnector} interface is. I suspect this is a typo? 2. If this is a typo and {@code MBeanServerConnection} was intended, then the text above is confusing since MBeanServerConnection will not throw UndeclaredThrowableException. Maybe something like: * An application remotely accessing the platform MXBeans using * proxy should prepare to catch {@code UndeclaredThrowableException} * and handle its {@linkplain UndeclaredThrowableException#getCause() * cause} as if that cause had been thrown by the * {@code MBeanServerConnection} interface. best regards, -- daniel On 07/01/16 11:06, Sharath Ballal wrote: > Hi, > CCC request is approved with some changes (http://ccc.us.oracle.com/6659240). Following is the link with the modifications: > > http://cr.openjdk.java.net/~jbachorik/sponsorship/6659240/webrev.01/ > > Kindly review the same. > > -Sharath Ballal > > > > -----Original Message----- > From: Jaroslav Bachorik > Sent: Wednesday, December 30, 2015 2:36 PM > To: serviceability-dev at openjdk.java.net > Subject: Re: Review of JDK-6659240 - Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFactory > > On 28.12.2015 18:01, Sharath Ballal wrote: >> Hi, >> >> Kindly review the changes for bug >> https://bugs.openjdk.java.net/browse/JDK-6659240 >> >> Webrev: http://cr.openjdk.java.net/~jbachorik/sponsorship/6659240/webrev.00/ > > Looks good! > > -JB- > >> >> CCC request for the same is being raised in parallel. >> >> -Sharath Ballal >> > From jaroslav.bachorik at oracle.com Thu Jan 7 15:02:45 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 7 Jan 2016 16:02:45 +0100 Subject: [ding] Re: jmx-dev [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <568BD39E.20305@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> Message-ID: <568E7E15.5020004@oracle.com> On 5.1.2016 15:30, Jaroslav Bachorik wrote: > On 4.1.2016 10:05, Jaroslav Bachorik wrote: >> Gentle reminder ... >> >> On 23.12.2015 11:26, Jaroslav Bachorik wrote: >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 >>> >>> The test fails for IPv6 addresses since the RMI expects an IPv6 address >>> to be properly wrapped in '[]'. In addition to that the logic for >>> selecting IP addresses to bind is flawed - it does not check for IP >>> addresses of multiple adapters but for multiple IP addresses assigned to >>> 'localhost'. In combination with IPv4 & IPv6 this will cause the test to >>> attempt binding to IPv4 and IPv6 address of the same adapter >>> simultaneously and the test will fail. >>> >>> The fix adds the requested wrapping for IPv6 addresses and adjusts the >>> IP selection logic to iterate over distinct adapters first and prevent >>> IPv4 and IPv6 address of the same adapter being treated as two addresses >>> (for the purposes of the test). >>> >>> Thanks, >>> >>> -JB- >> > From daniel.fuchs at oracle.com Thu Jan 7 16:32:08 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 7 Jan 2016 17:32:08 +0100 Subject: jmx-dev RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials In-Reply-To: <568CF933.8000508@oracle.com> References: <568CEABD.8000603@oracle.com> <568CF83C.7050804@oracle.com> <568CF933.8000508@oracle.com> Message-ID: <568E9308.2040706@oracle.com> On 06/01/16 12:23, Jaroslav Bachorik wrote: > On 6.1.2016 12:19, David Holmes wrote: >> On 6/01/2016 8:21 PM, Jaroslav Bachorik wrote: >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8145919 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.00 >>> >>> On AArch64 machines running multiple test rounds involving SSL >>> connections in rapid succession leads to error during SSL handshake. >> >> I can't see how this could be CPU specific. This is more likely an OS >> issue or an issue with the network hardware/environment of the test >> machines. > > Test is failing on AArch64 linux - various machines. I did more than 20 > runs on the test infrastructure and the test is consistently failing on > AArch64, no matter which machine takes up the job. I don't have a > separate standalone AArch64 hardware to cross-check. Therefore I went > down the path of the most obvious solution ... Looks good to me. RmiSslBootstrapTest.sh: Is jdk.testlibrary.* and /jdk/testlibrary still needed? It seems the test now only uses jdk.test.lib (unless jdk.testlibrary has classes in the unnamed package?) cheers, -- daniel > > -JB- > >> >> David >> >>> The fix is attempting to workaround this by inserting an arbitrary delay >>> between the test rounds on AArch64 platform. The fix has been verified >>> and makes the test pass reliably. >>> >>> Thanks, >>> >>> -JB- > From daniel.fuchs at oracle.com Thu Jan 7 16:40:29 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 7 Jan 2016 17:40:29 +0100 Subject: [ding] Re: jmx-dev [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <568E7E15.5020004@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> Message-ID: <568E94FD.6000206@oracle.com> Hi, This looks OK to me. I'm not sure I understand the full impact of the changes in getAddressesForLocalHost() though - so hopefully someone else will jump in to review that part... best regards, -- daniel On 07/01/16 16:02, Jaroslav Bachorik wrote: > On 5.1.2016 15:30, Jaroslav Bachorik wrote: >> On 4.1.2016 10:05, Jaroslav Bachorik wrote: >>> Gentle reminder ... >>> >>> On 23.12.2015 11:26, Jaroslav Bachorik wrote: >>>> Please, review the following test change >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 >>>> >>>> The test fails for IPv6 addresses since the RMI expects an IPv6 address >>>> to be properly wrapped in '[]'. In addition to that the logic for >>>> selecting IP addresses to bind is flawed - it does not check for IP >>>> addresses of multiple adapters but for multiple IP addresses >>>> assigned to >>>> 'localhost'. In combination with IPv4 & IPv6 this will cause the >>>> test to >>>> attempt binding to IPv4 and IPv6 address of the same adapter >>>> simultaneously and the test will fail. >>>> >>>> The fix adds the requested wrapping for IPv6 addresses and adjusts the >>>> IP selection logic to iterate over distinct adapters first and prevent >>>> IPv4 and IPv6 address of the same adapter being treated as two >>>> addresses >>>> (for the purposes of the test). >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From jaroslav.bachorik at oracle.com Fri Jan 8 08:57:51 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 8 Jan 2016 09:57:51 +0100 Subject: RFR 8146620: CodelistTest.java fails with "Test failed on: jdk.internal.misc.Unsafe.getUnsafe()Ljdk/internal/misc/Unsafe;" Message-ID: <568F7A0F.50006@oracle.com> Please, review the following simple test fix Issue : https://bugs.openjdk.java.net/rest/api/latest/issue/JDK-8146620 Webrev: http://cr.openjdk.java.net/~jbachorik/8146620/webrev.00 The test is treating the 'sun.misc.Unsafe.getUnsafe()' entry from the code list in a specific way - but since now it is possible to meet also the 'jdk.internal.misc.Unsafe.getUnsafe()' entry it is necessary to modify the test to expect this eventuality. Thanks, -JB- From staffan.larsen at oracle.com Fri Jan 8 09:06:20 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 8 Jan 2016 10:06:20 +0100 Subject: RFR 8146620: CodelistTest.java fails with "Test failed on: jdk.internal.misc.Unsafe.getUnsafe()Ljdk/internal/misc/Unsafe; " In-Reply-To: <568F7A0F.50006@oracle.com> References: <568F7A0F.50006@oracle.com> Message-ID: <8AA1795C-7E67-4CE6-8E07-490564C91D2A@oracle.com> Looks good! Thanks, /Staffan > On 8 jan. 2016, at 09:57, Jaroslav Bachorik wrote: > > Please, review the following simple test fix > > Issue : https://bugs.openjdk.java.net/rest/api/latest/issue/JDK-8146620 > Webrev: http://cr.openjdk.java.net/~jbachorik/8146620/webrev.00 > > The test is treating the 'sun.misc.Unsafe.getUnsafe()' entry from the code list in a specific way - but since now it is possible to meet also the 'jdk.internal.misc.Unsafe.getUnsafe()' entry it is necessary to modify the test to expect this eventuality. > > Thanks, > > -JB- From harsha.wardhana.b at oracle.com Fri Jan 8 09:44:03 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Fri, 8 Jan 2016 15:14:03 +0530 Subject: JDK-8031753 : Review request Message-ID: <568F84E3.2040602@oracle.com> Hi All, Please review the fix for, Issue : JDK-8031753 - JMXServiceURL should not use getLocalHost or its usage should be enhanced Webrev : http://cr.openjdk.java.net/~jbachorik/sponsorship/8031753/webrev.00/ The issue can be reproduced by removing entry for hostname in /etc/hosts (for linux) and running 'javax/management/remote/mandatory/connection/RMIConnectionIdTest' test. Hence no new jtreg test case have been written. Fix Description: If JMXServiceURL is given null host, it tries to resolve hostname via InetAddress.getLocalHost() and if that fails throws MalformedURLException. Since JMX Agent will listen on all interfaces (0.0.0.0) if host is null, the fix handles the exception and assigns first active non-loopback interface IP address to host. That way we can have JMXServiceURL with IP address instead of hostname. It is possible that we might end up constructing JMXServiceURL with IP for an interface which clients may not be able to connect (because of network reachability issues). In that case, the recommendation would be to try to start JMX Agent with com.sun.management.jmxremote.host=xx.xx.xx.xx option. That way, the agent will be started on interface that clients can actually connect to. Please review the fix and let me know your comments. The fix requires amending javadoc with above behavioral change and a CCC review as well which I will send out later. Thanks Harsha -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Fri Jan 8 09:56:29 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 8 Jan 2016 10:56:29 +0100 Subject: jmx-dev RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials In-Reply-To: <568E9308.2040706@oracle.com> References: <568CEABD.8000603@oracle.com> <568CF83C.7050804@oracle.com> <568CF933.8000508@oracle.com> <568E9308.2040706@oracle.com> Message-ID: <568F87CD.4050208@oracle.com> On 7.1.2016 17:32, Daniel Fuchs wrote: > On 06/01/16 12:23, Jaroslav Bachorik wrote: >> On 6.1.2016 12:19, David Holmes wrote: >>> On 6/01/2016 8:21 PM, Jaroslav Bachorik wrote: >>>> Please, review the following test change >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8145919 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.00 >>>> >>>> On AArch64 machines running multiple test rounds involving SSL >>>> connections in rapid succession leads to error during SSL handshake. >>> >>> I can't see how this could be CPU specific. This is more likely an OS >>> issue or an issue with the network hardware/environment of the test >>> machines. >> >> Test is failing on AArch64 linux - various machines. I did more than 20 >> runs on the test infrastructure and the test is consistently failing on >> AArch64, no matter which machine takes up the job. I don't have a >> separate standalone AArch64 hardware to cross-check. Therefore I went >> down the path of the most obvious solution ... > > Looks good to me. > > RmiSslBootstrapTest.sh: > > Is jdk.testlibrary.* and /jdk/testlibrary still needed? It seems the > test now only uses jdk.test.lib (unless jdk.testlibrary has classes > in the unnamed package?) Correct, thanks. We can remove reference to the jdk specific test library. Updated webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.01 -JB- > > cheers, > > -- daniel > >> >> -JB- >> >>> >>> David >>> >>>> The fix is attempting to workaround this by inserting an arbitrary >>>> delay >>>> between the test rounds on AArch64 platform. The fix has been verified >>>> and makes the test pass reliably. >>>> >>>> Thanks, >>>> >>>> -JB- >> > From daniel.fuchs at oracle.com Fri Jan 8 10:54:24 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 8 Jan 2016 11:54:24 +0100 Subject: jmx-dev RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials In-Reply-To: <568F87CD.4050208@oracle.com> References: <568CEABD.8000603@oracle.com> <568CF83C.7050804@oracle.com> <568CF933.8000508@oracle.com> <568E9308.2040706@oracle.com> <568F87CD.4050208@oracle.com> Message-ID: <568F9560.10606@oracle.com> On 08/01/16 10:56, Jaroslav Bachorik wrote: > On 7.1.2016 17:32, Daniel Fuchs wrote: >> On 06/01/16 12:23, Jaroslav Bachorik wrote: >>> On 6.1.2016 12:19, David Holmes wrote: >>>> On 6/01/2016 8:21 PM, Jaroslav Bachorik wrote: >>>>> Please, review the following test change >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8145919 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.00 >>>>> >>>>> On AArch64 machines running multiple test rounds involving SSL >>>>> connections in rapid succession leads to error during SSL handshake. >>>> >>>> I can't see how this could be CPU specific. This is more likely an OS >>>> issue or an issue with the network hardware/environment of the test >>>> machines. >>> >>> Test is failing on AArch64 linux - various machines. I did more than 20 >>> runs on the test infrastructure and the test is consistently failing on >>> AArch64, no matter which machine takes up the job. I don't have a >>> separate standalone AArch64 hardware to cross-check. Therefore I went >>> down the path of the most obvious solution ... >> >> Looks good to me. >> >> RmiSslBootstrapTest.sh: >> >> Is jdk.testlibrary.* and /jdk/testlibrary still needed? It seems the >> test now only uses jdk.test.lib (unless jdk.testlibrary has classes >> in the unnamed package?) > > Correct, thanks. We can remove reference to the jdk specific test library. > > Updated webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.01 Looks good. -- daniel > > -JB- > >> >> cheers, >> >> -- daniel >> >>> >>> -JB- >>> >>>> >>>> David >>>> >>>>> The fix is attempting to workaround this by inserting an arbitrary >>>>> delay >>>>> between the test rounds on AArch64 platform. The fix has been verified >>>>> and makes the test pass reliably. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>> >> > From jaroslav.bachorik at oracle.com Fri Jan 8 13:11:57 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 8 Jan 2016 14:11:57 +0100 Subject: RFR 8146620: CodelistTest.java fails with "Test failed on: jdk.internal.misc.Unsafe.getUnsafe()Ljdk/internal/misc/Unsafe;" In-Reply-To: <8AA1795C-7E67-4CE6-8E07-490564C91D2A@oracle.com> References: <568F7A0F.50006@oracle.com> <8AA1795C-7E67-4CE6-8E07-490564C91D2A@oracle.com> Message-ID: <568FB59D.4050902@oracle.com> On 8.1.2016 10:06, Staffan Larsen wrote: > Looks good! Thanks! > > Thanks, > /Staffan > >> On 8 jan. 2016, at 09:57, Jaroslav Bachorik wrote: >> >> Please, review the following simple test fix >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8146620 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8146620/webrev.00 >> >> The test is treating the 'sun.misc.Unsafe.getUnsafe()' entry from the code list in a specific way - but since now it is possible to meet also the 'jdk.internal.misc.Unsafe.getUnsafe()' entry it is necessary to modify the test to expect this eventuality. >> >> Thanks, >> >> -JB- > From erik.gahlin at oracle.com Fri Jan 8 14:08:24 2016 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Fri, 8 Jan 2016 15:08:24 +0100 Subject: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing In-Reply-To: <568CB5E3.6080105@oracle.com> References: <56742B46.9050106@gmail.com> <56793FE2.5090106@oracle.com> <5679FD8D.2090201@gmail.com> <567A2121.1060504@oracle.com> <567AAEE7.1060806@gmail.com> <568CB5E3.6080105@oracle.com> Message-ID: <568FC2D8.8060803@oracle.com> Sorry for the delay, we are looking into it. Erik On 2016-01-06 07:36, David Holmes wrote: > Pinging the serviceability tracing experts please! > > David > > On 24/12/2015 12:25 AM, Yasumasa Suenaga wrote: >> Hi David, >> >>>> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). >>> That is not likely to be an option - it would likely be far too >>> disruptive to the initialization sequence. >> Agree. Thus I choose 2. >> >>> We will have to wait for the tracing experts to have a good look at >>> this. >> I'm waiting that the tracing experts join this discussion. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2015/12/23 13:20, David Holmes wrote: >>> Hi Yasumasa, >>> >>> On 23/12/2015 11:49 AM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>> I've added callstack when JVM crashed: >>>> https://bugs.openjdk.java.net/browse/JDK-8145788?focusedCommentId=13880225&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13880225 >>> Thanks for that. >>> >>>> This crash occurrs in Arguments::apply_ergo() in Threads::create_vm(). >>>> apply_ergo() calls before JavaThread initialization. >>>> >>>> I think that TraceEvent can avoid crash with two approach: >>>> >>>> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). >>> That is not likely to be an option - it would likely be far too >>> disruptive to the initialization sequence. >>> >>>> 2. Avoid crash at TraceEvent when it is called before JavaThread initialization. >>> Or don't call it at all. >>> >>> We will have to wait for the tracing experts to have a good look at >>> this. We end up in code that is not expecting to be run before more of >>> the VM is initialized, so we have to look at what else may be being >>> assumed and then decide whether to handle the situation or avoid it. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2015/12/22 21:19, David Holmes wrote: >>>>> On 19/12/2015 1:50 AM, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> I encountered JVM crash when I passed -XX:+EnableTracing. >>>>>> >>>>>> I checked core image, it crashed in EventBooleanFlagChanged::writeEvent() >>>>>> which is called by Arguments::apply_ergo() because thread had not been >>>>>> initialized. (JVM seems to log changing GC algorithm to G1.) >>>>> This seems like a logic error to me - something is trying to happen too >>>>> early during VM initialization. We need to look at exactly what we are >>>>> trying to do here, not just work around the crash. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> writeEvent() uses ResourceMark. Default constructor of ResourceMark uses >>>>>> ResourceArea in current thread. So ResourceMark in writeEvent() should >>>>>> pass valid ResourceArea. >>>>>> >>>>>> I think this issue is in traceEventClasses.xsl . >>>>>> However, my environment (GCC 5.3.1 on Fedora23) cannot build it because >>>>>> -Werror=maybe-uninitialized was occurred. >>>>>> So I also fixed them together. >>>>>> >>>>>> I've uploaded webrev. Could you review it? >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8145788/webrev.00/ >>>>>> >>>>>> I'm jdk9 committer, however I cannot access JPRT. >>>>>> So I need a sponsor. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> From yasuenag at gmail.com Sun Jan 10 13:02:36 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sun, 10 Jan 2016 22:02:36 +0900 Subject: PING: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing In-Reply-To: <568CB5E3.6080105@oracle.com> References: <56742B46.9050106@gmail.com> <56793FE2.5090106@oracle.com> <5679FD8D.2090201@gmail.com> <567A2121.1060504@oracle.com> <567AAEE7.1060806@gmail.com> <568CB5E3.6080105@oracle.com> Message-ID: <5692566C.1000001@gmail.com> Ping: What do you think about this issue? On 2016/01/06 15:36, David Holmes wrote: > Pinging the serviceability tracing experts please! > > David > > On 24/12/2015 12:25 AM, Yasumasa Suenaga wrote: >> Hi David, >> >>>> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). >>> >>> That is not likely to be an option - it would likely be far too >>> disruptive to the initialization sequence. >> >> Agree. Thus I choose 2. >> >>> We will have to wait for the tracing experts to have a good look at >>> this. >> >> I'm waiting that the tracing experts join this discussion. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2015/12/23 13:20, David Holmes wrote: >>> Hi Yasumasa, >>> >>> On 23/12/2015 11:49 AM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>> I've added callstack when JVM crashed: >>>> https://bugs.openjdk.java.net/browse/JDK-8145788?focusedCommentId=13880225&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13880225 >>> >>> Thanks for that. >>> >>>> This crash occurrs in Arguments::apply_ergo() in Threads::create_vm(). >>>> apply_ergo() calls before JavaThread initialization. >>>> >>>> I think that TraceEvent can avoid crash with two approach: >>>> >>>> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). >>> >>> That is not likely to be an option - it would likely be far too >>> disruptive to the initialization sequence. >>> >>>> 2. Avoid crash at TraceEvent when it is called before JavaThread initialization. >>> >>> Or don't call it at all. >>> >>> We will have to wait for the tracing experts to have a good look at >>> this. We end up in code that is not expecting to be run before more of >>> the VM is initialized, so we have to look at what else may be being >>> assumed and then decide whether to handle the situation or avoid it. >>> >>> Thanks, >>> David >>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2015/12/22 21:19, David Holmes wrote: >>>>> On 19/12/2015 1:50 AM, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> I encountered JVM crash when I passed -XX:+EnableTracing. >>>>>> >>>>>> I checked core image, it crashed in EventBooleanFlagChanged::writeEvent() >>>>>> which is called by Arguments::apply_ergo() because thread had not been >>>>>> initialized. (JVM seems to log changing GC algorithm to G1.) >>>>> >>>>> This seems like a logic error to me - something is trying to happen too >>>>> early during VM initialization. We need to look at exactly what we are >>>>> trying to do here, not just work around the crash. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> writeEvent() uses ResourceMark. Default constructor of ResourceMark uses >>>>>> ResourceArea in current thread. So ResourceMark in writeEvent() should >>>>>> pass valid ResourceArea. >>>>>> >>>>>> I think this issue is in traceEventClasses.xsl . >>>>>> However, my environment (GCC 5.3.1 on Fedora23) cannot build it because >>>>>> -Werror=maybe-uninitialized was occurred. >>>>>> So I also fixed them together. >>>>>> >>>>>> I've uploaded webrev. Could you review it? >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8145788/webrev.00/ >>>>>> >>>>>> I'm jdk9 committer, however I cannot access JPRT. >>>>>> So I need a sponsor. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> From markus.gronlund at oracle.com Sun Jan 10 23:25:34 2016 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Sun, 10 Jan 2016 15:25:34 -0800 (PST) Subject: PING: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing In-Reply-To: <5692566C.1000001@gmail.com> References: <56742B46.9050106@gmail.com> <56793FE2.5090106@oracle.com> <5679FD8D.2090201@gmail.com> <567A2121.1060504@oracle.com> <567AAEE7.1060806@gmail.com> <568CB5E3.6080105@oracle.com> <5692566C.1000001@gmail.com> Message-ID: Hi Yasumasa, Apologies for the delay in getting a response to you. Thanks for reporting and attempting to fix this issue. I have investigated this a bit as well as trying out your suggested patch. I must admit it is hard to get this right at this early stage of the VM, and though I appreciated your effort for resolution, the patch suggestion will not work out of the box unfortunately. I have summarized some of my findings and reasoning here: http://cr.openjdk.java.net/~mgronlun/8145788/notes.txt As you can see, Thread::current() cannot be called at this stage. If we update to instead call Thread::current_or_null(), you will now run into problems in the interplay between an explicit delete of a Cheap allocated ResourceArea and the subsequent ResourceMark destructor. Here, the rm destructor asserts since it expects _nesting_level > 0, but that data has already been invalidated. You could accomplish all of this by doing: + bool thread_has_resource = Thread::current_or_null() != NULL; + ResourceArea *area = thread_has_resource + ? Thread::current()->resource_area() + : new (mtTracing)ResourceArea(Chunk::non_pool_size); + { + ResourceMark rm(area); + if (UseLockedTracing) { + ttyLocker lock; + writeEventContent(); + } else { + writeEventContent(); + } + } + + if (!thread_has_resource) { + delete area; } However, it is getting a bit complex. In addition, now every trace statement needs to check Thread::current_or_null().. If you look at my reasoning in the second part, I think we can fix this in an easier way. You can find my suggestion as a webrev here: http://cr.openjdk.java.net/~mgronlun/8145788/ Please try the patch out to see if you are ok with it. Thanks for your patience Best regards Markus -----Original Message----- From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] Sent: den 10 januari 2016 14:03 To: serviceability-dev at openjdk.java.net Subject: PING: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing Ping: What do you think about this issue? On 2016/01/06 15:36, David Holmes wrote: > Pinging the serviceability tracing experts please! > > David > > On 24/12/2015 12:25 AM, Yasumasa Suenaga wrote: >> Hi David, >> >>>> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). >>> >>> That is not likely to be an option - it would likely be far too >>> disruptive to the initialization sequence. >> >> Agree. Thus I choose 2. >> >>> We will have to wait for the tracing experts to have a good look at >>> this. >> >> I'm waiting that the tracing experts join this discussion. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2015/12/23 13:20, David Holmes wrote: >>> Hi Yasumasa, >>> >>> On 23/12/2015 11:49 AM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>> I've added callstack when JVM crashed: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8145788?focusedCommentId=1 >>>> 3880225&page=com.atlassian.jira.plugin.system.issuetabpanels:commen >>>> t-tabpanel#comment-13880225 >>> >>> Thanks for that. >>> >>>> This crash occurrs in Arguments::apply_ergo() in Threads::create_vm(). >>>> apply_ergo() calls before JavaThread initialization. >>>> >>>> I think that TraceEvent can avoid crash with two approach: >>>> >>>> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). >>> >>> That is not likely to be an option - it would likely be far too >>> disruptive to the initialization sequence. >>> >>>> 2. Avoid crash at TraceEvent when it is called before JavaThread initialization. >>> >>> Or don't call it at all. >>> >>> We will have to wait for the tracing experts to have a good look at >>> this. We end up in code that is not expecting to be run before more >>> of the VM is initialized, so we have to look at what else may be >>> being assumed and then decide whether to handle the situation or avoid it. >>> >>> Thanks, >>> David >>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2015/12/22 21:19, David Holmes wrote: >>>>> On 19/12/2015 1:50 AM, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> I encountered JVM crash when I passed -XX:+EnableTracing. >>>>>> >>>>>> I checked core image, it crashed in EventBooleanFlagChanged::writeEvent() >>>>>> which is called by Arguments::apply_ergo() because thread had not been >>>>>> initialized. (JVM seems to log changing GC algorithm to >>>>>> G1.) >>>>> >>>>> This seems like a logic error to me - something is trying to >>>>> happen too early during VM initialization. We need to look at >>>>> exactly what we are trying to do here, not just work around the crash. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> writeEvent() uses ResourceMark. Default constructor of ResourceMark uses >>>>>> ResourceArea in current thread. So ResourceMark in writeEvent() should >>>>>> pass valid ResourceArea. >>>>>> >>>>>> I think this issue is in traceEventClasses.xsl . >>>>>> However, my environment (GCC 5.3.1 on Fedora23) cannot build it >>>>>> because -Werror=maybe-uninitialized was occurred. >>>>>> So I also fixed them together. >>>>>> >>>>>> I've uploaded webrev. Could you review it? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8145788/webrev.00/ >>>>>> >>>>>> I'm jdk9 committer, however I cannot access JPRT. >>>>>> So I need a sponsor. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> From david.holmes at oracle.com Mon Jan 11 01:38:39 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Jan 2016 11:38:39 +1000 Subject: PING: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing In-Reply-To: References: <56742B46.9050106@gmail.com> <56793FE2.5090106@oracle.com> <5679FD8D.2090201@gmail.com> <567A2121.1060504@oracle.com> <567AAEE7.1060806@gmail.com> <568CB5E3.6080105@oracle.com> <5692566C.1000001@gmail.com> Message-ID: <5693079F.1020702@oracle.com> Hi Markus, Thanks very much for stepping in on this one. I like your solution to this particular problem. Aside: I noticed in writeEvent there is also UseLockedTracing and I'm wondering if that will also lead to an assertion failure due to no current thread? Thanks, David On 11/01/2016 9:25 AM, Markus Gronlund wrote: > Hi Yasumasa, > > Apologies for the delay in getting a response to you. > > Thanks for reporting and attempting to fix this issue. > > I have investigated this a bit as well as trying out your suggested patch. > > I must admit it is hard to get this right at this early stage of the VM, and though I appreciated your effort for resolution, the patch suggestion will not work out of the box unfortunately. > > I have summarized some of my findings and reasoning here: > > http://cr.openjdk.java.net/~mgronlun/8145788/notes.txt > > As you can see, Thread::current() cannot be called at this stage. If we update to instead call Thread::current_or_null(), you will now run into problems in the interplay between an explicit delete of a Cheap allocated ResourceArea and the subsequent ResourceMark destructor. Here, the rm destructor asserts since it expects _nesting_level > 0, but that data has already been invalidated. > > You could accomplish all of this by doing: > > + bool thread_has_resource = Thread::current_or_null() != NULL; > + ResourceArea *area = thread_has_resource > + ? Thread::current()->resource_area() > + : new (mtTracing)ResourceArea(Chunk::non_pool_size); > + { > + ResourceMark rm(area); > + if (UseLockedTracing) { > + ttyLocker lock; > + writeEventContent(); > + } else { > + writeEventContent(); > + } > + } > + > + if (!thread_has_resource) { > + delete area; > } > > > However, it is getting a bit complex. In addition, now every trace statement needs to check Thread::current_or_null().. > > If you look at my reasoning in the second part, I think we can fix this in an easier way. > > You can find my suggestion as a webrev here: > > http://cr.openjdk.java.net/~mgronlun/8145788/ > > Please try the patch out to see if you are ok with it. > > Thanks for your patience > > Best regards > Markus > > > > -----Original Message----- > From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] > Sent: den 10 januari 2016 14:03 > To: serviceability-dev at openjdk.java.net > Subject: PING: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing > > Ping: What do you think about this issue? > > On 2016/01/06 15:36, David Holmes wrote: >> Pinging the serviceability tracing experts please! >> >> David >> >> On 24/12/2015 12:25 AM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>>>> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). >>>> >>>> That is not likely to be an option - it would likely be far too >>>> disruptive to the initialization sequence. >>> >>> Agree. Thus I choose 2. >>> >>>> We will have to wait for the tracing experts to have a good look at >>>> this. >>> >>> I'm waiting that the tracing experts join this discussion. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2015/12/23 13:20, David Holmes wrote: >>>> Hi Yasumasa, >>>> >>>> On 23/12/2015 11:49 AM, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>> I've added callstack when JVM crashed: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8145788?focusedCommentId=1 >>>>> 3880225&page=com.atlassian.jira.plugin.system.issuetabpanels:commen >>>>> t-tabpanel#comment-13880225 >>>> >>>> Thanks for that. >>>> >>>>> This crash occurrs in Arguments::apply_ergo() in Threads::create_vm(). >>>>> apply_ergo() calls before JavaThread initialization. >>>>> >>>>> I think that TraceEvent can avoid crash with two approach: >>>>> >>>>> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). >>>> >>>> That is not likely to be an option - it would likely be far too >>>> disruptive to the initialization sequence. >>>> >>>>> 2. Avoid crash at TraceEvent when it is called before JavaThread initialization. >>>> >>>> Or don't call it at all. >>>> >>>> We will have to wait for the tracing experts to have a good look at >>>> this. We end up in code that is not expecting to be run before more >>>> of the VM is initialized, so we have to look at what else may be >>>> being assumed and then decide whether to handle the situation or avoid it. >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2015/12/22 21:19, David Holmes wrote: >>>>>> On 19/12/2015 1:50 AM, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I encountered JVM crash when I passed -XX:+EnableTracing. >>>>>>> >>>>>>> I checked core image, it crashed in EventBooleanFlagChanged::writeEvent() >>>>>>> which is called by Arguments::apply_ergo() because thread had not been >>>>>>> initialized. (JVM seems to log changing GC algorithm to >>>>>>> G1.) >>>>>> >>>>>> This seems like a logic error to me - something is trying to >>>>>> happen too early during VM initialization. We need to look at >>>>>> exactly what we are trying to do here, not just work around the crash. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> writeEvent() uses ResourceMark. Default constructor of ResourceMark uses >>>>>>> ResourceArea in current thread. So ResourceMark in writeEvent() should >>>>>>> pass valid ResourceArea. >>>>>>> >>>>>>> I think this issue is in traceEventClasses.xsl . >>>>>>> However, my environment (GCC 5.3.1 on Fedora23) cannot build it >>>>>>> because -Werror=maybe-uninitialized was occurred. >>>>>>> So I also fixed them together. >>>>>>> >>>>>>> I've uploaded webrev. Could you review it? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8145788/webrev.00/ >>>>>>> >>>>>>> I'm jdk9 committer, however I cannot access JPRT. >>>>>>> So I need a sponsor. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> From jaroslav.bachorik at oracle.com Mon Jan 11 09:21:21 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 11 Jan 2016 10:21:21 +0100 Subject: JDK-8031753 : Review request In-Reply-To: <568F84E3.2040602@oracle.com> References: <568F84E3.2040602@oracle.com> Message-ID: <56937411.5080208@oracle.com> [adding JMX dev list] On 8.1.2016 10:44, Harsha Wardhana B wrote: > Hi All, > > Please review the fix for, > > Issue : JDK-8031753 - JMXServiceURL should not use > getLocalHost or its usage should be enhanced > Webrev : > http://cr.openjdk.java.net/~jbachorik/sponsorship/8031753/webrev.00/ > > The issue can be reproduced by removing entry for hostname in /etc/hosts > (for linux) and running > 'javax/management/remote/mandatory/connection/RMIConnectionIdTest' test. > Hence no new jtreg test case have been written. > > Fix Description: > > If JMXServiceURL is given null host, it tries to resolve hostname via > InetAddress.getLocalHost() and if that fails throws > MalformedURLException. Since JMX Agent will listen on all interfaces > (0.0.0.0) if host is null, the fix handles the exception and assigns > first active non-loopback interface IP address to host. That way we can > have JMXServiceURL with IP address instead of hostname. > > It is possible that we might end up constructing JMXServiceURL with IP > for an interface which clients may not be able to connect (because of > network reachability issues). In that case, the recommendation would be > to try to start JMX Agent with > com.sun.management.jmxremote.host=xx.xx.xx.xx option. That way, the > agent will be started on interface that clients can actually connect to. > > Please review the fix and let me know your comments. The fix requires > amending javadoc with above behavioral change and a CCC review as well > which I will send out later. > > Thanks > Harsha > From markus.gronlund at oracle.com Mon Jan 11 09:48:52 2016 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Mon, 11 Jan 2016 01:48:52 -0800 (PST) Subject: PING: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing In-Reply-To: <5693079F.1020702@oracle.com> References: <56742B46.9050106@gmail.com> <56793FE2.5090106@oracle.com> <5679FD8D.2090201@gmail.com> <567A2121.1060504@oracle.com> <567AAEE7.1060806@gmail.com> <568CB5E3.6080105@oracle.com> <5692566C.1000001@gmail.com> <5693079F.1020702@oracle.com> Message-ID: Hi David, Thanks for pointing to the locked branch as well. Thanks to the bootstrap aware logic in defaultStream::hold(intx writer_id) this should be ok as is: ttyLocker will call the hold() member function which defaults to single threaded behavior during bootstrap (DefaultStream::NOWRITER). This is accomplished by checking the availability of both ttyLock as well as Thread::current_or_null(). Cheers Markus -----Original Message----- From: David Holmes Sent: den 11 januari 2016 02:39 To: Markus Gronlund; Yasumasa Suenaga Cc: serviceability-dev at openjdk.java.net Subject: Re: PING: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing Hi Markus, Thanks very much for stepping in on this one. I like your solution to this particular problem. Aside: I noticed in writeEvent there is also UseLockedTracing and I'm wondering if that will also lead to an assertion failure due to no current thread? Thanks, David On 11/01/2016 9:25 AM, Markus Gronlund wrote: > Hi Yasumasa, > > Apologies for the delay in getting a response to you. > > Thanks for reporting and attempting to fix this issue. > > I have investigated this a bit as well as trying out your suggested patch. > > I must admit it is hard to get this right at this early stage of the VM, and though I appreciated your effort for resolution, the patch suggestion will not work out of the box unfortunately. > > I have summarized some of my findings and reasoning here: > > http://cr.openjdk.java.net/~mgronlun/8145788/notes.txt > > As you can see, Thread::current() cannot be called at this stage. If we update to instead call Thread::current_or_null(), you will now run into problems in the interplay between an explicit delete of a Cheap allocated ResourceArea and the subsequent ResourceMark destructor. Here, the rm destructor asserts since it expects _nesting_level > 0, but that data has already been invalidated. > > You could accomplish all of this by doing: > > + bool thread_has_resource = Thread::current_or_null() != NULL; > + ResourceArea *area = thread_has_resource > + ? Thread::current()->resource_area() > + : new (mtTracing)ResourceArea(Chunk::non_pool_size); > + { > + ResourceMark rm(area); > + if (UseLockedTracing) { > + ttyLocker lock; > + writeEventContent(); > + } else { > + writeEventContent(); > + } > + } > + > + if (!thread_has_resource) { > + delete area; > } > > > However, it is getting a bit complex. In addition, now every trace statement needs to check Thread::current_or_null().. > > If you look at my reasoning in the second part, I think we can fix this in an easier way. > > You can find my suggestion as a webrev here: > > http://cr.openjdk.java.net/~mgronlun/8145788/ > > Please try the patch out to see if you are ok with it. > > Thanks for your patience > > Best regards > Markus > > > > -----Original Message----- > From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] > Sent: den 10 januari 2016 14:03 > To: serviceability-dev at openjdk.java.net > Subject: PING: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing > > Ping: What do you think about this issue? > > On 2016/01/06 15:36, David Holmes wrote: >> Pinging the serviceability tracing experts please! >> >> David >> >> On 24/12/2015 12:25 AM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>>>> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). >>>> >>>> That is not likely to be an option - it would likely be far too >>>> disruptive to the initialization sequence. >>> >>> Agree. Thus I choose 2. >>> >>>> We will have to wait for the tracing experts to have a good look at >>>> this. >>> >>> I'm waiting that the tracing experts join this discussion. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2015/12/23 13:20, David Holmes wrote: >>>> Hi Yasumasa, >>>> >>>> On 23/12/2015 11:49 AM, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>> I've added callstack when JVM crashed: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8145788?focusedCommentId= >>>>> 1 >>>>> 3880225&page=com.atlassian.jira.plugin.system.issuetabpanels:comme >>>>> n >>>>> t-tabpanel#comment-13880225 >>>> >>>> Thanks for that. >>>> >>>>> This crash occurrs in Arguments::apply_ergo() in Threads::create_vm(). >>>>> apply_ergo() calls before JavaThread initialization. >>>>> >>>>> I think that TraceEvent can avoid crash with two approach: >>>>> >>>>> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). >>>> >>>> That is not likely to be an option - it would likely be far too >>>> disruptive to the initialization sequence. >>>> >>>>> 2. Avoid crash at TraceEvent when it is called before JavaThread initialization. >>>> >>>> Or don't call it at all. >>>> >>>> We will have to wait for the tracing experts to have a good look at >>>> this. We end up in code that is not expecting to be run before more >>>> of the VM is initialized, so we have to look at what else may be >>>> being assumed and then decide whether to handle the situation or avoid it. >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2015/12/22 21:19, David Holmes wrote: >>>>>> On 19/12/2015 1:50 AM, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I encountered JVM crash when I passed -XX:+EnableTracing. >>>>>>> >>>>>>> I checked core image, it crashed in EventBooleanFlagChanged::writeEvent() >>>>>>> which is called by Arguments::apply_ergo() because thread had not been >>>>>>> initialized. (JVM seems to log changing GC algorithm to >>>>>>> G1.) >>>>>> >>>>>> This seems like a logic error to me - something is trying to >>>>>> happen too early during VM initialization. We need to look at >>>>>> exactly what we are trying to do here, not just work around the crash. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> writeEvent() uses ResourceMark. Default constructor of ResourceMark uses >>>>>>> ResourceArea in current thread. So ResourceMark in writeEvent() should >>>>>>> pass valid ResourceArea. >>>>>>> >>>>>>> I think this issue is in traceEventClasses.xsl . >>>>>>> However, my environment (GCC 5.3.1 on Fedora23) cannot build it >>>>>>> because -Werror=maybe-uninitialized was occurred. >>>>>>> So I also fixed them together. >>>>>>> >>>>>>> I've uploaded webrev. Could you review it? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8145788/webrev.00/ >>>>>>> >>>>>>> I'm jdk9 committer, however I cannot access JPRT. >>>>>>> So I need a sponsor. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> From yasuenag at gmail.com Mon Jan 11 10:08:39 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 11 Jan 2016 19:08:39 +0900 Subject: PING: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing In-Reply-To: References: <56742B46.9050106@gmail.com> <56793FE2.5090106@oracle.com> <5679FD8D.2090201@gmail.com> <567A2121.1060504@oracle.com> <567AAEE7.1060806@gmail.com> <568CB5E3.6080105@oracle.com> <5692566C.1000001@gmail.com> <5693079F.1020702@oracle.com> Message-ID: <56937F27.3080908@gmail.com> Hi Markus, David, I agree the solution of Markus too! Thanks, Yasumasa On 2016/01/11 18:48, Markus Gronlund wrote: > Hi David, > > Thanks for pointing to the locked branch as well. > > Thanks to the bootstrap aware logic in defaultStream::hold(intx writer_id) this should be ok as is: > > ttyLocker will call the hold() member function which defaults to single threaded behavior during bootstrap (DefaultStream::NOWRITER). This is accomplished by checking the availability of both ttyLock as well as Thread::current_or_null(). > > Cheers > Markus > > -----Original Message----- > From: David Holmes > Sent: den 11 januari 2016 02:39 > To: Markus Gronlund; Yasumasa Suenaga > Cc: serviceability-dev at openjdk.java.net > Subject: Re: PING: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing > > Hi Markus, > > Thanks very much for stepping in on this one. I like your solution to this particular problem. > > Aside: I noticed in writeEvent there is also UseLockedTracing and I'm wondering if that will also lead to an assertion failure due to no current thread? > > Thanks, > David > > On 11/01/2016 9:25 AM, Markus Gronlund wrote: >> Hi Yasumasa, >> >> Apologies for the delay in getting a response to you. >> >> Thanks for reporting and attempting to fix this issue. >> >> I have investigated this a bit as well as trying out your suggested patch. >> >> I must admit it is hard to get this right at this early stage of the VM, and though I appreciated your effort for resolution, the patch suggestion will not work out of the box unfortunately. >> >> I have summarized some of my findings and reasoning here: >> >> http://cr.openjdk.java.net/~mgronlun/8145788/notes.txt >> >> As you can see, Thread::current() cannot be called at this stage. If we update to instead call Thread::current_or_null(), you will now run into problems in the interplay between an explicit delete of a Cheap allocated ResourceArea and the subsequent ResourceMark destructor. Here, the rm destructor asserts since it expects _nesting_level > 0, but that data has already been invalidated. >> >> You could accomplish all of this by doing: >> >> + bool thread_has_resource = Thread::current_or_null() != NULL; >> + ResourceArea *area = thread_has_resource >> + ? Thread::current()->resource_area() >> + : new (mtTracing)ResourceArea(Chunk::non_pool_size); >> + { >> + ResourceMark rm(area); >> + if (UseLockedTracing) { >> + ttyLocker lock; >> + writeEventContent(); >> + } else { >> + writeEventContent(); >> + } >> + } >> + >> + if (!thread_has_resource) { >> + delete area; >> } >> >> >> However, it is getting a bit complex. In addition, now every trace statement needs to check Thread::current_or_null().. >> >> If you look at my reasoning in the second part, I think we can fix this in an easier way. >> >> You can find my suggestion as a webrev here: >> >> http://cr.openjdk.java.net/~mgronlun/8145788/ >> >> Please try the patch out to see if you are ok with it. >> >> Thanks for your patience >> >> Best regards >> Markus >> >> >> >> -----Original Message----- >> From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] >> Sent: den 10 januari 2016 14:03 >> To: serviceability-dev at openjdk.java.net >> Subject: PING: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing >> >> Ping: What do you think about this issue? >> >> On 2016/01/06 15:36, David Holmes wrote: >>> Pinging the serviceability tracing experts please! >>> >>> David >>> >>> On 24/12/2015 12:25 AM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>>>> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). >>>>> >>>>> That is not likely to be an option - it would likely be far too >>>>> disruptive to the initialization sequence. >>>> >>>> Agree. Thus I choose 2. >>>> >>>>> We will have to wait for the tracing experts to have a good look at >>>>> this. >>>> >>>> I'm waiting that the tracing experts join this discussion. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2015/12/23 13:20, David Holmes wrote: >>>>> Hi Yasumasa, >>>>> >>>>> On 23/12/2015 11:49 AM, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>> I've added callstack when JVM crashed: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8145788?focusedCommentId= >>>>>> 1 >>>>>> 3880225&page=com.atlassian.jira.plugin.system.issuetabpanels:comme >>>>>> n >>>>>> t-tabpanel#comment-13880225 >>>>> >>>>> Thanks for that. >>>>> >>>>>> This crash occurrs in Arguments::apply_ergo() in Threads::create_vm(). >>>>>> apply_ergo() calls before JavaThread initialization. >>>>>> >>>>>> I think that TraceEvent can avoid crash with two approach: >>>>>> >>>>>> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). >>>>> >>>>> That is not likely to be an option - it would likely be far too >>>>> disruptive to the initialization sequence. >>>>> >>>>>> 2. Avoid crash at TraceEvent when it is called before JavaThread initialization. >>>>> >>>>> Or don't call it at all. >>>>> >>>>> We will have to wait for the tracing experts to have a good look at >>>>> this. We end up in code that is not expecting to be run before more >>>>> of the VM is initialized, so we have to look at what else may be >>>>> being assumed and then decide whether to handle the situation or avoid it. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2015/12/22 21:19, David Holmes wrote: >>>>>>> On 19/12/2015 1:50 AM, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I encountered JVM crash when I passed -XX:+EnableTracing. >>>>>>>> >>>>>>>> I checked core image, it crashed in EventBooleanFlagChanged::writeEvent() >>>>>>>> which is called by Arguments::apply_ergo() because thread had not been >>>>>>>> initialized. (JVM seems to log changing GC algorithm to >>>>>>>> G1.) >>>>>>> >>>>>>> This seems like a logic error to me - something is trying to >>>>>>> happen too early during VM initialization. We need to look at >>>>>>> exactly what we are trying to do here, not just work around the crash. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> writeEvent() uses ResourceMark. Default constructor of ResourceMark uses >>>>>>>> ResourceArea in current thread. So ResourceMark in writeEvent() should >>>>>>>> pass valid ResourceArea. >>>>>>>> >>>>>>>> I think this issue is in traceEventClasses.xsl . >>>>>>>> However, my environment (GCC 5.3.1 on Fedora23) cannot build it >>>>>>>> because -Werror=maybe-uninitialized was occurred. >>>>>>>> So I also fixed them together. >>>>>>>> >>>>>>>> I've uploaded webrev. Could you review it? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8145788/webrev.00/ >>>>>>>> >>>>>>>> I'm jdk9 committer, however I cannot access JPRT. >>>>>>>> So I need a sponsor. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> From sharath.ballal at oracle.com Mon Jan 11 11:38:01 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 11 Jan 2016 03:38:01 -0800 (PST) Subject: Review of JDK-6659240 - Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFactory In-Reply-To: <568E7253.9000801@oracle.com> References: <2072ed8f-585c-4c1c-b036-c97775636db1@default> <56839E8D.3010706@oracle.com> <2140e74a-c99f-4131-ad0c-b6b05e06fc46@default> <568E7253.9000801@oracle.com> Message-ID: <5ecaf36a-b0a8-42d4-a084-f7c75d71dd08@default> Hi Daniel, Thanks for the comments. Yes it is a typo, I have modified the text to what you suggested as that is more clear. I will provide the link with the new changes. -Sharath Ballal -----Original Message----- From: Daniel Fuchs Sent: Thursday, January 07, 2016 7:43 PM To: Sharath Ballal; Jaroslav Bachorik; serviceability-dev at openjdk.java.net Subject: Re: Review of JDK-6659240 - Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFactory Hi, 524 * An application remotely accessing the platform MXBeans using 525 * proxy should prepare to catch {@code UndeclaredThrowableException} as if 526 * accessing with the {@code MBeanServerConnector} interface. I find this text confusing. 1. It's not clear what the {@code MBeanServerConnector} interface is. I suspect this is a typo? 2. If this is a typo and {@code MBeanServerConnection} was intended, then the text above is confusing since MBeanServerConnection will not throw UndeclaredThrowableException. Maybe something like: * An application remotely accessing the platform MXBeans using * proxy should prepare to catch {@code UndeclaredThrowableException} * and handle its {@linkplain UndeclaredThrowableException#getCause() * cause} as if that cause had been thrown by the * {@code MBeanServerConnection} interface. best regards, -- daniel On 07/01/16 11:06, Sharath Ballal wrote: > Hi, > CCC request is approved with some changes (http://ccc.us.oracle.com/6659240). Following is the link with the modifications: > > http://cr.openjdk.java.net/~jbachorik/sponsorship/6659240/webrev.01/ > > Kindly review the same. > > -Sharath Ballal > > > > -----Original Message----- > From: Jaroslav Bachorik > Sent: Wednesday, December 30, 2015 2:36 PM > To: serviceability-dev at openjdk.java.net > Subject: Re: Review of JDK-6659240 - Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFactory > > On 28.12.2015 18:01, Sharath Ballal wrote: >> Hi, >> >> Kindly review the changes for bug >> https://bugs.openjdk.java.net/browse/JDK-6659240 >> >> Webrev: http://cr.openjdk.java.net/~jbachorik/sponsorship/6659240/webrev.00/ > > Looks good! > > -JB- > >> >> CCC request for the same is being raised in parallel. >> >> -Sharath Ballal >> > From ivan.gerasimov at oracle.com Tue Jan 12 06:55:20 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 12 Jan 2016 09:55:20 +0300 Subject: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ... In-Reply-To: <568C973E.6030404@oracle.com> References: <566ECDA6.1030404@oracle.com> <566FB3BB.4050709@oracle.com> <567000F9.2070603@oracle.com> <56700279.4000408@oracle.com> <56700531.8060701@oracle.com> <56724BE9.5060304@oracle.com> <567270F6.7030206@oracle.com> <567390D4.10307@oracle.com> <56754D74.80802@oracle.com> <567A25FC.7080109@oracle.com> <567A9183.1000900@oracle.com> <568BFE80.9040000@oracle.com> <568C973E.6030404@oracle.com> Message-ID: <5694A358.9020705@oracle.com> Thanks David and Daniel! Yes, as David wrote, a thread-id is 32-bit on Windows. I'll do all the suggested changes and will push the fix later today. Sincerely yours, Ivan On 06.01.2016 7:25, David Holmes wrote: > On 6/01/2016 3:33 AM, Daniel D. Daugherty wrote: >> Happy New Year! > > And to you :) > >> >> > http://cr.openjdk.java.net/~igerasim/8145127/01/webrev/ >> >> src/os/windows/vm/os_windows.cpp >> L3923: Atomic::cmpxchg((jint)GetCurrentThreadId(), >> &process_exiting, 0); >> What's the return size of GetCurrentThreadId()? Are we > > It is a DWORD so 32-bit. > > Cheers, > David > ----- > >> down casting a larger size into a 'jint'? If so, that >> might allow more than one thread into this code when we >> only want one... >> >> Also please consider adding a comment above this line. >> Perhaps something like: >> >> // Atomically set process_exiting before the critical section >> // to increase the visibility between racing threads. >> >> L3998: if (portion_count > MAXIMUM_WAIT_OBJECTS) { >> L3999: portion_count = MAXIMUM_WAIT_OBJECTS; >> Wrong indent; should be two spaces relative to L3998. >> >> L4013: portion_count = handle_count - i; >> Please consider adding a comment for this error case. >> Perhaps something like: >> // Reset portion_count so we close the remaining >> // handles due to this error. >> >> L4030: if (OrderAccess::load_acquire(&process_exiting) != 0 && >> L4031: process_exiting != (jint)GetCurrentThreadId()) { >> L4032: while (true) { >> L4033: // Some other thread is about to call exit(), so we >> L4034: // don't let the current thread proceed to exit() or >> _endthreadex() >> The comment on L4033-4 is slightly misplaced now. It >> should be between L4031 and L4032. >> >> >> Thumbs up modulo the GetCurrentThreadId() return size question >> above. If that size is OK and you choose to make the comment >> changes, I don't need to see another webrev. >> >> Dan >> >> >> On 12/23/15 5:20 AM, Ivan Gerasimov wrote: >>> Thank you David for review! >>> >>> Sincerely yours, >>> Ivan >>> >>> On 23.12.2015 7:41, David Holmes wrote: >>>> Looks okay. >>>> >>>> Second review needed though. >>>> >>>> Thanks, >>>> David >>>> >>>> On 19/12/2015 10:28 PM, Ivan Gerasimov wrote: >>>>> >>>>> >>>>>>> We will suspend the current thread if two conditions are satisfied: >>>>>>> process_exiting != 0 and process_exiting != current thread id. >>>>>>> But, yes, pr_ex isn't really needed, as we can use process_exiting >>>>>>> directly. >>>>>>> >>>>>>> Here's the updated webrev: >>>>>>> http://cr.openjdk.java.net/~igerasim/8145127/01/webrev/ >>>>>> >>>>>> I still see pr_ex ?? >>>>>> >>>>> >>>>> Oops. >>>>> Forgot to 'hg qrefresh' before generating the webrev. >>>>> The webrev has just been updated in place. >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>> >>> >> > From markus.gronlund at oracle.com Tue Jan 12 09:34:51 2016 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 12 Jan 2016 01:34:51 -0800 (PST) Subject: PING: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing In-Reply-To: <56937F27.3080908@gmail.com> References: <56742B46.9050106@gmail.com> <56793FE2.5090106@oracle.com> <5679FD8D.2090201@gmail.com> <567A2121.1060504@oracle.com> <567AAEE7.1060806@gmail.com> <568CB5E3.6080105@oracle.com> <5692566C.1000001@gmail.com> <5693079F.1020702@oracle.com> <56937F27.3080908@gmail.com> Message-ID: <230196ae-cb72-4d53-9f61-d6d9053102b1@default> Thanks David and Yasumasa, I will then proceed with checking in my suggestion. Thanks again Markus -----Original Message----- From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] Sent: den 11 januari 2016 11:09 To: Markus Gronlund; David Holmes Cc: serviceability-dev at openjdk.java.net Subject: Re: PING: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing Hi Markus, David, I agree the solution of Markus too! Thanks, Yasumasa On 2016/01/11 18:48, Markus Gronlund wrote: > Hi David, > > Thanks for pointing to the locked branch as well. > > Thanks to the bootstrap aware logic in defaultStream::hold(intx writer_id) this should be ok as is: > > ttyLocker will call the hold() member function which defaults to single threaded behavior during bootstrap (DefaultStream::NOWRITER). This is accomplished by checking the availability of both ttyLock as well as Thread::current_or_null(). > > Cheers > Markus > > -----Original Message----- > From: David Holmes > Sent: den 11 januari 2016 02:39 > To: Markus Gronlund; Yasumasa Suenaga > Cc: serviceability-dev at openjdk.java.net > Subject: Re: PING: RFR: JDK-8145788: JVM crashes with > -XX:+EnableTracing > > Hi Markus, > > Thanks very much for stepping in on this one. I like your solution to this particular problem. > > Aside: I noticed in writeEvent there is also UseLockedTracing and I'm wondering if that will also lead to an assertion failure due to no current thread? > > Thanks, > David > > On 11/01/2016 9:25 AM, Markus Gronlund wrote: >> Hi Yasumasa, >> >> Apologies for the delay in getting a response to you. >> >> Thanks for reporting and attempting to fix this issue. >> >> I have investigated this a bit as well as trying out your suggested patch. >> >> I must admit it is hard to get this right at this early stage of the VM, and though I appreciated your effort for resolution, the patch suggestion will not work out of the box unfortunately. >> >> I have summarized some of my findings and reasoning here: >> >> http://cr.openjdk.java.net/~mgronlun/8145788/notes.txt >> >> As you can see, Thread::current() cannot be called at this stage. If we update to instead call Thread::current_or_null(), you will now run into problems in the interplay between an explicit delete of a Cheap allocated ResourceArea and the subsequent ResourceMark destructor. Here, the rm destructor asserts since it expects _nesting_level > 0, but that data has already been invalidated. >> >> You could accomplish all of this by doing: >> >> + bool thread_has_resource = Thread::current_or_null() != NULL; >> + ResourceArea *area = thread_has_resource >> + ? Thread::current()->resource_area() >> + : new (mtTracing)ResourceArea(Chunk::non_pool_size); >> + { >> + ResourceMark rm(area); >> + if (UseLockedTracing) { >> + ttyLocker lock; >> + writeEventContent(); >> + } else { >> + writeEventContent(); >> + } >> + } >> + >> + if (!thread_has_resource) { >> + delete area; >> } >> >> >> However, it is getting a bit complex. In addition, now every trace statement needs to check Thread::current_or_null().. >> >> If you look at my reasoning in the second part, I think we can fix this in an easier way. >> >> You can find my suggestion as a webrev here: >> >> http://cr.openjdk.java.net/~mgronlun/8145788/ >> >> Please try the patch out to see if you are ok with it. >> >> Thanks for your patience >> >> Best regards >> Markus >> >> >> >> -----Original Message----- >> From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] >> Sent: den 10 januari 2016 14:03 >> To: serviceability-dev at openjdk.java.net >> Subject: PING: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing >> >> Ping: What do you think about this issue? >> >> On 2016/01/06 15:36, David Holmes wrote: >>> Pinging the serviceability tracing experts please! >>> >>> David >>> >>> On 24/12/2015 12:25 AM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>>>> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). >>>>> >>>>> That is not likely to be an option - it would likely be far too >>>>> disruptive to the initialization sequence. >>>> >>>> Agree. Thus I choose 2. >>>> >>>>> We will have to wait for the tracing experts to have a good look >>>>> at this. >>>> >>>> I'm waiting that the tracing experts join this discussion. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2015/12/23 13:20, David Holmes wrote: >>>>> Hi Yasumasa, >>>>> >>>>> On 23/12/2015 11:49 AM, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>> I've added callstack when JVM crashed: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8145788?focusedCommentId >>>>>> = >>>>>> 1 >>>>>> 3880225&page=com.atlassian.jira.plugin.system.issuetabpanels:comm >>>>>> e >>>>>> n >>>>>> t-tabpanel#comment-13880225 >>>>> >>>>> Thanks for that. >>>>> >>>>>> This crash occurrs in Arguments::apply_ergo() in Threads::create_vm(). >>>>>> apply_ergo() calls before JavaThread initialization. >>>>>> >>>>>> I think that TraceEvent can avoid crash with two approach: >>>>>> >>>>>> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). >>>>> >>>>> That is not likely to be an option - it would likely be far too >>>>> disruptive to the initialization sequence. >>>>> >>>>>> 2. Avoid crash at TraceEvent when it is called before JavaThread initialization. >>>>> >>>>> Or don't call it at all. >>>>> >>>>> We will have to wait for the tracing experts to have a good look >>>>> at this. We end up in code that is not expecting to be run before >>>>> more of the VM is initialized, so we have to look at what else may >>>>> be being assumed and then decide whether to handle the situation or avoid it. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2015/12/22 21:19, David Holmes wrote: >>>>>>> On 19/12/2015 1:50 AM, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I encountered JVM crash when I passed -XX:+EnableTracing. >>>>>>>> >>>>>>>> I checked core image, it crashed in EventBooleanFlagChanged::writeEvent() >>>>>>>> which is called by Arguments::apply_ergo() because thread had not been >>>>>>>> initialized. (JVM seems to log changing GC algorithm >>>>>>>> to >>>>>>>> G1.) >>>>>>> >>>>>>> This seems like a logic error to me - something is trying to >>>>>>> happen too early during VM initialization. We need to look at >>>>>>> exactly what we are trying to do here, not just work around the crash. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> writeEvent() uses ResourceMark. Default constructor of ResourceMark uses >>>>>>>> ResourceArea in current thread. So ResourceMark in writeEvent() should >>>>>>>> pass valid ResourceArea. >>>>>>>> >>>>>>>> I think this issue is in traceEventClasses.xsl . >>>>>>>> However, my environment (GCC 5.3.1 on Fedora23) cannot build it >>>>>>>> because -Werror=maybe-uninitialized was occurred. >>>>>>>> So I also fixed them together. >>>>>>>> >>>>>>>> I've uploaded webrev. Could you review it? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8145788/webrev.00/ >>>>>>>> >>>>>>>> I'm jdk9 committer, however I cannot access JPRT. >>>>>>>> So I need a sponsor. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> From serguei.spitsyn at oracle.com Tue Jan 12 10:47:32 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 12 Jan 2016 02:47:32 -0800 Subject: [ding] Re: jmx-dev [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <568E94FD.6000206@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> <568E94FD.6000206@oracle.com> Message-ID: <5694D9C4.1030901@oracle.com> On 1/7/16 08:40, Daniel Fuchs wrote: > Hi, > > This looks OK to me. > I'm not sure I understand the full impact of the changes > in getAddressesForLocalHost() though - so hopefully someone > else will jump in to review that part... Hi Jaroslav, I do not understand the full impact of the getAddressesForLocalHost() change either so that, please, do not count me as a reviewer. However, I have a question on the fragment: + private static boolean isLocalhost(InetAddress i) { + if (!i.isLoopbackAddress()) { + return i.getHostName().toLowerCase().equals("localhost"); + } + return false; } Should true be returned instead of false if the i.isLoopbackAddress() returns true? Do we normally treat the loopbackAddress case as a localhost variant? Thanks, Serguei > > best regards, > > -- daniel > > On 07/01/16 16:02, Jaroslav Bachorik wrote: >> On 5.1.2016 15:30, Jaroslav Bachorik wrote: >>> On 4.1.2016 10:05, Jaroslav Bachorik wrote: >>>> Gentle reminder ... >>>> >>>> On 23.12.2015 11:26, Jaroslav Bachorik wrote: >>>>> Please, review the following test change >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 >>>>> >>>>> The test fails for IPv6 addresses since the RMI expects an IPv6 >>>>> address >>>>> to be properly wrapped in '[]'. In addition to that the logic for >>>>> selecting IP addresses to bind is flawed - it does not check for IP >>>>> addresses of multiple adapters but for multiple IP addresses >>>>> assigned to >>>>> 'localhost'. In combination with IPv4 & IPv6 this will cause the >>>>> test to >>>>> attempt binding to IPv4 and IPv6 address of the same adapter >>>>> simultaneously and the test will fail. >>>>> >>>>> The fix adds the requested wrapping for IPv6 addresses and adjusts >>>>> the >>>>> IP selection logic to iterate over distinct adapters first and >>>>> prevent >>>>> IPv4 and IPv6 address of the same adapter being treated as two >>>>> addresses >>>>> (for the purposes of the test). >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Tue Jan 12 11:49:08 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 12 Jan 2016 12:49:08 +0100 Subject: [ding] Re: jmx-dev [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <5694D9C4.1030901@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> <568E94FD.6000206@oracle.com> <5694D9C4.1030901@oracle.com> Message-ID: <5694E834.9020502@oracle.com> On 12.1.2016 11:47, serguei.spitsyn at oracle.com wrote: > On 1/7/16 08:40, Daniel Fuchs wrote: >> Hi, >> >> This looks OK to me. >> I'm not sure I understand the full impact of the changes >> in getAddressesForLocalHost() though - so hopefully someone >> else will jump in to review that part... > > Hi Jaroslav, > > I do not understand the full impact of the getAddressesForLocalHost() > change either > so that, please, do not count me as a reviewer. Looks like > > However, I have a question on the fragment: > > + private static boolean isLocalhost(InetAddress i) { > + if (!i.isLoopbackAddress()) { > + return i.getHostName().toLowerCase().equals("localhost"); > + } > + return false; > } > > > Should true be returned instead of false if the i.isLoopbackAddress() > returns true? > Do we normally treat the loopbackAddress case as a localhost variant? Ok, maybe the method name is missing a bit - the idea is to get all 'true' localhosts - a localhost defined on a real non-loopback adapter (as it doesn't make sense to bind JMX remote connector to a loopback address). I just couldn't come up with more describing name not being excessively long :( I'm open to any suggestions. -JB- > > Thanks, > Serguei > > >> >> best regards, >> >> -- daniel >> >> On 07/01/16 16:02, Jaroslav Bachorik wrote: >>> On 5.1.2016 15:30, Jaroslav Bachorik wrote: >>>> On 4.1.2016 10:05, Jaroslav Bachorik wrote: >>>>> Gentle reminder ... >>>>> >>>>> On 23.12.2015 11:26, Jaroslav Bachorik wrote: >>>>>> Please, review the following test change >>>>>> >>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 >>>>>> >>>>>> The test fails for IPv6 addresses since the RMI expects an IPv6 >>>>>> address >>>>>> to be properly wrapped in '[]'. In addition to that the logic for >>>>>> selecting IP addresses to bind is flawed - it does not check for IP >>>>>> addresses of multiple adapters but for multiple IP addresses >>>>>> assigned to >>>>>> 'localhost'. In combination with IPv4 & IPv6 this will cause the >>>>>> test to >>>>>> attempt binding to IPv4 and IPv6 address of the same adapter >>>>>> simultaneously and the test will fail. >>>>>> >>>>>> The fix adds the requested wrapping for IPv6 addresses and adjusts >>>>>> the >>>>>> IP selection logic to iterate over distinct adapters first and >>>>>> prevent >>>>>> IPv4 and IPv6 address of the same adapter being treated as two >>>>>> addresses >>>>>> (for the purposes of the test). >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Tue Jan 12 11:55:57 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 12 Jan 2016 03:55:57 -0800 Subject: [ding] Re: jmx-dev [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <5694E834.9020502@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> <568E94FD.6000206@oracle.com> <5694D9C4.1030901@oracle.com> <5694E834.9020502@oracle.com> Message-ID: <5694E9CD.9040409@oracle.com> On 1/12/16 03:49, Jaroslav Bachorik wrote: > On 12.1.2016 11:47, serguei.spitsyn at oracle.com wrote: >> On 1/7/16 08:40, Daniel Fuchs wrote: >>> Hi, >>> >>> This looks OK to me. >>> I'm not sure I understand the full impact of the changes >>> in getAddressesForLocalHost() though - so hopefully someone >>> else will jump in to review that part... >> >> Hi Jaroslav, >> >> I do not understand the full impact of the getAddressesForLocalHost() >> change either >> so that, please, do not count me as a reviewer. > > Looks like > >> >> However, I have a question on the fragment: >> >> + private static boolean isLocalhost(InetAddress i) { >> + if (!i.isLoopbackAddress()) { >> + return i.getHostName().toLowerCase().equals("localhost"); >> + } >> + return false; >> } >> >> >> Should true be returned instead of false if the i.isLoopbackAddress() >> returns true? >> Do we normally treat the loopbackAddress case as a localhost variant? > > Ok, maybe the method name is missing a bit - the idea is to get all > 'true' localhosts - a localhost defined on a real non-loopback adapter > (as it doesn't make sense to bind JMX remote connector to a loopback > address). Got it. Thank you for the explanation. > > I just couldn't come up with more describing name not being > excessively long :( I'm open to any suggestions. The name looks Ok to me. I'd suggest to add a short comment with your explanation above. Thanks, Serguei > > -JB- > >> >> Thanks, >> Serguei >> >> >>> >>> best regards, >>> >>> -- daniel >>> >>> On 07/01/16 16:02, Jaroslav Bachorik wrote: >>>> On 5.1.2016 15:30, Jaroslav Bachorik wrote: >>>>> On 4.1.2016 10:05, Jaroslav Bachorik wrote: >>>>>> Gentle reminder ... >>>>>> >>>>>> On 23.12.2015 11:26, Jaroslav Bachorik wrote: >>>>>>> Please, review the following test change >>>>>>> >>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 >>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 >>>>>>> >>>>>>> The test fails for IPv6 addresses since the RMI expects an IPv6 >>>>>>> address >>>>>>> to be properly wrapped in '[]'. In addition to that the logic for >>>>>>> selecting IP addresses to bind is flawed - it does not check for IP >>>>>>> addresses of multiple adapters but for multiple IP addresses >>>>>>> assigned to >>>>>>> 'localhost'. In combination with IPv4 & IPv6 this will cause the >>>>>>> test to >>>>>>> attempt binding to IPv4 and IPv6 address of the same adapter >>>>>>> simultaneously and the test will fail. >>>>>>> >>>>>>> The fix adds the requested wrapping for IPv6 addresses and adjusts >>>>>>> the >>>>>>> IP selection logic to iterate over distinct adapters first and >>>>>>> prevent >>>>>>> IPv4 and IPv6 address of the same adapter being treated as two >>>>>>> addresses >>>>>>> (for the purposes of the test). >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >>>>>> >>>>> >>>> >>> >> > From alexander.kulyakhtin at oracle.com Tue Jan 12 14:22:12 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 12 Jan 2016 06:22:12 -0800 (PST) Subject: RFR: JDK-8130063: Refactoring tmtools jstat and jstack tests to jtreg Message-ID: <6c8a9096-8d7c-4b8f-aaec-ce12e1dc2e4b@default> Hi, Could you, please, review the following test-only change CR: https://bugs.openjdk.java.net/browse/JDK-8130063 "Refactoring tmtools jstat and jstack tests to jtreg" WebRev: http://cr.openjdk.java.net/~akulyakh/8130063_01/ Before the change we had a set of tests verifying the correctness of jstat and jstack tools output in various scenarios. Those tests have been implemented by means of an internal framework, which sometimes worked unstable, resulting in false nightly failures. The functionality, which the tests verify, fully belongs to the open JDK. We are refactoring a subset of the tests to use jtreg as the test framework. In this way we are able to avoid some of the false failures of the old framework. We are also moving the tests to the Open JDK as they verify the open functionality only. For the similar refactoring of the remaining java tools tests, a separate JEP is going to be submitted. The changes have been pre-reviewed internally, the reviewers are CC'ed. Best regards, Alexander From marcus.larsson at oracle.com Tue Jan 12 14:29:07 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 12 Jan 2016 15:29:07 +0100 Subject: PING: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing In-Reply-To: <230196ae-cb72-4d53-9f61-d6d9053102b1@default> References: <56742B46.9050106@gmail.com> <56793FE2.5090106@oracle.com> <5679FD8D.2090201@gmail.com> <567A2121.1060504@oracle.com> <567AAEE7.1060806@gmail.com> <568CB5E3.6080105@oracle.com> <5692566C.1000001@gmail.com> <5693079F.1020702@oracle.com> <56937F27.3080908@gmail.com> <230196ae-cb72-4d53-9f61-d6d9053102b1@default> Message-ID: <56950DB3.9070808@oracle.com> Hi Markus, Looks good! Thanks, Marcus On 01/12/2016 10:34 AM, Markus Gronlund wrote: > Thanks David and Yasumasa, > > I will then proceed with checking in my suggestion. > > Thanks again > Markus > > -----Original Message----- > From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] > Sent: den 11 januari 2016 11:09 > To: Markus Gronlund; David Holmes > Cc: serviceability-dev at openjdk.java.net > Subject: Re: PING: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing > > Hi Markus, David, > > I agree the solution of Markus too! > > > Thanks, > > Yasumasa > > > On 2016/01/11 18:48, Markus Gronlund wrote: >> Hi David, >> >> Thanks for pointing to the locked branch as well. >> >> Thanks to the bootstrap aware logic in defaultStream::hold(intx writer_id) this should be ok as is: >> >> ttyLocker will call the hold() member function which defaults to single threaded behavior during bootstrap (DefaultStream::NOWRITER). This is accomplished by checking the availability of both ttyLock as well as Thread::current_or_null(). >> >> Cheers >> Markus >> >> -----Original Message----- >> From: David Holmes >> Sent: den 11 januari 2016 02:39 >> To: Markus Gronlund; Yasumasa Suenaga >> Cc: serviceability-dev at openjdk.java.net >> Subject: Re: PING: RFR: JDK-8145788: JVM crashes with >> -XX:+EnableTracing >> >> Hi Markus, >> >> Thanks very much for stepping in on this one. I like your solution to this particular problem. >> >> Aside: I noticed in writeEvent there is also UseLockedTracing and I'm wondering if that will also lead to an assertion failure due to no current thread? >> >> Thanks, >> David >> >> On 11/01/2016 9:25 AM, Markus Gronlund wrote: >>> Hi Yasumasa, >>> >>> Apologies for the delay in getting a response to you. >>> >>> Thanks for reporting and attempting to fix this issue. >>> >>> I have investigated this a bit as well as trying out your suggested patch. >>> >>> I must admit it is hard to get this right at this early stage of the VM, and though I appreciated your effort for resolution, the patch suggestion will not work out of the box unfortunately. >>> >>> I have summarized some of my findings and reasoning here: >>> >>> http://cr.openjdk.java.net/~mgronlun/8145788/notes.txt >>> >>> As you can see, Thread::current() cannot be called at this stage. If we update to instead call Thread::current_or_null(), you will now run into problems in the interplay between an explicit delete of a Cheap allocated ResourceArea and the subsequent ResourceMark destructor. Here, the rm destructor asserts since it expects _nesting_level > 0, but that data has already been invalidated. >>> >>> You could accomplish all of this by doing: >>> >>> + bool thread_has_resource = Thread::current_or_null() != NULL; >>> + ResourceArea *area = thread_has_resource >>> + ? Thread::current()->resource_area() >>> + : new (mtTracing)ResourceArea(Chunk::non_pool_size); >>> + { >>> + ResourceMark rm(area); >>> + if (UseLockedTracing) { >>> + ttyLocker lock; >>> + writeEventContent(); >>> + } else { >>> + writeEventContent(); >>> + } >>> + } >>> + >>> + if (!thread_has_resource) { >>> + delete area; >>> } >>> >>> >>> However, it is getting a bit complex. In addition, now every trace statement needs to check Thread::current_or_null().. >>> >>> If you look at my reasoning in the second part, I think we can fix this in an easier way. >>> >>> You can find my suggestion as a webrev here: >>> >>> http://cr.openjdk.java.net/~mgronlun/8145788/ >>> >>> Please try the patch out to see if you are ok with it. >>> >>> Thanks for your patience >>> >>> Best regards >>> Markus >>> >>> >>> >>> -----Original Message----- >>> From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] >>> Sent: den 10 januari 2016 14:03 >>> To: serviceability-dev at openjdk.java.net >>> Subject: PING: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing >>> >>> Ping: What do you think about this issue? >>> >>> On 2016/01/06 15:36, David Holmes wrote: >>>> Pinging the serviceability tracing experts please! >>>> >>>> David >>>> >>>> On 24/12/2015 12:25 AM, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>>>> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). >>>>>> That is not likely to be an option - it would likely be far too >>>>>> disruptive to the initialization sequence. >>>>> Agree. Thus I choose 2. >>>>> >>>>>> We will have to wait for the tracing experts to have a good look >>>>>> at this. >>>>> I'm waiting that the tracing experts join this discussion. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2015/12/23 13:20, David Holmes wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> On 23/12/2015 11:49 AM, Yasumasa Suenaga wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> I've added callstack when JVM crashed: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8145788?focusedCommentId >>>>>>> = >>>>>>> 1 >>>>>>> 3880225&page=com.atlassian.jira.plugin.system.issuetabpanels:comm >>>>>>> e >>>>>>> n >>>>>>> t-tabpanel#comment-13880225 >>>>>> Thanks for that. >>>>>> >>>>>>> This crash occurrs in Arguments::apply_ergo() in Threads::create_vm(). >>>>>>> apply_ergo() calls before JavaThread initialization. >>>>>>> >>>>>>> I think that TraceEvent can avoid crash with two approach: >>>>>>> >>>>>>> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). >>>>>> That is not likely to be an option - it would likely be far too >>>>>> disruptive to the initialization sequence. >>>>>> >>>>>>> 2. Avoid crash at TraceEvent when it is called before JavaThread initialization. >>>>>> Or don't call it at all. >>>>>> >>>>>> We will have to wait for the tracing experts to have a good look >>>>>> at this. We end up in code that is not expecting to be run before >>>>>> more of the VM is initialized, so we have to look at what else may >>>>>> be being assumed and then decide whether to handle the situation or avoid it. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2015/12/22 21:19, David Holmes wrote: >>>>>>>> On 19/12/2015 1:50 AM, Yasumasa Suenaga wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I encountered JVM crash when I passed -XX:+EnableTracing. >>>>>>>>> >>>>>>>>> I checked core image, it crashed in EventBooleanFlagChanged::writeEvent() >>>>>>>>> which is called by Arguments::apply_ergo() because thread had not been >>>>>>>>> initialized. (JVM seems to log changing GC algorithm >>>>>>>>> to >>>>>>>>> G1.) >>>>>>>> This seems like a logic error to me - something is trying to >>>>>>>> happen too early during VM initialization. We need to look at >>>>>>>> exactly what we are trying to do here, not just work around the crash. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> writeEvent() uses ResourceMark. Default constructor of ResourceMark uses >>>>>>>>> ResourceArea in current thread. So ResourceMark in writeEvent() should >>>>>>>>> pass valid ResourceArea. >>>>>>>>> >>>>>>>>> I think this issue is in traceEventClasses.xsl . >>>>>>>>> However, my environment (GCC 5.3.1 on Fedora23) cannot build it >>>>>>>>> because -Werror=maybe-uninitialized was occurred. >>>>>>>>> So I also fixed them together. >>>>>>>>> >>>>>>>>> I've uploaded webrev. Could you review it? >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8145788/webrev.00/ >>>>>>>>> >>>>>>>>> I'm jdk9 committer, however I cannot access JPRT. >>>>>>>>> So I need a sponsor. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> From markus.gronlund at oracle.com Tue Jan 12 14:33:43 2016 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 12 Jan 2016 06:33:43 -0800 (PST) Subject: PING: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing In-Reply-To: <56950DB3.9070808@oracle.com> References: <56742B46.9050106@gmail.com> <56793FE2.5090106@oracle.com> <5679FD8D.2090201@gmail.com> <567A2121.1060504@oracle.com> <567AAEE7.1060806@gmail.com> <568CB5E3.6080105@oracle.com> <5692566C.1000001@gmail.com> <5693079F.1020702@oracle.com> <56937F27.3080908@gmail.com> <230196ae-cb72-4d53-9f61-d6d9053102b1@default> <56950DB3.9070808@oracle.com> Message-ID: Thanks Marcus for taking a look. /Markus -----Original Message----- From: Marcus Larsson Sent: den 12 januari 2016 15:29 To: Markus Gronlund; Yasumasa Suenaga; David Holmes Cc: serviceability-dev at openjdk.java.net Subject: Re: PING: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing Hi Markus, Looks good! Thanks, Marcus On 01/12/2016 10:34 AM, Markus Gronlund wrote: > Thanks David and Yasumasa, > > I will then proceed with checking in my suggestion. > > Thanks again > Markus > > -----Original Message----- > From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] > Sent: den 11 januari 2016 11:09 > To: Markus Gronlund; David Holmes > Cc: serviceability-dev at openjdk.java.net > Subject: Re: PING: RFR: JDK-8145788: JVM crashes with > -XX:+EnableTracing > > Hi Markus, David, > > I agree the solution of Markus too! > > > Thanks, > > Yasumasa > > > On 2016/01/11 18:48, Markus Gronlund wrote: >> Hi David, >> >> Thanks for pointing to the locked branch as well. >> >> Thanks to the bootstrap aware logic in defaultStream::hold(intx writer_id) this should be ok as is: >> >> ttyLocker will call the hold() member function which defaults to single threaded behavior during bootstrap (DefaultStream::NOWRITER). This is accomplished by checking the availability of both ttyLock as well as Thread::current_or_null(). >> >> Cheers >> Markus >> >> -----Original Message----- >> From: David Holmes >> Sent: den 11 januari 2016 02:39 >> To: Markus Gronlund; Yasumasa Suenaga >> Cc: serviceability-dev at openjdk.java.net >> Subject: Re: PING: RFR: JDK-8145788: JVM crashes with >> -XX:+EnableTracing >> >> Hi Markus, >> >> Thanks very much for stepping in on this one. I like your solution to this particular problem. >> >> Aside: I noticed in writeEvent there is also UseLockedTracing and I'm wondering if that will also lead to an assertion failure due to no current thread? >> >> Thanks, >> David >> >> On 11/01/2016 9:25 AM, Markus Gronlund wrote: >>> Hi Yasumasa, >>> >>> Apologies for the delay in getting a response to you. >>> >>> Thanks for reporting and attempting to fix this issue. >>> >>> I have investigated this a bit as well as trying out your suggested patch. >>> >>> I must admit it is hard to get this right at this early stage of the VM, and though I appreciated your effort for resolution, the patch suggestion will not work out of the box unfortunately. >>> >>> I have summarized some of my findings and reasoning here: >>> >>> http://cr.openjdk.java.net/~mgronlun/8145788/notes.txt >>> >>> As you can see, Thread::current() cannot be called at this stage. If we update to instead call Thread::current_or_null(), you will now run into problems in the interplay between an explicit delete of a Cheap allocated ResourceArea and the subsequent ResourceMark destructor. Here, the rm destructor asserts since it expects _nesting_level > 0, but that data has already been invalidated. >>> >>> You could accomplish all of this by doing: >>> >>> + bool thread_has_resource = Thread::current_or_null() != NULL; >>> + ResourceArea *area = thread_has_resource >>> + ? Thread::current()->resource_area() >>> + : new (mtTracing)ResourceArea(Chunk::non_pool_size); >>> + { >>> + ResourceMark rm(area); >>> + if (UseLockedTracing) { >>> + ttyLocker lock; >>> + writeEventContent(); >>> + } else { >>> + writeEventContent(); >>> + } >>> + } >>> + >>> + if (!thread_has_resource) { >>> + delete area; >>> } >>> >>> >>> However, it is getting a bit complex. In addition, now every trace statement needs to check Thread::current_or_null().. >>> >>> If you look at my reasoning in the second part, I think we can fix this in an easier way. >>> >>> You can find my suggestion as a webrev here: >>> >>> http://cr.openjdk.java.net/~mgronlun/8145788/ >>> >>> Please try the patch out to see if you are ok with it. >>> >>> Thanks for your patience >>> >>> Best regards >>> Markus >>> >>> >>> >>> -----Original Message----- >>> From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] >>> Sent: den 10 januari 2016 14:03 >>> To: serviceability-dev at openjdk.java.net >>> Subject: PING: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing >>> >>> Ping: What do you think about this issue? >>> >>> On 2016/01/06 15:36, David Holmes wrote: >>>> Pinging the serviceability tracing experts please! >>>> >>>> David >>>> >>>> On 24/12/2015 12:25 AM, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>>>> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). >>>>>> That is not likely to be an option - it would likely be far too >>>>>> disruptive to the initialization sequence. >>>>> Agree. Thus I choose 2. >>>>> >>>>>> We will have to wait for the tracing experts to have a good look >>>>>> at this. >>>>> I'm waiting that the tracing experts join this discussion. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2015/12/23 13:20, David Holmes wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> On 23/12/2015 11:49 AM, Yasumasa Suenaga wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> I've added callstack when JVM crashed: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8145788?focusedCommentI >>>>>>> d >>>>>>> = >>>>>>> 1 >>>>>>> 3880225&page=com.atlassian.jira.plugin.system.issuetabpanels:com >>>>>>> m >>>>>>> e >>>>>>> n >>>>>>> t-tabpanel#comment-13880225 >>>>>> Thanks for that. >>>>>> >>>>>>> This crash occurrs in Arguments::apply_ergo() in Threads::create_vm(). >>>>>>> apply_ergo() calls before JavaThread initialization. >>>>>>> >>>>>>> I think that TraceEvent can avoid crash with two approach: >>>>>>> >>>>>>> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). >>>>>> That is not likely to be an option - it would likely be far too >>>>>> disruptive to the initialization sequence. >>>>>> >>>>>>> 2. Avoid crash at TraceEvent when it is called before JavaThread initialization. >>>>>> Or don't call it at all. >>>>>> >>>>>> We will have to wait for the tracing experts to have a good look >>>>>> at this. We end up in code that is not expecting to be run before >>>>>> more of the VM is initialized, so we have to look at what else >>>>>> may be being assumed and then decide whether to handle the situation or avoid it. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2015/12/22 21:19, David Holmes wrote: >>>>>>>> On 19/12/2015 1:50 AM, Yasumasa Suenaga wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I encountered JVM crash when I passed -XX:+EnableTracing. >>>>>>>>> >>>>>>>>> I checked core image, it crashed in EventBooleanFlagChanged::writeEvent() >>>>>>>>> which is called by Arguments::apply_ergo() because thread had not been >>>>>>>>> initialized. (JVM seems to log changing GC algorithm >>>>>>>>> to >>>>>>>>> G1.) >>>>>>>> This seems like a logic error to me - something is trying to >>>>>>>> happen too early during VM initialization. We need to look at >>>>>>>> exactly what we are trying to do here, not just work around the crash. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> writeEvent() uses ResourceMark. Default constructor of ResourceMark uses >>>>>>>>> ResourceArea in current thread. So ResourceMark in writeEvent() should >>>>>>>>> pass valid ResourceArea. >>>>>>>>> >>>>>>>>> I think this issue is in traceEventClasses.xsl . >>>>>>>>> However, my environment (GCC 5.3.1 on Fedora23) cannot build >>>>>>>>> it because -Werror=maybe-uninitialized was occurred. >>>>>>>>> So I also fixed them together. >>>>>>>>> >>>>>>>>> I've uploaded webrev. Could you review it? >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8145788/webrev.00/ >>>>>>>>> >>>>>>>>> I'm jdk9 committer, however I cannot access JPRT. >>>>>>>>> So I need a sponsor. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> From cheleswer.sahu at oracle.com Wed Jan 13 10:25:54 2016 From: cheleswer.sahu at oracle.com (cheleswer sahu) Date: Wed, 13 Jan 2016 15:55:54 +0530 Subject: RFR[9u-dev] 8130425: libjvm crash due to stack overflow in executables with 32k tbss/tdata Message-ID: <56962632.7080404@oracle.com> Hi, Please review the code changes for "https://bugs.openjdk.java.net/browse/JDK-8130425". Problem summary: When a large TLS (Thread Local Storage) size is set for threads, JVM is throwing StackOverflow exception. Problem Identified: As per investigation and a discussion we came to the conclusion that issue is not with the JVM but it lies in the way glibc has been implemented. When a TLS is declared , it steals the space from threads stack size. So if a thread is created with small stack size, and TLS is set to a large value, then it will result in StackOverflow. This is the exact case in this bug where reaper thread is allocated a very low stack size 32768. Discussion thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037558.html Solution proposed: Its expected to get fix in glibc sometime , but for now I propose a workaround, a boolean system property "processReaperUseDefaultStackSize" using which we can set the stack size for reaper thread to default instead of fix 32768. This property can be set by the user using "-D" or "System.setProperty()". I have tested this fix, it works well with TLS size between 32k to 128k. Fix: diff -r 5c4530bb9ae6 src/java.base/share/classes/java/lang/ProcessHandleImpl.jav --- a/src/java.base/share/classes/java/lang/ProcessHandleImpl.java Fri Jan 08 13:06:29 2016 +0800 +++ b/src/java.base/share/classes/java/lang/ProcessHandleImpl.java Tue Jan 12 15:55:50 2016 +0530 @@ -83,9 +83,13 @@ ThreadGroup systemThreadGroup = tg; ThreadFactory threadFactory = grimReaper -> { - // Our thread stack requirement is quite modest. - Thread t = new Thread(systemThreadGroup, grimReaper, - "process reaper", 32768); + Thread t = null; + if (Boolean.getBoolean("processReaperUseDefaultStackSize")) { + t = new Thread(systemThreadGroup, grimReaper, "process reaper"); + } else { + // Our thread stack requirement is quite modest. + t = new Thread(systemThreadGroup, grimReaper, "process reaper", 32768); + } t.setDaemon(true); // A small attempt (probably futile) to avoid priority inversion t.setPriority(Thread.MAX_PRIORITY); Regards, Cheleswer From jaroslav.bachorik at oracle.com Wed Jan 13 11:16:21 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 13 Jan 2016 12:16:21 +0100 Subject: [ding] Re: jmx-dev [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <5694E9CD.9040409@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> <568E94FD.6000206@oracle.com> <5694D9C4.1030901@oracle.com> <5694E834.9020502@oracle.com> <5694E9CD.9040409@oracle.com> Message-ID: <56963205.5000505@oracle.com> On 12.1.2016 12:55, serguei.spitsyn at oracle.com wrote: > On 1/12/16 03:49, Jaroslav Bachorik wrote: >> On 12.1.2016 11:47, serguei.spitsyn at oracle.com wrote: >>> On 1/7/16 08:40, Daniel Fuchs wrote: >>>> Hi, >>>> >>>> This looks OK to me. >>>> I'm not sure I understand the full impact of the changes >>>> in getAddressesForLocalHost() though - so hopefully someone >>>> else will jump in to review that part... >>> >>> Hi Jaroslav, >>> >>> I do not understand the full impact of the getAddressesForLocalHost() >>> change either >>> so that, please, do not count me as a reviewer. >> >> Looks like >> >>> >>> However, I have a question on the fragment: >>> >>> + private static boolean isLocalhost(InetAddress i) { >>> + if (!i.isLoopbackAddress()) { >>> + return i.getHostName().toLowerCase().equals("localhost"); >>> + } >>> + return false; >>> } >>> >>> >>> Should true be returned instead of false if the i.isLoopbackAddress() >>> returns true? >>> Do we normally treat the loopbackAddress case as a localhost variant? >> >> Ok, maybe the method name is missing a bit - the idea is to get all >> 'true' localhosts - a localhost defined on a real non-loopback adapter >> (as it doesn't make sense to bind JMX remote connector to a loopback >> address). > > Got it. > Thank you for the explanation. > > >> >> I just couldn't come up with more describing name not being >> excessively long :( I'm open to any suggestions. > > The name looks Ok to me. > I'd suggest to add a short comment with your explanation above. Thanks. I've added the explanation and also disambiguated the method name a bit. http://cr.openjdk.java.net/~jbachorik/8146015/webrev.01 It looks like no one else is going to jump in and verify the getAddressesForLocalHost() change (basically, excluding the loopback localhost addresses as they are not suitable for binding the remote JMX connector to) :/ Maybe Severing could comment, as the orignal author? I would like to integrate this change ASAP since the test is failing 100% in nightly runs. -JB- > > > Thanks, > Serguei > > >> >> -JB- >> >>> >>> Thanks, >>> Serguei >>> >>> >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 07/01/16 16:02, Jaroslav Bachorik wrote: >>>>> On 5.1.2016 15:30, Jaroslav Bachorik wrote: >>>>>> On 4.1.2016 10:05, Jaroslav Bachorik wrote: >>>>>>> Gentle reminder ... >>>>>>> >>>>>>> On 23.12.2015 11:26, Jaroslav Bachorik wrote: >>>>>>>> Please, review the following test change >>>>>>>> >>>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 >>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 >>>>>>>> >>>>>>>> The test fails for IPv6 addresses since the RMI expects an IPv6 >>>>>>>> address >>>>>>>> to be properly wrapped in '[]'. In addition to that the logic for >>>>>>>> selecting IP addresses to bind is flawed - it does not check for IP >>>>>>>> addresses of multiple adapters but for multiple IP addresses >>>>>>>> assigned to >>>>>>>> 'localhost'. In combination with IPv4 & IPv6 this will cause the >>>>>>>> test to >>>>>>>> attempt binding to IPv4 and IPv6 address of the same adapter >>>>>>>> simultaneously and the test will fail. >>>>>>>> >>>>>>>> The fix adds the requested wrapping for IPv6 addresses and adjusts >>>>>>>> the >>>>>>>> IP selection logic to iterate over distinct adapters first and >>>>>>>> prevent >>>>>>>> IPv4 and IPv6 address of the same adapter being treated as two >>>>>>>> addresses >>>>>>>> (for the purposes of the test). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -JB- >>>>>>> >>>>>> >>>>> >>>> >>> >> > From daniel.fuchs at oracle.com Wed Jan 13 12:00:22 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 13 Jan 2016 13:00:22 +0100 Subject: [ding] Re: jmx-dev [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <56963205.5000505@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> <568E94FD.6000206@oracle.com> <5694D9C4.1030901@oracle.com> <5694E834.9020502@oracle.com> <5694E9CD.9040409@oracle.com> <56963205.5000505@oracle.com> Message-ID: <56963C56.9090209@oracle.com> On 13/01/16 12:16, Jaroslav Bachorik wrote: > Thanks. I've added the explanation and also disambiguated the method > name a bit. > > http://cr.openjdk.java.net/~jbachorik/8146015/webrev.01 > > It looks like no one else is going to jump in and verify the > getAddressesForLocalHost() change (basically, excluding the loopback > localhost addresses as they are not suitable for binding the remote JMX > connector to) :/ Maybe Severing could comment, as the orignal author? > > I would like to integrate this change ASAP since the test is failing > 100% in nightly runs. > Looks to me Jaroslav :-) -- daniel From jaroslav.bachorik at oracle.com Wed Jan 13 12:13:21 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 13 Jan 2016 13:13:21 +0100 Subject: [ding] Re: jmx-dev [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <56963C56.9090209@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> <568E94FD.6000206@oracle.com> <5694D9C4.1030901@oracle.com> <5694E834.9020502@oracle.com> <5694E9CD.9040409@oracle.com> <56963205.5000505@oracle.com> <56963C56.9090209@oracle.com> Message-ID: <56963F61.2040508@oracle.com> On 13.1.2016 13:00, Daniel Fuchs wrote: > On 13/01/16 12:16, Jaroslav Bachorik wrote: >> Thanks. I've added the explanation and also disambiguated the method >> name a bit. >> >> http://cr.openjdk.java.net/~jbachorik/8146015/webrev.01 >> >> It looks like no one else is going to jump in and verify the >> getAddressesForLocalHost() change (basically, excluding the loopback >> localhost addresses as they are not suitable for binding the remote JMX >> connector to) :/ Maybe Severing could comment, as the orignal author? >> >> I would like to integrate this change ASAP since the test is failing >> 100% in nightly runs. >> > > Looks to me Jaroslav :-) Thanks :) It's nice that this kind of change is named after me ;) -JB- > > -- daniel From david.holmes at oracle.com Wed Jan 13 12:25:17 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Jan 2016 22:25:17 +1000 Subject: RFR[9u-dev] 8130425: libjvm crash due to stack overflow in executables with 32k tbss/tdata In-Reply-To: <56962632.7080404@oracle.com> References: <56962632.7080404@oracle.com> Message-ID: <5696422D.5060402@oracle.com> Hi Cheleswer, On 13/01/2016 8:25 PM, cheleswer sahu wrote: > Hi, > > Please review the code changes for > "https://bugs.openjdk.java.net/browse/JDK-8130425". > > Problem summary: When a large TLS (Thread Local Storage) size is set for > threads, JVM is throwing StackOverflow exception. > > Problem Identified: > As per investigation and a discussion we came to the conclusion that > issue is not with the JVM but it lies in the way glibc has been > implemented. When a TLS is declared , it steals the space from threads > stack size. > So if a thread is created with small stack size, and TLS is set to a > large value, then it will result in StackOverflow. This is the exact > case in this bug where reaper thread is allocated a very low stack size > 32768. > > Discussion thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037558.html > > > Solution proposed: > Its expected to get fix in glibc sometime , but for now I propose a > workaround, a boolean system property "processReaperUseDefaultStackSize" That might be a reasonable name for a -XX VM flag but system properties follow a more structured naming convention - possibly something like java.lang.Process.processReaperUsesDefaultStackSize? Though this is an implementation detail so maybe java.lang is not the right namespace for this either. Not sure who would know the best way to name this - probably core-libs folk. This would need to go through CCC process as well. David ----- > using which we can set the stack size for reaper thread to default > instead of fix 32768. This property can be set by the user using "-D" or > "System.setProperty()". I have tested this fix, it works well with TLS > size between 32k to 128k. > > Fix: > diff -r 5c4530bb9ae6 > src/java.base/share/classes/java/lang/ProcessHandleImpl.jav > --- a/src/java.base/share/classes/java/lang/ProcessHandleImpl.java Fri > Jan 08 13:06:29 2016 +0800 > +++ b/src/java.base/share/classes/java/lang/ProcessHandleImpl.java Tue > Jan 12 15:55:50 2016 +0530 > @@ -83,9 +83,13 @@ > ThreadGroup systemThreadGroup = tg; > > ThreadFactory threadFactory = grimReaper -> { > - // Our thread stack requirement is quite modest. > - Thread t = new Thread(systemThreadGroup, grimReaper, > - "process reaper", 32768); > + Thread t = null; > + if > (Boolean.getBoolean("processReaperUseDefaultStackSize")) { > + t = new Thread(systemThreadGroup, grimReaper, > "process reaper"); > + } else { > + // Our thread stack requirement is quite modest. > + t = new Thread(systemThreadGroup, grimReaper, > "process reaper", 32768); > + } > t.setDaemon(true); > // A small attempt (probably futile) to avoid > priority inversion > t.setPriority(Thread.MAX_PRIORITY); > > > Regards, > Cheleswer From andreas.eriksson at oracle.com Wed Jan 13 12:39:11 2016 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Wed, 13 Jan 2016 13:39:11 +0100 Subject: RFR (M): 8129419: heapDumper.cpp: assert(length_in_bytes > 0) failed: nothing to copy In-Reply-To: <5682ECC8.2040309@oracle.com> References: <566EE268.1010803@oracle.com> <566EFCC7.6010106@oracle.com> <566F0BCB.3000407@oracle.com> <568140F6.40805@oracle.com> <5682ECC8.2040309@oracle.com> Message-ID: <5696456F.8020904@oracle.com> Hi, On 2015-12-29 21:27, Dmitry Samersoff wrote: > Andreas, > > Great work. All but write_internal looks good for me (see below). > > > HprofReader.java: > > Nit - length -= skipped; should be after if skipped == 0 > > heapDumper.cpp:480 > > 1. For windows you can do : > assert(len < (size_t)UINT_MAX, ... ); > ::write( ..., (uint) (len & UINT_MAX)); > > 2. You should check for n < len and if it is true, > deal with errno. n = 0 is legitimate case, > so assert is not necessary. I only think n = 0 is valid if write is called with length 0, which write_internal will never do. Otherwise, according to posix, n will be -1 if an error occurred, or greater than zero if some bytes were written. [1] If some bytes but not all were written then the while(len > 0) loop will make sure we try to write the rest of the bytes. It looks like windows write should never return 0 when len != 0 either. [2] I should however handle the -1 result with errno EINTR, working on a new webrev. Thanks, Andreas [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html If write() is interrupted by a signal before it writes any data, it shall return -1 with errno set to [EINTR]. If write() is interrupted by a signal after it successfully writes some data, it shall return the number of bytes written. [2] https://msdn.microsoft.com/en-us/library/1570wh78(v=vs.80).aspx > -Dmitry > > On 2015-12-28 17:02, Andreas Eriksson wrote: >> Hi, >> >> Here is the webrev for type changes. >> Top-repo: >> http://cr.openjdk.java.net/~aeriksso/8129419/webrev.01/jdk9-hs-rt/ >> Hotspot: http://cr.openjdk.java.net/~aeriksso/8129419/webrev.01/hotspot/ >> >> The windows_x64 native write function uses a length of type uint, not >> size_t. I added an ifdef for that case and handled it, but better >> suggestions are welcome. >> >> Also found and fixed another problem in the hprof parser when skipping >> over bytes. >> >> I've not included the tests, they have OOM issues on several JPRT hosts, >> and until I've figured out a way to fix that I wont be pushing them. >> >> Thanks, >> Andreas >> >> On 2015-12-14 19:34, Andreas Eriksson wrote: >>> Hi Dmitry, thanks for looking at this. >>> >>> >>> On 2015-12-14 18:30, Dmitry Samersoff wrote: >>>> Andreas, >>>> >>>> Nice cleanup. >>>> >>>> Some generic comments below. >>>> >>>> 1. It would be excellent if you can split webrev into two parts, one >>>> part with types cleanup and other part with array truncation related >>>> changes or ever push these changes separately as it address different >>>> problems. >>>> >>>> Type cleanup could be reviewed quickly, but review of array truncation >>>> requires some time. >>>> >>>> (We already have two different CRs: JDK-8129419 for type cleanup and >>>> JDK-8144732 for array truncation) >>> Yes, that's a good point. >>> >>>> >>>> 2. >>>> it might be better to use size_t and jlong (or julong) across all file >>>> and get rid of all other types with a few exclusion. >>> I'll see what I can do, and we can look at it closer once I've split >>> the type changes into a separate webrev. >>> >>>> 3. >>>> Each assert costs some time in nightly testing, so we probably don't >>>> need as much asserts. >>> Alright. >>> >>>> 4. write_internal: >>>> >>>> There are couple of cases where ::write writes less bytes than >>>> requested and doesn't return -1. >>>> So we should check if ::write returns a value less that len and if it >>>> happens deal with errno - either repeat entire write >>>> attempt(EINTR/EAGAIN) or abort writing. >>> Actually, I meant to ask about that, but forgot: >>> I tried using os::write, which handles EINTR/EAGAIN if necessary >>> (depending on platform), but Solaris has an assert that fails: >>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/5a42c1dde332/src/os/solaris/vm/os_solaris.cpp#l5692 >>> >>> It checks that os::write is called by a JavaThread that is in_native, >>> which we are not, since we are in the VM_thread doing a safepoint_op. >>> Does anyone know if that assert is really needed? It's only done for >>> Solaris. >>> >>>> 5. we should handle zero-length array in calculate_array_max_length - >>>> it's a legitimate case >>> Not sure what you mean here, I believe it does handle zero-length arrays. >>> It should just fall through without taking any of the if-clauses. >>> (Or do you mean that I should add a return immediately at the top if >>> length is zero?) >>> >>>> 6. max_juint is less than SegmentedHeapDumpThreshold so non-segmented >>>> heapdump can't contain huge array and it's better to check for segmented >>>> dump before any other checks. >>> Correct me if I'm wrong here, but SegmentedHeapDumpThreshold could in >>> theory be set so that we have a non-segmented heap dump while still >>> having huge arrays. >>> Not sure if this is worth taking into account, since it most likely >>> would lead to other problems as well, and the flag is develop only, so >>> it can't happen in product builds. >>> What do you think would be best to do here? >>> >>> - Andreas >>> >>>> -Dmitry >>>> >>>> >>>> On 2015-12-14 18:38, Andreas Eriksson wrote: >>>>> Hi, >>>>> >>>>> Please review this fix for dumping of long arrays, and general cleanup >>>>> of types in heapDumper.cpp. >>>>> >>>>> Problem: >>>>> At several places in heapDumper.cpp overflows could happen when dumping >>>>> long arrays. >>>>> Also the hprof format uses an u4 as a record length field, but arrays >>>>> can be longer than that (counted in bytes). >>>>> >>>>> Fix: >>>>> Many types that were previously signed are changed to equivalent >>>>> unsigned types and/or to a larger type to prevent overflow. >>>>> The bulk of the change though is the addition of >>>>> calculate_array_max_length, which for a given array returns the number >>>>> of elements we can dump. That length is then used to truncate arrays >>>>> that are too long. >>>>> Whenever an array is truncated a warning is printed: >>>>> Java HotSpot(TM) 64-Bit Server VM warning: cannot dump array of type >>>>> object[] with length 1,073,741,823; truncating to length 536,870,908 >>>>> >>>>> Much of the rest of the change is moving functions needed by >>>>> calculate_array_max_length to the DumpWriter or DumperSupport class so >>>>> that they can be accessed. >>>>> >>>>> Added a test that relies on the hprof parser, which also had a >>>>> couple of >>>>> overflow problems (top repo changes). >>>>> I've also run this change against a couple of other tests, but they are >>>>> problematic in JPRT because they are using large heaps and lots of >>>>> disk. >>>>> >>>>> Bug: >>>>> 8129419: heapDumper.cpp: assert(length_in_bytes > 0) failed: nothing to >>>>> copy >>>>> https://bugs.openjdk.java.net/browse/JDK-8129419 >>>>> >>>>> Also fixed in this change is the problems seen in these two bugs: >>>>> 8133317: Integer overflow in heapDumper.cpp leads to corrupt HPROF >>>>> dumps >>>>> https://bugs.openjdk.java.net/browse/JDK-8133317 >>>>> >>>>> 8144732: VM_HeapDumper hits assert with bad dump_len >>>>> https://bugs.openjdk.java.net/browse/JDK-8144732 >>>>> >>>>> Webrev: >>>>> Top repo: >>>>> http://cr.openjdk.java.net/~aeriksso/8129419/webrev.00/jdk9-hs-rt/ >>>>> Hotspot: >>>>> http://cr.openjdk.java.net/~aeriksso/8129419/webrev.00/hotspot/ >>>>> >>>>> Regards, >>>>> Andreas > From jaroslav.bachorik at oracle.com Wed Jan 13 16:30:07 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 13 Jan 2016 17:30:07 +0100 Subject: RFR: JDK-8130063: Refactoring tmtools jstat and jstack tests to jtreg In-Reply-To: <6c8a9096-8d7c-4b8f-aaec-ce12e1dc2e4b@default> References: <6c8a9096-8d7c-4b8f-aaec-ce12e1dc2e4b@default> Message-ID: <56967B8F.3050704@oracle.com> Hi Alexander, On 12.1.2016 15:22, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review the following test-only change > > CR: https://bugs.openjdk.java.net/browse/JDK-8130063 "Refactoring tmtools jstat and jstack tests to jtreg" > WebRev: http://cr.openjdk.java.net/~akulyakh/8130063_01/ The changes look good. Thanks for taking care of the rewrite. -JB- > > Before the change we had a set of tests verifying the correctness of jstat and jstack tools output in various scenarios. > > Those tests have been implemented by means of an internal framework, which sometimes worked unstable, resulting in false nightly failures. > The functionality, which the tests verify, fully belongs to the open JDK. > > We are refactoring a subset of the tests to use jtreg as the test framework. In this way we are able to avoid some of the false failures of the old framework. > We are also moving the tests to the Open JDK as they verify the open functionality only. > > For the similar refactoring of the remaining java tools tests, a separate JEP is going to be submitted. > > The changes have been pre-reviewed internally, the reviewers are CC'ed. > > Best regards, > Alexander > > > From dmitry.samersoff at oracle.com Wed Jan 13 18:45:47 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 13 Jan 2016 21:45:47 +0300 Subject: RFR(M): JDK-8141070 vm/services/management.cpp should be resilient to missing 'jdk.management' module Message-ID: <56969B5B.5080006@oracle.com> Everybody, Please, review the fix: http://cr.openjdk.java.net/~dsamersoff/JDK-8141070/webrev.01/ The problem: Code in management.cpp throw NoClassDefFound exception if any of requested classes is missing. But, in upcoming modular JDK classes that not belong to java.lang.management (sun.management, com.sun.management etc) might not be present. Solution: Refactor class resolving code to support two type of classes - REQUIRED (still throw NCDFE if the class is missing) and OPTIONAL (just return NULL). I introduced a new parameter to highlight the fact that a class is an optional one on caller side rather than handle it silently inside management.cpp. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Wed Jan 13 18:51:07 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 13 Jan 2016 10:51:07 -0800 Subject: [ding] Re: jmx-dev [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <56963205.5000505@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> <568E94FD.6000206@oracle.com> <5694D9C4.1030901@oracle.com> <5694E834.9020502@oracle.com> <5694E9CD.9040409@oracle.com> <56963205.5000505@oracle.com> Message-ID: <56969C9B.1080104@oracle.com> On 1/13/16 03:16, Jaroslav Bachorik wrote: > On 12.1.2016 12:55, serguei.spitsyn at oracle.com wrote: >> On 1/12/16 03:49, Jaroslav Bachorik wrote: >>> On 12.1.2016 11:47, serguei.spitsyn at oracle.com wrote: >>>> On 1/7/16 08:40, Daniel Fuchs wrote: >>>>> Hi, >>>>> >>>>> This looks OK to me. >>>>> I'm not sure I understand the full impact of the changes >>>>> in getAddressesForLocalHost() though - so hopefully someone >>>>> else will jump in to review that part... >>>> >>>> Hi Jaroslav, >>>> >>>> I do not understand the full impact of the getAddressesForLocalHost() >>>> change either >>>> so that, please, do not count me as a reviewer. >>> >>> Looks like >>> >>>> >>>> However, I have a question on the fragment: >>>> >>>> + private static boolean isLocalhost(InetAddress i) { >>>> + if (!i.isLoopbackAddress()) { >>>> + return i.getHostName().toLowerCase().equals("localhost"); >>>> + } >>>> + return false; >>>> } >>>> >>>> >>>> Should true be returned instead of false if the i.isLoopbackAddress() >>>> returns true? >>>> Do we normally treat the loopbackAddress case as a localhost variant? >>> >>> Ok, maybe the method name is missing a bit - the idea is to get all >>> 'true' localhosts - a localhost defined on a real non-loopback adapter >>> (as it doesn't make sense to bind JMX remote connector to a loopback >>> address). >> >> Got it. >> Thank you for the explanation. >> >> >>> >>> I just couldn't come up with more describing name not being >>> excessively long :( I'm open to any suggestions. >> >> The name looks Ok to me. >> I'd suggest to add a short comment with your explanation above. > > Thanks. I've added the explanation and also disambiguated the method > name a bit. > > http://cr.openjdk.java.net/~jbachorik/8146015/webrev.01 > > It looks like no one else is going to jump in and verify the > getAddressesForLocalHost() change (basically, excluding the loopback > localhost addresses as they are not suitable for binding the remote > JMX connector to) :/ Maybe Severing could comment, as the orignal author? > > I would like to integrate this change ASAP since the test is failing > 100% in nightly runs. Ok. I looked to the getAddressesForLocalHost() part and think this fix is fine. Thumbs up from me. Thanks, Serguei > > -JB- > >> >> >> Thanks, >> Serguei >> >> >>> >>> -JB- >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>>> >>>>> On 07/01/16 16:02, Jaroslav Bachorik wrote: >>>>>> On 5.1.2016 15:30, Jaroslav Bachorik wrote: >>>>>>> On 4.1.2016 10:05, Jaroslav Bachorik wrote: >>>>>>>> Gentle reminder ... >>>>>>>> >>>>>>>> On 23.12.2015 11:26, Jaroslav Bachorik wrote: >>>>>>>>> Please, review the following test change >>>>>>>>> >>>>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 >>>>>>>>> >>>>>>>>> The test fails for IPv6 addresses since the RMI expects an IPv6 >>>>>>>>> address >>>>>>>>> to be properly wrapped in '[]'. In addition to that the logic for >>>>>>>>> selecting IP addresses to bind is flawed - it does not check >>>>>>>>> for IP >>>>>>>>> addresses of multiple adapters but for multiple IP addresses >>>>>>>>> assigned to >>>>>>>>> 'localhost'. In combination with IPv4 & IPv6 this will cause the >>>>>>>>> test to >>>>>>>>> attempt binding to IPv4 and IPv6 address of the same adapter >>>>>>>>> simultaneously and the test will fail. >>>>>>>>> >>>>>>>>> The fix adds the requested wrapping for IPv6 addresses and >>>>>>>>> adjusts >>>>>>>>> the >>>>>>>>> IP selection logic to iterate over distinct adapters first and >>>>>>>>> prevent >>>>>>>>> IPv4 and IPv6 address of the same adapter being treated as two >>>>>>>>> addresses >>>>>>>>> (for the purposes of the test). >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -JB- >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From martinrb at google.com Wed Jan 13 18:54:26 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 13 Jan 2016 10:54:26 -0800 Subject: RFR[9u-dev] 8130425: libjvm crash due to stack overflow in executables with 32k tbss/tdata In-Reply-To: <56962632.7080404@oracle.com> References: <56962632.7080404@oracle.com> Message-ID: You should include core-libs-dev (and perhaps hotspot-runtime-dev) in this thread. You're changing core library code. On Wed, Jan 13, 2016 at 2:25 AM, cheleswer sahu wrote: > Hi, > > Please review the code changes for > "https://bugs.openjdk.java.net/browse/JDK-8130425". > > Problem summary: When a large TLS (Thread Local Storage) size is set for > threads, JVM is throwing StackOverflow exception. > > Problem Identified: > As per investigation and a discussion we came to the conclusion that issue > is not with the JVM but it lies in the way glibc has been implemented. When > a TLS is declared , it steals the space from threads stack size. > So if a thread is created with small stack size, and TLS is set to a large > value, then it will result in StackOverflow. This is the exact case in this > bug where reaper thread is allocated a very low stack size 32768. > > Discussion thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037558.html > > Solution proposed: > Its expected to get fix in glibc sometime , but for now I propose a > workaround, a boolean system property "processReaperUseDefaultStackSize" > using which we can set the stack size for reaper thread to default > instead of fix 32768. This property can be set by the user using "-D" or > "System.setProperty()". I have tested this fix, it works well with TLS size > between 32k to 128k. > > Fix: > diff -r 5c4530bb9ae6 > src/java.base/share/classes/java/lang/ProcessHandleImpl.jav > --- a/src/java.base/share/classes/java/lang/ProcessHandleImpl.java Fri Jan > 08 13:06:29 2016 +0800 > +++ b/src/java.base/share/classes/java/lang/ProcessHandleImpl.java Tue Jan > 12 15:55:50 2016 +0530 > @@ -83,9 +83,13 @@ > ThreadGroup systemThreadGroup = tg; > > ThreadFactory threadFactory = grimReaper -> { > - // Our thread stack requirement is quite modest. > - Thread t = new Thread(systemThreadGroup, grimReaper, > - "process reaper", 32768); > + Thread t = null; > + if > (Boolean.getBoolean("processReaperUseDefaultStackSize")) { > + t = new Thread(systemThreadGroup, grimReaper, > "process reaper"); > + } else { > + // Our thread stack requirement is quite modest. > + t = new Thread(systemThreadGroup, grimReaper, > "process reaper", 32768); > + } > t.setDaemon(true); > // A small attempt (probably futile) to avoid priority > inversion > t.setPriority(Thread.MAX_PRIORITY); > > > Regards, > Cheleswer From harsha.wardhana.b at oracle.com Thu Jan 14 04:04:21 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Thu, 14 Jan 2016 09:34:21 +0530 Subject: JDK-8031753 : Review request In-Reply-To: <56937411.5080208@oracle.com> References: <568F84E3.2040602@oracle.com> <56937411.5080208@oracle.com> Message-ID: <56971E45.5010305@oracle.com> Gentle reminder :) On Monday 11 January 2016 02:51 PM, Jaroslav Bachorik wrote: > [adding JMX dev list] > > On 8.1.2016 10:44, Harsha Wardhana B wrote: >> Hi All, >> >> Please review the fix for, >> >> Issue : JDK-8031753 - JMXServiceURL should not use >> getLocalHost or its usage should be enhanced >> Webrev : >> http://cr.openjdk.java.net/~jbachorik/sponsorship/8031753/webrev.00/ >> >> The issue can be reproduced by removing entry for hostname in /etc/hosts >> (for linux) and running >> 'javax/management/remote/mandatory/connection/RMIConnectionIdTest' test. >> Hence no new jtreg test case have been written. >> >> Fix Description: >> >> If JMXServiceURL is given null host, it tries to resolve hostname via >> InetAddress.getLocalHost() and if that fails throws >> MalformedURLException. Since JMX Agent will listen on all interfaces >> (0.0.0.0) if host is null, the fix handles the exception and assigns >> first active non-loopback interface IP address to host. That way we can >> have JMXServiceURL with IP address instead of hostname. >> >> It is possible that we might end up constructing JMXServiceURL with IP >> for an interface which clients may not be able to connect (because of >> network reachability issues). In that case, the recommendation would be >> to try to start JMX Agent with >> com.sun.management.jmxremote.host=xx.xx.xx.xx option. That way, the >> agent will be started on interface that clients can actually connect to. >> >> Please review the fix and let me know your comments. The fix requires >> amending javadoc with above behavioral change and a CCC review as well >> which I will send out later. >> >> Thanks >> Harsha >> > From david.holmes at oracle.com Thu Jan 14 04:06:54 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Jan 2016 14:06:54 +1000 Subject: RFR(M): JDK-8141070 vm/services/management.cpp should be resilient to missing 'jdk.management' module In-Reply-To: <56969B5B.5080006@oracle.com> References: <56969B5B.5080006@oracle.com> Message-ID: <56971EDE.9080508@oracle.com> Hi Dmitry, On 14/01/2016 4:45 AM, Dmitry Samersoff wrote: > Everybody, > > Please, review the fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8141070/webrev.01/ > > The problem: > > Code in management.cpp throw NoClassDefFound exception if any of > requested classes is missing. > > But, in upcoming modular JDK classes that not belong to > java.lang.management (sun.management, com.sun.management etc) might not > be present. Is this because the management API's are actually split across the base module (java.lang.management) and the jdk.management module? If so that seem messy. If not then I'm not understanding the issue. I would have hoped that the management initialization function in the VM could simply check for the management module being present and set a flag that can be checked by all the management entry points. Something that might even be better done at the Java level. ?? Cheers, David > Solution: > > Refactor class resolving code to support two type of classes - REQUIRED > (still throw NCDFE if the class is missing) and OPTIONAL (just return > NULL). > > I introduced a new parameter to highlight the fact that a class is an > optional one on caller side rather than handle it silently inside > management.cpp. > > -Dmitry > From cheleswer.sahu at oracle.com Thu Jan 14 06:53:13 2016 From: cheleswer.sahu at oracle.com (cheleswer sahu) Date: Thu, 14 Jan 2016 12:23:13 +0530 Subject: RFR[9u-dev] 8130425: libjvm crash due to stack overflow in executables with 32k tbss/tdata In-Reply-To: References: <56962632.7080404@oracle.com> Message-ID: <569745D9.1090007@oracle.com> Adding core-libs-dev and hotspot-runtime-dev team . On 1/14/2016 12:24 AM, Martin Buchholz wrote: > You should include core-libs-dev (and perhaps hotspot-runtime-dev) in > this thread. You're changing core library code. > > On Wed, Jan 13, 2016 at 2:25 AM, cheleswer sahu > wrote: >> Hi, >> >> Please review the code changes for >> "https://bugs.openjdk.java.net/browse/JDK-8130425". >> >> Problem summary: When a large TLS (Thread Local Storage) size is set for >> threads, JVM is throwing StackOverflow exception. >> >> Problem Identified: >> As per investigation and a discussion we came to the conclusion that issue >> is not with the JVM but it lies in the way glibc has been implemented. When >> a TLS is declared , it steals the space from threads stack size. >> So if a thread is created with small stack size, and TLS is set to a large >> value, then it will result in StackOverflow. This is the exact case in this >> bug where reaper thread is allocated a very low stack size 32768. >> >> Discussion thread: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037558.html >> >> Solution proposed: >> Its expected to get fix in glibc sometime , but for now I propose a >> workaround, a boolean system property "processReaperUseDefaultStackSize" >> using which we can set the stack size for reaper thread to default >> instead of fix 32768. This property can be set by the user using "-D" or >> "System.setProperty()". I have tested this fix, it works well with TLS size >> between 32k to 128k. >> >> Fix: >> diff -r 5c4530bb9ae6 >> src/java.base/share/classes/java/lang/ProcessHandleImpl.jav >> --- a/src/java.base/share/classes/java/lang/ProcessHandleImpl.java Fri Jan >> 08 13:06:29 2016 +0800 >> +++ b/src/java.base/share/classes/java/lang/ProcessHandleImpl.java Tue Jan >> 12 15:55:50 2016 +0530 >> @@ -83,9 +83,13 @@ >> ThreadGroup systemThreadGroup = tg; >> >> ThreadFactory threadFactory = grimReaper -> { >> - // Our thread stack requirement is quite modest. >> - Thread t = new Thread(systemThreadGroup, grimReaper, >> - "process reaper", 32768); >> + Thread t = null; >> + if >> (Boolean.getBoolean("processReaperUseDefaultStackSize")) { >> + t = new Thread(systemThreadGroup, grimReaper, >> "process reaper"); >> + } else { >> + // Our thread stack requirement is quite modest. >> + t = new Thread(systemThreadGroup, grimReaper, >> "process reaper", 32768); >> + } >> t.setDaemon(true); >> // A small attempt (probably futile) to avoid priority >> inversion >> t.setPriority(Thread.MAX_PRIORITY); >> >> >> Regards, >> Cheleswer From alexander.kulyakhtin at oracle.com Thu Jan 14 09:20:53 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Thu, 14 Jan 2016 01:20:53 -0800 (PST) Subject: RFR: JDK-8130063: Refactoring tmtools jstat and jstack tests to jtreg Message-ID: Hi Jaroslav, Thank you very much for the review. Best regards, Alexander ----- Original Message ----- From: jaroslav.bachorik at oracle.com To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net Cc: stefan.sarne at oracle.com, staffan.larsen at oracle.com Sent: Wednesday, January 13, 2016 7:30:08 PM GMT +03:00 Iraq Subject: Re: RFR: JDK-8130063: Refactoring tmtools jstat and jstack tests to jtreg Hi Alexander, On 12.1.2016 15:22, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review the following test-only change > > CR: https://bugs.openjdk.java.net/browse/JDK-8130063 "Refactoring tmtools jstat and jstack tests to jtreg" > WebRev: http://cr.openjdk.java.net/~akulyakh/8130063_01/ The changes look good. Thanks for taking care of the rewrite. -JB- > > Before the change we had a set of tests verifying the correctness of jstat and jstack tools output in various scenarios. > > Those tests have been implemented by means of an internal framework, which sometimes worked unstable, resulting in false nightly failures. > The functionality, which the tests verify, fully belongs to the open JDK. > > We are refactoring a subset of the tests to use jtreg as the test framework. In this way we are able to avoid some of the false failures of the old framework. > We are also moving the tests to the Open JDK as they verify the open functionality only. > > For the similar refactoring of the remaining java tools tests, a separate JEP is going to be submitted. > > The changes have been pre-reviewed internally, the reviewers are CC'ed. > > Best regards, > Alexander > > > From dmitry.samersoff at oracle.com Thu Jan 14 09:47:00 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 14 Jan 2016 12:47:00 +0300 Subject: RFR(S): JDK-8145698 Memory leak in add_lib_info_fd of libproc_impl.c:174 Message-ID: <56976E94.30403@oracle.com> Everybody, Please review the fix: http://cr.openjdk.java.net/~dsamersoff/JDK-8145698/webrev.01/ added missed free() call. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Thu Jan 14 09:51:05 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 14 Jan 2016 12:51:05 +0300 Subject: RFR(M): JDK-8141070 vm/services/management.cpp should be resilient to missing 'jdk.management' module In-Reply-To: <56971EDE.9080508@oracle.com> References: <56969B5B.5080006@oracle.com> <56971EDE.9080508@oracle.com> Message-ID: <56976F89.5070409@oracle.com> David, > Is this because the management API's are actually split across > the base module (java.lang.management) and the jdk.management module? > If so that seem messy. If not then I'm not understanding the issue. Yes. Exactly. Moreover future management functionality may require additional modules. -Dmitry On 2016-01-14 07:06, David Holmes wrote: > Hi Dmitry, > > On 14/01/2016 4:45 AM, Dmitry Samersoff wrote: >> Everybody, >> >> Please, review the fix: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8141070/webrev.01/ >> >> The problem: >> >> Code in management.cpp throw NoClassDefFound exception if any of >> requested classes is missing. >> >> But, in upcoming modular JDK classes that not belong to >> java.lang.management (sun.management, com.sun.management etc) might not >> be present. > > Is this because the management API's are actually split across the base > module (java.lang.management) and the jdk.management module? If so that > seem messy. If not then I'm not understanding the issue. > > I would have hoped that the management initialization function in the VM > could simply check for the management module being present and set a > flag that can be checked by all the management entry points. Something > that might even be better done at the Java level. ?? > > Cheers, > David > >> Solution: >> >> Refactor class resolving code to support two type of classes - REQUIRED >> (still throw NCDFE if the class is missing) and OPTIONAL (just return >> NULL). >> >> I introduced a new parameter to highlight the fact that a class is an >> optional one on caller side rather than handle it silently inside >> management.cpp. >> >> -Dmitry >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jaroslav.bachorik at oracle.com Thu Jan 14 10:14:07 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 14 Jan 2016 11:14:07 +0100 Subject: RFR(S): JDK-8145698 Memory leak in add_lib_info_fd of libproc_impl.c:174 In-Reply-To: <56976E94.30403@oracle.com> References: <56976E94.30403@oracle.com> Message-ID: <569774EF.20008@oracle.com> On 14.1.2016 10:47, Dmitry Samersoff wrote: > Everybody, > > Please review the fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8145698/webrev.01/ > > added missed free() call. Looks good! Thanks, -JB- > > -Dmitry > From serguei.spitsyn at oracle.com Thu Jan 14 10:31:23 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 14 Jan 2016 02:31:23 -0800 Subject: RFR(S): JDK-8145698 Memory leak in add_lib_info_fd of libproc_impl.c:174 In-Reply-To: <56976E94.30403@oracle.com> References: <56976E94.30403@oracle.com> Message-ID: <569778FB.3040802@oracle.com> The fix looks good. However, it seems, there check at the lines 172 or 218 could be done before the call to the calloc(). In such a case, there would be no need to free the new_lib. It can be like this: if (strlen(libname) >= BUF_SIZE - 1) { print_debug("libname %s too long\n", libname); return NULL; } Thanks, Serguei On 1/14/16 01:47, Dmitry Samersoff wrote: > Everybody, > > Please review the fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8145698/webrev.01/ > > added missed free() call. > > -Dmitry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Jan 14 10:35:57 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Jan 2016 20:35:57 +1000 Subject: RFR(M): JDK-8141070 vm/services/management.cpp should be resilient to missing 'jdk.management' module In-Reply-To: <56976F89.5070409@oracle.com> References: <56969B5B.5080006@oracle.com> <56971EDE.9080508@oracle.com> <56976F89.5070409@oracle.com> Message-ID: <56977A0D.7080400@oracle.com> On 14/01/2016 7:51 PM, Dmitry Samersoff wrote: > David, > >> Is this because the management API's are actually split across >> the base module (java.lang.management) and the jdk.management module? >> If so that seem messy. If not then I'm not understanding the issue. > > Yes. Exactly. > > Moreover future management functionality may require additional modules. If the management module is not present what would call the code in the VM? Shouldn't the base management code be detecting and responding to the absence of the actual module? It is very hard to see the overall architecture/structure here. David > -Dmitry > > > On 2016-01-14 07:06, David Holmes wrote: >> Hi Dmitry, >> >> On 14/01/2016 4:45 AM, Dmitry Samersoff wrote: >>> Everybody, >>> >>> Please, review the fix: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8141070/webrev.01/ >>> >>> The problem: >>> >>> Code in management.cpp throw NoClassDefFound exception if any of >>> requested classes is missing. >>> >>> But, in upcoming modular JDK classes that not belong to >>> java.lang.management (sun.management, com.sun.management etc) might not >>> be present. >> >> Is this because the management API's are actually split across the base >> module (java.lang.management) and the jdk.management module? If so that >> seem messy. If not then I'm not understanding the issue. >> >> I would have hoped that the management initialization function in the VM >> could simply check for the management module being present and set a >> flag that can be checked by all the management entry points. Something >> that might even be better done at the Java level. ?? >> >> Cheers, >> David >> >>> Solution: >>> >>> Refactor class resolving code to support two type of classes - REQUIRED >>> (still throw NCDFE if the class is missing) and OPTIONAL (just return >>> NULL). >>> >>> I introduced a new parameter to highlight the fact that a class is an >>> optional one on caller side rather than handle it silently inside >>> management.cpp. >>> >>> -Dmitry >>> > > From Alan.Bateman at oracle.com Thu Jan 14 10:46:52 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Jan 2016 10:46:52 +0000 Subject: RFR(M): JDK-8141070 vm/services/management.cpp should be resilient to missing 'jdk.management' module In-Reply-To: <56971EDE.9080508@oracle.com> References: <56969B5B.5080006@oracle.com> <56971EDE.9080508@oracle.com> Message-ID: <56977C9C.9050107@oracle.com> On 14/01/2016 04:06, David Holmes wrote: > > Is this because the management API's are actually split across the > base module (java.lang.management) and the jdk.management module? If > so that seem messy. If not then I'm not understanding the issue. The two management modules are: java.management - exports the standard/Java APIs: java.lang.management and javax.management.**. This module also has the JMX agent. jdk.management - this exports the JDK-specific API com.sun.management. It's possible to create a run-time image that has neither, both, or has java.management but not jdk.management. We just need to make sure that VM handles all cases gracefully. -Alan From daniel.fuchs at oracle.com Thu Jan 14 11:48:41 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 14 Jan 2016 12:48:41 +0100 Subject: RFR(M): JDK-8141070 vm/services/management.cpp should be resilient to missing 'jdk.management' module In-Reply-To: <56969B5B.5080006@oracle.com> References: <56969B5B.5080006@oracle.com> Message-ID: <56978B19.5060804@oracle.com> Hi Dmitry, First an observation: - java.lang.management and sun.management packages are part of the java.management module. - com.sun.management and com.sun.management.internal are part of jdk.management What strategy did you use to decide whether to use OPTIONAL | REQUIRED? I'm not sure I understand the logic... For instance: 80 Klass* k = Management::com_sun_management_internal_GarbageCollectorExtImpl_klass(Management::OPTIONAL, CHECK_NH); => class from jdk.management: OPTIONAL looks like the right choice. 103 Klass* mu_klass = Management::java_lang_management_MemoryUsage_klass(Management::OPTIONAL, CHECK_NH); => class from java.management: should it be REQUIRED? Or is it optional for some other reason (e.g. the feature/method depends on jdk.management being present)? Or is it optional to make room for the case when java.management is not there? Is there some other underlying logic here? best regards, -- daniel On 13/01/16 19:45, Dmitry Samersoff wrote: > Everybody, > > Please, review the fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8141070/webrev.01/ > > The problem: > > Code in management.cpp throw NoClassDefFound exception if any of > requested classes is missing. > > But, in upcoming modular JDK classes that not belong to > java.lang.management (sun.management, com.sun.management etc) might not > be present. > > Solution: > > Refactor class resolving code to support two type of classes - REQUIRED > (still throw NCDFE if the class is missing) and OPTIONAL (just return > NULL). > > I introduced a new parameter to highlight the fact that a class is an > optional one on caller side rather than handle it silently inside > management.cpp. > > -Dmitry > From david.holmes at oracle.com Thu Jan 14 12:06:52 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Jan 2016 22:06:52 +1000 Subject: RFR(M): JDK-8141070 vm/services/management.cpp should be resilient to missing 'jdk.management' module In-Reply-To: <56977C9C.9050107@oracle.com> References: <56969B5B.5080006@oracle.com> <56971EDE.9080508@oracle.com> <56977C9C.9050107@oracle.com> Message-ID: <56978F5C.1020200@oracle.com> On 14/01/2016 8:46 PM, Alan Bateman wrote: > > > On 14/01/2016 04:06, David Holmes wrote: >> >> Is this because the management API's are actually split across the >> base module (java.lang.management) and the jdk.management module? If >> so that seem messy. If not then I'm not understanding the issue. > The two management modules are: > > java.management - exports the standard/Java APIs: java.lang.management > and javax.management.**. This module also has the JMX agent. > > jdk.management - this exports the JDK-specific API com.sun.management. > > It's possible to create a run-time image that has neither, both, or has > java.management but not jdk.management. > > We just need to make sure that VM handles all cases gracefully. Of course, but I'm having trouble seeing the overall architecture of the solution or understanding how the problem manifests. Is it just VM initialization that assumes classes are always present? Thanks, David > -Alan From dmitry.samersoff at oracle.com Thu Jan 14 12:31:31 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 14 Jan 2016 15:31:31 +0300 Subject: RFR(M): JDK-8141070 vm/services/management.cpp should be resilient to missing 'jdk.management' module In-Reply-To: <56978B19.5060804@oracle.com> References: <56969B5B.5080006@oracle.com> <56978B19.5060804@oracle.com> Message-ID: <56979523.7030800@oracle.com> Daniel, > What strategy did you use to decide whether > to use OPTIONAL | REQUIRED? > I'm not sure I understand the logic... Everything in java.lang.management should be REQUIRED, anything outside of it - OPTIONAL. java_lang_management_MemoryUsage_klass should be required, it's just a typeo. -Dmitry On 2016-01-14 14:48, Daniel Fuchs wrote: > Hi Dmitry, > > First an observation: > > - java.lang.management and sun.management packages are part of > the java.management module. > > - com.sun.management and com.sun.management.internal are part > of jdk.management > > What strategy did you use to decide whether to use OPTIONAL | REQUIRED? > I'm not sure I understand the logic... Everything in java.lang.management should be required, anything outside of it - optional. > > For instance: > > 80 Klass* k = > Management::com_sun_management_internal_GarbageCollectorExtImpl_klass(Management::OPTIONAL, > CHECK_NH); > > => class from jdk.management: OPTIONAL looks like the right choice. > > 103 Klass* mu_klass = > Management::java_lang_management_MemoryUsage_klass(Management::OPTIONAL, > CHECK_NH); > > => class from java.management: should it be REQUIRED? > Or is it optional for some other reason (e.g. the feature/method > depends on jdk.management being present)? > Or is it optional to make room for the case when java.management is > not there? > > Is there some other underlying logic here? > > best regards, > > -- daniel > > On 13/01/16 19:45, Dmitry Samersoff wrote: >> Everybody, >> >> Please, review the fix: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8141070/webrev.01/ >> >> The problem: >> >> Code in management.cpp throw NoClassDefFound exception if any of >> requested classes is missing. >> >> But, in upcoming modular JDK classes that not belong to >> java.lang.management (sun.management, com.sun.management etc) might not >> be present. >> >> Solution: >> >> Refactor class resolving code to support two type of classes - REQUIRED >> (still throw NCDFE if the class is missing) and OPTIONAL (just return >> NULL). >> >> I introduced a new parameter to highlight the fact that a class is an >> optional one on caller side rather than handle it silently inside >> management.cpp. >> >> -Dmitry >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.fuchs at oracle.com Thu Jan 14 13:00:33 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 14 Jan 2016 14:00:33 +0100 Subject: RFR(M): JDK-8141070 vm/services/management.cpp should be resilient to missing 'jdk.management' module In-Reply-To: <56979523.7030800@oracle.com> References: <56969B5B.5080006@oracle.com> <56978B19.5060804@oracle.com> <56979523.7030800@oracle.com> Message-ID: <56979BF1.90807@oracle.com> Hi Dmitry, On 14/01/16 13:31, Dmitry Samersoff wrote: > Daniel, > >> What strategy did you use to decide whether >> to use OPTIONAL | REQUIRED? >> I'm not sure I understand the logic... > > Everything in java.lang.management should be REQUIRED, anything outside > of it - OPTIONAL. > > java_lang_management_MemoryUsage_klass should be required, it's just a > typeo. OK. What of the sun.* implementation classes in java.management? Should these be REQUIRED as well? best regards, -- daniel > > -Dmitry > > On 2016-01-14 14:48, Daniel Fuchs wrote: >> Hi Dmitry, >> >> First an observation: >> >> - java.lang.management and sun.management packages are part of >> the java.management module. >> >> - com.sun.management and com.sun.management.internal are part >> of jdk.management >> >> What strategy did you use to decide whether to use OPTIONAL | REQUIRED? >> I'm not sure I understand the logic... > > Everything in java.lang.management should be required, anything outside > of it - optional. > >> >> For instance: >> >> 80 Klass* k = >> Management::com_sun_management_internal_GarbageCollectorExtImpl_klass(Management::OPTIONAL, >> CHECK_NH); >> >> => class from jdk.management: OPTIONAL looks like the right choice. >> >> 103 Klass* mu_klass = >> Management::java_lang_management_MemoryUsage_klass(Management::OPTIONAL, >> CHECK_NH); >> >> => class from java.management: should it be REQUIRED? >> Or is it optional for some other reason (e.g. the feature/method >> depends on jdk.management being present)? >> Or is it optional to make room for the case when java.management is >> not there? >> >> Is there some other underlying logic here? >> >> best regards, >> >> -- daniel >> >> On 13/01/16 19:45, Dmitry Samersoff wrote: >>> Everybody, >>> >>> Please, review the fix: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8141070/webrev.01/ >>> >>> The problem: >>> >>> Code in management.cpp throw NoClassDefFound exception if any of >>> requested classes is missing. >>> >>> But, in upcoming modular JDK classes that not belong to >>> java.lang.management (sun.management, com.sun.management etc) might not >>> be present. >>> >>> Solution: >>> >>> Refactor class resolving code to support two type of classes - REQUIRED >>> (still throw NCDFE if the class is missing) and OPTIONAL (just return >>> NULL). >>> >>> I introduced a new parameter to highlight the fact that a class is an >>> optional one on caller side rather than handle it silently inside >>> management.cpp. >>> >>> -Dmitry >>> >> > > From Alan.Bateman at oracle.com Thu Jan 14 13:05:58 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Jan 2016 13:05:58 +0000 Subject: RFR(M): JDK-8141070 vm/services/management.cpp should be resilient to missing 'jdk.management' module In-Reply-To: <56978F5C.1020200@oracle.com> References: <56969B5B.5080006@oracle.com> <56971EDE.9080508@oracle.com> <56977C9C.9050107@oracle.com> <56978F5C.1020200@oracle.com> Message-ID: <56979D36.8050503@oracle.com> On 14/01/2016 12:06, David Holmes wrote: > > Of course, but I'm having trouble seeing the overall architecture of > the solution or understanding how the problem manifests. Is it just VM > initialization that assumes classes are always present? I haven't looked at what Dmitry is doing but I think part of it is startup, say starting with com.sun.management properties on the command line. In that scenario the VM must have management support (can't be minimal VM) and the java.management module must be present. At second part might be using the jcmd tool to run diagnostic options that require the VM to have the jdk.management module. In both cases then it would be good to handle them gracefully. One thing to be aware of is that in the jigsaw/jake forest then we have changed this code so that attempting to start with com.sun.management properties set on the command line will add "java.management" to the initial set of modules to resolve. This means that startup already fails gracefully when this module is not observable, here's an example: $ jlink --modulepath jmods --addmods java.base --output myimage $ myimage/bin/java -listmods java.base at 9-internal $ myimage/bin/java -Dcom.sun.management.jmxremote.port=5000 -jar foo.jar Error occurred during initialization of VM java.lang.module.ResolutionException: Module java.management not found at java.lang.module.Resolver.fail(java.base at 9-internal/Resolver.java:860) at java.lang.module.Resolver.resolve(java.base at 9-internal/Resolver.java:291) at java.lang.module.Configuration.resolve(java.base at 9-internal/Configuration.java:249) at jdk.internal.module.ModuleBootstrap.boot(java.base at 9-internal/ModuleBootstrap.java:188) at java.lang.System.initPhase2(java.base at 9-internal/System.java:1911) -Alan From yasuenag at gmail.com Thu Jan 14 14:00:16 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 14 Jan 2016 23:00:16 +0900 Subject: RFR: JDK-8147388: Add diagnostic commands to attach JVMTI agent. Message-ID: <5697A9F0.6010104@gmail.com> Hi all, We can use Attach API to attach JVMTI agent to live process. However, we have to write Java code for it. If we can attach JVMTI agents through jcmd, it is very useful. So I want to add two new diagnostic commands: * JVMTI.agent_load: Load JVMTI native agent. * JVMTI.javaagent_load: Load JVMTI java agent. I maintain two JVMTI agents - HeapStats [1] and JLivePatcher [2]. [1] is native agent, [2] is java agent. They provide a program for attaching to live process. I guess that various JVMTI agents provide own attach mechanism like them. I think that we should provide general way to attach. I've uploaded webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8147388/webrev.00/ I'm jdk9 committer, however I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa [1] http://icedtea.classpath.org/wiki/HeapStats [2] https://github.com/YaSuenag/jlivepatcher (in Japanese) From dmitry.samersoff at oracle.com Thu Jan 14 14:49:56 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 14 Jan 2016 17:49:56 +0300 Subject: RFR(M): JDK-8141070 vm/services/management.cpp should be resilient to missing 'jdk.management' module In-Reply-To: <56979BF1.90807@oracle.com> References: <56969B5B.5080006@oracle.com> <56978B19.5060804@oracle.com> <56979523.7030800@oracle.com> <56979BF1.90807@oracle.com> Message-ID: <5697B594.8040104@oracle.com> Daniel, > OK. What of the sun.* implementation classes in java.management? > Should these be REQUIRED as well? java.management module might be missing. It's the main goal to the fix - provide a way to handle missing java.management module on VM level. i.e. if java.lang.management is missing, VM fails with NCDFE. if java.management is missing, implementation of particular function can do something to handle it. -Dmitry On 2016-01-14 16:00, Daniel Fuchs wrote: > Hi Dmitry, > > On 14/01/16 13:31, Dmitry Samersoff wrote: >> Daniel, >> >>> What strategy did you use to decide whether >>> to use OPTIONAL | REQUIRED? >>> I'm not sure I understand the logic... >> >> Everything in java.lang.management should be REQUIRED, anything outside >> of it - OPTIONAL. >> >> java_lang_management_MemoryUsage_klass should be required, it's just a >> typeo. > > OK. What of the sun.* implementation classes in java.management? > Should these be REQUIRED as well? > > best regards, > > -- daniel > > >> >> -Dmitry >> >> On 2016-01-14 14:48, Daniel Fuchs wrote: >>> Hi Dmitry, >>> >>> First an observation: >>> >>> - java.lang.management and sun.management packages are part of >>> the java.management module. >>> >>> - com.sun.management and com.sun.management.internal are part >>> of jdk.management >>> >>> What strategy did you use to decide whether to use OPTIONAL | REQUIRED? >>> I'm not sure I understand the logic... >> >> Everything in java.lang.management should be required, anything outside >> of it - optional. >> >>> >>> For instance: >>> >>> 80 Klass* k = >>> Management::com_sun_management_internal_GarbageCollectorExtImpl_klass(Management::OPTIONAL, >>> >>> CHECK_NH); >>> >>> => class from jdk.management: OPTIONAL looks like the right choice. >>> >>> 103 Klass* mu_klass = >>> Management::java_lang_management_MemoryUsage_klass(Management::OPTIONAL, >>> CHECK_NH); >>> >>> => class from java.management: should it be REQUIRED? >>> Or is it optional for some other reason (e.g. the feature/method >>> depends on jdk.management being present)? >>> Or is it optional to make room for the case when >>> java.management is >>> not there? >>> >>> Is there some other underlying logic here? >>> >>> best regards, >>> >>> -- daniel >>> >>> On 13/01/16 19:45, Dmitry Samersoff wrote: >>>> Everybody, >>>> >>>> Please, review the fix: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8141070/webrev.01/ >>>> >>>> The problem: >>>> >>>> Code in management.cpp throw NoClassDefFound exception if any of >>>> requested classes is missing. >>>> >>>> But, in upcoming modular JDK classes that not belong to >>>> java.lang.management (sun.management, com.sun.management etc) might not >>>> be present. >>>> >>>> Solution: >>>> >>>> Refactor class resolving code to support two type of classes - >>>> REQUIRED >>>> (still throw NCDFE if the class is missing) and OPTIONAL (just return >>>> NULL). >>>> >>>> I introduced a new parameter to highlight the fact that a class >>>> is an >>>> optional one on caller side rather than handle it silently inside >>>> management.cpp. >>>> >>>> -Dmitry >>>> >>> >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From marcus.larsson at oracle.com Thu Jan 14 15:00:02 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 14 Jan 2016 16:00:02 +0100 Subject: RFR: 8146879: Truncate new UL log files Message-ID: <5697B7F2.50104@oracle.com> Hi, Please review the following patch to make sure UL truncates existing log files before writing to them. Since files are opened in append mode, truncation isn't done automatically, so instead the patch adds an attempt to remove the log file before opening it. Webrev: http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8146879 Testing: Included test through JPRT Thanks, Marcus From dmitry.samersoff at oracle.com Thu Jan 14 15:06:57 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 14 Jan 2016 18:06:57 +0300 Subject: RFR: JDK-8147388: Add diagnostic commands to attach JVMTI agent. In-Reply-To: <5697A9F0.6010104@gmail.com> References: <5697A9F0.6010104@gmail.com> Message-ID: <5697B991.6030907@oracle.com> Yasumasa, diagnosticCommand.cpp:294 1. It's better to check _libpath.value() and write a message, that the parameter is required. 2. It might be better to avoid malloc here by pre-calcualting length of required option length and than declare char *new_options[new_options_len]; Otherwise looks good for me (I'll sponsor the push). -Dmitry On 2016-01-14 17:00, Yasumasa Suenaga wrote: > Hi all, > > We can use Attach API to attach JVMTI agent to live process. > However, we have to write Java code for it. > > If we can attach JVMTI agents through jcmd, it is very useful. > So I want to add two new diagnostic commands: > > * JVMTI.agent_load: Load JVMTI native agent. > * JVMTI.javaagent_load: Load JVMTI java agent. > > I maintain two JVMTI agents - HeapStats [1] and JLivePatcher [2]. > [1] is native agent, [2] is java agent. > They provide a program for attaching to live process. > > I guess that various JVMTI agents provide own attach mechanism like them. > I think that we should provide general way to attach. > > I've uploaded webrev. Could you review it? > http://cr.openjdk.java.net/~ysuenaga/JDK-8147388/webrev.00/ > > I'm jdk9 committer, however I cannot access JPRT. > So I need a sponsor. > > > Thanks, > > Yasumasa > > > [1] http://icedtea.classpath.org/wiki/HeapStats > [2] https://github.com/YaSuenag/jlivepatcher (in Japanese) > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From marcus.larsson at oracle.com Thu Jan 14 15:09:59 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 14 Jan 2016 16:09:59 +0100 Subject: RFR (XS): 8147079: Add serviceability/logging folder to hotspot_serviceability test group Message-ID: <5697BA47.1080000@oracle.com> Hi, Please review the following patch to add the serviceability/logging folder to the hotspot_serviceability test group. This will include the UL tests for JPRT runs. Webrev: http://cr.openjdk.java.net/~mlarsson/8147079/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8147079 Testing: JPRT Thanks, Marcus From jaroslav.bachorik at oracle.com Thu Jan 14 15:18:23 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 14 Jan 2016 16:18:23 +0100 Subject: RFR (XS): 8147079: Add serviceability/logging folder to hotspot_serviceability test group In-Reply-To: <5697BA47.1080000@oracle.com> References: <5697BA47.1080000@oracle.com> Message-ID: <5697BC3F.4090207@oracle.com> Ship it! -JB- On 14.1.2016 16:09, Marcus Larsson wrote: > Hi, > > Please review the following patch to add the serviceability/logging > folder to the hotspot_serviceability test group. This will include the > UL tests for JPRT runs. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8147079/webrev.00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8147079 > > Testing: > JPRT > > Thanks, > Marcus From dmitry.samersoff at oracle.com Thu Jan 14 15:28:50 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 14 Jan 2016 18:28:50 +0300 Subject: RFR: 8146879: Truncate new UL log files In-Reply-To: <5697B7F2.50104@oracle.com> References: <5697B7F2.50104@oracle.com> Message-ID: <5697BEB2.3040206@oracle.com> Marcus, fopen(name, "wa+") truncate file before open it in append mode. -Dmitry On 2016-01-14 18:00, Marcus Larsson wrote: > Hi, > > Please review the following patch to make sure UL truncates existing log > files before writing to them. Since files are opened in append mode, > truncation isn't done automatically, so instead the patch adds an > attempt to remove the log file before opening it. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8146879 > > Testing: > Included test through JPRT > > Thanks, > Marcus -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From sgehwolf at redhat.com Thu Jan 14 16:23:07 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 14 Jan 2016 17:23:07 +0100 Subject: jmx-dev [ding] Re: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <56969C9B.1080104@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> <568E94FD.6000206@oracle.com> <5694D9C4.1030901@oracle.com> <5694E834.9020502@oracle.com> <5694E9CD.9040409@oracle.com> <56963205.5000505@oracle.com> <56969C9B.1080104@oracle.com> Message-ID: <1452788587.3685.29.camel@redhat.com> Hi, On Wed, 2016-01-13 at 10:51 -0800, serguei.spitsyn at oracle.com wrote: > On 1/13/16 03:16, Jaroslav Bachorik wrote: > > On 12.1.2016 12:55, serguei.spitsyn at oracle.com wrote: > > > On 1/12/16 03:49, Jaroslav Bachorik wrote: > > > > On 12.1.2016 11:47, serguei.spitsyn at oracle.com wrote: > > > > > On 1/7/16 08:40, Daniel Fuchs wrote: > > > > > > Hi, > > > > > > > > > > > > This looks OK to me. > > > > > > I'm not sure I understand the full impact of the changes > > > > > > in getAddressesForLocalHost() though - so hopefully someone > > > > > > else will jump in to review that part... > > > > > > > > > > Hi Jaroslav, > > > > > > > > > > I do not understand the full impact of the getAddressesForLocalHost() > > > > > change either > > > > > so that, please, do not count me as a reviewer. > > > > > > > > Looks like > > > > > > > > > > > > > > However, I have a question on the fragment: > > > > > > > > > > + private static boolean isLocalhost(InetAddress i) { > > > > > + if (!i.isLoopbackAddress()) { > > > > > + return i.getHostName().toLowerCase().equals("localhost"); > > > > > + } > > > > > + return false; > > > > > ??????} > > > > > > > > > > > > > > > Should true be returned instead of false if the i.isLoopbackAddress() > > > > > returns true? > > > > > Do we normally treat the loopbackAddress case as a localhost variant? > > > > > > > > Ok, maybe the method name is missing a bit - the idea is to get all > > > > 'true' localhosts - a localhost defined on a real non-loopback adapter > > > > (as it doesn't make sense to bind JMX remote connector to a loopback > > > > address). > > > > > > Got it. > > > Thank you for the explanation. > > > > > > > > > > > > > > I just couldn't come up with more describing name not being > > > > excessively long :( I'm open to any suggestions. > > > > > > The name looks Ok to me. > > > I'd suggest to add a short comment with your explanation above. > > > > Thanks. I've added the explanation and also disambiguated the method? > > name a bit. > > > > http://cr.openjdk.java.net/~jbachorik/8146015/webrev.01 > > > > It looks like no one else is going to jump in and verify the? > > getAddressesForLocalHost() change (basically, excluding the loopback? > > localhost addresses as they are not suitable for binding the remote? > > JMX connector to) :/ Maybe Severing could comment, as the orignal author? Sorry for being late in the game with this.? +????private static List getAddressesForLocalHost() { + ?????????try { -????????????addrs = InetAddress.getAllByName("localhost"); -????????} catch (UnknownHostException e) { +????????????return NetworkInterface.networkInterfaces() +????????????????.flatMap(NetworkInterface::inetAddresses) +????????????????.filter(JMXInterfaceBindingTest::isNonloopbackLocalhost) +????????????????.collect(Collectors.toList()); I wonder if this does what you claim it does. It looks like it's getting all the addresses per adapter (IPv4 or IPv6) and then filters addresses out which have "localhost" as name and aren't loopback. It's not really what you said it does: """" The fix adds the requested wrapping for IPv6 addresses and adjusts the? IP selection logic to iterate over distinct adapters first and prevent? IPv4 and IPv6 address of the same adapter being treated as two addresses """" How is it preventing IPv4 and IPv6 addresses *both* being used for one adapter? Could it be that this fix works because loopback was the only one with IPv4 and IPv6 address config on the test server? Say one has the following /etc/hosts config: 192.168.1.14 ? ? ? ? ? ? ?localhost fe80::56ee:75ff:fe35:d1d4 localhost with the following adapter info (from ifconfig): enp0s25: flags=4163??mtu 1500 ????????inet 192.168.1.14??netmask 255.255.255.0??broadcast 192.168.1.255 ????????inet6 fe80::56ee:75ff:fe35:d1d4 I.e. for adapter enp0s25 I specify the IP addresses 192.168.1.14 and fe80::56ee:75ff:fe35:d1d4 to be "localhost". I'd expect the test to still fail after this patch. +????// we need 'real' localhost addresses only (eg. not loopback ones) +????// so we can bind the remote JMX connector to them +????private static boolean isNonloopbackLocalhost(InetAddress i) { +????????if (!i.isLoopbackAddress()) { +????????????return i.getHostName().toLowerCase().equals("localhost"); +????????} +????????return false; TBH, I don't understand why this comment is there. Particularly, the loopback exclusion. Yet, this may be platform specific. It worked for me under linux. It was fine with binding to IPv4 loopback (127.0.0.1) and some interface address (e.g. 192.168.1.x). Looking at the bug it seems the main issue was a conflict of binding to IPv4 loopback + IPv6 loopback. So the gist would be to not use both IPv4 *and* IPv6 addresses of the same adapter for the binding. How about using something like this for a filter: private static boolean isIpV4Address(InetAddress i) { ? ?return i instanceof Inet4Address; } Thoughts? Anyway, looks like it's too late now :-/ Cheers, Severin > > I would like to integrate this change ASAP since the test is failing? > > 100% in nightly runs. > > Ok. I looked??to the getAddressesForLocalHost() part and think this fix? > is fine. > Thumbs up from me. > > Thanks, > Serguei > > > > > -JB- > > > > > > > > > > > Thanks, > > > Serguei > > > > > > > > > > > > > > -JB- > > > > > > > > > > > > > > Thanks, > > > > > Serguei > > > > > > > > > > > > > > > > > > > > > > best regards, > > > > > > > > > > > > -- daniel > > > > > > > > > > > > On 07/01/16 16:02, Jaroslav Bachorik wrote: > > > > > > > On 5.1.2016 15:30, Jaroslav Bachorik wrote: > > > > > > > > On 4.1.2016 10:05, Jaroslav Bachorik wrote: > > > > > > > > > Gentle reminder ... > > > > > > > > > > > > > > > > > > On 23.12.2015 11:26, Jaroslav Bachorik wrote: > > > > > > > > > > Please, review the following test change > > > > > > > > > > > > > > > > > > > > Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 > > > > > > > > > > Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 > > > > > > > > > > > > > > > > > > > > The test fails for IPv6 addresses since the RMI expects an IPv6 > > > > > > > > > > address > > > > > > > > > > to be properly wrapped in '[]'. In addition to that the logic for > > > > > > > > > > selecting IP addresses to bind is flawed - it does not check? > > > > > > > > > > for IP > > > > > > > > > > addresses of multiple adapters but for multiple IP addresses > > > > > > > > > > assigned to > > > > > > > > > > 'localhost'. In combination with IPv4 & IPv6 this will cause the > > > > > > > > > > test to > > > > > > > > > > attempt binding to IPv4 and IPv6 address of the same adapter > > > > > > > > > > simultaneously and the test will fail. > > > > > > > > > > > > > > > > > > > > The fix adds the requested wrapping for IPv6 addresses and? > > > > > > > > > > adjusts > > > > > > > > > > the > > > > > > > > > > IP selection logic to iterate over distinct adapters first and > > > > > > > > > > prevent > > > > > > > > > > IPv4 and IPv6 address of the same adapter being treated as two > > > > > > > > > > addresses > > > > > > > > > > (for the purposes of the test). > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > -JB- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From mandy.chung at oracle.com Thu Jan 14 17:15:32 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 14 Jan 2016 09:15:32 -0800 Subject: RFR(M): JDK-8141070 vm/services/management.cpp should be resilient to missing 'jdk.management' module In-Reply-To: <56976F89.5070409@oracle.com> References: <56969B5B.5080006@oracle.com> <56971EDE.9080508@oracle.com> <56976F89.5070409@oracle.com> Message-ID: > On Jan 14, 2016, at 1:51 AM, Dmitry Samersoff wrote: > > David, > >> Is this because the management API's are actually split across >> the base module (java.lang.management) and the jdk.management module? >> If so that seem messy. If not then I'm not understanding the issue. > > Yes. Exactly. Can you give a test case to show what issue you run into? If jdk.management module is not present, I expect the com.sun.management API can?t be invoked at all and hence it should never call to the VM for com.sun.management functionality. Mandy From kubota.yuji at gmail.com Thu Jan 14 17:45:43 2016 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Fri, 15 Jan 2016 02:45:43 +0900 Subject: [PING]Re: Unexpected ArithmeticException at sun.jvm.hotspot.utilities.CompactHashTable Message-ID: Hi all, Could you please review this patch? Thanks, Yuji 2015-12-18 15:27 GMT+09:00 KUBOTA Yuji : > Hi all, > > I caught an unexpected java.lang.ArithmeticException by CLHSDB through > jhsdb as below. > > ----- > ./jhsdb clhsdb --pid 16809 > Attaching to process 16809, please wait... > hsdb> class java/lang/ArithmeticException > java/lang/ArithmeticException @0x0000000100011958 > hsdb> class java > class not found: java > hsdb> class java/lang > Error: java.lang.ArithmeticException: / by zero > ----- > > I think that CLHSDB returns "class not found: java/lang". But > ArithmetricException is returned instead. > CLHSDB tries to search the given class name from the regular symbol > table and the shared symbol table. > And called the probe function of the shared symbol table does not > support a case of the empty bucket such as below expression > >> long index = hash % bucketCount(); > > then, throws ArithmetricException. > > The stack trace of this java.lang.ArithmeticException is here. > ------ > java.lang.ArithmeticException: / by zero > at sun.jvm.hotspot.utilities.CompactHashTable.probe(CompactHashTable.java:89) > at sun.jvm.hotspot.memory.SymbolTable.probe(SymbolTable.java:97) > at sun.jvm.hotspot.memory.SymbolTable.probe(SymbolTable.java:75) > at sun.jvm.hotspot.memory.SystemDictionary.find(SystemDictionary.java:149) > at sun.jvm.hotspot.utilities.SystemDictionaryHelper.findInstanceKlass(SystemDictionaryHelper.java:107) > at jdk.nashorn.internal.scripts.Script$Recompilation$2402$7541A$sa.main$jclass(sa.js:247) > at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:625) > at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:511) > at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393) > at jdk.nashorn.api.scripting.ScriptObjectMirror.callMember(ScriptObjectMirror.java:199) > at jdk.nashorn.api.scripting.NashornScriptEngine.invokeImpl(NashornScriptEngine.java:383) > at jdk.nashorn.api.scripting.NashornScriptEngine.invokeFunction(NashornScriptEngine.java:190) > at sun.jvm.hotspot.utilities.soql.JSJavaScriptEngine.call(JSJavaScriptEngine.java:78) > at sun.jvm.hotspot.CommandProcessor$52.doit(CommandProcessor.java:1755) > at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1951) > at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1921) > at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1801) > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) > at sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:134) > at sun.jvm.hotspot.SALauncher.main(SALauncher.java:334) > ------ > > I have created a patch from jdk9/dev/hotspot (changeset: > 9625:de592ea5f7ba) as below, and checked to return "class not found > java/lang" correctly. Please review it. > > diff --git a/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java > b/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java > --- a/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java > +++ b/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java > @@ -86,6 +86,10 @@ > Address baseAddress = baseAddressField.getValue(addr); > Address bucket = bucketsField.getValue(addr); > Address bucketEnd = bucket; > + > + if (bucketCount() == 0) { > + return null; > + } > long index = hash % bucketCount(); > int bucketInfo = (int)bucket.getCIntegerAt(index * uintSize, > uintSize, true); > int bucketOffset = bucketOffset(bucketInfo); > > > Thanks, > Yuji From martinrb at google.com Thu Jan 14 18:59:26 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 14 Jan 2016 10:59:26 -0800 Subject: RFR[9u-dev] 8130425: libjvm crash due to stack overflow in executables with 32k tbss/tdata In-Reply-To: <569745D9.1090007@oracle.com> References: <56962632.7080404@oracle.com> <569745D9.1090007@oracle.com> Message-ID: The process grim reaper ends up being the first point of failure since it tries not to waste the user's memory and it's in a core library, but in principle it's not special. I think a more general workaround would be to add a hotspot flag that would add a memory safety zone to all threads. If it's known that TLS is stealing 32k from every thread's stack, then the flag should ensure that every thread stack is 32k larger. More generally, I was hoping that hotspot would ensure that the -Xss size was available for actual java stack frames and OS overhead was added on automatically, but that is hard to implement, so the best alternative workaround is for users to be able to specify that additional stack size padding. Maybe -XX:StackSizeOverhead=32768 ? From serguei.spitsyn at oracle.com Thu Jan 14 19:07:51 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 14 Jan 2016 11:07:51 -0800 Subject: RFR (XS): 8147079: Add serviceability/logging folder to hotspot_serviceability test group In-Reply-To: <5697BC3F.4090207@oracle.com> References: <5697BA47.1080000@oracle.com> <5697BC3F.4090207@oracle.com> Message-ID: <5697F207.3020906@oracle.com> +1 Ship it! Thanks, Serguei On 1/14/16 07:18, Jaroslav Bachorik wrote: > Ship it! > > -JB- > > On 14.1.2016 16:09, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to add the serviceability/logging >> folder to the hotspot_serviceability test group. This will include the >> UL tests for JPRT runs. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8147079/webrev.00/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8147079 >> >> Testing: >> JPRT >> >> Thanks, >> Marcus > From ecki at zusammenkunft.net Thu Jan 14 20:36:58 2016 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Thu, 14 Jan 2016 21:36:58 +0100 Subject: RFR: 8146879: Truncate new UL log files In-Reply-To: <5697BEB2.3040206@oracle.com> References: <5697B7F2.50104@oracle.com> <5697BEB2.3040206@oracle.com> Message-ID: Hello, Especially for the GC log it is bad if the file is lost after a restart. It is of course possible to include PID or timestamp into the logfile, and then the truncation is no option, however if you do that you have to do your own purging. If you just want a number of generations with a fixed filename the truncation is not very good, Generally speaking why would you want to tru cate anyway? (You always have the option to delete the files if you want to feel the start,) but in all automated scenarios I cant see a good reason for truncating existing logs. So it should be at least an option to truncate. (And if you do that, I dont think using append mode is needed). Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Dmitry Samersoff To: Marcus Larsson , serviceability-dev at openjdk.java.net, hotspot-runtime-dev at openjdk.java.net Sent: Do., 14 Jan. 2016 16:39 Subject: Re: RFR: 8146879: Truncate new UL log files Marcus, fopen(name, "wa+") truncate file before open it in append mode. -Dmitry On 2016-01-14 18:00, Marcus Larsson wrote: > Hi, > > Please review the following patch to make sure UL truncates existing log > files before writing to them. Since files are opened in append mode, > truncation isn't done automatically, so instead the patch adds an > attempt to remove the log file before opening it. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8146879 > > Testing: > Included test through JPRT > > Thanks, > Marcus -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From kim.barrett at oracle.com Thu Jan 14 22:43:09 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 14 Jan 2016 17:43:09 -0500 Subject: RFR: 8146879: Truncate new UL log files In-Reply-To: <5697B7F2.50104@oracle.com> References: <5697B7F2.50104@oracle.com> Message-ID: On Jan 14, 2016, at 10:00 AM, Marcus Larsson wrote: > > Hi, > > Please review the following patch to make sure UL truncates existing log files before writing to them. Since files are opened in append mode, truncation isn't done automatically, so instead the patch adds an attempt to remove the log file before opening it. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8146879 > > Testing: > Included test through JPRT > > Thanks, > Marcus Deleting possibly critical data seems like a good way to generate a mob of angry users. From yasuenag at gmail.com Thu Jan 14 23:54:44 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 15 Jan 2016 08:54:44 +0900 Subject: RFR: JDK-8147388: Add diagnostic commands to attach JVMTI agent. In-Reply-To: <5697B991.6030907@oracle.com> References: <5697A9F0.6010104@gmail.com> <5697B991.6030907@oracle.com> Message-ID: <56983544.7040407@gmail.com> Hi Dmitry, > Otherwise looks good for me (I'll sponsor the push). Thanks! > 1. It's better to check _libpath.value() and write a message, that the > parameter is required. I set true to 4th argument (mandatory) of DCmdArgument c'tor. If we execute jcmd without libpath, we get message as below: ----------- $ jcmd 939 JVMTI.javaagent_load 939: java.lang.IllegalArgumentException: The argument 'library path' is mandatory. ----------- > 2. It might be better to avoid malloc here by pre-calcualting length of > required option length and than declare > > char *new_options[new_options_len]; Sorry, I could not understand details. We have to be different way for option string of libinstrument. If option value is not NULL, we have to build string like =