From kubota.yuji at gmail.com Mon May 4 16:19:54 2015 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Tue, 5 May 2015 01:19:54 +0900 Subject: Potential infinite waiting at JMXConnection#createConnection In-Reply-To: References: Message-ID: Hi all, I want to contribute this issue. If there are a problem about this patch or a better way for openjdk community, please advise me. Thanks for 2015-04-22 0:31 GMT+09:00 KUBOTA Yuji : > Hi all, > > I found an infinite waiting at TCPChannel#createConnection. > This method flushes the DataOutputStream without the socket timeout settings > when choose stream protocol [1]. > > If connection lost (the destination server do no return response) > during the flush, > this method has possibilities to take long time beyond the expectations > at java.net.SocketInputStream.socketRead0 as following stack trace. > > stack trace : > at java.net.SocketInputStream.socketRead0(SocketInputStream.java) > at java.net.SocketInputStream.read(SocketInputStream.java) > at java.net.SocketInputStream.read(SocketInputStream.java) > at sun.security.ssl.InputRecord.readFully(InputRecord.java) > at sun.security.ssl.InputRecord.read(InputRecord.java) > at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java) > at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java) > at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java) > at sun.security.ssl.AppOutputStream.write(AppOutputStream.java) > at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java) > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java) > at java.io.DataOutputStream.flush(DataOutputStream.java) > at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java) > at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java) > at sun.rmi.server.UnicastRef.invoke(UnicastRef.java) > at javax.management.remote.rmi.RMIServerImpl_Stub.newClient > at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java) > at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java) > at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java) > > When create connection, we cannot set the timeout by properties. > Therefore, JMX sets the default value of SO_TIMEOUT, i.e., infinite. > So I wrote a patch to fix this infinite waiting by using property-configured value: > sun.rmi.transport.tcp.responseTimeout. > > Please review this patch. :) > > Note: My OCA has been processed a few hour ago, so my name may take a > short time to > appear on the OCA signatories page. > > Thanks, > KUBOTA Yuji > > [1]: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPConnection.java#l191 > > 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 > @@ -222,20 +222,34 @@ > // choose protocol (single op if not reusable socket) > if (!conn.isReusable()) { > out.writeByte(TransportConstants.SingleOpProtocol); > } else { > out.writeByte(TransportConstants.StreamProtocol); > + > + int usableSoTimeout = 0; > + try { > + /* > + * If socket factory had set a zero timeout on its own, > + * then set the property-configured value to prevent > + * an infinite waiting. > + */ > + 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(); > > /* > * Set socket read timeout to configured value for JRMP > * 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 > } > > @@ -279,18 +293,11 @@ > * connection. NOTE: this timeout, if configured to a > * finite duration, places an upper bound on the time > * 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 > } > > out.flush(); From benjamin.john.evans at gmail.com Mon May 4 17:22:04 2015 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Mon, 4 May 2015 18:22:04 +0100 Subject: Potential infinite waiting at JMXConnection#createConnection In-Reply-To: References: Message-ID: Hi Kubota, I think that perhaps the AdoptOpenJDK project (https://java.net/projects/adoptopenjdk) can help here. I've copied in their mailing list, in case one of the developers there can help you. Thanks, Ben On Mon, May 4, 2015 at 5:19 PM, KUBOTA Yuji wrote: > Hi all, > > I want to contribute this issue. > If there are a problem about this patch or a better way for openjdk > community, please advise me. > > Thanks for > > 2015-04-22 0:31 GMT+09:00 KUBOTA Yuji : >> Hi all, >> >> I found an infinite waiting at TCPChannel#createConnection. >> This method flushes the DataOutputStream without the socket timeout settings >> when choose stream protocol [1]. >> >> If connection lost (the destination server do no return response) >> during the flush, >> this method has possibilities to take long time beyond the expectations >> at java.net.SocketInputStream.socketRead0 as following stack trace. >> >> stack trace : >> at java.net.SocketInputStream.socketRead0(SocketInputStream.java) >> at java.net.SocketInputStream.read(SocketInputStream.java) >> at java.net.SocketInputStream.read(SocketInputStream.java) >> at sun.security.ssl.InputRecord.readFully(InputRecord.java) >> at sun.security.ssl.InputRecord.read(InputRecord.java) >> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java) >> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java) >> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java) >> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java) >> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java) >> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java) >> at java.io.DataOutputStream.flush(DataOutputStream.java) >> at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java) >> at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java) >> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java) >> at javax.management.remote.rmi.RMIServerImpl_Stub.newClient >> at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java) >> at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java) >> at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java) >> >> When create connection, we cannot set the timeout by properties. >> Therefore, JMX sets the default value of SO_TIMEOUT, i.e., infinite. >> So I wrote a patch to fix this infinite waiting by using property-configured value: >> sun.rmi.transport.tcp.responseTimeout. >> >> Please review this patch. :) >> >> Note: My OCA has been processed a few hour ago, so my name may take a >> short time to >> appear on the OCA signatories page. >> >> Thanks, >> KUBOTA Yuji >> >> [1]: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPConnection.java#l191 >> >> 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 >> @@ -222,20 +222,34 @@ >> // choose protocol (single op if not reusable socket) >> if (!conn.isReusable()) { >> out.writeByte(TransportConstants.SingleOpProtocol); >> } else { >> out.writeByte(TransportConstants.StreamProtocol); >> + >> + int usableSoTimeout = 0; >> + try { >> + /* >> + * If socket factory had set a zero timeout on its own, >> + * then set the property-configured value to prevent >> + * an infinite waiting. >> + */ >> + 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(); >> >> /* >> * Set socket read timeout to configured value for JRMP >> * 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 >> } >> >> @@ -279,18 +293,11 @@ >> * connection. NOTE: this timeout, if configured to a >> * finite duration, places an upper bound on the time >> * 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 >> } >> >> out.flush(); From kubota.yuji at gmail.com Mon May 4 18:55:25 2015 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Tue, 5 May 2015 03:55:25 +0900 Subject: Potential infinite waiting at JMXConnection#createConnection In-Reply-To: References: Message-ID: Hi all, My apologies for the re-post and wrong link, the link [1] of the initial post is not correctly. The correct link is below. [1]: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java#l227 The users cant specify the timeout by sun.rmi.transport.tcp.responseTimeout, e.g. the second flush() of TCPChannel#createConnection [2]. However, the first flush() [1] is not affected by sun.rmi.transport.tcp.responseTimeout, and will be the (potential) infinite waiting by bad luck. [2]: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java#l296 Thanks, Yuji 2015-05-05 1:19 GMT+09:00 KUBOTA Yuji : > Hi all, > > I want to contribute this issue. > If there are a problem about this patch or a better way for openjdk > community, please advise me. > > Thanks for > > 2015-04-22 0:31 GMT+09:00 KUBOTA Yuji : >> Hi all, >> >> I found an infinite waiting at TCPChannel#createConnection. >> This method flushes the DataOutputStream without the socket timeout settings >> when choose stream protocol [1]. >> >> If connection lost (the destination server do no return response) >> during the flush, >> this method has possibilities to take long time beyond the expectations >> at java.net.SocketInputStream.socketRead0 as following stack trace. >> >> stack trace : >> at java.net.SocketInputStream.socketRead0(SocketInputStream.java) >> at java.net.SocketInputStream.read(SocketInputStream.java) >> at java.net.SocketInputStream.read(SocketInputStream.java) >> at sun.security.ssl.InputRecord.readFully(InputRecord.java) >> at sun.security.ssl.InputRecord.read(InputRecord.java) >> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java) >> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java) >> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java) >> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java) >> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java) >> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java) >> at java.io.DataOutputStream.flush(DataOutputStream.java) >> at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java) >> at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java) >> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java) >> at javax.management.remote.rmi.RMIServerImpl_Stub.newClient >> at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java) >> at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java) >> at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java) >> >> When create connection, we cannot set the timeout by properties. >> Therefore, JMX sets the default value of SO_TIMEOUT, i.e., infinite. >> So I wrote a patch to fix this infinite waiting by using property-configured value: >> sun.rmi.transport.tcp.responseTimeout. >> >> Please review this patch. :) >> >> Note: My OCA has been processed a few hour ago, so my name may take a >> short time to >> appear on the OCA signatories page. >> >> Thanks, >> KUBOTA Yuji >> >> [1]: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPConnection.java#l191 >> >> 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 >> @@ -222,20 +222,34 @@ >> // choose protocol (single op if not reusable socket) >> if (!conn.isReusable()) { >> out.writeByte(TransportConstants.SingleOpProtocol); >> } else { >> out.writeByte(TransportConstants.StreamProtocol); >> + >> + int usableSoTimeout = 0; >> + try { >> + /* >> + * If socket factory had set a zero timeout on its own, >> + * then set the property-configured value to prevent >> + * an infinite waiting. >> + */ >> + 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(); >> >> /* >> * Set socket read timeout to configured value for JRMP >> * 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 >> } >> >> @@ -279,18 +293,11 @@ >> * connection. NOTE: this timeout, if configured to a >> * finite duration, places an upper bound on the time >> * 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 >> } >> >> out.flush(); From martijnverburg at gmail.com Tue May 5 11:57:41 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 5 May 2015 12:57:41 +0100 Subject: Potential infinite waiting at JMXConnection#createConnection In-Reply-To: References: Message-ID: Hi Yuji, A good place to start would be to provide some unit tests and/or client code showcasing the behaviour you are describing. Cheers, Martijn On 4 May 2015 at 19:55, KUBOTA Yuji wrote: > Hi all, > > My apologies for the re-post and wrong link, the link [1] of the > initial post is not correctly. > The correct link is below. > > [1]: > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java#l227 > > The users cant specify the timeout by > sun.rmi.transport.tcp.responseTimeout, e.g. the second flush() of > TCPChannel#createConnection [2]. > However, the first flush() [1] is not affected by > sun.rmi.transport.tcp.responseTimeout, and will be the (potential) > infinite waiting by bad luck. > > [2]: > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java#l296 > > Thanks, > Yuji > > 2015-05-05 1:19 GMT+09:00 KUBOTA Yuji : > > Hi all, > > > > I want to contribute this issue. > > If there are a problem about this patch or a better way for openjdk > > community, please advise me. > > > > Thanks for > > > > 2015-04-22 0:31 GMT+09:00 KUBOTA Yuji : > >> Hi all, > >> > >> I found an infinite waiting at TCPChannel#createConnection. > >> This method flushes the DataOutputStream without the socket timeout > settings > >> when choose stream protocol [1]. > >> > >> If connection lost (the destination server do no return response) > >> during the flush, > >> this method has possibilities to take long time beyond the expectations > >> at java.net.SocketInputStream.socketRead0 as following stack trace. > >> > >> stack trace : > >> at > java.net.SocketInputStream.socketRead0(SocketInputStream.java) > >> at java.net.SocketInputStream.read(SocketInputStream.java) > >> at java.net.SocketInputStream.read(SocketInputStream.java) > >> at sun.security.ssl.InputRecord.readFully(InputRecord.java) > >> at sun.security.ssl.InputRecord.read(InputRecord.java) > >> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java) > >> at > sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java) > >> at > sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java) > >> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java) > >> at > java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java) > >> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java) > >> at java.io.DataOutputStream.flush(DataOutputStream.java) > >> at > sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java) > >> at > sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java) > >> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java) > >> at javax.management.remote.rmi.RMIServerImpl_Stub.newClient > >> at > javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java) > >> at > javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java) > >> at > javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java) > >> > >> When create connection, we cannot set the timeout by properties. > >> Therefore, JMX sets the default value of SO_TIMEOUT, i.e., infinite. > >> So I wrote a patch to fix this infinite waiting by using > property-configured value: > >> sun.rmi.transport.tcp.responseTimeout. > >> > >> Please review this patch. :) > >> > >> Note: My OCA has been processed a few hour ago, so my name may take a > >> short time to > >> appear on the OCA signatories page. > >> > >> Thanks, > >> KUBOTA Yuji > >> > >> [1]: > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPConnection.java#l191 > >> > >> 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 > >> @@ -222,20 +222,34 @@ > >> // choose protocol (single op if not reusable socket) > >> if (!conn.isReusable()) { > >> out.writeByte(TransportConstants.SingleOpProtocol); > >> } else { > >> out.writeByte(TransportConstants.StreamProtocol); > >> + > >> + int usableSoTimeout = 0; > >> + try { > >> + /* > >> + * If socket factory had set a zero timeout on > its own, > >> + * then set the property-configured value to > prevent > >> + * an infinite waiting. > >> + */ > >> + 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(); > >> > >> /* > >> * Set socket read timeout to configured value for > JRMP > >> * 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 > >> } > >> > >> @@ -279,18 +293,11 @@ > >> * connection. NOTE: this timeout, if configured > to a > >> * finite duration, places an upper bound on the > time > >> * 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 > >> } > >> > >> out.flush(); > From alejandro.murillo at oracle.com Tue May 5 15:30:52 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 05 May 2015 09:30:52 -0600 Subject: jdk9-dev: HotSpot Message-ID: <5548E22C.108@oracle.com> jdk9-hs-2015-04-30 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/9e629631b747 http://hg.openjdk.java.net/jdk9/dev/corba/rev/2bb058ce572e http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/a0df4738688e http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/4a8f895f0317 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/b5c22d09b1c9 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2a9879bb24a1 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/67ae665c791e http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/a9b03ce75736 Component : VM Status : Go for integration Date : 05/05/2015 at 17:00 MSK Tested By : VM SQE &leonid.mesnik at oracle.com Bundles : 2015-05-04-094201.staffan.jdk9-hs-main Testing: 613 new failures, 2499 known failures, 347678 passed. Issues and Notes: 8079345: After 8079248 fixed JDK still fails with "jdk\\bin\\management_ext.dll: The specified procedure could not be found" 8079345 is not considered as blocker. No detailed analysis was done for other failures. Go for integration CRs for testing: 6983747: Remove obsolete dl_mutex lock 7127066: Class verifier accepts an invalid class file 8005521: StressMethodComparator is not thread-safe 8016276: CMS concurrentMarkSweepGeneration contains lots of unnecessary allocation failure handling 8022853: add ability to load uncompressed object and Klass references in a compressed environment to Unsafe 8023093: Add ManagementAgent.status diagnostic command 8024055: serviceability/attach/AttachWithStalePidFile.java createJavaPidFile() fails 8026043: Add regression test for JDK-8000831 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods 8027668: sun/tools/jstatd/TestJstatdPort.java: java.net.ConnectException: Connection refused: connect 8029630: Thread id should be displayed as a hex number in error report 8033465: JSR292: InvokerBytecodeGenerator: convert a check for REF_invokeVirtual on an interface into an assert 8042891: Format issues embedded in macros for two g1 source files 8042901: Allow com.sun.management to be in a different module to java.lang.management 8043225: Make whitebox API functions more stable 8044416: serviceability/sa/jmap-hashcode/Test8028623.java fails with AssertionFailure: can not get class data for java/lang/UNIXProcess$Platform$$Lambda 8054890: Serviceability: New diagnostic commands 'VM.set_flag' and 'JVMTI.data_dump' 8057919: Class.getSimpleName() should work for non-JLS compliant class names 8057967: CallSite dependency tracking scales devastatingly poorly 8058354: SPECjvm2008-Derby -2.7% performance regression on Solaris-X64 starting with 9-b29 8062280: C2: inlining failure due to access checks being too strict 8064923: [TESTBUG] jps doesn't display anything on embedded platforms and it causes some tests to fail 8066679: jvmtiRedefineClasses.cpp assert cache ptrs must match 8067235: embedded/minvm/checknmt fails on compact1 and compact2 with minimal VM 8067648: JVM crashes reproducible with GCM cipher suites in GCTR doFinal 8067662: "java.lang.NullPointerException: Method name is null" from StackTraceElement. 8067991: [Findbugs] SA com.sun.java.swing.ui.CommonUI some methods need final protect 8068007: [Findbugs] SA com.sun.java.swing.action.ActionManager.manager should be package protect 8068352: Move virtualspace.* out of src/share/vm/runtime to memory directory 8068582: UseSerialGC not always set up properly 8068945: Use RBP register as proper frame pointer in JIT compiled code on x86 8069004: Kitchensink hanged with 16Gb heap and GC pause >30 min 8069191: moving predicate out of loops may cause array accesses to bypass null check 8069263: assert(fm == NULL || fm->method_holder() == _participants[n]) failed: sanity 8069367: Eagerly reclaimed humongous objects left on mark stack 8071546: hotspot/test/compiler/codecache/jmx/PoolsIndependenceTest.java has been fixed, but still is in the exclude list 8072128: mutexLocker.cpp _mutex_array[] initialization broken with safepoint check change 8072863: Replace fatal() with vm_exit_during_initialization() when an incorrect class is found on the bootclasspath 8072897: File sawindbg.dll has incorrect file version 8073165: Contended Locking fast exit bucket 8073480: C2 should optimize explicit range checks 8073705: more performance issues in class redefinition 8073866: Fix for 8064703 is not sufficient 8073989: Deprecated integer options are considered as invalid instead of deprecated in Java 9 8074026: Deprecated UseBoundThreads, DefaultThreadPriority and NoYieldsInMicrolock VM options still defined in globals.hpp 8074345: Enable RewriteBytecodes when VM runs with CDS 8074354: Make CreateMinidumpOnCrash a new name and available on all platforms 8074368: ThreadMXBean.getThreadInfo() corrupts memory when called with empty array for thread ids 8074545: Rename and clean up the ParGCAllocBuffer class 8074546: Rename and clean up the ParGCAllocBuffer class 8074548: Never-taken branches cause repeated deopts in MHs.GWT case 8074676: java.lang.invoke.PermuteArgsTest.java fails with "assert(is_Initialize()) failed: invalid node class" 8074718: Merge templateTable_x86 _32 and _64 .hpp files 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows 8074895: os::getenv is inadequate 8074981: Integer/FP scalar reduction optimization 8075118: JVM stuck in infinite loop during verification 8075136: Unnecessary sign extension for byte array access 8075140: Solaris build of native libraries not consistently using EXTRA_CFLAGS and EXTRA_LDFLAGS 8075214: SIGSEGV in nmethod sweeping 8075216: Remove old flags, regarding to JDK9, from obsolete_jvm_flags 8075263: MHI::checkCustomized isn't eliminated for inlined MethodHandles 8075266: Show runtime call details when printing machine code 8075269: Extend -XX:CompileCommand=print,* to work for MethodHandle.invokeBasic/linkTo* 8075270: Print locals & stack slots location for PcDescs 8075324: Costs of memory operands in aarch64.ad are inconsistent 8075331: jdb eval java.util.Arrays.asList(array) shows inconsistent behaviour 8075438: [TESTBUG] Hotspot JTREG tests should use unique CDS archive names 8075466: SATB queue pre-filter verify found reclaimed humongous object 8075488: compiler/whitebox/DeoptimizeFramesTest fails with exit code 1 due to unrecognized VM option -XX:+IgnoreUnexpectedVMOptions 8075505: aix: improve handling of native memory 8075533: Zero JVM segfaults for -version after JDK-8074552 8075587: Compilation of constant array containing different sub classes crashes the JVM 8075663: compiler/rangechecks/TestExplicitRangeChecks.java fails in compiler nightlies 8075725: Remove /jre subdir in hotspot dist dir 8075798: Allow ADLC register class to depend on runtime conditions also for cisc-spillable classes 8075818: serviceability/threads/TestFalseDeadLock.java should be unquarantined 8075820: java/lang/management/ThreadMXBean/FindDeadlocks.java should be unquarantined 8075858: AIX: clean-up HotSpot make files 8075921: assert assert(allocx == alloc) fails in library_call.cpp 8075922: assert(t == t_no_spec) fails in phaseX.cpp 8075955: Replace the macro based implementation of oop_oop_iterate with a template based solution 8075967: Zero interpreter asserts for SafeFetch<32,N> calls in ObjectMonitor 8076050: java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java fails intermittently 8076057: aix: After 8075506, aix does not support large pages. 8076094: CheckCastPPNode::Value() has outdated logic for constants 8076154: com/sun/jdi/InstanceFilter.java failing due to missing MethodEntryRequest calls 8076163: ppc: port "8074345: Enable RewriteBytecodes when VM runs with CDS" 8076181: bytecodeInterpreter.cpp refers to unknown labels. 8076185: Provide SafeFetchX implementation for zero 8076212: AllocateHeap() and ReallocateHeap() should be inlined. 8076236: VM permits illegal flags for class init method 8076265: Simplify deal_with_reference 8076267: Remove n_gens() 8076274: [TESTBUG] Remove @ignore from runtime\NMT\JcmdDetailDiff.java 8076289: Move the StrongRootsScope out of SharedHeap 8076311: Java 9 process negative MaxTenuringThreshold in different way than Java 8 8076314: Remove the static instance variable SharedHeap:: _sh 8076325: java hangs with -XX:ParallelGCThreads=0 -XX:+ExplicitGCInvokesConcurrent options 8076344: serviceability/dcmd/vm/SetVMFlagTest.java test fails with "java.lang.Error: 'MaxHeapSize' flag is not available or immutable" 8076421: Fix Zero Interpreter bugs in class redefinition and template interpreter changes 8076447: Remove unused MemoryManager::kind() 8076450: com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java: assert(!on_C_heap() || allocated_on_C_heap()) failed: growable array must be on C heap if elements are 8076452: Remove SharedHeap 8076454: Clean up/move things out of SharedHeap 8076456: Remove unnecessary oopDesc::klass() calls 8076457: Fix includes of inline.hpp in GC code 8076461: JSR292: remove unused native and constants 8076475: Misuses of strncpy/strncat 8076492: Make common code from template interpreter code 8076523: assert(((ABS(iv_adjustment_in_bytes) % elt_size) == 0)) fails in superword.cpp 8076532: Fix format warning/error in methodHandles_ppc.cpp 8076534: CollectedHeapName in SA agent incorrect 8076541: Parallel GC registers Java heap twice to NMT 8076614: Add comment to ClearNoncleanCardWrapper::do_MemRegion() 8076625: IndexOutOfBoundsException in HeapByteBufferTest.java 8076968: PICL based initialization of L2 cache line size on some SPARC systems is incorrect 8076971: sun/management/jmxremote/startstop/JMXStatusTest.java failed with AssertionError 8076987: C1 should support conditional card marks (UseCondCardMark) 8077054: DMH LFs should be customizeable 8077137: Port jdk.internal.instrumentation to jdk 9 8077255: TracePageSizes output reports wrong page size on Windows with G1 8077257: Use CanUseSafeFetch instead of probing SafeFetch stub directly 8077265: Modify assert to help debug JDK-8068448 8077301: Optimized build is broken 8077302: src/share/vm/oops/instanceRefKlass.inline.hpp has a doubble /* 8077308: Fix warning: increase O_BUFLEN in ostream.hpp -- output truncated 8077315: Build failure on OSX after compiler upgrade 8077327: ThreadStackTrace.java throws exception: BlockedThread expected to have BLOCKED but got RUNNABLE 8077364: "if( !this )" construct prevents build on Xcode 6.3 8077400: Unnecessary and incorrect "Code Cache Roots" G1 log entry 8077402: JMXStartStopTest fails intermittently on slow hosts 8077403: Remove guarantee from GenCollectedHeap::is_in() 8077411: Remove CollectedHeap::supports_heap_inspection() 8077413: Avoid use of Universe::heap() inside collectors 8077414: PSPromotionLAB _state is unintialized 8077415: Remove duplicate variables holding the CollectedHeap 8077417: Cleanup of Universe::initialize_heap() 8077420: Build failure with SS12u4 8077423: jstatd is not terminated even though it cannot contact or bind to RMI Registry 8077524: Enable selective test bundle installation for jprt test targets 8077608: [TESTBUG] Enable Hotspot jtreg tests to run in agentvm mode 8077611: com/sun/jdi/ConnectedVMs.java should be unquarantined 8077615: AARCH64: Add C2 intrinsic for BigInteger::multiplyToLen() method 8077618: Move rtmLocking.cpp to shared directory. 8077674: BSD build failures due to undefined macros 8077710: BACKOUT - java hangs with -XX:ParallelGCThreads=0 -XX:+ExplicitGCInvokesConcurrent options 8077832: SA's dumpreplaydata, dumpcfg and buildreplayjars are broken 8077836: Make sure G1ParGCAllocBuffer are marked as retired 8077838: Recent developments for ppc. 8077841: G1: Remove PrintReachable support 8077843: adlc: allow nodes that use TEMP inputs in expand rules. 8077873: G1: Remove G1SATBPrintStubs 8077936: Remove the unused java_lang_invoke_CallSite::target_volatile 8077938: Remove TraceMarkSweep 8078017: Introduce hotspot_basicvmtest 8078021: SATB apply_closure_to_completed_buffer should have closure argument 8078023: verify_no_cset_oops found reclaimed humongous object in SATB buffer 8078048: Fix non-pch build after "8076457: Fix includes of inline.hpp in GC code" 8078113: 8011102 changes may cause incorrect results 8078144: many nightly tests failed due to NoSuchMethodError: sun.management.ManagementFactoryHelper.getDiagnosticMXBean 8078156: G1: Remove dead code PrintObjsInRegionClosure 8078193: BACKOUT: Rename and clean up the ParGCAllocBuffer class 8078243: Fix include of stack.inline.hpp in taskqueue.hpp. 8078290: Customize adapted MethodHandle in MH.invoke() case 8078309: compiler/jsr292/MHInlineTest.java failed with java.lang.RuntimeException: 'MHInlineTest$A::protected_x (3 bytes) virtual call' found in stdout 8078349: remove dead code - fast_iagetfield 8078383: [TESTBUG] Merge hotspot_runtime and hotspot_runtime_closed in jprt test set 8078426: mb/jvm/compiler/InterfaceCalls/testAC2 - assert(predicate_proj == 0L) failed: only one predicate entry expected 8078435: [TESTBUG] runtime/CommandLine/TestVMOptions.java fails when running with an OpenJDK build 8078444: compiler/arraycopy/TestArrayCopyNoInitDeopt.java fails with exception 'm2 not deoptimized' 8078482: ppc: pass thread to throw_AbstractMethodError 8078504: Zero fails to build 8078519: Can't run SA tools from a non-images build 8078595: [TESTBUG] Fix runtime/StackGuardPages/testme.sh to deal with 64k pages 8078666: JVM fastdebug build compiled with GCC 5 asserts with "widen increases" 8079231: quarantine compiler/jsr292/CallSiteDepContextTest.java 8079235: quarantine TestLargePageUseForAuxMemory.java 8079248: JDK fails with "jdk\\bin\\management_ext.dll: The specified procedure could not be found" -- Alejandro From mark.reinhold at oracle.com Tue May 5 16:21:31 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 05 May 2015 09:21:31 -0700 Subject: Proposed schedule for JDK 9 Message-ID: <20150505092131.712129@eggemoggin.niobe.net> Here is a proposed schedule for JDK 9: 2015-12-10 Feature Complete 2016-02-04 All Tests Run 2016-02-25 Rampdown Start 2016-04-21 Zero Bug Bounce 2016-06-16 Rampdown Phase 2 2016-07-21 Final Release Candidate 2016-09-22 General Availability The dates here are meant to leave sufficient time for broad review and testing of the significant features of the release, in particular the introduction of a module system and the modularization of the platform, while maintaining the cadence of shipping a major release about every two years. The milestone definitions are the same as those for JDK 8 [1]. Comments from JDK 9 Committers are welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC next Tuesday, 12 May, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] this will be adopted as the schedule for JDK 9. (This information is also available on the JDK 9 Project Page [3]). - Mark [1] http://openjdk.java.net/projects/jdk8/milestones#definitions [2] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html [3] http://openjdk.java.net/projects/jdk9/ From volker.simonis at gmail.com Wed May 6 16:12:24 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 6 May 2015 18:12:24 +0200 Subject: RFR(XS): 8079510: AIX: fix build after '8042901: Allow com.sun.management to be in a different module...' Message-ID: Hi, can somebody please review this trivial AIX-only change which fixes an AIX build error: http://cr.openjdk.java.net/~simonis/webrevs/2015/8079510/ https://bugs.openjdk.java.net/browse/JDK-8079510 Here are the details: Change '8042901: Allow com.sun.management to be in a different module to java.lang.management' has refactored the management package and moved the files: jdk/src/java.management/unix/native/libmanagement/OperatingSystem.c to: jdk/src/jdk.management//native/libmanagement_ext/UnixOperatingSystem.c Unfortunately we've never had a AIXOperatingSystem.c file on AIX (see 8030957). This was no problem with the old setup but with the new one the build complains about a missing directory 'jdk/src/jdk.management/aix/native/libmanagement_ext'. This bug is just for fixing the build, by introducing an emty stub file. The actual implementation of the corresponding OperatingSystemMXBean is still up to 8030957. Thanks, Volker From andreas.kohn at gmail.com Wed May 6 15:29:05 2015 From: andreas.kohn at gmail.com (Andreas Kohn) Date: Wed, 06 May 2015 15:29:05 +0000 Subject: Eclipse no longer working with 1.9.0-ea-b61 Message-ID: Eclipse no longer starts with 1.9.0-ea-b61 or higher, complaining about missing org.w3c.dom.stylesheets.StyleSheetList. I'm guessing this is due to http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8042244 (Re-examine the supportedness of non-SE org.w3c.dom.** API), which points to a regression that should be fixed with http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8078139 Unfortunately doing a local build from 9dev with the commit for that bug included doesn't help, the message stays the same. Is this an eclipse issue, or a legitimate regression on the JDK side? -- Andreas PS: Attached the full eclipse log file for b60, b61 and my local version. The local version was built from: $ for f in . corba hotspot jaxp jaxws jdk langtools nashorn; do (cd $f; t=`hg tip`; echo "$f: $t"); done .: 1476:d909f7785f99 8078046: Remove MCS post-processing on Solaris (ihse) [default tag tip] corba: 672:6b017d166ac2 8079342: some docs cleanup for CORBA - part 2 (avstepan) [default tag tip] hotspot: 8299:c06fef227be6 8079359: disable JDK-8061553 optimization while JDK-8077392 is resolved (dcubed) [default tag tip] jaxp: 730:4a8f895f0317 Added tag jdk9-b62 for changeset 3bcf83c1bbc1 (katleman) [default tag tip] jaxws: 591:b5c22d09b1c9 Added tag jdk9-b62 for changeset cd0cf72b2cbf (katleman) [default tag tip] jdk: 11880:5d018ec41792 8077992: Eliminate JDK build dependency of native2ascii and update Japanese nroff man pages to UTF-8 encoding (ihse) [default tag tip] langtools: 2909:67ae665c791e Merge (amurillo) [default tag tip] nashorn: 1264:6af2ee7b09a9 8079470: Misleading error message when explicit signature constructor is called with wrong arguments (sundar) [default tag tip] From Alan.Bateman at oracle.com Wed May 6 18:18:11 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 May 2015 19:18:11 +0100 Subject: Eclipse no longer working with 1.9.0-ea-b61 In-Reply-To: References: Message-ID: <554A5AE3.1000200@oracle.com> On 06/05/2015 16:29, Andreas Kohn wrote: > Eclipse no longer starts with 1.9.0-ea-b61 or higher, complaining about > missing org.w3c.dom.stylesheets.StyleSheetList. > > I'm guessing this is due to > http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8042244 (Re-examine the > supportedness of non-SE org.w3c.dom.** API), which points to a regression > that should be fixed with > http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8078139 > Unfortunately doing a local build from 9dev with the commit for that bug > included doesn't help, the message stays the same. > > Is this an eclipse issue, or a legitimate regression on the JDK side? > In JDK 9 then several components that have historically had their types loaded by the boot loader have been moved to the extension loader. This includes CORBA, JAXB, JAX-WS, the JavaBeans Activation Framework and a few more. There are a number of motivations for this, one is that we allows these components to be configured with reduced permissions (compared to getting all permissions when defined by the boot loader). The W3C DOM API is a bit confusing because Java SE only endorsed a subset of the API. There are a number of additional API packages, org.w3c.dom.stylesheets being one of them, that are not part of Java SE. The JDK has always shipped this and the other packages but nothing can really depend on them being there. This is clearly confusing so I think Eclipse and others that might depend on these other API packages can be forgiven. The proposal in JDK 9 is to continue to ship these packages in a module named jdk.xml.dom. Furthermore, the proposal is move this to the extension loader as they are not core and have no reason to be loaded by the boot loader. This is what JDK-8042244 is about. As regards Eclipse then I assume it must be using one of its own class loaders that delegates to the boot loader rather than the system class loader. This is unfortunate as it means that many standard and JDK-specific type won't be visible (esp. as more non-core components are moved out of the boot loader). I would be curious if -Dorg.osgi.framework.bundle.parent=app fixes the issue. As you bring it up then I think it would be good to get a bug submitted to Eclipse on this, it would be unfortunate if only a subset of the standard and JDK types are visible via its class loaders. -Alan From lana.steuck at oracle.com Wed May 6 20:17:09 2015 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 6 May 2015 13:17:09 -0700 (PDT) Subject: jdk9-b63: dev Message-ID: <201505062017.t46KH9es005134@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/0b32ed628fa6 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/bc8e67bec2f9 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/a28b7f42dae9 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fd3281c40034 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/b5c22d09b1c9 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/4a8f895f0317 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2ac9b6b36689 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/0acac6937de7 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8079107 client-libs Update TestKeyPairGenerator.java to use random number generator librar JDK-8024086 core-libs (fs) AtomicMoveNotSupportedException allows reason to be null JDK-8075156 core-libs (prefs) get*() and remove() should disallow the use of the null contro JDK-8078369 core-libs [testbug] java/time/tck/java/time/TCKOffsetTime[now] fails on slow dev JDK-8078826 core-libs Add diagnostic info for java/lang/Runtime/exec/LotsOfOutput.java fails JDK-8075545 core-libs Add permission check for locale service provider implementations JDK-8053905 core-libs Eager code generation fails for earley boyer with split threshold set JDK-8066407 core-libs Function with same body not reparsed after SyntaxError JDK-8059455 core-libs LambdaForm.prepare() does unnecessary work for cached LambdaForms JDK-8078334 core-libs Mark regression tests using randomness JDK-8078490 core-libs Missed submissions in ForkJoinPool JDK-8078672 core-libs Print and allow setting by Java property seeds used to initialize Rand JDK-8076224 core-libs Some tidy warnings from core libs JDK-8078622 core-svc remove tidy warnings from JPDA docs JDK-8077994 hotspot [TESTBUG] Exclude compiler/floatingpoint/ModNaN.java JDK-8078621 hotspot AARCH64: Fails to build without precompiled headers JDK-8075930 hotspot aarch64: Make fp register available to register allocator JDK-8078437 infrastructure Enable use of devkits for Windows. JDK-8075007 security-libs Additional tests for krb5-related cipher suites with unbound server JDK-8078528 security-libs clean out tidy warnings from security.auth JDK-8078880 security-libs Mark a few more intermittently failing security-libs tests JDK-8078468 security-libs Update security libraries to use diamond with anonymous classes JDK-8078520 tools [TESTBUG] fix 'test/tools/launcher/ExecutionEnvironment.java' to run o JDK-8078054 tools [TESTBUG] tools/javac/Paths/wcMineField.sh failed with "operation not JDK-8044537 tools Implement classfile tests for Synthetic attribute. JDK-8044196 tools Incorrect applying of repeatable annotations with incompatible target JDK-8078600 tools Infinite loop when compiling annotations with -XDcompletionDeps JDK-8077605 tools Initializing static fields causes unbounded recursion in javac JDK-8079191 tools remove remaining references to "cp -p" from langtools/test JDK-8078861 tools tools/javac/classfiles/attributes/Synthetic/PackageInfoTest.java fails From peter.brunet at oracle.com Wed May 6 21:47:26 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 06 May 2015 16:47:26 -0500 Subject: Where is JavaAppletPlugin.plugin after building jdk 9? Message-ID: <554A8BEE.3070101@oracle.com> I need to debug code that runs JavaAppletPlugin.plugin. I can't find this in the Mac build products. I also find no dmg or pkg files. I used make images. Do I need a different make target? From erik.joelsson at oracle.com Thu May 7 08:08:59 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 07 May 2015 10:08:59 +0200 Subject: Where is JavaAppletPlugin.plugin after building jdk 9? In-Reply-To: <554A8BEE.3070101@oracle.com> References: <554A8BEE.3070101@oracle.com> Message-ID: <554B1D9B.5090503@oracle.com> JavaAppletPlugin.plugin is part of deploy so you need to make sure you are building the deploy repo by running the make target "deploy". Normally the deploy build will be enabled if configure finds all the dependencies necessary for it. If you want to be sure it's enabled, you can add --enable-deploy to configure. If the deploy build is disabled, "make deploy" will do nothing. /Erik On 2015-05-06 23:47, Pete Brunet wrote: > I need to debug code that runs JavaAppletPlugin.plugin. I can't find > this in the Mac build products. I also find no dmg or pkg files. I > used make images. Do I need a different make target? From Alan.Bateman at oracle.com Thu May 7 08:13:35 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 May 2015 09:13:35 +0100 Subject: Eclipse no longer working with 1.9.0-ea-b61 In-Reply-To: References: <554A5AE3.1000200@oracle.com> Message-ID: <554B1EAF.5070005@oracle.com> On 07/05/2015 08:57, Andreas Kohn wrote: > Hi, > > Thanks, that makes sense. > > I tried with your suggestion of adjusting the OSGi parent class > loader, and the results are "interesting": > b60: things work, i.e. I couldn't observe any ill effects. > b61: same error (makes sense, as the classes simply aren't there, if I > understand the 8078139 bug correctly) The classes are there, it's just that the defining loader will be the application class loader rather than the extension class loader as planned. > > With my local build however things change: Eclipse still doesn't > start, but now reports "java.lang.LinkageError: loader constraint > violation: loader (instance of sun/misc/Launcher$ExtClassLoader) > previously initiated loading for a different type with name > "org/w3c/dom/stylesheets/StyleSheet"". > > Will file an issue with eclipse, pointing here, thanks for your help > again! Loader constraint issues are a pain to diagnose. Can you run with -verbose as I'm curious where org.w3c.dom.stylesheets.StyleSheet is being loaded from. I will guess that Eclipse is shipping its own copy. -Alan From Alan.Bateman at oracle.com Thu May 7 09:22:59 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 May 2015 10:22:59 +0100 Subject: Eclipse no longer working with 1.9.0-ea-b61 In-Reply-To: References: <554A5AE3.1000200@oracle.com> <554B1EAF.5070005@oracle.com> Message-ID: <554B2EF3.80604@oracle.com> On 07/05/2015 09:33, Andreas Kohn wrote: > : > > Indeed, Eclipse seems to load them from a javax.xml bundle as well, > attached are the -verbose and -verbose + -Dsun.misc.URLClassPath.debug > logs. > > Quick grep: > [andreas at winterfell ~]$ grep org.w3c.dom.stylesheets > eclipse-9-internal-app-verbose-debug.out > URLClassPath.getResource("org/w3c/dom/stylesheets/DocumentStyle.class") > [Loaded org.w3c.dom.stylesheets.DocumentStyle from > file:/home/andreas/modules/eclipse-4.5M6/plugins/javax.xml_1.3.4.v201005080400.jar] > URLClassPath.getResource("org/w3c/dom/stylesheets/StyleSheetList.class") > URLClassPath.getResource("org/w3c/dom/stylesheets/StyleSheetList.class") > [Loaded org.w3c.dom.stylesheets.StyleSheetList from jrt:/jdk.xml.dom] > URLClassPath.getResource("org/w3c/dom/stylesheets/StyleSheet.class") > [Loaded org.w3c.dom.stylesheets.StyleSheet from > file:/home/andreas/modules/eclipse-4.5M6/plugins/javax.xml_1.3.4.v201005080400.jar] > URLClassPath.getResource("org/w3c/dom/stylesheets/MediaList.class") > URLClassPath.getResource("org/w3c/dom/stylesheets/MediaList.class") > [Loaded org.w3c.dom.stylesheets.MediaList from jrt:/jdk.xml.dom] > URLClassPath.getResource("org/w3c/dom/stylesheets/StyleSheet.class") > URLClassPath.getResource("org/w3c/dom/stylesheets/StyleSheet.class") > [Loaded org.w3c.dom.stylesheets.StyleSheet from jrt:/jdk.xml.dom] > > -- > Andreas > > PS: The eclipse bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=466690 I'm curious what else might be in this javax.xml bundle in case there are other potential issues too. Thanks for create the bug in Eclipse's bugzilla. -Alan From Alan.Bateman at oracle.com Thu May 7 12:06:09 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 May 2015 13:06:09 +0100 Subject: Eclipse no longer working with 1.9.0-ea-b61 In-Reply-To: References: <554A5AE3.1000200@oracle.com> <554B1EAF.5070005@oracle.com> <554B2EF3.80604@oracle.com> Message-ID: <554B5531.8070000@oracle.com> On 07/05/2015 12:02, Andreas Kohn wrote: > You can actually download the bundle via Eclipses' orbit repository: > http://download.eclipse.org/tools/orbit/downloads/drops/R20150124073747/repository/plugins/javax.xml_1.3.4.v201005080400.jar > > The description for this bundle at > http://download.eclipse.org/tools/orbit/downloads/drops/R20150124073747/ > says "Part of and required for Xerces 2.9.0. The bundle corresponds to > the xml-apis.jar in the Xerces distribution.", Thanks for the digging, I didn't have cycles to track down these downloads myself. I guess there must be some historical reason for shipping the XML APIs, maybe it goes back to before JDK 1.4. That might explain the vintage JAXP version too, assuming that version="1.3" on each of these packages means JAXP 1.3. If you are in contact with the Eclipse folks then it might be useful to point out that JSR 206 announced its end as a standalone technology in the JAXP 1.6 update. Going forward then the proposal is to subsume it into the platform JSR with Java SE 9 as the first opportunity to do this. This doesn't impact anyone wanting to ship their own XML parser implementation of course but the service provider interfaces (improved in JAXP 1.6) is the way to do this rather than trying to override the API classes. > > It "exports" these things: > javax.xml;version="1.3", > javax.xml.datatype;version="1.3", > javax.xml.namespace;version="1.3", > javax.xml.parsers;version="1.3", > javax.xml.transform;version="1.3", > javax.xml.transform.dom;version="1.3", > javax.xml.transform.sax;version="1.3", > javax.xml.transform.stream;version="1.3", > javax.xml.validation;version="1.3", > javax.xml.xpath;version="1.3", > org.apache.xmlcommons;version="1.3.4", > org.w3c.dom;version="3.0", > org.w3c.dom.bootstrap;version="3.0", > org.w3c.dom.css;version="2.0", > org.w3c.dom.events;version="2.0", > org.w3c.dom.html;version="2.0", > org.w3c.dom.ls ;version="2.0", > org.w3c.dom.ranges;version="2.0", > org.w3c.dom.stylesheets;version="2.0", > org.w3c.dom.traversal;version="2.0", > org.w3c.dom.views;version="2.0", > org.w3c.dom.xpath;version="3.0", > org.xml.sax;version="2.0.2", > org.xml.sax.ext;version="2.0.2", > org.xml.sax.helpers;version="2.0.2" > > With that said I did a small experiment: remove all classes from the > bundle, and only leave a (trimmed) META-INF/MANIFEST.MF. That didn't > work, however just by additionally keeping the org.w3c.dom.css classes > eclipse starts up again. :) > > $ jar xf ~/modules/eclipse/plugins/javax.xml_1.3.4.v201005080400.jar > $ rm ~/modules/eclipse/plugins/javax.xml_1.3.4.v201005080400.jar > $ # remove stuff from META-INF/MANIFEST.MF > $ jar cvmf META-INF/MANIFEST.MF-trimmed > ~/modules/eclipse/plugins/javax.xml_1.3.4.v201005080400.jar about* > license/ org/apache/ plugin.properties org/w3c/dom/css > > Thanks for pointing me in the right direction, will update the eclipse > bug as well! > Good experiment. The org.w3c.dom.css is another one of the API packages that weren't in the subset of the W3C API endorsed by Java SE. -Alan. From andreas.kohn at gmail.com Thu May 7 07:57:44 2015 From: andreas.kohn at gmail.com (Andreas Kohn) Date: Thu, 07 May 2015 07:57:44 +0000 Subject: Eclipse no longer working with 1.9.0-ea-b61 In-Reply-To: <554A5AE3.1000200@oracle.com> References: <554A5AE3.1000200@oracle.com> Message-ID: Hi, Thanks, that makes sense. I tried with your suggestion of adjusting the OSGi parent class loader, and the results are "interesting": b60: things work, i.e. I couldn't observe any ill effects. b61: same error (makes sense, as the classes simply aren't there, if I understand the 8078139 bug correctly) With my local build however things change: Eclipse still doesn't start, but now reports "java.lang.LinkageError: loader constraint violation: loader (instance of sun/misc/Launcher$ExtClassLoader) previously initiated loading for a different type with name "org/w3c/dom/stylesheets/StyleSheet"". Will file an issue with eclipse, pointing here, thanks for your help again! Regards, -- Andreas On Wed, May 6, 2015 at 8:18 PM Alan Bateman wrote: > On 06/05/2015 16:29, Andreas Kohn wrote: > > Eclipse no longer starts with 1.9.0-ea-b61 or higher, complaining about > > missing org.w3c.dom.stylesheets.StyleSheetList. > > > > I'm guessing this is due to > > http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8042244 (Re-examine > the > > supportedness of non-SE org.w3c.dom.** API), which points to a regression > > that should be fixed with > > http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8078139 > > Unfortunately doing a local build from 9dev with the commit for that bug > > included doesn't help, the message stays the same. > > > > Is this an eclipse issue, or a legitimate regression on the JDK side? > > > In JDK 9 then several components that have historically had their types > loaded by the boot loader have been moved to the extension loader. This > includes CORBA, JAXB, JAX-WS, the JavaBeans Activation Framework and a > few more. There are a number of motivations for this, one is that we > allows these components to be configured with reduced permissions > (compared to getting all permissions when defined by the boot loader). > > The W3C DOM API is a bit confusing because Java SE only endorsed a > subset of the API. There are a number of additional API packages, > org.w3c.dom.stylesheets being one of them, that are not part of Java SE. > The JDK has always shipped this and the other packages but nothing can > really depend on them being there. This is clearly confusing so I think > Eclipse and others that might depend on these other API packages can be > forgiven. The proposal in JDK 9 is to continue to ship these packages in > a module named jdk.xml.dom. Furthermore, the proposal is move this to > the extension loader as they are not core and have no reason to be > loaded by the boot loader. This is what JDK-8042244 is about. > > As regards Eclipse then I assume it must be using one of its own class > loaders that delegates to the boot loader rather than the system class > loader. This is unfortunate as it means that many standard and > JDK-specific type won't be visible (esp. as more non-core components are > moved out of the boot loader). I would be curious if > -Dorg.osgi.framework.bundle.parent=app fixes the issue. As you bring it > up then I think it would be good to get a bug submitted to Eclipse on > this, it would be unfortunate if only a subset of the standard and JDK > types are visible via its class loaders. > > -Alan > > > > > From andreas.kohn at gmail.com Thu May 7 08:33:53 2015 From: andreas.kohn at gmail.com (Andreas Kohn) Date: Thu, 07 May 2015 08:33:53 +0000 Subject: Eclipse no longer working with 1.9.0-ea-b61 In-Reply-To: <554B1EAF.5070005@oracle.com> References: <554A5AE3.1000200@oracle.com> <554B1EAF.5070005@oracle.com> Message-ID: On Thu, May 7, 2015 at 10:13 AM Alan Bateman wrote: > > With my local build however things change: Eclipse still doesn't > > start, but now reports "java.lang.LinkageError: loader constraint > > violation: loader (instance of sun/misc/Launcher$ExtClassLoader) > > previously initiated loading for a different type with name > > "org/w3c/dom/stylesheets/StyleSheet"". > > > > Will file an issue with eclipse, pointing here, thanks for your help > > again! > Loader constraint issues are a pain to diagnose. Can you run with > -verbose as I'm curious where org.w3c.dom.stylesheets.StyleSheet is > being loaded from. I will guess that Eclipse is shipping its own copy. > > Indeed, Eclipse seems to load them from a javax.xml bundle as well, attached are the -verbose and -verbose + -Dsun.misc.URLClassPath.debug logs. Quick grep: [andreas at winterfell ~]$ grep org.w3c.dom.stylesheets eclipse-9-internal-app-verbose-debug.out URLClassPath.getResource("org/w3c/dom/stylesheets/DocumentStyle.class") [Loaded org.w3c.dom.stylesheets.DocumentStyle from file:/home/andreas/modules/eclipse-4.5M6/plugins/javax.xml_1.3.4.v201005080400.jar] URLClassPath.getResource("org/w3c/dom/stylesheets/StyleSheetList.class") URLClassPath.getResource("org/w3c/dom/stylesheets/StyleSheetList.class") [Loaded org.w3c.dom.stylesheets.StyleSheetList from jrt:/jdk.xml.dom] URLClassPath.getResource("org/w3c/dom/stylesheets/StyleSheet.class") [Loaded org.w3c.dom.stylesheets.StyleSheet from file:/home/andreas/modules/eclipse-4.5M6/plugins/javax.xml_1.3.4.v201005080400.jar] URLClassPath.getResource("org/w3c/dom/stylesheets/MediaList.class") URLClassPath.getResource("org/w3c/dom/stylesheets/MediaList.class") [Loaded org.w3c.dom.stylesheets.MediaList from jrt:/jdk.xml.dom] URLClassPath.getResource("org/w3c/dom/stylesheets/StyleSheet.class") URLClassPath.getResource("org/w3c/dom/stylesheets/StyleSheet.class") [Loaded org.w3c.dom.stylesheets.StyleSheet from jrt:/jdk.xml.dom] -- Andreas PS: The eclipse bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=466690 From andreas.kohn at gmail.com Thu May 7 11:02:42 2015 From: andreas.kohn at gmail.com (Andreas Kohn) Date: Thu, 07 May 2015 11:02:42 +0000 Subject: Eclipse no longer working with 1.9.0-ea-b61 In-Reply-To: <554B2EF3.80604@oracle.com> References: <554A5AE3.1000200@oracle.com> <554B1EAF.5070005@oracle.com> <554B2EF3.80604@oracle.com> Message-ID: You can actually download the bundle via Eclipses' orbit repository: http://download.eclipse.org/tools/orbit/downloads/drops/R20150124073747/repository/plugins/javax.xml_1.3.4.v201005080400.jar The description for this bundle at http://download.eclipse.org/tools/orbit/downloads/drops/R20150124073747/ says "Part of and required for Xerces 2.9.0. The bundle corresponds to the xml-apis.jar in the Xerces distribution.", It "exports" these things: javax.xml;version="1.3", javax.xml.datatype;version="1.3", javax.xml.namespace;version="1.3", javax.xml.parsers;version="1.3", javax.xml.transform;version="1.3", javax.xml.transform.dom;version="1.3", javax.xml.transform.sax;version="1.3", javax.xml.transform.stream;version="1.3", javax.xml.validation;version="1.3", javax.xml.xpath;version="1.3", org.apache.xmlcommons;version="1.3.4", org.w3c.dom;version="3.0", org.w3c.dom.bootstrap;version="3.0", org.w3c.dom.css;version="2.0", org.w3c.dom.events;version="2.0", org.w3c.dom.html;version="2.0", org.w3c.dom.ls;version="2.0", org.w3c.dom.ranges;version="2.0", org.w3c.dom.stylesheets;version="2.0", org.w3c.dom.traversal;version="2.0", org.w3c.dom.views;version="2.0", org.w3c.dom.xpath;version="3.0", org.xml.sax;version="2.0.2", org.xml.sax.ext;version="2.0.2", org.xml.sax.helpers;version="2.0.2" With that said I did a small experiment: remove all classes from the bundle, and only leave a (trimmed) META-INF/MANIFEST.MF. That didn't work, however just by additionally keeping the org.w3c.dom.css classes eclipse starts up again. :) $ jar xf ~/modules/eclipse/plugins/javax.xml_1.3.4.v201005080400.jar $ rm ~/modules/eclipse/plugins/javax.xml_1.3.4.v201005080400.jar $ # remove stuff from META-INF/MANIFEST.MF $ jar cvmf META-INF/MANIFEST.MF-trimmed ~/modules/eclipse/plugins/javax.xml_1.3.4.v201005080400.jar about* license/ org/apache/ plugin.properties org/w3c/dom/css Thanks for pointing me in the right direction, will update the eclipse bug as well! -- Andreas On Thu, May 7, 2015 at 11:23 AM Alan Bateman wrote: > > > On 07/05/2015 09:33, Andreas Kohn wrote: > > : > > > > Indeed, Eclipse seems to load them from a javax.xml bundle as well, > > attached are the -verbose and -verbose + -Dsun.misc.URLClassPath.debug > > logs. > > > > Quick grep: > > [andreas at winterfell ~]$ grep org.w3c.dom.stylesheets > > eclipse-9-internal-app-verbose-debug.out > > URLClassPath.getResource("org/w3c/dom/stylesheets/DocumentStyle.class") > > [Loaded org.w3c.dom.stylesheets.DocumentStyle from > > > file:/home/andreas/modules/eclipse-4.5M6/plugins/javax.xml_1.3.4.v201005080400.jar] > > URLClassPath.getResource("org/w3c/dom/stylesheets/StyleSheetList.class") > > URLClassPath.getResource("org/w3c/dom/stylesheets/StyleSheetList.class") > > [Loaded org.w3c.dom.stylesheets.StyleSheetList from jrt:/jdk.xml.dom] > > URLClassPath.getResource("org/w3c/dom/stylesheets/StyleSheet.class") > > [Loaded org.w3c.dom.stylesheets.StyleSheet from > > > file:/home/andreas/modules/eclipse-4.5M6/plugins/javax.xml_1.3.4.v201005080400.jar] > > URLClassPath.getResource("org/w3c/dom/stylesheets/MediaList.class") > > URLClassPath.getResource("org/w3c/dom/stylesheets/MediaList.class") > > [Loaded org.w3c.dom.stylesheets.MediaList from jrt:/jdk.xml.dom] > > URLClassPath.getResource("org/w3c/dom/stylesheets/StyleSheet.class") > > URLClassPath.getResource("org/w3c/dom/stylesheets/StyleSheet.class") > > [Loaded org.w3c.dom.stylesheets.StyleSheet from jrt:/jdk.xml.dom] > > > > -- > > Andreas > > > > PS: The eclipse bug: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=466690 > I'm curious what else might be in this javax.xml bundle in case there > are other potential issues too. > > Thanks for create the bug in Eclipse's bugzilla. > > -Alan > From goetz.lindenmaier at sap.com Thu May 7 13:39:58 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 7 May 2015 13:39:58 +0000 Subject: RFR(XS): 8079510: AIX: fix build after '8042901: Allow com.sun.management to be in a different module...' In-Reply-To: References: Message-ID: <4295855A5C1DE049A61835A1887419CC2CFDBD0F@DEWDFEMB12A.global.corp.sap> Hi Volker, the change looks good. Thanks for fixing this. Best regards, Goetz. -----Original Message----- From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis Sent: Mittwoch, 6. Mai 2015 18:12 To: jdk9-dev at openjdk.java.net; serviceability-dev at openjdk.java.net Subject: RFR(XS): 8079510: AIX: fix build after '8042901: Allow com.sun.management to be in a different module...' Hi, can somebody please review this trivial AIX-only change which fixes an AIX build error: http://cr.openjdk.java.net/~simonis/webrevs/2015/8079510/ https://bugs.openjdk.java.net/browse/JDK-8079510 Here are the details: Change '8042901: Allow com.sun.management to be in a different module to java.lang.management' has refactored the management package and moved the files: jdk/src/java.management/unix/native/libmanagement/OperatingSystem.c to: jdk/src/jdk.management//native/libmanagement_ext/UnixOperatingSystem.c Unfortunately we've never had a AIXOperatingSystem.c file on AIX (see 8030957). This was no problem with the old setup but with the new one the build complains about a missing directory 'jdk/src/jdk.management/aix/native/libmanagement_ext'. This bug is just for fixing the build, by introducing an emty stub file. The actual implementation of the corresponding OperatingSystemMXBean is still up to 8030957. Thanks, Volker From mike.milinkovich at eclipse.org Thu May 7 18:28:11 2015 From: mike.milinkovich at eclipse.org (Mike Milinkovich) Date: Thu, 07 May 2015 14:28:11 -0400 Subject: Eclipse no longer working with 1.9.0-ea-b61 In-Reply-To: <554B5531.8070000@oracle.com> References: <554A5AE3.1000200@oracle.com> <554B1EAF.5070005@oracle.com> <554B2EF3.80604@oracle.com> <554B5531.8070000@oracle.com> Message-ID: <554BAEBB.4000304@eclipse.org> "The Eclipse folks" are not hard to find. Please see https://bugs.eclipse.org/bugs/show_bug.cgi?id=466683 On 07/05/2015 8:06 AM, Alan Bateman wrote: > > On 07/05/2015 12:02, Andreas Kohn wrote: >> You can actually download the bundle via Eclipses' orbit repository: >> http://download.eclipse.org/tools/orbit/downloads/drops/R20150124073747/repository/plugins/javax.xml_1.3.4.v201005080400.jar >> >> >> The description for this bundle at >> http://download.eclipse.org/tools/orbit/downloads/drops/R20150124073747/ >> says "Part of and required for Xerces 2.9.0. The bundle corresponds >> to the xml-apis.jar in the Xerces distribution.", > Thanks for the digging, I didn't have cycles to track down these > downloads myself. > > I guess there must be some historical reason for shipping the XML > APIs, maybe it goes back to before JDK 1.4. That might explain the > vintage JAXP version too, assuming that version="1.3" on each of these > packages means JAXP 1.3. If you are in contact with the Eclipse folks > then it might be useful to point out that JSR 206 announced its end as > a standalone technology in the JAXP 1.6 update. Going forward then the > proposal is to subsume it into the platform JSR with Java SE 9 as the > first opportunity to do this. This doesn't impact anyone wanting to > ship their own XML parser implementation of course but the service > provider interfaces (improved in JAXP 1.6) is the way to do this > rather than trying to override the API classes. > >> >> It "exports" these things: >> javax.xml;version="1.3", >> javax.xml.datatype;version="1.3", >> javax.xml.namespace;version="1.3", >> javax.xml.parsers;version="1.3", >> javax.xml.transform;version="1.3", >> javax.xml.transform.dom;version="1.3", >> javax.xml.transform.sax;version="1.3", >> javax.xml.transform.stream;version="1.3", >> javax.xml.validation;version="1.3", >> javax.xml.xpath;version="1.3", >> org.apache.xmlcommons;version="1.3.4", >> org.w3c.dom;version="3.0", >> org.w3c.dom.bootstrap;version="3.0", >> org.w3c.dom.css;version="2.0", >> org.w3c.dom.events;version="2.0", >> org.w3c.dom.html;version="2.0", >> org.w3c.dom.ls ;version="2.0", >> org.w3c.dom.ranges;version="2.0", >> org.w3c.dom.stylesheets;version="2.0", >> org.w3c.dom.traversal;version="2.0", >> org.w3c.dom.views;version="2.0", >> org.w3c.dom.xpath;version="3.0", >> org.xml.sax;version="2.0.2", >> org.xml.sax.ext;version="2.0.2", >> org.xml.sax.helpers;version="2.0.2" >> >> With that said I did a small experiment: remove all classes from the >> bundle, and only leave a (trimmed) META-INF/MANIFEST.MF. That didn't >> work, however just by additionally keeping the org.w3c.dom.css >> classes eclipse starts up again. :) >> >> $ jar xf ~/modules/eclipse/plugins/javax.xml_1.3.4.v201005080400.jar >> $ rm ~/modules/eclipse/plugins/javax.xml_1.3.4.v201005080400.jar >> $ # remove stuff from META-INF/MANIFEST.MF >> $ jar cvmf META-INF/MANIFEST.MF-trimmed >> ~/modules/eclipse/plugins/javax.xml_1.3.4.v201005080400.jar about* >> license/ org/apache/ plugin.properties org/w3c/dom/css >> >> Thanks for pointing me in the right direction, will update the >> eclipse bug as well! >> > Good experiment. The org.w3c.dom.css is another one of the API > packages that weren't in the subset of the W3C API endorsed by Java SE. > > -Alan. -- Mike Milinkovich mike.milinkovich at eclipse.org +1.613.220.3223 (mobile) From peter.brunet at oracle.com Fri May 8 19:11:08 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 08 May 2015 14:11:08 -0500 Subject: RfR JDK-8078408,Java version applet hangs with Voice over turned on Message-ID: <554D0A4C.5080700@oracle.com> Please review the fix for JDK-8078408 "Java version applet hangs with Voice over turned on". The failure is an NPE. There is a variable that is OK to be null at the point of failure and the fix adds a check for it being null. http://cr.openjdk.java.net/~ptbrunet/JDK-8078408/webrev.00/ Thanks, Pete From mark.reinhold at oracle.com Fri May 8 22:54:00 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 08 May 2015 15:54:00 -0700 Subject: JEPs proposed to target JDK 9 (2015/4/30) In-Reply-To: <20150430153924.942430@eggemoggin.niobe.net> References: <20150430153924.942430@eggemoggin.niobe.net> Message-ID: <20150508155400.501006@eggemoggin.niobe.net> 2015/4/30 3:39 -0700, mark.reinhold at oracle.com: > The following JEPs have been placed into the "Proposed to Target" > state by their owners after discussion and review: > > 232: Improve Secure Application Performance http://openjdk.java.net/jeps/232 > 245: Validate JVM Command-Line Flag Arguments http://openjdk.java.net/jeps/245 > > Feedback on these proposals is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC next > Thursday, 7 May, or if they're raised and then satisfactorily > answered, then per the JEP 2.0 process proposal [1] I'll target > these JEPs to JDK 9. Hearing no objections, I've targeted these JEPs to JDK 9. - Mark From mark.reinhold at oracle.com Fri May 8 23:05:07 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 08 May 2015 16:05:07 -0700 Subject: JEP proposed to target JDK 9 (2015/5/8) Message-ID: <20150508160507.367489@eggemoggin.niobe.net> The following JEP has been placed into the "Proposed to Target" state by its owner after discussion and review: 222: jshell: The Java Shell (Read-Eval-Print Loop) http://openjdk.java.net/jeps/222 Feedback on this proposal is more than welcome, as are reasoned objections. If no such objections are raised by 23:30 UTC next Friday, 15 May, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target these JEPs to JDK 9. (This information is also available on the JDK 9 Project Page [2]). - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html [2] http://openjdk.java.net/projects/jdk9/ From martijnverburg at gmail.com Sun May 10 11:06:03 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sun, 10 May 2015 12:06:03 +0100 Subject: JEP proposed to target JDK 9 (2015/5/8) In-Reply-To: <20150508160507.367489@eggemoggin.niobe.net> References: <20150508160507.367489@eggemoggin.niobe.net> Message-ID: This is great news - the REPL was really well received in our hack day last month, it seemed really polished already. Cheers, Martijn On 9 May 2015 at 00:05, wrote: > The following JEP has been placed into the "Proposed to Target" > state by its owner after discussion and review: > > 222: jshell: The Java Shell (Read-Eval-Print Loop) > http://openjdk.java.net/jeps/222 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 23:30 UTC next > Friday, 15 May, or if they're raised and then satisfactorily > answered, then per the JEP 2.0 process proposal [1] I'll target > these JEPs to JDK 9. > > (This information is also available on the JDK 9 Project Page [2]). > > - Mark > > > [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html > [2] http://openjdk.java.net/projects/jdk9/ > From alexander.kulyakhtin at oracle.com Wed May 13 15:48:48 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 13 May 2015 08:48:48 -0700 (PDT) Subject: Changes fro JDK-8075327: moving jdk testlibraty files duplicated in hotspot to the common test repository Message-ID: <15629659-f6ca-4ad4-8458-9174f8ce473f@default> Adding jdk9-dev mailing list ----- Original Message ----- From: alexander.kulyakhtin at oracle.com To: core-libs-dev at openjdk.java.net, awt-dev at openjdk.java.net, hotspot-dev at openjdk.java.net Cc: stefan.sarne at oracle.com, yekaterina.kantserova at oracle.com, alan.bateman at oracle.com Sent: Wednesday, May 13, 2015 5:52:20 PM GMT +03:00 Iraq Subject: Changes fro JDK-8075327: moving jdk testlibraty files duplicated in hotspot to the common test repository Hi, Could you please, review the following tests-only changes to the hs-rt/jdk and hs-rt/test repositories. These changes are a part of the changes for "JDK-8075327: Merge jdk and hotspot test libraries" The changes are as follows: http://cr.openjdk.java.net/~akulyakh/8075327/jdk_patch/webrev/ http://cr.openjdk.java.net/~akulyakh/8075327/test_patch/webrev/ 1) Renaming jdk.testlibrary package to jdk.test.lib in the hs-rt/jdk repo, so it has the same name as the jdk.test.lib package in the hotspot repo. 2) Several files from the jdk/testlibrary have duplicates in the hotspot/testlibrary. We are moving those files from jdk/testlibrary to the upper-level hs-rt/test so they can be shared by jdk and hotspot (also updating @library directives to reflect that). If these proposed changes are acceptable then we'll merge the duplicates between the hs-rt/hotspot and hs-rt/test/lib files into hs-rt/test/lib and prepare a full review. Thank you very much for the review. Best regards, Alexander From alexander.kulyakhtin at oracle.com Wed May 13 15:55:38 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 13 May 2015 08:55:38 -0700 (PDT) Subject: Changes fro JDK-8075327: moving jdk testlibraty files duplicated in hotspot to the common test repository Message-ID: <88114659-c772-48fd-a3e3-f08e609557e1@default> Jon, I've made the changes not knowing the new jtreg, in which one can specify roots in TEST.properties is coming very soon. I think, it is definitely worth to wait for the new jtreg then. Best regards, Alexander ----- Original Message ----- From: jonathan.gibbons at oracle.com To: alexander.kulyakhtin at oracle.com, Alan.Bateman at oracle.com Cc: "jdk_confidential_ww_grp" , christian.tornqvist at oracle.com, "hotspot_runtime_dev_confidential_ww_grp" , stefan.sarne at oracle.com, yekaterina.kantserova at oracle.com Sent: Wednesday, May 13, 2015 6:48:02 PM GMT +03:00 Iraq Subject: Re: Changes fro JDK-8075327: moving jdk testlibraty files duplicated in hotspot to the common test repository There is a change coming up in jtreg (it's available in the nightly build already) that allows you to avoid using excessive .. paths. I expect that we will promote this new version soon (before end of month.) Is it worth waiting for that version so that you can avoid a double update to the tests? -- Jon On 05/13/2015 07:32 AM, Alexander Kulyakhtin wrote: > Alan, > > Thank you very much for the correction. I'm now going to send the same to the Open JDK. > > Best regards, > Alexander > > > > ----- Original Message ----- > From: Alan.Bateman at oracle.com > To: alexander.kulyakhtin at oracle.com, "jdk_confidential_ww_grp" , "hotspot_runtime_dev_confidential_ww_grp" > Cc: christian.tornqvist at oracle.com, stefan.sarne at oracle.com, yekaterina.kantserova at oracle.com > Sent: Wednesday, May 13, 2015 5:22:52 PM GMT +03:00 Iraq > Subject: Re: Changes fro JDK-8075327: moving jdk testlibraty files duplicated in hotspot to the common test repository > > On 13/05/2015 14:34, Alexander Kulyakhtin wrote: >> Hi, >> >> Could you please, review the following changes to the hs-rt/jdk and hs-rt/test repositories. These changes are a part of the changes for "JDK-8075327: Merge jdk and hotspot test libraries" >> > Did you mean to mail Oracle internal mailing lists with this? As this > code is in OpenJDK then I assume that it should be discussed there. > > -Alan > From chris.hegarty at oracle.com Wed May 13 16:48:02 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 May 2015 17:48:02 +0100 Subject: Changes fro JDK-8075327: moving jdk testlibraty files duplicated in hotspot to the common test repository In-Reply-To: <5e28a49a-4ff3-43b4-8e02-7bfe73f0bfd6@default> References: <5e28a49a-4ff3-43b4-8e02-7bfe73f0bfd6@default> Message-ID: <34348D14-9BBC-40E6-A1DB-923D88AFCD90@oracle.com> Alexander, > On 13 May 2015, at 16:46, Alexander Kulyakhtin wrote: > > Hi Chris, > > >> I suspect that these changes are best going directly into jdk9/dev, as >> opposed to a a downstream forest. > Yes, they are going directly to jdk9/dev, I forgot to add the group, adding now. > >> In may places '@library /lib/testlibrary ...' remains. Is this >> redundant, in many tests? If so, it be removed. > No, this is mostly not redundant, as the jdk/testlibrary comntains many files specific for jdk only. Only a relatively small number of files are duplicated between hotspot and jdk. Right, but mostly is not all. For example test/com/sun/net/httpserver/Test1.java should no longer include @library /lib/testlibrary. It depends only on SimpleSSLContext which is being moved. It is easy to see this by looking at the imports. Whatever script you have for updating these tests should also remove redundant values in the @library tag. I suspect there are a significant number of these ( a lot of tests just use one library class ). Just on that, is it for a library class to indicate that it depends on a class from another library? I believe this is the case for some library utilities. How can a test know this. It needs to be a library class that indicates this dependency.I see nothing in the webrev for this ( or maybe I missed it ). -Chris. > >> The changes are to the 'test' directory in the "top" repo? You are not >> proposing to add a new repo, right? > No, we are not proposing a new repo. The changes are in the 'top' repo. > >> test/lib/testlibrary/jdk/testlibrary/RandomFactory.java was updated >> recently in jdk9/dev. The version in your webrev is a little out of date. > We are going to upmerge the changes then > >> Is there any special update needed to jtreg to support this? > For thse changes no jtreg update is required. > However, there are plans for the jtreg to prohibit referencing any @libraries above the repo root unless such libraries are directly specified in TEST.properties > If jtreg thus prohibits our using /../../test/lib (because it's above the root) we will have to additionally make a change to jdk and hotspot TEST.properties > > Best regards, > Alexander From alexander.kulyakhtin at oracle.com Wed May 13 17:08:29 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 13 May 2015 10:08:29 -0700 (PDT) Subject: Changes for JDK-8075327: moving jdk testlibraty files duplicated in hotspot to the common test repository Message-ID: Chris, Following the feedback from Jon Gibbons, we have changed our current plan to the following: 1) We are waiting till the new jtreg is promoted. The new jtreg allows for specifying in the repository's TEST.properties file one or more paths to search for libraries 2) After the jtreg is out we are adding both path to jdk/testlibrary and path to toplevel/test/lib/share library to the jdk and hotspot TEST.properties files Under those testlibrary roots we are rearranging the directories to have the same jdk/test/lib structure (to provide for the jdk.test.lib package) 3) Same as with the current changes we are changing import package jdk.testlib.* to import package jdk.test.lib.* in the jdk and hotspot tests. This way, if the jtreg does not find a required class from the jdk.test.lib in the jdk/testlibrary it will look for it in the toplevel/test/lib/share test library. The same will be done for the hotspot tests. Best regards, Alexander ----- Original Message ----- From: chris.hegarty at oracle.com To: alexander.kulyakhtin at oracle.com Cc: core-libs-dev at openjdk.java.net, awt-dev at openjdk.java.net, stefan.sarne at oracle.com, yekaterina.kantserova at oracle.com, hotspot-dev at openjdk.java.net, jdk9-dev at openjdk.java.net Sent: Wednesday, May 13, 2015 7:48:06 PM GMT +03:00 Iraq Subject: Re: Changes fro JDK-8075327: moving jdk testlibraty files duplicated in hotspot to the common test repository Alexander, > On 13 May 2015, at 16:46, Alexander Kulyakhtin wrote: > > Hi Chris, > > >> I suspect that these changes are best going directly into jdk9/dev, as >> opposed to a a downstream forest. > Yes, they are going directly to jdk9/dev, I forgot to add the group, adding now. > >> In may places '@library /lib/testlibrary ...' remains. Is this >> redundant, in many tests? If so, it be removed. > No, this is mostly not redundant, as the jdk/testlibrary comntains many files specific for jdk only. Only a relatively small number of files are duplicated between hotspot and jdk. Right, but mostly is not all. For example test/com/sun/net/httpserver/Test1.java should no longer include @library /lib/testlibrary. It depends only on SimpleSSLContext which is being moved. It is easy to see this by looking at the imports. Whatever script you have for updating these tests should also remove redundant values in the @library tag. I suspect there are a significant number of these ( a lot of tests just use one library class ). Just on that, is it for a library class to indicate that it depends on a class from another library? I believe this is the case for some library utilities. How can a test know this. It needs to be a library class that indicates this dependency.I see nothing in the webrev for this ( or maybe I missed it ). -Chris. > >> The changes are to the 'test' directory in the "top" repo? You are not >> proposing to add a new repo, right? > No, we are not proposing a new repo. The changes are in the 'top' repo. > >> test/lib/testlibrary/jdk/testlibrary/RandomFactory.java was updated >> recently in jdk9/dev. The version in your webrev is a little out of date. > We are going to upmerge the changes then > >> Is there any special update needed to jtreg to support this? > For thse changes no jtreg update is required. > However, there are plans for the jtreg to prohibit referencing any @libraries above the repo root unless such libraries are directly specified in TEST.properties > If jtreg thus prohibits our using /../../test/lib (because it's above the root) we will have to additionally make a change to jdk and hotspot TEST.properties > > Best regards, > Alexander From mark.reinhold at oracle.com Wed May 13 18:25:02 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 13 May 2015 11:25:02 -0700 Subject: JDK 9 release schedule In-Reply-To: <20150505092131.712129@eggemoggin.niobe.net> References: <20150505092131.712129@eggemoggin.niobe.net> Message-ID: <20150513112502.626887@eggemoggin.niobe.net> 2015/5/5 9:21 -0700, mark.reinhold at oracle.com: > Here is a proposed schedule for JDK 9: > > 2015-12-10 Feature Complete > 2016-02-04 All Tests Run > 2016-02-25 Rampdown Start > 2016-04-21 Zero Bug Bounce > 2016-06-16 Rampdown Phase 2 > 2016-07-21 Final Release Candidate > 2016-09-22 General Availability Hearing no objections, I've posted this as the schedule of record on the JDK 9 Project page: http://openjdk.java.net/projects/jdk9/ . - Mark From lana.steuck at oracle.com Wed May 13 21:28:08 2015 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 13 May 2015 14:28:08 -0700 (PDT) Subject: jdk9-b64: dev Message-ID: <201505132128.t4DLS8Z2021824@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/82cf9aab9a83 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/00df6e4fc75a http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/809d66512998 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7de8d036ad09 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/df100399ed27 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/6f91749b5aae http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/bf92b8db249c http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/0a5e5a7c3539 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8078049 core-libs Nashorn crashes when attempting to start TypeScript compiler JDK-8079510 client-libs AIX: fix build after '8042901: Allow com.sun.management to be in a dif JDK-8079419 client-libs Update to RegEx test to use random number library JDK-8026049 core-libs (bf) Intrinsify ByteBuffer.put{Int,Double,Float,...} methods JDK-8065109 core-libs (fs spec) Files.newBufferedWriter doesn't specify SecurityException fo JDK-8077685 core-libs (tz) Support tzdata2015d JDK-8078245 core-libs aarch64 fails to build from source JDK-8079186 core-libs Add 'localeServiceProvider' target in the class description of Runtime JDK-8057919 core-libs Class.getSimpleName() should work for non-JLS compliant class names JDK-8078290 core-libs Customize adapted MethodHandle in MH.invoke() case JDK-8077054 core-libs DMH LFs should be customizeable JDK-8079349 core-libs Eliminate dead code around Nashorn code generator JDK-8079362 core-libs Enforce best practices for Node token API usage JDK-8066237 core-libs Fuzzing bug: Parser error on optimistic recompilation JDK-8074003 core-libs java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized JDK-8033465 core-libs JSR292: InvokerBytecodeGenerator: convert a check for REF_invokeVirtua JDK-8076461 core-libs JSR292: remove unused native and constants JDK-8079544 core-libs Mark java/util/regex/RegExTest.java as failing intermittently JDK-8079470 core-libs Misleading error message when explicit signature constructor is called JDK-8079269 core-libs Optimistic rewrite in object literal causes ArrayIndexOutOfBoundsExcep JDK-8078612 core-libs Persistent code cache should support more configurations JDK-8066751 core-libs Remove casts redundant with Java 9 buffer APIs JDK-8074545 core-libs Undefined object values in object literals with spill properties JDK-8078896 core-svc Add @modules as needed to the jdk_svc tests JDK-8023093 core-svc Add ManagementAgent.status diagnostic command JDK-8042901 core-svc Allow com.sun.management to be in a different module to java.lang.mana JDK-8077611 core-svc com/sun/jdi/ConnectedVMs.java should be unquarantined JDK-8077422 core-svc hprof agent: Build failed with VS2013 Update 4 JDK-8075820 core-svc java/lang/management/ThreadMXBean/FindDeadlocks.java should be unquara JDK-8076050 core-svc java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java fails int JDK-8077423 core-svc jstatd is not terminated even though it cannot contact or bind to RMI JDK-8077956 core-svc nsk/jdwp/ReferenceType/MethodsWithGeneric/methwithgeneric001 should be JDK-8027668 core-svc sun/tools/jstatd/TestJstatdPort.java: java.net.ConnectException: Conne JDK-8074368 core-svc ThreadMXBean.getThreadInfo() corrupts memory when called with empty ar JDK-8077327 core-svc ThreadStackTrace.java throws exception: BlockedThread expected to have JDK-8077364 hotspot "if( !this )" construct prevents build on Xcode 6.3 JDK-8067662 hotspot "java.lang.NullPointerException: Method name is null" from StackTraceE JDK-8077257 hotspot (AIX) Use CanUseSafeFetch instead of probing SafeFetch stub directly JDK-8077608 hotspot [TESTBUG] Enable Hotspot jtreg tests to run in agentvm mode JDK-8078595 hotspot [TESTBUG] Fix runtime/StackGuardPages/testme.sh to deal with 64k pages JDK-8075438 hotspot [TESTBUG] Hotspot JTREG tests should use unique CDS archive names JDK-8078383 hotspot [TESTBUG] Merge hotspot_runtime and hotspot_runtime_closed in jprt tes JDK-8076274 hotspot [TESTBUG] Remove @ignore from runtime\NMT\JcmdDetailDiff.java JDK-8075107 hotspot [TESTBUG] Remove closed/com/oracle/jfr/compiler/CodeCacheFullEventTest JDK-8078435 hotspot [TESTBUG] runtime/CommandLine/TestVMOptions.java fails when running wi JDK-8078113 hotspot 8011102 changes may cause incorrect results. JDK-8077615 hotspot AARCH64: Add C2 intrinsic for BigInteger::multiplyToLen() method JDK-8022853 hotspot add ability to load uncompressed object and Klass references in a comp JDK-8076614 hotspot Add comment to ClearNoncleanCardWrapper::do_MemRegion() JDK-8026043 hotspot Add regression test for JDK-8000831 JDK-8077843 hotspot adlc: allow nodes that use TEMP inputs in expand rules. JDK-8076057 hotspot aix: After 8075506, aix does not support large pages. JDK-8075858 hotspot AIX: clean-up HotSpot make files JDK-8076212 hotspot AllocateHeap() and ReallocateHeap() should be inlined. JDK-8075798 hotspot Allow ADLC register class to depend on runtime conditions also for cis JDK-8075921 hotspot assert assert(allocx == alloc) fails in library_call.cpp JDK-8076523 hotspot assert(((ABS(iv_adjustment_in_bytes) % elt_size) == 0)) fails in super JDK-8069263 hotspot assert(fm == NULL || fm->method_holder() == _participants[n]) failed: JDK-8075922 hotspot assert(t == t_no_spec) fails in phaseX.cpp JDK-8077413 hotspot Avoid use of Universe::heap() inside collectors JDK-8077710 hotspot BACKOUT - java hangs with -XX:ParallelGCThreads=0 -XX:+ExplicitGCInvok JDK-8078193 hotspot BACKOUT: Rename and clean up the ParGCAllocBuffer class JDK-8077674 hotspot BSD build failures due to undefined macros JDK-8077315 hotspot Build failure on OSX after compiler upgrade JDK-8077420 hotspot Build failure with SS12u4 JDK-8076181 hotspot bytecodeInterpreter.cpp refers to unknown labels. JDK-8076987 hotspot C1 should support conditional card marks (UseCondCardMark) JDK-8073480 hotspot C2 should optimize explicit range checks JDK-8062280 hotspot C2: inlining failure due to access checks being too strict JDK-8057967 hotspot CallSite dependency tracking scales devastatingly poorly JDK-8078519 hotspot Can't run SA tools from a non-images build JDK-8076094 hotspot CheckCastPPNode::Value() has outdated logic for constants JDK-7127066 hotspot Class verifier accepts an invalid class file JDK-8076454 hotspot Clean up/move things out of SharedHeap JDK-8077417 hotspot Cleanup of Universe::initialize_heap() JDK-8016276 hotspot CMS concurrentMarkSweepGeneration contains lots of unnecessary allocat JDK-8076534 hotspot CollectedHeapName in SA agent incorrect JDK-8076450 hotspot com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java: assert(!o JDK-8075587 hotspot Compilation of constant array containing different sub classes crashes JDK-8078309 hotspot compiler/jsr292/MHInlineTest.java failed with java.lang.RuntimeExcepti JDK-8075663 hotspot compiler/rangechecks/TestExplicitRangeChecks.java fails in compiler ni JDK-8075488 hotspot compiler/whitebox/DeoptimizeFramesTest fails with exit code 1 due to u JDK-8073165 hotspot Contended Locking fast exit bucket JDK-8075324 hotspot Costs of memory operands in aarch64.ad are inconsistent JDK-8073989 hotspot Deprecated integer options are considered as invalid instead of deprec JDK-8074026 hotspot Deprecated UseBoundThreads, DefaultThreadPriority and NoYieldsInMicrol JDK-8079359 hotspot disable JDK-8061553 optimization while JDK-8077392 is resolved JDK-8069367 hotspot Eagerly reclaimed humongous objects left on mark stack JDK-8074345 hotspot Enable RewriteBytecodes when VM runs with CDS JDK-8075269 hotspot Extend -XX:CompileCommand=print,* to work for MethodHandle.invokeBasic JDK-8073866 hotspot Fix for 8064703 is not sufficient JDK-8076532 hotspot Fix format warning/error in methodHandles_ppc.cpp JDK-8078243 hotspot Fix include of stack.inline.hpp in taskqueue.hpp. JDK-8076457 hotspot Fix includes of inline.hpp in GC code JDK-8078048 hotspot Fix non-pch build after "8076457: Fix includes of inline.hpp in GC cod JDK-8076421 hotspot Fix Zero Interpreter bugs in class redefinition and template interpret JDK-8042891 hotspot Format issues embedded in macros for two g1 source files JDK-8078156 hotspot G1: Remove dead code PrintObjsInRegionClosure JDK-8077873 hotspot G1: Remove G1SATBPrintStubs JDK-8077841 hotspot G1: Remove PrintReachable support JDK-8071546 hotspot hotspot/test/compiler/codecache/jmx/PoolsIndependenceTest.java has bee JDK-8076625 hotspot IndexOutOfBoundsException in HeapByteBufferTest.java JDK-8074981 hotspot Integer/FP scalar reduction optimization JDK-8078017 hotspot Introduce hotspot_basicvmtest JDK-8076311 hotspot Java 9 process negative MaxTenuringThreshold in different way than Jav JDK-8074676 hotspot java.lang.invoke.PermuteArgsTest.java fails with "assert(is_Initialize JDK-8075331 hotspot jdb eval java.util.Arrays.asList(array) shows inconsistent behaviour JDK-8079248 hotspot JDK fails with "jdk\\bin\\management_ext.dll: The specified procedure JDK-8079507 hotspot jdk9: aarch64: fails to build after merge from hs-comp JDK-8077402 hotspot JMXStartStopTest fails intermittently on slow hosts JDK-8067648 hotspot JVM crashes reproducible with GCM cipher suites in GCTR doFinal JDK-8078666 hotspot JVM fastdebug build compiled with GCC 5 asserts with "widen increases" JDK-8075118 hotspot JVM stuck in infinite loop during verification JDK-8069004 hotspot Kitchensink hanged with 16Gb heap and GC pause >30 min JDK-8076492 hotspot Make common code from template interpreter code JDK-8074354 hotspot Make CreateMinidumpOnCrash a new name and available on all platforms JDK-8077836 hotspot Make sure G1ParGCAllocBuffer are marked as retired JDK-8043225 hotspot Make whitebox API functions more stable JDK-8078426 hotspot mb/jvm/compiler/InterfaceCalls/testAC2 - assert(predicate_proj == 0L) JDK-8074718 hotspot Merge templateTable_x86 _32 and _64 .hpp files JDK-8075263 hotspot MHI::checkCustomized isn't eliminated for inlined MethodHandles JDK-8076475 hotspot Misuses of strncpy/strncat JDK-8077265 hotspot Modify assert to help debug JDK-8068448 JDK-8073705 hotspot more performance issues in class redefinition JDK-8077618 hotspot Move rtmLocking.cpp to shared directory. JDK-8076289 hotspot Move the StrongRootsScope out of SharedHeap JDK-8068352 hotspot Move virtualspace.* out of src/share/vm/runtime to memory directory JDK-8069191 hotspot moving predicate out of loops may cause array accesses to bypass null JDK-8072128 hotspot mutexLocker.cpp _mutex_array[] initialization broken with safepoint ch JDK-8074548 hotspot Never-taken branches cause repeated deopts in MHs.GWT case JDK-8077308 hotspot OpenJDK 64-Bit Server VM warning: increase O_BUFLEN in ostream.hpp -- JDK-8077301 hotspot Optimized build is broken JDK-8074895 hotspot os::getenv is inadequate JDK-8076541 hotspot Parallel GC registers Java heap twice to NMT JDK-8078482 hotspot ppc: pass thread to throw_AbstractMethodError JDK-8076163 hotspot ppc: port "8074345: Enable RewriteBytecodes when VM runs with CDS" JDK-8075270 hotspot Print locals & stack slots location for PcDescs JDK-8076185 hotspot Provide SafeFetch implementation for zero JDK-8077414 hotspot PSPromotionLAB _state is unintialized JDK-8079231 hotspot quarantine compiler/jsr292/CallSiteDepContextTest.java JDK-8079235 hotspot quarantine TestLargePageUseForAuxMemory.java JDK-8077838 hotspot Recent developments for ppc. JDK-8077411 hotspot Remove CollectedHeap::supports_heap_inspection() JDK-8077415 hotspot Remove duplicate variables holding the CollectedHeap JDK-8077403 hotspot Remove guarantee from GenCollectedHeap::is_in() JDK-8076267 hotspot Remove n_gens() JDK-6983747 hotspot Remove obsolete dl_mutex lock JDK-8075216 hotspot Remove old flags, regarding to JDK9, from obsolete_jvm_flags JDK-8076452 hotspot Remove SharedHeap JDK-8076314 hotspot Remove the static instance variable SharedHeap:: _sh JDK-8077936 hotspot Remove the unused java_lang_invoke_CallSite::target_volatile JDK-8077938 hotspot Remove TraceMarkSweep JDK-8076456 hotspot Remove unnecessary oopDesc::klass() calls JDK-8076447 hotspot Remove unused MemoryManager::kind() JDK-8074546 hotspot Rename and clean up the ParGCAllocBuffer class JDK-8072863 hotspot Replace fatal() with vm_exit_during_initialization() when an incorrect JDK-8075955 hotspot Replace the macro based implementation of oop_oop_iterate with a templ JDK-8077832 hotspot SA's dumpreplaydata, dumpcfg and buildreplayjars are broken JDK-8078021 hotspot SATB apply_closure_to_completed_buffer should have closure argument JDK-8075466 hotspot SATB queue pre-filter verify found reclaimed humongous object JDK-8054890 hotspot Serviceability: New diagnostic commands 'VM.set_flag' and 'JVMTI.data_ JDK-8076344 hotspot serviceability/dcmd/vm/SetVMFlagTest.java test fails with "java.lang.E JDK-8044416 hotspot serviceability/sa/jmap-hashcode/Test8028623.java fails with AssertionF JDK-8075818 hotspot serviceability/threads/TestFalseDeadLock.java should be unquarantined JDK-8075266 hotspot Show runtime call details when printing machine code JDK-8075214 hotspot SIGSEGV in nmethod sweeping JDK-8076265 hotspot Simplify deal_with_reference JDK-8075140 hotspot Solaris build of native libraries not consistently using EXTRA_CFLAGS JDK-8058354 hotspot SPECjvm2008-Derby -2.7% performance regression on Solaris-X64 starting JDK-8077302 hotspot src/share/vm/oops/instanceRefKlass.inline.hpp has a double /* JDK-8005521 hotspot StressMethodComparator is not thread-safe JDK-8074860 hotspot Structured Exception Catcher missing around CreateJavaVM on Windows JDK-8076971 hotspot sun/management/jmxremote/startstop/JMXStatusTest.java failed with Asse JDK-8029630 hotspot Thread id should be displayed as hex number in error report JDK-8077255 hotspot TracePageSizes output reports wrong page size on Windows with G1 JDK-8077400 hotspot Unnecessary and incorrect "Code Cache Roots" G1 log entry JDK-8075136 hotspot Unnecessary sign extension for byte array access JDK-8068945 hotspot Use RBP register as proper frame pointer in JIT compiled code on x86 JDK-8068582 hotspot UseSerialGC not always set up properly JDK-8078023 hotspot verify_no_cset_oops found reclaimed humongous object in SATB buffer JDK-8078504 hotspot Zero fails to build JDK-8075967 hotspot Zero interpreter asserts for SafeFetch<32,N> calls in ObjectMonitor JDK-8075533 hotspot Zero JVM segfaults for -version after JDK-8074552 JDK-8079087 infrastructure Add support for Cygwin 2.0 JDK-8079344 infrastructure Allow custom or platform specific java source to automatically overrid JDK-8078058 infrastructure Clean up mac bundles logic JDK-8077992 infrastructure Eliminate JDK build dependency of native2ascii and update Japanese nro JDK-8077524 infrastructure Enable selective test bundle installation for jprt test targets JDK-8076060 infrastructure Improve make bootstrap process JDK-8075725 infrastructure Remove /jre subdir in hotspot dist dir JDK-8078046 infrastructure Remove MCS post-processing on Solaris JDK-8079075 other-libs some docs cleanup for CORBA - part 1 JDK-8079342 other-libs some docs cleanup for CORBA - part 2 JDK-8076486 security-libs [TESTBUG] javax/security/auth/Subject/doAs/NestedActions.java fails if JDK-8058543 security-libs Certificate returns null Subject Alternative Name if it is an X400Addr JDK-8078495 security-libs End time checking for native TGT is wrong JDK-8079129 security-libs NullPointerException in PKCS#12 Keystore in PKCS12KeyStore.java JDK-8079478 security-libs some docs cleanup for sun.security JDK-8078439 security-libs SPNEGO auth fails if client proposes MS krb5 OID JDK-8078592 tools Compiler fails to reject erroneous use of diamond with anonymous class JDK-8078473 tools javac diamond finder crashes when used to build java.base module JDK-8076279 tools Refactor Attr.check* methods to receive/handle a CheckMode enumeration JDK-8079335 tools The field Gen.stringBufferType is no longer needed (and not always ini JDK-8078225 tools tools/launcher/FXLauncherTest.java fails intermittently (win) From brett.bernstein at gmail.com Thu May 14 05:17:23 2015 From: brett.bernstein at gmail.com (Brett Bernstein) Date: Thu, 14 May 2015 01:17:23 -0400 Subject: PriorityQueue Message-ID: To whom this may concern: I believe the list of PriorityQueue constructors has a glaring omission that could be easily rectified. That is, there is no constructor that takes a Collection and a Comparator. What steps should I go through to get this suggested to be added to the class? Thanks, Brett Bernstein From benjamin.john.evans at gmail.com Thu May 14 05:36:02 2015 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Thu, 14 May 2015 14:36:02 +0900 Subject: PriorityQueue In-Reply-To: References: Message-ID: Hi Brett, The AdoptOpenJDK project is a good place for developers to start contributing. In general, a patch featuring working code & a signed OCA will go a long way towards getting your ideas listened to. I've copied in Martijn & Mani from Adopt - they should be able to help. Thanks, Ben On Thu, May 14, 2015 at 2:17 PM, Brett Bernstein wrote: > To whom this may concern: > I believe the list of PriorityQueue constructors has a glaring omission > that could be easily rectified. That is, there is no constructor that > takes a Collection and a Comparator. What steps should I go through to get > this suggested to be added to the class? > > Thanks, > Brett Bernstein From martinrb at google.com Thu May 14 06:08:18 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 13 May 2015 23:08:18 -0700 Subject: PriorityQueue In-Reply-To: References: Message-ID: Software is hard. We tried and got stuck, although the former effort can be revived. RFR : 6799426 : (xs) Add constructor PriorityQueue(Comparator) http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019124.html On Wed, May 13, 2015 at 10:17 PM, Brett Bernstein wrote: > To whom this may concern: > I believe the list of PriorityQueue constructors has a glaring omission > that could be easily rectified. That is, there is no constructor that > takes a Collection and a Comparator. What steps should I go through to get > this suggested to be added to the class? > > Thanks, > Brett Bernstein > From brett.bernstein at gmail.com Thu May 14 06:17:24 2015 From: brett.bernstein at gmail.com (Brett Bernstein) Date: Thu, 14 May 2015 02:17:24 -0400 Subject: PriorityQueue In-Reply-To: References: Message-ID: I believe the linked sequence of messages refer to the addition of a PriorityQueue constructor only taking a Comparator which was does appear in Java 1.8. Did you have a link to something regarding the a constructor taking a Collection and a Comparator (2 arguments)? On Thu, May 14, 2015 at 2:08 AM, Martin Buchholz wrote: > Software is hard. > We tried and got stuck, although the former effort can be revived. > RFR : 6799426 : (xs) Add constructor PriorityQueue(Comparator) > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019124.html > > > > On Wed, May 13, 2015 at 10:17 PM, Brett Bernstein < > brett.bernstein at gmail.com> wrote: > >> To whom this may concern: >> I believe the list of PriorityQueue constructors has a glaring omission >> that could be easily rectified. That is, there is no constructor that >> takes a Collection and a Comparator. What steps should I go through to >> get >> this suggested to be added to the class? >> >> Thanks, >> Brett Bernstein >> > > From martinrb at google.com Thu May 14 06:21:06 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 13 May 2015 23:21:06 -0700 Subject: PriorityQueue In-Reply-To: References: Message-ID: On Wed, May 13, 2015 at 11:17 PM, Brett Bernstein wrote: > I believe the linked sequence of messages refer to the addition of a > PriorityQueue constructor only taking a Comparator which was does appear in > Java 1.8. Did you have a link to something regarding the a constructor > taking a Collection and a Comparator (2 arguments)? > Oops - you are right... The one I referenced did get added, and your constructor is still missing. You may have trouble finding someone with the same enthusiasm for this constructor as yourself. From vitalyd at gmail.com Thu May 14 14:11:04 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 14 May 2015 10:11:04 -0400 Subject: PriorityQueue In-Reply-To: References: Message-ID: What would be the intrinsic advantage of such a constructor? Why not a simple static util method in your own code that emulates this? sent from my phone On May 14, 2015 1:17 AM, "Brett Bernstein" wrote: > To whom this may concern: > I believe the list of PriorityQueue constructors has a glaring omission > that could be easily rectified. That is, there is no constructor that > takes a Collection and a Comparator. What steps should I go through to get > this suggested to be added to the class? > > Thanks, > Brett Bernstein > From brett.bernstein at gmail.com Thu May 14 15:27:31 2015 From: brett.bernstein at gmail.com (Brett Bernstein) Date: Thu, 14 May 2015 11:27:31 -0400 Subject: PriorityQueue In-Reply-To: References: Message-ID: I may not understand what static method you are suggesting. If you have a collection containing data and you wish to make it into a PriorityQueue using a Comparator, there is no efficient method at the moment (addAll doesn't work). On Thu, May 14, 2015 at 10:11 AM, Vitaly Davidovich wrote: > What would be the intrinsic advantage of such a constructor? Why not a > simple static util method in your own code that emulates this? > > sent from my phone > On May 14, 2015 1:17 AM, "Brett Bernstein" > wrote: > >> To whom this may concern: >> I believe the list of PriorityQueue constructors has a glaring omission >> that could be easily rectified. That is, there is no constructor that >> takes a Collection and a Comparator. What steps should I go through to >> get >> this suggested to be added to the class? >> >> Thanks, >> Brett Bernstein >> > From vitalyd at gmail.com Thu May 14 15:35:47 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 14 May 2015 11:35:47 -0400 Subject: PriorityQueue In-Reply-To: References: Message-ID: What I mean is what could the PQ do more efficiently with your Collection vs you manually add()'ing each method? Are you looking to exploit the same behavior in its PriorityQueue(Collection), i.e. add and then heapify in bulk? initElementsFromCollection() doesn't seem all that efficient in the first place if one were to invoke this on fast paths. On Thu, May 14, 2015 at 11:27 AM, Brett Bernstein wrote: > I may not understand what static method you are suggesting. If you have a > collection containing data and you wish to make it into a PriorityQueue > using a Comparator, there is no efficient method at the moment (addAll > doesn't work). > > > On Thu, May 14, 2015 at 10:11 AM, Vitaly Davidovich > wrote: > >> What would be the intrinsic advantage of such a constructor? Why not a >> simple static util method in your own code that emulates this? >> >> sent from my phone >> On May 14, 2015 1:17 AM, "Brett Bernstein" >> wrote: >> >>> To whom this may concern: >>> I believe the list of PriorityQueue constructors has a glaring omission >>> that could be easily rectified. That is, there is no constructor that >>> takes a Collection and a Comparator. What steps should I go through to >>> get >>> this suggested to be added to the class? >>> >>> Thanks, >>> Brett Bernstein >>> >> > From brett.bernstein at gmail.com Thu May 14 15:52:34 2015 From: brett.bernstein at gmail.com (Brett Bernstein) Date: Thu, 14 May 2015 11:52:34 -0400 Subject: PriorityQueue In-Reply-To: References: Message-ID: My motivation is essentially what you stated. If someone needs to make a heap and their data is Comparable, the corresponding constructor gives a O(n) runtime. If their data uses a Comparator, the corresponding runtime (using addAll) is O(n*log(n)). It is true they will need to copy the data into an array to use it (as initElementsFromCollection does), but that is unavoidable. On Thu, May 14, 2015 at 11:35 AM, Vitaly Davidovich wrote: > What I mean is what could the PQ do more efficiently with your Collection > vs you manually add()'ing each method? Are you looking to exploit the same > behavior in its PriorityQueue(Collection), i.e. add and then heapify in > bulk? initElementsFromCollection() doesn't seem all that efficient in the > first place if one were to invoke this on fast paths. > > On Thu, May 14, 2015 at 11:27 AM, Brett Bernstein < > brett.bernstein at gmail.com> wrote: > >> I may not understand what static method you are suggesting. If you have >> a collection containing data and you wish to make it into a PriorityQueue >> using a Comparator, there is no efficient method at the moment (addAll >> doesn't work). >> >> >> On Thu, May 14, 2015 at 10:11 AM, Vitaly Davidovich >> wrote: >> >>> What would be the intrinsic advantage of such a constructor? Why not a >>> simple static util method in your own code that emulates this? >>> >>> sent from my phone >>> On May 14, 2015 1:17 AM, "Brett Bernstein" >>> wrote: >>> >>>> To whom this may concern: >>>> I believe the list of PriorityQueue constructors has a glaring omission >>>> that could be easily rectified. That is, there is no constructor that >>>> takes a Collection and a Comparator. What steps should I go through to >>>> get >>>> this suggested to be added to the class? >>>> >>>> Thanks, >>>> Brett Bernstein >>>> >>> >> > From benjamin.john.evans at gmail.com Thu May 14 16:01:53 2015 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Fri, 15 May 2015 01:01:53 +0900 Subject: PriorityQueue In-Reply-To: References: Message-ID: That sounds entirely plausible & will be of interest. Do you have a patch the community can review & contribute to? Thanks, Ben On Fri, May 15, 2015 at 12:52 AM, Brett Bernstein wrote: > My motivation is essentially what you stated. If someone needs to make a > heap and their data is Comparable, the corresponding constructor gives a > O(n) runtime. If their data uses a Comparator, the corresponding runtime > (using addAll) is O(n*log(n)). It is true they will need to copy the data > into an array to use it (as initElementsFromCollection does), but that is > unavoidable. > > On Thu, May 14, 2015 at 11:35 AM, Vitaly Davidovich > wrote: > >> What I mean is what could the PQ do more efficiently with your Collection >> vs you manually add()'ing each method? Are you looking to exploit the same >> behavior in its PriorityQueue(Collection), i.e. add and then heapify in >> bulk? initElementsFromCollection() doesn't seem all that efficient in the >> first place if one were to invoke this on fast paths. >> >> On Thu, May 14, 2015 at 11:27 AM, Brett Bernstein < >> brett.bernstein at gmail.com> wrote: >> >>> I may not understand what static method you are suggesting. If you have >>> a collection containing data and you wish to make it into a PriorityQueue >>> using a Comparator, there is no efficient method at the moment (addAll >>> doesn't work). >>> >>> >>> On Thu, May 14, 2015 at 10:11 AM, Vitaly Davidovich >>> wrote: >>> >>>> What would be the intrinsic advantage of such a constructor? Why not a >>>> simple static util method in your own code that emulates this? >>>> >>>> sent from my phone >>>> On May 14, 2015 1:17 AM, "Brett Bernstein" >>>> wrote: >>>> >>>>> To whom this may concern: >>>>> I believe the list of PriorityQueue constructors has a glaring omission >>>>> that could be easily rectified. That is, there is no constructor that >>>>> takes a Collection and a Comparator. What steps should I go through to >>>>> get >>>>> this suggested to be added to the class? >>>>> >>>>> Thanks, >>>>> Brett Bernstein >>>>> >>>> >>> >> From vitalyd at gmail.com Thu May 14 16:06:14 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 14 May 2015 12:06:14 -0400 Subject: PriorityQueue In-Reply-To: References: Message-ID: Ok, understood. Given PQ already works with Collection, this seems like it should be trivial to add. In fact, the constructor taking a SortedSet seems superfluous since it's just using that interface to grab the comparator; indeed, a bit puzzling why a (Collection, Comparator) ctor wasn't there to begin with as it's more to the point. On Thu, May 14, 2015 at 11:52 AM, Brett Bernstein wrote: > My motivation is essentially what you stated. If someone needs to make a > heap and their data is Comparable, the corresponding constructor gives a > O(n) runtime. If their data uses a Comparator, the corresponding runtime > (using addAll) is O(n*log(n)). It is true they will need to copy the data > into an array to use it (as initElementsFromCollection does), but that is > unavoidable. > > On Thu, May 14, 2015 at 11:35 AM, Vitaly Davidovich > wrote: > >> What I mean is what could the PQ do more efficiently with your Collection >> vs you manually add()'ing each method? Are you looking to exploit the same >> behavior in its PriorityQueue(Collection), i.e. add and then heapify in >> bulk? initElementsFromCollection() doesn't seem all that efficient in the >> first place if one were to invoke this on fast paths. >> >> On Thu, May 14, 2015 at 11:27 AM, Brett Bernstein < >> brett.bernstein at gmail.com> wrote: >> >>> I may not understand what static method you are suggesting. If you have >>> a collection containing data and you wish to make it into a PriorityQueue >>> using a Comparator, there is no efficient method at the moment (addAll >>> doesn't work). >>> >>> >>> On Thu, May 14, 2015 at 10:11 AM, Vitaly Davidovich >>> wrote: >>> >>>> What would be the intrinsic advantage of such a constructor? Why not a >>>> simple static util method in your own code that emulates this? >>>> >>>> sent from my phone >>>> On May 14, 2015 1:17 AM, "Brett Bernstein" >>>> wrote: >>>> >>>>> To whom this may concern: >>>>> I believe the list of PriorityQueue constructors has a glaring omission >>>>> that could be easily rectified. That is, there is no constructor that >>>>> takes a Collection and a Comparator. What steps should I go through >>>>> to get >>>>> this suggested to be added to the class? >>>>> >>>>> Thanks, >>>>> Brett Bernstein >>>>> >>>> >>> >> > From brett.bernstein at gmail.com Thu May 14 16:49:24 2015 From: brett.bernstein at gmail.com (Brett Bernstein) Date: Thu, 14 May 2015 12:49:24 -0400 Subject: PriorityQueue In-Reply-To: References: Message-ID: Thank you for the encouragement. I wanted to make sure I wasn't missing something silly before learning how the submission process works, how to build the JDK on my machine, signed agreements, etc. I will hopefully be able to start down that road soon assuming my schedule accomodates. -Brett On Thu, May 14, 2015 at 12:01 PM, Ben Evans wrote: > That sounds entirely plausible & will be of interest. > > Do you have a patch the community can review & contribute to? > > Thanks, > > Ben > > > On Fri, May 15, 2015 at 12:52 AM, Brett Bernstein > wrote: > > My motivation is essentially what you stated. If someone needs to make a > > heap and their data is Comparable, the corresponding constructor gives a > > O(n) runtime. If their data uses a Comparator, the corresponding runtime > > (using addAll) is O(n*log(n)). It is true they will need to copy the > data > > into an array to use it (as initElementsFromCollection does), but that is > > unavoidable. > > > > On Thu, May 14, 2015 at 11:35 AM, Vitaly Davidovich > > wrote: > > > >> What I mean is what could the PQ do more efficiently with your > Collection > >> vs you manually add()'ing each method? Are you looking to exploit the > same > >> behavior in its PriorityQueue(Collection), i.e. add and then heapify in > >> bulk? initElementsFromCollection() doesn't seem all that efficient in > the > >> first place if one were to invoke this on fast paths. > >> > >> On Thu, May 14, 2015 at 11:27 AM, Brett Bernstein < > >> brett.bernstein at gmail.com> wrote: > >> > >>> I may not understand what static method you are suggesting. If you > have > >>> a collection containing data and you wish to make it into a > PriorityQueue > >>> using a Comparator, there is no efficient method at the moment (addAll > >>> doesn't work). > >>> > >>> > >>> On Thu, May 14, 2015 at 10:11 AM, Vitaly Davidovich > > >>> wrote: > >>> > >>>> What would be the intrinsic advantage of such a constructor? Why not a > >>>> simple static util method in your own code that emulates this? > >>>> > >>>> sent from my phone > >>>> On May 14, 2015 1:17 AM, "Brett Bernstein" > > >>>> wrote: > >>>> > >>>>> To whom this may concern: > >>>>> I believe the list of PriorityQueue constructors has a glaring > omission > >>>>> that could be easily rectified. That is, there is no constructor > that > >>>>> takes a Collection and a Comparator. What steps should I go through > to > >>>>> get > >>>>> this suggested to be added to the class? > >>>>> > >>>>> Thanks, > >>>>> Brett Bernstein > >>>>> > >>>> > >>> > >> > From martijnverburg at gmail.com Thu May 14 18:11:14 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 14 May 2015 19:11:14 +0100 Subject: PriorityQueue In-Reply-To: References: Message-ID: Hi Brett, You can ask over at adoption-discuss about process, build etc. It is the case at times where doing the work to produce a patch is just a starting point for a discussion (it can be easier to discuss concrete code rather than abstract ideas). One of the key things would be to have one of the core committers of jdk9 and/or core-libs respond on this thread as well (see jdk9 & core-libs membership at http://openjdk.java.net/census#members). Also I'd search the archives for any previous discussions on this topic (possibly under core-libs as well). Cheers, Martijn On 14 May 2015 at 17:49, Brett Bernstein wrote: > Thank you for the encouragement. I wanted to make sure I wasn't missing > something silly before learning how the submission process works, how to > build the JDK on my machine, signed agreements, etc. I will hopefully be > able to start down that road soon assuming my schedule accomodates. > > -Brett > > On Thu, May 14, 2015 at 12:01 PM, Ben Evans > > wrote: > > > That sounds entirely plausible & will be of interest. > > > > Do you have a patch the community can review & contribute to? > > > > Thanks, > > > > Ben > > > > > > On Fri, May 15, 2015 at 12:52 AM, Brett Bernstein > > wrote: > > > My motivation is essentially what you stated. If someone needs to > make a > > > heap and their data is Comparable, the corresponding constructor gives > a > > > O(n) runtime. If their data uses a Comparator, the corresponding > runtime > > > (using addAll) is O(n*log(n)). It is true they will need to copy the > > data > > > into an array to use it (as initElementsFromCollection does), but that > is > > > unavoidable. > > > > > > On Thu, May 14, 2015 at 11:35 AM, Vitaly Davidovich > > > > wrote: > > > > > >> What I mean is what could the PQ do more efficiently with your > > Collection > > >> vs you manually add()'ing each method? Are you looking to exploit the > > same > > >> behavior in its PriorityQueue(Collection), i.e. add and then heapify > in > > >> bulk? initElementsFromCollection() doesn't seem all that efficient in > > the > > >> first place if one were to invoke this on fast paths. > > >> > > >> On Thu, May 14, 2015 at 11:27 AM, Brett Bernstein < > > >> brett.bernstein at gmail.com> wrote: > > >> > > >>> I may not understand what static method you are suggesting. If you > > have > > >>> a collection containing data and you wish to make it into a > > PriorityQueue > > >>> using a Comparator, there is no efficient method at the moment > (addAll > > >>> doesn't work). > > >>> > > >>> > > >>> On Thu, May 14, 2015 at 10:11 AM, Vitaly Davidovich < > vitalyd at gmail.com > > > > > >>> wrote: > > >>> > > >>>> What would be the intrinsic advantage of such a constructor? Why > not a > > >>>> simple static util method in your own code that emulates this? > > >>>> > > >>>> sent from my phone > > >>>> On May 14, 2015 1:17 AM, "Brett Bernstein" < > brett.bernstein at gmail.com > > > > > >>>> wrote: > > >>>> > > >>>>> To whom this may concern: > > >>>>> I believe the list of PriorityQueue constructors has a glaring > > omission > > >>>>> that could be easily rectified. That is, there is no constructor > > that > > >>>>> takes a Collection and a Comparator. What steps should I go > through > > to > > >>>>> get > > >>>>> this suggested to be added to the class? > > >>>>> > > >>>>> Thanks, > > >>>>> Brett Bernstein > > >>>>> > > >>>> > > >>> > > >> > > > From sadhak001 at gmail.com Thu May 14 19:05:02 2015 From: sadhak001 at gmail.com (Mani Sarkar) Date: Thu, 14 May 2015 20:05:02 +0100 Subject: PriorityQueue In-Reply-To: References: Message-ID: Thanks Ben. @Brett, your starting point to anything OpenJDK is our homepage - https://java.net/projects/adoptopenjdk/ (also check out the Wiki), and in parallel I also recommend having a look at community contributed gitbook at http://neomatrix369.gitbooks.io/adoptopenjdk-getting-started-kit/ I hope this helps with you on your queries. Feel free to write back to us with more queries, as Ben and Martijn pointed out adoption-discuss at openjdk.java.net ( http://mail.openjdk.java.net/mailman/listinfo/adoption-discuss) is a good place to start such discussions. Cheers, Mani On Thu, May 14, 2015 at 6:36 AM, Ben Evans wrote: > Hi Brett, > > The AdoptOpenJDK project is a good place for developers to start > contributing. > > In general, a patch featuring working code & a signed OCA will go a > long way towards getting your ideas listened to. > > I've copied in Martijn & Mani from Adopt - they should be able to help. > > Thanks, > > Ben > > On Thu, May 14, 2015 at 2:17 PM, Brett Bernstein > wrote: > > To whom this may concern: > > I believe the list of PriorityQueue constructors has a glaring omission > > that could be easily rectified. That is, there is no constructor that > > takes a Collection and a Comparator. What steps should I go through to > get > > this suggested to be added to the class? > > > > Thanks, > > Brett Bernstein > -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From mark.reinhold at oracle.com Thu May 14 20:56:58 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 14 May 2015 13:56:58 -0700 Subject: JEP proposed to target JDK 9 (2015/5/14) Message-ID: <20150514135658.136505@eggemoggin.niobe.net> The following JEP has been placed into the "Proposed to Target" state by its owner after discussion and review: 247: Compile for Older Platform Versions http://openjdk.java.net/jeps/247 Feedback on this proposal is more than welcome, as are reasoned objections. If no such objections are raised by 22:00 UTC next Thursday, 21 May, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target these JEPs to JDK 9. (This information is also available on the JDK 9 Project Page [2]). - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html[2] [2] http://openjdk.java.net/projects/jdk9/[3] From alexander.potochkin at oracle.com Fri May 15 11:33:23 2015 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Fri, 15 May 2015 14:33:23 +0300 Subject: Result: New JDK 9 Committer: Alexey Ivanov Message-ID: <5555D983.3040609@oracle.com> Voting for Alexey Ivanov [1] is now closed. Yes: 13 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Thanks alexp [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-April/002138.html From stuart.marks at oracle.com Fri May 15 17:18:46 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 15 May 2015 10:18:46 -0700 Subject: PriorityQueue In-Reply-To: References: Message-ID: <55562A76.6070501@oracle.com> Hi Martijn/Ben/Mani, Thanks for volunteering to help out Brett via the AdoptOpenJDK effort. Hi Brett, Thanks for picking this up. This is indeed an omission in the JDK and it would definitely be an improvement if this were added. Also note this has gotten a bit confusing, as there is a parallel thread on core-libs-dev at openjdk.java.net. I'd suggest that further discussion take place there. (Setting Reply-To on this message; we'll see if that has any effect.) Thanks. s'marks On 5/14/15 11:11 AM, Martijn Verburg wrote: > Hi Brett, > > You can ask over at adoption-discuss about process, build etc. It is the > case at times where doing the work to produce a patch is just a starting > point for a discussion (it can be easier to discuss concrete code rather > than abstract ideas). One of the key things would be to have one of the > core committers of jdk9 and/or core-libs respond on this thread as well > (see jdk9 & core-libs membership at http://openjdk.java.net/census#members). > Also I'd search the archives for any previous discussions on this topic > (possibly under core-libs as well). > > Cheers, > Martijn > > On 14 May 2015 at 17:49, Brett Bernstein wrote: > >> Thank you for the encouragement. I wanted to make sure I wasn't missing >> something silly before learning how the submission process works, how to >> build the JDK on my machine, signed agreements, etc. I will hopefully be >> able to start down that road soon assuming my schedule accomodates. >> >> -Brett >> >> On Thu, May 14, 2015 at 12:01 PM, Ben Evans >> >> wrote: >> >>> That sounds entirely plausible & will be of interest. >>> >>> Do you have a patch the community can review & contribute to? >>> >>> Thanks, >>> >>> Ben >>> >>> >>> On Fri, May 15, 2015 at 12:52 AM, Brett Bernstein >>> wrote: >>>> My motivation is essentially what you stated. If someone needs to >> make a >>>> heap and their data is Comparable, the corresponding constructor gives >> a >>>> O(n) runtime. If their data uses a Comparator, the corresponding >> runtime >>>> (using addAll) is O(n*log(n)). It is true they will need to copy the >>> data >>>> into an array to use it (as initElementsFromCollection does), but that >> is >>>> unavoidable. >>>> >>>> On Thu, May 14, 2015 at 11:35 AM, Vitaly Davidovich >> >>>> wrote: >>>> >>>>> What I mean is what could the PQ do more efficiently with your >>> Collection >>>>> vs you manually add()'ing each method? Are you looking to exploit the >>> same >>>>> behavior in its PriorityQueue(Collection), i.e. add and then heapify >> in >>>>> bulk? initElementsFromCollection() doesn't seem all that efficient in >>> the >>>>> first place if one were to invoke this on fast paths. >>>>> >>>>> On Thu, May 14, 2015 at 11:27 AM, Brett Bernstein < >>>>> brett.bernstein at gmail.com> wrote: >>>>> >>>>>> I may not understand what static method you are suggesting. If you >>> have >>>>>> a collection containing data and you wish to make it into a >>> PriorityQueue >>>>>> using a Comparator, there is no efficient method at the moment >> (addAll >>>>>> doesn't work). >>>>>> >>>>>> >>>>>> On Thu, May 14, 2015 at 10:11 AM, Vitaly Davidovich < >> vitalyd at gmail.com >>>> >>>>>> wrote: >>>>>> >>>>>>> What would be the intrinsic advantage of such a constructor? Why >> not a >>>>>>> simple static util method in your own code that emulates this? >>>>>>> >>>>>>> sent from my phone >>>>>>> On May 14, 2015 1:17 AM, "Brett Bernstein" < >> brett.bernstein at gmail.com >>>> >>>>>>> wrote: >>>>>>> >>>>>>>> To whom this may concern: >>>>>>>> I believe the list of PriorityQueue constructors has a glaring >>> omission >>>>>>>> that could be easily rectified. That is, there is no constructor >>> that >>>>>>>> takes a Collection and a Comparator. What steps should I go >> through >>> to >>>>>>>> get >>>>>>>> this suggested to be added to the class? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Brett Bernstein >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> From alejandro.murillo at oracle.com Tue May 19 18:58:38 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 19 May 2015 12:58:38 -0600 Subject: jdk9-dev: HotSpot Message-ID: <555B87DE.10002@oracle.com> jdk9-hs-2015-05-14 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/aa82f2db653e http://hg.openjdk.java.net/jdk9/dev/corba/rev/afc1e295c4bf http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/9dc9bcc49745 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/c35e3ab989a1 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/45ef73bb85c1 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c34ff3aa7624 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6bc40a5172e8 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/71d7a37e6dfb omponent : VM Status : Go for integration Date : 05/19/2015 at 21:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : jprt job id: 2015-05-14-190907.amurillo.jdk9-hs-2015-05-14-snapshot Testing: 686 new failures, 2289, known failures, 404255 passed. Issues and Notes: One critical issue has been caught by testing: https://bugs.openjdk.java.net/browse/JDK-8080692 But we hope it's not a stopper for integration. So, please go ahead and integrate the changes. Analysis of failures is still in progress, so perhaps new bugs will be submitted soon. CRs for testing: 6407976: GC worker number should be unsigned 6755586: Test com/sun/jdi/NoLaunchOptionTest.java may erroneously fail 7006810: G1: Introduce peace-of-mind checking in the Suspendible Thread Set 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index 8030680: 292 cleanup from default method code assessment 8031401: Remove unused code in the reference processor 8059047: Extract parser/validator from jhat for use in tests 8064458: OopMap class could be more compact 8067013: Rename the com.oracle.java.testlibary package 8069005: Hotspot crashes in System.out.println with assert(resolved_method->method_holder()->is_linked()) failed: must be linked 8071462: Remove G1ParGCAllocator::alloc_buffer_waste 8072906: sun/management/jmxremote/bootstrap/CustomLauncherTest.java failing on embedded platform 8073204: Determining the desired PLAB size adjusts to the the number of threads at the wrong place 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans 8073632: Make auxiliary data structures know their own translation factor 8073669: gc/TestSoftReferencesBehaviorOnOOME.java times out in nightlies 8074016: Add convenient way of adding custom test targets to hotspot's test makefile 8075215: SATB buffer processing found reclaimed humongous object 8075492: adopt recent IGV 8075966: Update ProjectCreator to create projects using Visual Studio 2013 toolset 8076177: Remove usage of stack.inline.hpp functions from taskqueue.hpp 8076188: Optimize arraycopy out for non escaping destination 8076276: Add support for AVX512 8076284: Improve vectorization of parallel streams 8076318: split verifier needs to add TraceClassResolution 8076473: Remove the jhat code and update makefiles 8076524: Remove jhat tests and help library from JDK 8076542: G1 does not print heap page size information with -XX:+TracePageSizes 8076579: Popping a stack frame after exception breakpoint sets last method param to exception 8076995: gc/ergonomics/TestDynamicNumberOfGCThreads.java failed with java.lang.RuntimeException: 'new_active_workers' missing from stdout/stderr 8076998: BadHandshakeTest.java fails due to warnings in output 8077276: allocating heap with UseLargePages and HugeTLBFS may trash existing memory mappings (linux) 8077529: [TESTBUG] Remove hotspot.internalvmtests from jprt config 8077743: (rm) Port ResourceManagement to JDK9 8078121: Add 'CreateMinidumpOnCrash' (JDK-8074354) caused many tests failed in nightly testing 8078340: Remove the unused PSParallelCompact::KeepAliveClosure 8078341: Remove the unused PSParallelCompact::_updated_int_array_klass_obj 8078345: Move PSParallelCompact::mark_and_push to ParCompactionManager 8078405: Heap decommit failed in TestShrinkAuxiliaryData tests 8078436: java/util/stream/boottest/java/util/stream/UnorderedTest.java crashed with an assert in ifnode.cpp 8078497: C2's superword optimization causes unaligned memory accesses 8078558: [TESTBUG] Merge hotspot_wbapitest with existing jtreg jprt job 8078563: Restrict reduction optimization 8078593: [TESTBUG] ppc: Enable jtreg tests for new features 8078601: print_concurrent_locks should be guarded with INCLUDE_SERVICES 8078613: HAS_BEEN_MOVED has been moved 8078628: linux-zero does not build without precompiled header 8078897: Clean out unused code in G1MMUTracker 8079080: ConcurrentMark::mark_stack_push(oop) is unused 8079091: Remove dictionary NULL check on common path of BlockFreeList methods 8079112: [TESTBUG] hotspot_jprt group in TEST.groups refers to non-existent groups 8079120: serviceability/dcmd/gc/HeapDumpAllTest.java: compilation failed 8079148: Fix incorrect include guards 8079200: Fix heapdump tests to validate heapdump after jhat is removed 8079263: Suppress warning about disabling adaptive size policy when enabling UseLargePages with UseNUMA when adaptive size policy is disabled 8079275: Remove CollectedHeap::use_parallel_gc_threads 8079280: Fix format warning/error in vm_version_ppc.cpp 8079330: Circular dependency between G1CollectedHeap and G1BlockOffsetSharedArray 8079337: Format string issues in workgroup.cpp and taskqueue.cpp 8079343: Crash in PhaseIdealLoop with "assert(!had_error) failed: bad dominance" 8079345: After 8079248 fixed JDK still fails with "jdk\\bin\\management_ext.dll: The specified procedure could not be found" 8079360: AttachProviderImpl could not be instantiated 8079545: [TESTBUG] hotspot_basicvmtest doesn't fail even if VM crashes 8079556: BACKOUT - Determining the desired PLAB size adjusts to the the number of threads at the wrong place 8079559: Exclude demo/jvmti/hprof tests 8079561: Add a method to convert counters to milliseconds 8079579: Add SuspendibleThreadSetLeaver and make SuspendibleThreadSet::joint()/leave() private 8079797: assert(index >= 0 && index < _count) failed: check 8079840: G1StringDedupTable::deduplicate() reset String hash value unnecessarily. 8080048: Test jdk/test/com/sun/jdi/NoLaunchOptionTest.java was merged incorrectly 8080100: compiler/rtm/* tests fail due to Compilation failed 8080155: field "_pc_offset" not found in type ImmutableOopMapSet 8080420: Compilation of TestVectorizationWithInvariant fails with "error: package com.oracle.java.testlibrary does not exist" -- Alejandro From lana.steuck at oracle.com Wed May 20 16:48:29 2015 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 20 May 2015 09:48:29 -0700 (PDT) Subject: jdk9-b65: dev Message-ID: <201505201648.t4KGmT3d004188@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/7c31f9d7b932 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/2054d01ae326 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/4fcf722b8114 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ed94f3e7ba6b http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/45ef73bb85c1 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/ae7406e82828 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e7ae94c4f35e http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/afc1e295c4bf --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8077014 install [8u60 b10 PIT] Uninstall JRE have issues when both 32bit and 64bit JREs JDK-7145508 client-libs [embedded] java.awt.GraphicsDevice.get/setDisplayMode behavior is inco JDK-8076106 client-libs [macosx] Drag image of TransferHandler does not honor MultiResolutionI JDK-8076264 client-libs [macosx] Launching app on MacOSX requires enclosing class JDK-8078165 client-libs [macosx] NPE when attempting to get image from toolkit JDK-8078082 client-libs [TEST_BUG] java/awt/SplashScreen/MultiResolutionSplash/MultiResolution JDK-8079428 client-libs [TEST_BUG] Test javax/swing/plaf/windows/6921687/bug6921687.java fails JDK-8076151 client-libs [TESTBUG] Test java/awt/FontClass/CreateFont/fileaccess/FontFile.java JDK-8075942 client-libs ArrayIndexOutOfBoundsException at sun.java2d.pisces.Dasher.goTo(Dasher JDK-8074956 client-libs ArrayIndexOutOfBoundsException in javax.swing.text.html.parser.Conten JDK-8078654 client-libs CloseTTFontFileFunc callback should be removed JDK-8072767 client-libs DefaultCellEditor for comboBox creates ActionEvent with wrong source o JDK-8080317 client-libs Disable warning treated as error for signed/unsigned comparison in bui JDK-8035302 client-libs Eliminate dependency on jdk.charsets from 2D font code. JDK-8076422 client-libs Fix missing doclint warnings in javax.swing.border JDK-8076624 client-libs Fix missing doclint warnings in javax.swing.text JDK-8075082 client-libs Fix missing doclint warnings in the javax.swing package JDK-8077094 client-libs Fix missing doclint warnings in the javax.swing.plaf package JDK-8077095 client-libs Fix missing doclint warnings in the javax.swing.plaf.basic package JDK-8073453 client-libs Focus doesn't move when pressing Shift + Tab keys JDK-8051617 client-libs Fullscreen mode is not working properly on Xorg JDK-8077982 client-libs GIFLIB upgrade JDK-8076455 client-libs IME Composition Window is displayed on incorrect position JDK-6866751 client-libs J2SE_Swing_Reg: the caret disappears when moving to the end of the lin JDK-4703110 client-libs java.awt.Canvas(GraphicaConfiguration): null reaction JDK-8073001 client-libs Java's system LnF on OS X: editable JComboBoxes are being rendered in JDK-8030123 client-libs java/beans/Introspector/Test8027648.java fails JDK-8076315 client-libs move 4 manual functional swing tests to regression suite JDK-8079067 client-libs New version string scheme - Java2D JDK-8078464 client-libs Path2D storage growth algorithms should be less linear JDK-6829245 client-libs Reg test: java/awt/Component/isLightweightCrash/StubPeerCrash.java fai JDK-8074763 client-libs Remove API references to java.awt.dnd.peer JDK-8074028 client-libs Remove API references to java.awt.peer JDK-8074757 client-libs Remove java.awt.Toolkit methods which return peer types JDK-8031109 client-libs Rendering HTML code in JEditorPane throws NumberFormatException JDK-7081580 client-libs Specification for MouseInfo.getNumberOfButtons() doesn't contain info JDK-8069361 client-libs SunGraphics2D.getDefaultTransform() does not include scale factor JDK-8064939 client-libs SwingSet2: Themes are incorrectly enabled when running with Nimbus Loo JDK-8044444 client-libs The output's 'Page-n' footer does not show completely. JDK-6206437 client-libs Typo in JInternalFrame setDefaultCloseOperation() doc (WindowClosing - JDK-8078331 client-libs Upgrade JDK to use LittleCMS 2.7 JDK-8078614 client-libs WindowsClassicLookAndFeel : MetalComboBoxUI.getbaseLine fails with Ill JDK-8077518 client-libs XMLParserTest unit test failure. JDK-8080090 core-libs -d option should dump script source as well JDK-8080330 core-libs (cs) Charset.availableCharsets failing with NPE on several platforms JDK-8079651 core-libs (dc) Promiscuous.java fails with NumberFormatException due to network JDK-8029689 core-libs (spec) Reader.read(char[], int, int) throws unspecified IndexOutOfBoun JDK-8080182 core-libs Array.prototype.sort throws IAE on inconsistent comparison JDK-8079841 core-libs Buffer underflow with empty zip entry names JDK-8080042 core-libs can't build nashorn.jar from jdk9-dev/nashorn using jdk8 installation JDK-8067931 core-libs Improve error message when with statement is passed a POJO JDK-8079773 core-libs java/util/logging/LogManager/TestLoggerNames.java JDK-8079900 core-libs javadoc is missing for jdk.nashorn.api.tree package JDK-8053918 core-libs make the spec for @Documented comprehensible JDK-8080295 core-libs Need to adjust test output for 8067931 JDK-8079782 core-libs RandomFactory should be in the jdk.testlibrary package JDK-8078645 core-libs removeIf(filter) in ConcurrentHashMap removes entries for which filter JDK-8078463 core-libs TEST_BUG: optimize java/util/Map/Collisions.java JDK-8080286 core-libs use path separator setting consistently in Nashorn project properties JDK-8042632 deploy Application with Signed JNLP cannot pass accented characters in regis JDK-8078210 install Eliminate MacOSX install build dependency on native2ascii JDK-8038084 security-libs CertStore needs a way to add new CertStore types JDK-8075706 security-libs Policy implementation does not allow policy.provider to be on the clas JDK-8068180 security-libs sun/security/pkcs11 tests are still in ProblemList.txt JDK-6470634 security-libs Typos in CardTerminals.list(CardTerminals.State) javadoc JDK-8034820 security-libs Wrong isAssignableFrom test when adding Principal to Subject JDK-8062518 xml AIOBE occurs when accessing to document function in extended function From mark.reinhold at oracle.com Thu May 21 22:03:24 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 21 May 2015 15:03:24 -0700 Subject: JEP proposed to target JDK 9 (2015/5/8) In-Reply-To: <20150508160507.367489@eggemoggin.niobe.net> References: <20150508160507.367489@eggemoggin.niobe.net> Message-ID: <20150521150324.795083@eggemoggin.niobe.net> 2015/5/8 4:05 -0700, mark.reinhold at oracle.com: > The following JEP has been placed into the "Proposed to Target" > state by its owner after discussion and review: > > 222: jshell: The Java Shell (Read-Eval-Print Loop) > http://openjdk.java.net/jeps/222 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 23:30 UTC next > Friday, 15 May, or if they're raised and then satisfactorily > answered, then per the JEP 2.0 process proposal [1] I'll target > these JEPs to JDK 9. Hearing no objections, I've targeted this JEP to JDK 9. - Mark From mark.reinhold at oracle.com Thu May 21 22:03:27 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 21 May 2015 15:03:27 -0700 Subject: JEP proposed to target JDK 9 (2015/5/14) In-Reply-To: <20150514135658.136505@eggemoggin.niobe.net> References: <20150514135658.136505@eggemoggin.niobe.net> Message-ID: <20150521150327.916028@eggemoggin.niobe.net> 2015/5/14 1:56 -0700, mark.reinhold at oracle.com: > The following JEP has been placed into the "Proposed to Target" > state by its owner after discussion and review: > > 247: Compile for Older Platform Versions > http://openjdk.java.net/jeps/247 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 22:00 UTC next > Thursday, 21 May, or if they're raised and then satisfactorily > answered, then per the JEP 2.0 process proposal [1] I'll target > these JEPs to JDK 9. Hearing no objections, I've targeted this JEP to JDK 9. - Mark From mark.reinhold at oracle.com Thu May 21 22:05:33 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 21 May 2015 15:05:33 -0700 Subject: JEPs proposed to target JDK 9 (2015/5/21) Message-ID: <20150521150533.791873@eggemoggin.niobe.net> The following JEPs have been placed into the "Proposed to Target" state by their owners after discussion and review: 233: Generate Run-Time Compiler Tests Automatically http://openjdk.java.net/jeps/233 246: Leverage CPU Instructions for GHASH and RSA http://openjdk.java.net/jeps/246 248: Make G1 the Default Garbage Collector http://openjdk.java.net/jeps/248 249: OCSP Stapling for TLS http://openjdk.java.net/jeps/249 250: Store Interned Strings in CDS Archives http://openjdk.java.net/jeps/250 252: Use CLDR Locale Data by Default http://openjdk.java.net/jeps/252 Feedback on these proposals is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC next Thursday, 28 May, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target these JEPs to JDK 9. (This information is also available on the JDK 9 Project Page [2]). - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html [2] http://openjdk.java.net/projects/jdk9/ From benjamin.john.evans at gmail.com Fri May 22 00:15:40 2015 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Fri, 22 May 2015 09:15:40 +0900 Subject: JEPs proposed to target JDK 9 (2015/5/21) In-Reply-To: <20150521150533.791873@eggemoggin.niobe.net> References: <20150521150533.791873@eggemoggin.niobe.net> Message-ID: Hi Mark, I've mostly been very pleased with the JEPs targeted at JDK 9. However, I have to object to: 248: Make G1 the Default Garbage Collector My reasoning is as follows: I have been working with G1 for ~5 years, ever since it was experimental (& highly crash-prone in JDK 6). In the intervening time, I have seen dozens (if not hundreds) of installations, across a wide range of customers. I have participated in, or been consulted on at least a dozen direct trials of GC alternatives. It is only in the last 18 months that I have seen *any* real-life workload on G1 beat the alternatives, and only in the last 12 months that I've had any customer prepared to go live with G1 in production. >From my experience, I think that G1 is a fine collector, with a bright future that should be pursued. However, I haven't seen anything that would make a switch to it as default collector seem compelling in the JDK 9 timeframe. Obviously, my experience is not universal, so I'd like to ask you / Oracle: 1) Can you explain the survey methodology and customer testing that you performed to arrive at the conclusion that G1 is ready to become default? 2) Can you share aggregate results of the surveying ("We worked with X customers and ran Y tests of G1 vs alternatives, and in Z% of cases, G1 worked better by W margin")? 3) Can you ask some of the customers you worked with to speak publicly about the trials you ran with them? Thanks, Ben On Fri, May 22, 2015 at 7:05 AM, wrote: > The following JEPs have been placed into the "Proposed to Target" > state by their owners after discussion and review: > > 233: Generate Run-Time Compiler Tests Automatically > http://openjdk.java.net/jeps/233 > > 246: Leverage CPU Instructions for GHASH and RSA > http://openjdk.java.net/jeps/246 > > 248: Make G1 the Default Garbage Collector > http://openjdk.java.net/jeps/248 > > 249: OCSP Stapling for TLS > http://openjdk.java.net/jeps/249 > > 250: Store Interned Strings in CDS Archives > http://openjdk.java.net/jeps/250 > > 252: Use CLDR Locale Data by Default > http://openjdk.java.net/jeps/252 > > Feedback on these proposals is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC next > Thursday, 28 May, or if they're raised and then satisfactorily > answered, then per the JEP 2.0 process proposal [1] I'll target > these JEPs to JDK 9. > > (This information is also available on the JDK 9 Project Page [2]). > > - Mark > > > [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html > [2] http://openjdk.java.net/projects/jdk9/ From sadhak001 at gmail.com Fri May 22 01:52:52 2015 From: sadhak001 at gmail.com (Mani Sarkar) Date: Fri, 22 May 2015 02:52:52 +0100 Subject: JEP proposed to target JDK 9 (2015/5/8) In-Reply-To: <20150521150324.795083@eggemoggin.niobe.net> References: <20150508160507.367489@eggemoggin.niobe.net> <20150521150324.795083@eggemoggin.niobe.net> Message-ID: +1 to Java REPL! On Thu, May 21, 2015 at 11:03 PM, wrote: > 2015/5/8 4:05 -0700, mark.reinhold at oracle.com: > > The following JEP has been placed into the "Proposed to Target" > > state by its owner after discussion and review: > > > > 222: jshell: The Java Shell (Read-Eval-Print Loop) > > http://openjdk.java.net/jeps/222 > > > > Feedback on this proposal is more than welcome, as are reasoned > > objections. If no such objections are raised by 23:30 UTC next > > Friday, 15 May, or if they're raised and then satisfactorily > > answered, then per the JEP 2.0 process proposal [1] I'll target > > these JEPs to JDK 9. > > Hearing no objections, I've targeted this JEP to JDK 9. > > - Mark > -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From benjamin.john.evans at gmail.com Fri May 22 02:01:17 2015 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Fri, 22 May 2015 11:01:17 +0900 Subject: JEP proposed to target JDK 9 (2015/5/8) In-Reply-To: References: <20150508160507.367489@eggemoggin.niobe.net> <20150521150324.795083@eggemoggin.niobe.net> Message-ID: Seconded - any ideas as to when we might see an initial version in betas from the mainline? Ben On Fri, May 22, 2015 at 10:52 AM, Mani Sarkar wrote: > +1 to Java REPL! > > On Thu, May 21, 2015 at 11:03 PM, wrote: > >> 2015/5/8 4:05 -0700, mark.reinhold at oracle.com: >> > The following JEP has been placed into the "Proposed to Target" >> > state by its owner after discussion and review: >> > >> > 222: jshell: The Java Shell (Read-Eval-Print Loop) >> > http://openjdk.java.net/jeps/222 >> > >> > Feedback on this proposal is more than welcome, as are reasoned >> > objections. If no such objections are raised by 23:30 UTC next >> > Friday, 15 May, or if they're raised and then satisfactorily >> > answered, then per the JEP 2.0 process proposal [1] I'll target >> > these JEPs to JDK 9. >> >> Hearing no objections, I've targeted this JEP to JDK 9. >> >> - Mark >> > > > > -- > @theNeomatrix369 * | **Blog > ** | *LJC Associate & LJC Advocate > (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project - *MutabilityDetector > * | **Bitbucket > * * | **Github > * * | **LinkedIn > * > *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/ > > *Don't chase success, rather aim for "Excellence", and success will come > chasing after you!* From stefan.karlsson at oracle.com Tue May 26 09:47:57 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 26 May 2015 11:47:57 +0200 Subject: CFV: New JDK 9 Reviewer: Per =?UTF-8?B?TGlkw6lu?= Message-ID: <5564414D.6040808@oracle.com> I hereby nominate Per Lid?n to JDK 9 Reviewer. Per is a member of the HotSpot GC team and has contributed 41 patches to HotSpot [4]. He is also the author of "String Deduplication in G1" [3]. Votes are due by 11:45 AM CEST, Tuesday June 9, 2015. Only current JDK 9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Stefan Karlsson [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote [3] http://openjdk.java.net/jeps/192 [4] List of patches: 8080930: SA changes broke bootcycle-images builds 8080584: isGCActiveMark.hpp should not include parallelScavengeHeap.hpp 8080585: concurrentGCThread.hpp should not include suspendibleThreadSet.hpp 8080581: Align SA with new GC directory structure 8079792: GC directory structure cleanup 8079579: Add SuspendibleThreadSetLeaver and make SuspendibleThreadSet::joint()/leave() private 8079330: Circular dependency between G1CollectedHeap and G1BlockOffsetSharedArray 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index 8079148: Fix incorrect include guards 8068582: UseSerialGC not always set up properly 8077417: Cleanup of Universe::initialize_heap() 8077415: Remove duplicate variables holding the CollectedHeap 8077413: Avoid use of Universe::heap() inside collectors 8076534: CollectedHeapName in SA agent incorrect 8076447: Remove unused MemoryManager::kind() 8076294: Cleanup of CollectedHeap::kind() 8076231: Remove unused is_in_partial_collection() 8046231: G1: Code root location ... from nmethod ... not in strong code roots for region 8044796: G1: Enable G1CollectedHeap::stop() 8044768: Backout fix for JDK-8040807 8040807: G1: Enable G1CollectedHeap::stop() 8042310: TestStringDeduplicationMemoryUsage test failing 8044132: Quarantine unstable/broken GC tests 8039042: G1: Phantom zeros in cardtable 8040804: G1: Concurrent mark stuck in loop calling os::elapsedVTime() 8040803: G1: Concurrent mark hangs when mark stack overflows 8040245: G1: VM hangs during shutdown 8039147: Cleanup SuspendibleThreadSet 8037112: gc/g1/TestHumongousAllocInitialMark.java caused SIGSEGV 8038461: Test gc/g1/TestStringDeduplicationMemoryUsage.java fails with unexpected memory usage 8029075: String deduplication in G1 8036673: G1: Abort weak reference processing if mark stack overflows 8036672: G1: alloc_purpose in copy_to_survivor_space() used incorrectly 8031703: Missing post-barrier in ReferenceProcessor 8029162: G1: Shared SATB queue never enabled 8029255: G1: Reference processing should not enqueue references on the shared SATB queue 8024634: gc/startup_warnings tests can fail due to unrelated warnings 8024632: Description of InitialSurvivorRatio flag in globals.hpp is incorrect 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full gcs, expect 0 full gcs 8024974: Incorrect use of GC_locker::is_active() 8014022: G1: Non Java threads should lock the shared SATB queue lock without safepoint checks From bengt.rutisson at oracle.com Tue May 26 09:52:11 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 26 May 2015 11:52:11 +0200 Subject: CFV: New JDK 9 Reviewer: Per =?UTF-8?B?TGlkw6lu?= In-Reply-To: <5564414D.6040808@oracle.com> References: <5564414D.6040808@oracle.com> Message-ID: <5564424B.4020708@oracle.com> Vote: yes Bengt On 2015-05-26 11:47, Stefan Karlsson wrote: > I hereby nominate Per Lid?n to JDK 9 Reviewer. > > Per is a member of the HotSpot GC team and has contributed 41 patches > to HotSpot [4]. He is also the author of "String Deduplication in G1" > [3]. > > Votes are due by 11:45 AM CEST, Tuesday June 9, 2015. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/jeps/192 > [4] List of patches: > 8080930: SA changes broke bootcycle-images builds > 8080584: isGCActiveMark.hpp should not include parallelScavengeHeap.hpp > 8080585: concurrentGCThread.hpp should not include > suspendibleThreadSet.hpp > 8080581: Align SA with new GC directory structure > 8079792: GC directory structure cleanup > 8079579: Add SuspendibleThreadSetLeaver and make > SuspendibleThreadSet::joint()/leave() private > 8079330: Circular dependency between G1CollectedHeap and > G1BlockOffsetSharedArray > 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit > PtrQueue::_index > 8079148: Fix incorrect include guards > 8068582: UseSerialGC not always set up properly > 8077417: Cleanup of Universe::initialize_heap() > 8077415: Remove duplicate variables holding the CollectedHeap > 8077413: Avoid use of Universe::heap() inside collectors > 8076534: CollectedHeapName in SA agent incorrect > 8076447: Remove unused MemoryManager::kind() > 8076294: Cleanup of CollectedHeap::kind() > 8076231: Remove unused is_in_partial_collection() > 8046231: G1: Code root location ... from nmethod ... not in strong > code roots for region > 8044796: G1: Enable G1CollectedHeap::stop() > 8044768: Backout fix for JDK-8040807 > 8040807: G1: Enable G1CollectedHeap::stop() > 8042310: TestStringDeduplicationMemoryUsage test failing > 8044132: Quarantine unstable/broken GC tests > 8039042: G1: Phantom zeros in cardtable > 8040804: G1: Concurrent mark stuck in loop calling os::elapsedVTime() > 8040803: G1: Concurrent mark hangs when mark stack overflows > 8040245: G1: VM hangs during shutdown > 8039147: Cleanup SuspendibleThreadSet > 8037112: gc/g1/TestHumongousAllocInitialMark.java caused SIGSEGV > 8038461: Test gc/g1/TestStringDeduplicationMemoryUsage.java fails with > unexpected memory usage > 8029075: String deduplication in G1 > 8036673: G1: Abort weak reference processing if mark stack overflows > 8036672: G1: alloc_purpose in copy_to_survivor_space() used incorrectly > 8031703: Missing post-barrier in ReferenceProcessor > 8029162: G1: Shared SATB queue never enabled > 8029255: G1: Reference processing should not enqueue references on the > shared SATB queue > 8024634: gc/startup_warnings tests can fail due to unrelated warnings > 8024632: Description of InitialSurvivorRatio flag in globals.hpp is > incorrect > 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full > gcs, expect 0 full gcs > 8024974: Incorrect use of GC_locker::is_active() > 8014022: G1: Non Java threads should lock the shared SATB queue lock > without safepoint checks > From stefan.karlsson at oracle.com Tue May 26 09:55:49 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 26 May 2015 11:55:49 +0200 Subject: CFV: New JDK 9 Reviewer: Per =?UTF-8?B?TGlkw6lu?= In-Reply-To: <5564414D.6040808@oracle.com> References: <5564414D.6040808@oracle.com> Message-ID: <55644325.8040403@oracle.com> Vote: yes StefanK On 2015-05-26 11:47, Stefan Karlsson wrote: > I hereby nominate Per Lid?n to JDK 9 Reviewer. > > Per is a member of the HotSpot GC team and has contributed 41 patches > to HotSpot [4]. He is also the author of "String Deduplication in G1" > [3]. > > Votes are due by 11:45 AM CEST, Tuesday June 9, 2015. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/jeps/192 > [4] List of patches: > 8080930: SA changes broke bootcycle-images builds > 8080584: isGCActiveMark.hpp should not include parallelScavengeHeap.hpp > 8080585: concurrentGCThread.hpp should not include > suspendibleThreadSet.hpp > 8080581: Align SA with new GC directory structure > 8079792: GC directory structure cleanup > 8079579: Add SuspendibleThreadSetLeaver and make > SuspendibleThreadSet::joint()/leave() private > 8079330: Circular dependency between G1CollectedHeap and > G1BlockOffsetSharedArray > 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit > PtrQueue::_index > 8079148: Fix incorrect include guards > 8068582: UseSerialGC not always set up properly > 8077417: Cleanup of Universe::initialize_heap() > 8077415: Remove duplicate variables holding the CollectedHeap > 8077413: Avoid use of Universe::heap() inside collectors > 8076534: CollectedHeapName in SA agent incorrect > 8076447: Remove unused MemoryManager::kind() > 8076294: Cleanup of CollectedHeap::kind() > 8076231: Remove unused is_in_partial_collection() > 8046231: G1: Code root location ... from nmethod ... not in strong > code roots for region > 8044796: G1: Enable G1CollectedHeap::stop() > 8044768: Backout fix for JDK-8040807 > 8040807: G1: Enable G1CollectedHeap::stop() > 8042310: TestStringDeduplicationMemoryUsage test failing > 8044132: Quarantine unstable/broken GC tests > 8039042: G1: Phantom zeros in cardtable > 8040804: G1: Concurrent mark stuck in loop calling os::elapsedVTime() > 8040803: G1: Concurrent mark hangs when mark stack overflows > 8040245: G1: VM hangs during shutdown > 8039147: Cleanup SuspendibleThreadSet > 8037112: gc/g1/TestHumongousAllocInitialMark.java caused SIGSEGV > 8038461: Test gc/g1/TestStringDeduplicationMemoryUsage.java fails with > unexpected memory usage > 8029075: String deduplication in G1 > 8036673: G1: Abort weak reference processing if mark stack overflows > 8036672: G1: alloc_purpose in copy_to_survivor_space() used incorrectly > 8031703: Missing post-barrier in ReferenceProcessor > 8029162: G1: Shared SATB queue never enabled > 8029255: G1: Reference processing should not enqueue references on the > shared SATB queue > 8024634: gc/startup_warnings tests can fail due to unrelated warnings > 8024632: Description of InitialSurvivorRatio flag in globals.hpp is > incorrect > 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full > gcs, expect 0 full gcs > 8024974: Incorrect use of GC_locker::is_active() > 8014022: G1: Non Java threads should lock the shared SATB queue lock > without safepoint checks > From mikael.gerdin at oracle.com Tue May 26 09:56:58 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 26 May 2015 11:56:58 +0200 Subject: =?UTF-8?B?UmU6IENGVjogTmV3IEpESyA5IFJldmlld2VyOiBQZXIgTGlkw6lu?= In-Reply-To: <5564414D.6040808@oracle.com> References: <5564414D.6040808@oracle.com> Message-ID: <14d8fa73ab8.27e3.2bd8b3e304f6b680ef02ac6d3e44f07f@oracle.com> Vote: yes /Mikael On May 26, 2015 11:48:14 AM Stefan Karlsson wrote: > I hereby nominate Per Lid?n to JDK 9 Reviewer. > > Per is a member of the HotSpot GC team and has contributed 41 patches to > HotSpot [4]. He is also the author of "String Deduplication in G1" [3]. > > Votes are due by 11:45 AM CEST, Tuesday June 9, 2015. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/jeps/192 > [4] List of patches: > 8080930: SA changes broke bootcycle-images builds > 8080584: isGCActiveMark.hpp should not include parallelScavengeHeap.hpp > 8080585: concurrentGCThread.hpp should not include suspendibleThreadSet.hpp > 8080581: Align SA with new GC directory structure > 8079792: GC directory structure cleanup > 8079579: Add SuspendibleThreadSetLeaver and make > SuspendibleThreadSet::joint()/leave() private > 8079330: Circular dependency between G1CollectedHeap and > G1BlockOffsetSharedArray > 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit > PtrQueue::_index > 8079148: Fix incorrect include guards > 8068582: UseSerialGC not always set up properly > 8077417: Cleanup of Universe::initialize_heap() > 8077415: Remove duplicate variables holding the CollectedHeap > 8077413: Avoid use of Universe::heap() inside collectors > 8076534: CollectedHeapName in SA agent incorrect > 8076447: Remove unused MemoryManager::kind() > 8076294: Cleanup of CollectedHeap::kind() > 8076231: Remove unused is_in_partial_collection() > 8046231: G1: Code root location ... from nmethod ... not in strong code > roots for region > 8044796: G1: Enable G1CollectedHeap::stop() > 8044768: Backout fix for JDK-8040807 > 8040807: G1: Enable G1CollectedHeap::stop() > 8042310: TestStringDeduplicationMemoryUsage test failing > 8044132: Quarantine unstable/broken GC tests > 8039042: G1: Phantom zeros in cardtable > 8040804: G1: Concurrent mark stuck in loop calling os::elapsedVTime() > 8040803: G1: Concurrent mark hangs when mark stack overflows > 8040245: G1: VM hangs during shutdown > 8039147: Cleanup SuspendibleThreadSet > 8037112: gc/g1/TestHumongousAllocInitialMark.java caused SIGSEGV > 8038461: Test gc/g1/TestStringDeduplicationMemoryUsage.java fails with > unexpected memory usage > 8029075: String deduplication in G1 > 8036673: G1: Abort weak reference processing if mark stack overflows > 8036672: G1: alloc_purpose in copy_to_survivor_space() used incorrectly > 8031703: Missing post-barrier in ReferenceProcessor > 8029162: G1: Shared SATB queue never enabled > 8029255: G1: Reference processing should not enqueue references on the > shared SATB queue > 8024634: gc/startup_warnings tests can fail due to unrelated warnings > 8024632: Description of InitialSurvivorRatio flag in globals.hpp is > incorrect > 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full gcs, > expect 0 full gcs > 8024974: Incorrect use of GC_locker::is_active() > 8014022: G1: Non Java threads should lock the shared SATB queue lock > without safepoint checks > From jaroslav.bachorik at oracle.com Tue May 26 09:58:30 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 26 May 2015 11:58:30 +0200 Subject: CFV: New JDK 9 Reviewer: Per =?UTF-8?B?TGlkw6lu?= In-Reply-To: <5564414D.6040808@oracle.com> References: <5564414D.6040808@oracle.com> Message-ID: <556443C6.8090100@oracle.com> Vote: yes -JB- On 26.5.2015 11:47, Stefan Karlsson wrote: > I hereby nominate Per Lid?n to JDK 9 Reviewer. > > Per is a member of the HotSpot GC team and has contributed 41 patches to > HotSpot [4]. He is also the author of "String Deduplication in G1" [3]. > > Votes are due by 11:45 AM CEST, Tuesday June 9, 2015. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/jeps/192 > [4] List of patches: > 8080930: SA changes broke bootcycle-images builds > 8080584: isGCActiveMark.hpp should not include parallelScavengeHeap.hpp > 8080585: concurrentGCThread.hpp should not include suspendibleThreadSet.hpp > 8080581: Align SA with new GC directory structure > 8079792: GC directory structure cleanup > 8079579: Add SuspendibleThreadSetLeaver and make > SuspendibleThreadSet::joint()/leave() private > 8079330: Circular dependency between G1CollectedHeap and > G1BlockOffsetSharedArray > 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit > PtrQueue::_index > 8079148: Fix incorrect include guards > 8068582: UseSerialGC not always set up properly > 8077417: Cleanup of Universe::initialize_heap() > 8077415: Remove duplicate variables holding the CollectedHeap > 8077413: Avoid use of Universe::heap() inside collectors > 8076534: CollectedHeapName in SA agent incorrect > 8076447: Remove unused MemoryManager::kind() > 8076294: Cleanup of CollectedHeap::kind() > 8076231: Remove unused is_in_partial_collection() > 8046231: G1: Code root location ... from nmethod ... not in strong code > roots for region > 8044796: G1: Enable G1CollectedHeap::stop() > 8044768: Backout fix for JDK-8040807 > 8040807: G1: Enable G1CollectedHeap::stop() > 8042310: TestStringDeduplicationMemoryUsage test failing > 8044132: Quarantine unstable/broken GC tests > 8039042: G1: Phantom zeros in cardtable > 8040804: G1: Concurrent mark stuck in loop calling os::elapsedVTime() > 8040803: G1: Concurrent mark hangs when mark stack overflows > 8040245: G1: VM hangs during shutdown > 8039147: Cleanup SuspendibleThreadSet > 8037112: gc/g1/TestHumongousAllocInitialMark.java caused SIGSEGV > 8038461: Test gc/g1/TestStringDeduplicationMemoryUsage.java fails with > unexpected memory usage > 8029075: String deduplication in G1 > 8036673: G1: Abort weak reference processing if mark stack overflows > 8036672: G1: alloc_purpose in copy_to_survivor_space() used incorrectly > 8031703: Missing post-barrier in ReferenceProcessor > 8029162: G1: Shared SATB queue never enabled > 8029255: G1: Reference processing should not enqueue references on the > shared SATB queue > 8024634: gc/startup_warnings tests can fail due to unrelated warnings > 8024632: Description of InitialSurvivorRatio flag in globals.hpp is > incorrect > 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full gcs, > expect 0 full gcs > 8024974: Incorrect use of GC_locker::is_active() > 8014022: G1: Non Java threads should lock the shared SATB queue lock > without safepoint checks > From staffan.larsen at oracle.com Tue May 26 10:16:43 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 26 May 2015 12:16:43 +0200 Subject: =?utf-8?Q?Re=3A_CFV=3A_New_JDK_9_Reviewer=3A_Per_Lid=C3=A9n?= In-Reply-To: <5564414D.6040808@oracle.com> References: <5564414D.6040808@oracle.com> Message-ID: <451E5555-D422-4F7F-8AF3-934877CDF359@oracle.com> Vote: yes > On 26 maj 2015, at 11:47, Stefan Karlsson wrote: > > I hereby nominate Per Lid?n to JDK 9 Reviewer. > > Per is a member of the HotSpot GC team and has contributed 41 patches to HotSpot [4]. He is also the author of "String Deduplication in G1" [3]. > > Votes are due by 11:45 AM CEST, Tuesday June 9, 2015. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/jeps/192 > [4] List of patches: > 8080930: SA changes broke bootcycle-images builds > 8080584: isGCActiveMark.hpp should not include parallelScavengeHeap.hpp > 8080585: concurrentGCThread.hpp should not include suspendibleThreadSet.hpp > 8080581: Align SA with new GC directory structure > 8079792: GC directory structure cleanup > 8079579: Add SuspendibleThreadSetLeaver and make SuspendibleThreadSet::joint()/leave() private > 8079330: Circular dependency between G1CollectedHeap and G1BlockOffsetSharedArray > 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index > 8079148: Fix incorrect include guards > 8068582: UseSerialGC not always set up properly > 8077417: Cleanup of Universe::initialize_heap() > 8077415: Remove duplicate variables holding the CollectedHeap > 8077413: Avoid use of Universe::heap() inside collectors > 8076534: CollectedHeapName in SA agent incorrect > 8076447: Remove unused MemoryManager::kind() > 8076294: Cleanup of CollectedHeap::kind() > 8076231: Remove unused is_in_partial_collection() > 8046231: G1: Code root location ... from nmethod ... not in strong code roots for region > 8044796: G1: Enable G1CollectedHeap::stop() > 8044768: Backout fix for JDK-8040807 > 8040807: G1: Enable G1CollectedHeap::stop() > 8042310: TestStringDeduplicationMemoryUsage test failing > 8044132: Quarantine unstable/broken GC tests > 8039042: G1: Phantom zeros in cardtable > 8040804: G1: Concurrent mark stuck in loop calling os::elapsedVTime() > 8040803: G1: Concurrent mark hangs when mark stack overflows > 8040245: G1: VM hangs during shutdown > 8039147: Cleanup SuspendibleThreadSet > 8037112: gc/g1/TestHumongousAllocInitialMark.java caused SIGSEGV > 8038461: Test gc/g1/TestStringDeduplicationMemoryUsage.java fails with unexpected memory usage > 8029075: String deduplication in G1 > 8036673: G1: Abort weak reference processing if mark stack overflows > 8036672: G1: alloc_purpose in copy_to_survivor_space() used incorrectly > 8031703: Missing post-barrier in ReferenceProcessor > 8029162: G1: Shared SATB queue never enabled > 8029255: G1: Reference processing should not enqueue references on the shared SATB queue > 8024634: gc/startup_warnings tests can fail due to unrelated warnings > 8024632: Description of InitialSurvivorRatio flag in globals.hpp is incorrect > 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full gcs, expect 0 full gcs > 8024974: Incorrect use of GC_locker::is_active() > 8014022: G1: Non Java threads should lock the shared SATB queue lock without safepoint checks > From paul.sandoz at oracle.com Tue May 26 10:38:46 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 26 May 2015 12:38:46 +0200 Subject: =?iso-8859-1?Q?Re=3A_CFV=3A_New_JDK_9_Reviewer=3A_Per_Lid=E9n?= In-Reply-To: <5564414D.6040808@oracle.com> References: <5564414D.6040808@oracle.com> Message-ID: <90744558-1A99-4975-AC84-3EF2716A2230@oracle.com> Vote: yes Paul. From serguei.spitsyn at oracle.com Tue May 26 11:00:55 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 May 2015 04:00:55 -0700 Subject: CFV: New JDK 9 Reviewer: Per =?UTF-8?B?TGlkw6lu?= In-Reply-To: <5564414D.6040808@oracle.com> References: <5564414D.6040808@oracle.com> Message-ID: <55645267.1060905@oracle.com> Vote: yes -Serguei On 5/26/15 2:47 AM, Stefan Karlsson wrote: > I hereby nominate Per Lid?n to JDK 9 Reviewer. > > Per is a member of the HotSpot GC team and has contributed 41 patches > to HotSpot [4]. He is also the author of "String Deduplication in G1" > [3]. > > Votes are due by 11:45 AM CEST, Tuesday June 9, 2015. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/jeps/192 > [4] List of patches: > 8080930: SA changes broke bootcycle-images builds > 8080584: isGCActiveMark.hpp should not include parallelScavengeHeap.hpp > 8080585: concurrentGCThread.hpp should not include > suspendibleThreadSet.hpp > 8080581: Align SA with new GC directory structure > 8079792: GC directory structure cleanup > 8079579: Add SuspendibleThreadSetLeaver and make > SuspendibleThreadSet::joint()/leave() private > 8079330: Circular dependency between G1CollectedHeap and > G1BlockOffsetSharedArray > 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit > PtrQueue::_index > 8079148: Fix incorrect include guards > 8068582: UseSerialGC not always set up properly > 8077417: Cleanup of Universe::initialize_heap() > 8077415: Remove duplicate variables holding the CollectedHeap > 8077413: Avoid use of Universe::heap() inside collectors > 8076534: CollectedHeapName in SA agent incorrect > 8076447: Remove unused MemoryManager::kind() > 8076294: Cleanup of CollectedHeap::kind() > 8076231: Remove unused is_in_partial_collection() > 8046231: G1: Code root location ... from nmethod ... not in strong > code roots for region > 8044796: G1: Enable G1CollectedHeap::stop() > 8044768: Backout fix for JDK-8040807 > 8040807: G1: Enable G1CollectedHeap::stop() > 8042310: TestStringDeduplicationMemoryUsage test failing > 8044132: Quarantine unstable/broken GC tests > 8039042: G1: Phantom zeros in cardtable > 8040804: G1: Concurrent mark stuck in loop calling os::elapsedVTime() > 8040803: G1: Concurrent mark hangs when mark stack overflows > 8040245: G1: VM hangs during shutdown > 8039147: Cleanup SuspendibleThreadSet > 8037112: gc/g1/TestHumongousAllocInitialMark.java caused SIGSEGV > 8038461: Test gc/g1/TestStringDeduplicationMemoryUsage.java fails with > unexpected memory usage > 8029075: String deduplication in G1 > 8036673: G1: Abort weak reference processing if mark stack overflows > 8036672: G1: alloc_purpose in copy_to_survivor_space() used incorrectly > 8031703: Missing post-barrier in ReferenceProcessor > 8029162: G1: Shared SATB queue never enabled > 8029255: G1: Reference processing should not enqueue references on the > shared SATB queue > 8024634: gc/startup_warnings tests can fail due to unrelated warnings > 8024632: Description of InitialSurvivorRatio flag in globals.hpp is > incorrect > 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full > gcs, expect 0 full gcs > 8024974: Incorrect use of GC_locker::is_active() > 8014022: G1: Non Java threads should lock the shared SATB queue lock > without safepoint checks > From vladimir.x.ivanov at oracle.com Tue May 26 11:05:05 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 26 May 2015 14:05:05 +0300 Subject: CFV: New JDK 9 Reviewer: Per =?UTF-8?B?TGlkw6lu?= In-Reply-To: <5564414D.6040808@oracle.com> References: <5564414D.6040808@oracle.com> Message-ID: <55645361.6030703@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 5/26/15 12:47 PM, Stefan Karlsson wrote: > I hereby nominate Per Lid?n to JDK 9 Reviewer. > > Per is a member of the HotSpot GC team and has contributed 41 patches to > HotSpot [4]. He is also the author of "String Deduplication in G1" [3]. > > Votes are due by 11:45 AM CEST, Tuesday June 9, 2015. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/jeps/192 > [4] List of patches: > 8080930: SA changes broke bootcycle-images builds > 8080584: isGCActiveMark.hpp should not include parallelScavengeHeap.hpp > 8080585: concurrentGCThread.hpp should not include suspendibleThreadSet.hpp > 8080581: Align SA with new GC directory structure > 8079792: GC directory structure cleanup > 8079579: Add SuspendibleThreadSetLeaver and make > SuspendibleThreadSet::joint()/leave() private > 8079330: Circular dependency between G1CollectedHeap and > G1BlockOffsetSharedArray > 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit > PtrQueue::_index > 8079148: Fix incorrect include guards > 8068582: UseSerialGC not always set up properly > 8077417: Cleanup of Universe::initialize_heap() > 8077415: Remove duplicate variables holding the CollectedHeap > 8077413: Avoid use of Universe::heap() inside collectors > 8076534: CollectedHeapName in SA agent incorrect > 8076447: Remove unused MemoryManager::kind() > 8076294: Cleanup of CollectedHeap::kind() > 8076231: Remove unused is_in_partial_collection() > 8046231: G1: Code root location ... from nmethod ... not in strong code > roots for region > 8044796: G1: Enable G1CollectedHeap::stop() > 8044768: Backout fix for JDK-8040807 > 8040807: G1: Enable G1CollectedHeap::stop() > 8042310: TestStringDeduplicationMemoryUsage test failing > 8044132: Quarantine unstable/broken GC tests > 8039042: G1: Phantom zeros in cardtable > 8040804: G1: Concurrent mark stuck in loop calling os::elapsedVTime() > 8040803: G1: Concurrent mark hangs when mark stack overflows > 8040245: G1: VM hangs during shutdown > 8039147: Cleanup SuspendibleThreadSet > 8037112: gc/g1/TestHumongousAllocInitialMark.java caused SIGSEGV > 8038461: Test gc/g1/TestStringDeduplicationMemoryUsage.java fails with > unexpected memory usage > 8029075: String deduplication in G1 > 8036673: G1: Abort weak reference processing if mark stack overflows > 8036672: G1: alloc_purpose in copy_to_survivor_space() used incorrectly > 8031703: Missing post-barrier in ReferenceProcessor > 8029162: G1: Shared SATB queue never enabled > 8029255: G1: Reference processing should not enqueue references on the > shared SATB queue > 8024634: gc/startup_warnings tests can fail due to unrelated warnings > 8024632: Description of InitialSurvivorRatio flag in globals.hpp is > incorrect > 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full gcs, > expect 0 full gcs > 8024974: Incorrect use of GC_locker::is_active() > 8014022: G1: Non Java threads should lock the shared SATB queue lock > without safepoint checks > From volker.simonis at gmail.com Tue May 26 12:06:33 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 26 May 2015 14:06:33 +0200 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_JDK_9_Reviewer=3A_Per_Lid=C3=A9n?= In-Reply-To: <5564414D.6040808@oracle.com> References: <5564414D.6040808@oracle.com> Message-ID: Vote: yes On Tue, May 26, 2015 at 11:47 AM, Stefan Karlsson wrote: > I hereby nominate Per Lid?n to JDK 9 Reviewer. > > Per is a member of the HotSpot GC team and has contributed 41 patches to > HotSpot [4]. He is also the author of "String Deduplication in G1" [3]. > > Votes are due by 11:45 AM CEST, Tuesday June 9, 2015. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/jeps/192 > [4] List of patches: > 8080930: SA changes broke bootcycle-images builds > 8080584: isGCActiveMark.hpp should not include parallelScavengeHeap.hpp > 8080585: concurrentGCThread.hpp should not include suspendibleThreadSet.hpp > 8080581: Align SA with new GC directory structure > 8079792: GC directory structure cleanup > 8079579: Add SuspendibleThreadSetLeaver and make > SuspendibleThreadSet::joint()/leave() private > 8079330: Circular dependency between G1CollectedHeap and > G1BlockOffsetSharedArray > 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit > PtrQueue::_index > 8079148: Fix incorrect include guards > 8068582: UseSerialGC not always set up properly > 8077417: Cleanup of Universe::initialize_heap() > 8077415: Remove duplicate variables holding the CollectedHeap > 8077413: Avoid use of Universe::heap() inside collectors > 8076534: CollectedHeapName in SA agent incorrect > 8076447: Remove unused MemoryManager::kind() > 8076294: Cleanup of CollectedHeap::kind() > 8076231: Remove unused is_in_partial_collection() > 8046231: G1: Code root location ... from nmethod ... not in strong code > roots for region > 8044796: G1: Enable G1CollectedHeap::stop() > 8044768: Backout fix for JDK-8040807 > 8040807: G1: Enable G1CollectedHeap::stop() > 8042310: TestStringDeduplicationMemoryUsage test failing > 8044132: Quarantine unstable/broken GC tests > 8039042: G1: Phantom zeros in cardtable > 8040804: G1: Concurrent mark stuck in loop calling os::elapsedVTime() > 8040803: G1: Concurrent mark hangs when mark stack overflows > 8040245: G1: VM hangs during shutdown > 8039147: Cleanup SuspendibleThreadSet > 8037112: gc/g1/TestHumongousAllocInitialMark.java caused SIGSEGV > 8038461: Test gc/g1/TestStringDeduplicationMemoryUsage.java fails with > unexpected memory usage > 8029075: String deduplication in G1 > 8036673: G1: Abort weak reference processing if mark stack overflows > 8036672: G1: alloc_purpose in copy_to_survivor_space() used incorrectly > 8031703: Missing post-barrier in ReferenceProcessor > 8029162: G1: Shared SATB queue never enabled > 8029255: G1: Reference processing should not enqueue references on the > shared SATB queue > 8024634: gc/startup_warnings tests can fail due to unrelated warnings > 8024632: Description of InitialSurvivorRatio flag in globals.hpp is > incorrect > 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full gcs, > expect 0 full gcs > 8024974: Incorrect use of GC_locker::is_active() > 8014022: G1: Non Java threads should lock the shared SATB queue lock without > safepoint checks > From coleen.phillimore at oracle.com Tue May 26 12:45:34 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 26 May 2015 08:45:34 -0400 Subject: =?utf-8?Q?Re:_CFV:_New_JDK_9_Reviewer:_Per_Lid=C3=A9n?= In-Reply-To: <5564414D.6040808@oracle.com> References: <5564414D.6040808@oracle.com> Message-ID: <3077824A-B045-411F-A4B2-D5F2208BD3E5@oracle.com> Vote: yes Sent from my iPhone > On May 26, 2015, at 5:47 AM, Stefan Karlsson wrote: > > I hereby nominate Per Lid?n to JDK 9 Reviewer. > > Per is a member of the HotSpot GC team and has contributed 41 patches to HotSpot [4]. He is also the author of "String Deduplication in G1" [3]. > > Votes are due by 11:45 AM CEST, Tuesday June 9, 2015. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/jeps/192 > [4] List of patches: > 8080930: SA changes broke bootcycle-images builds > 8080584: isGCActiveMark.hpp should not include parallelScavengeHeap.hpp > 8080585: concurrentGCThread.hpp should not include suspendibleThreadSet.hpp > 8080581: Align SA with new GC directory structure > 8079792: GC directory structure cleanup > 8079579: Add SuspendibleThreadSetLeaver and make SuspendibleThreadSet::joint()/leave() private > 8079330: Circular dependency between G1CollectedHeap and G1BlockOffsetSharedArray > 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index > 8079148: Fix incorrect include guards > 8068582: UseSerialGC not always set up properly > 8077417: Cleanup of Universe::initialize_heap() > 8077415: Remove duplicate variables holding the CollectedHeap > 8077413: Avoid use of Universe::heap() inside collectors > 8076534: CollectedHeapName in SA agent incorrect > 8076447: Remove unused MemoryManager::kind() > 8076294: Cleanup of CollectedHeap::kind() > 8076231: Remove unused is_in_partial_collection() > 8046231: G1: Code root location ... from nmethod ... not in strong code roots for region > 8044796: G1: Enable G1CollectedHeap::stop() > 8044768: Backout fix for JDK-8040807 > 8040807: G1: Enable G1CollectedHeap::stop() > 8042310: TestStringDeduplicationMemoryUsage test failing > 8044132: Quarantine unstable/broken GC tests > 8039042: G1: Phantom zeros in cardtable > 8040804: G1: Concurrent mark stuck in loop calling os::elapsedVTime() > 8040803: G1: Concurrent mark hangs when mark stack overflows > 8040245: G1: VM hangs during shutdown > 8039147: Cleanup SuspendibleThreadSet > 8037112: gc/g1/TestHumongousAllocInitialMark.java caused SIGSEGV > 8038461: Test gc/g1/TestStringDeduplicationMemoryUsage.java fails with unexpected memory usage > 8029075: String deduplication in G1 > 8036673: G1: Abort weak reference processing if mark stack overflows > 8036672: G1: alloc_purpose in copy_to_survivor_space() used incorrectly > 8031703: Missing post-barrier in ReferenceProcessor > 8029162: G1: Shared SATB queue never enabled > 8029255: G1: Reference processing should not enqueue references on the shared SATB queue > 8024634: gc/startup_warnings tests can fail due to unrelated warnings > 8024632: Description of InitialSurvivorRatio flag in globals.hpp is incorrect > 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full gcs, expect 0 full gcs > 8024974: Incorrect use of GC_locker::is_active() > 8014022: G1: Non Java threads should lock the shared SATB queue lock without safepoint checks > From Roger.Riggs at Oracle.com Tue May 26 13:48:37 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 26 May 2015 09:48:37 -0400 Subject: CFV: New JDK 9 Reviewer: Per =?UTF-8?B?TGlkw6lu?= In-Reply-To: <5564414D.6040808@oracle.com> References: <5564414D.6040808@oracle.com> Message-ID: <556479B5.6030500@Oracle.com> Vote: Yes On 5/26/2015 5:47 AM, Stefan Karlsson wrote: > I hereby nominate Per Lid?n to JDK 9 Reviewer. From Alan.Bateman at oracle.com Tue May 26 13:52:16 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 May 2015 14:52:16 +0100 Subject: CFV: New JDK 9 Reviewer: Per =?UTF-8?B?TGlkw6lu?= In-Reply-To: <5564414D.6040808@oracle.com> References: <5564414D.6040808@oracle.com> Message-ID: <55647A90.3030008@oracle.com> Vote: yes From erik.helin at oracle.com Tue May 26 14:09:56 2015 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 26 May 2015 16:09:56 +0200 Subject: CFV: New JDK 9 =?iso-8859-1?Q?Reviewer?= =?iso-8859-1?Q?=3A_Per_Lid=E9n?= In-Reply-To: <5564414D.6040808@oracle.com> References: <5564414D.6040808@oracle.com> Message-ID: <20150526140956.GO2552@ehelin.jrpg.bea.com> Vote: yes On 2015-05-26, Stefan Karlsson wrote: > I hereby nominate Per Lid?n to JDK 9 Reviewer. > > Per is a member of the HotSpot GC team and has contributed 41 patches to > HotSpot [4]. He is also the author of "String Deduplication in G1" [3]. > > Votes are due by 11:45 AM CEST, Tuesday June 9, 2015. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/jeps/192 > [4] List of patches: > 8080930: SA changes broke bootcycle-images builds > 8080584: isGCActiveMark.hpp should not include parallelScavengeHeap.hpp > 8080585: concurrentGCThread.hpp should not include suspendibleThreadSet.hpp > 8080581: Align SA with new GC directory structure > 8079792: GC directory structure cleanup > 8079579: Add SuspendibleThreadSetLeaver and make > SuspendibleThreadSet::joint()/leave() private > 8079330: Circular dependency between G1CollectedHeap and > G1BlockOffsetSharedArray > 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit > PtrQueue::_index > 8079148: Fix incorrect include guards > 8068582: UseSerialGC not always set up properly > 8077417: Cleanup of Universe::initialize_heap() > 8077415: Remove duplicate variables holding the CollectedHeap > 8077413: Avoid use of Universe::heap() inside collectors > 8076534: CollectedHeapName in SA agent incorrect > 8076447: Remove unused MemoryManager::kind() > 8076294: Cleanup of CollectedHeap::kind() > 8076231: Remove unused is_in_partial_collection() > 8046231: G1: Code root location ... from nmethod ... not in strong code > roots for region > 8044796: G1: Enable G1CollectedHeap::stop() > 8044768: Backout fix for JDK-8040807 > 8040807: G1: Enable G1CollectedHeap::stop() > 8042310: TestStringDeduplicationMemoryUsage test failing > 8044132: Quarantine unstable/broken GC tests > 8039042: G1: Phantom zeros in cardtable > 8040804: G1: Concurrent mark stuck in loop calling os::elapsedVTime() > 8040803: G1: Concurrent mark hangs when mark stack overflows > 8040245: G1: VM hangs during shutdown > 8039147: Cleanup SuspendibleThreadSet > 8037112: gc/g1/TestHumongousAllocInitialMark.java caused SIGSEGV > 8038461: Test gc/g1/TestStringDeduplicationMemoryUsage.java fails with > unexpected memory usage > 8029075: String deduplication in G1 > 8036673: G1: Abort weak reference processing if mark stack overflows > 8036672: G1: alloc_purpose in copy_to_survivor_space() used incorrectly > 8031703: Missing post-barrier in ReferenceProcessor > 8029162: G1: Shared SATB queue never enabled > 8029255: G1: Reference processing should not enqueue references on the > shared SATB queue > 8024634: gc/startup_warnings tests can fail due to unrelated warnings > 8024632: Description of InitialSurvivorRatio flag in globals.hpp is > incorrect > 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full gcs, > expect 0 full gcs > 8024974: Incorrect use of GC_locker::is_active() > 8014022: G1: Non Java threads should lock the shared SATB queue lock without > safepoint checks > From vladimir.kozlov at oracle.com Tue May 26 16:36:56 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 May 2015 09:36:56 -0700 Subject: CFV: New JDK 9 Reviewer: Per =?UTF-8?B?TGlkw6lu?= In-Reply-To: <5564414D.6040808@oracle.com> References: <5564414D.6040808@oracle.com> Message-ID: <5564A128.1060100@oracle.com> Vote: yes On 5/26/15 2:47 AM, Stefan Karlsson wrote: > I hereby nominate Per Lid?n to JDK 9 Reviewer. > > Per is a member of the HotSpot GC team and has contributed 41 patches to > HotSpot [4]. He is also the author of "String Deduplication in G1" [3]. > > Votes are due by 11:45 AM CEST, Tuesday June 9, 2015. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/jeps/192 > [4] List of patches: > 8080930: SA changes broke bootcycle-images builds > 8080584: isGCActiveMark.hpp should not include parallelScavengeHeap.hpp > 8080585: concurrentGCThread.hpp should not include suspendibleThreadSet.hpp > 8080581: Align SA with new GC directory structure > 8079792: GC directory structure cleanup > 8079579: Add SuspendibleThreadSetLeaver and make > SuspendibleThreadSet::joint()/leave() private > 8079330: Circular dependency between G1CollectedHeap and > G1BlockOffsetSharedArray > 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit > PtrQueue::_index > 8079148: Fix incorrect include guards > 8068582: UseSerialGC not always set up properly > 8077417: Cleanup of Universe::initialize_heap() > 8077415: Remove duplicate variables holding the CollectedHeap > 8077413: Avoid use of Universe::heap() inside collectors > 8076534: CollectedHeapName in SA agent incorrect > 8076447: Remove unused MemoryManager::kind() > 8076294: Cleanup of CollectedHeap::kind() > 8076231: Remove unused is_in_partial_collection() > 8046231: G1: Code root location ... from nmethod ... not in strong code > roots for region > 8044796: G1: Enable G1CollectedHeap::stop() > 8044768: Backout fix for JDK-8040807 > 8040807: G1: Enable G1CollectedHeap::stop() > 8042310: TestStringDeduplicationMemoryUsage test failing > 8044132: Quarantine unstable/broken GC tests > 8039042: G1: Phantom zeros in cardtable > 8040804: G1: Concurrent mark stuck in loop calling os::elapsedVTime() > 8040803: G1: Concurrent mark hangs when mark stack overflows > 8040245: G1: VM hangs during shutdown > 8039147: Cleanup SuspendibleThreadSet > 8037112: gc/g1/TestHumongousAllocInitialMark.java caused SIGSEGV > 8038461: Test gc/g1/TestStringDeduplicationMemoryUsage.java fails with > unexpected memory usage > 8029075: String deduplication in G1 > 8036673: G1: Abort weak reference processing if mark stack overflows > 8036672: G1: alloc_purpose in copy_to_survivor_space() used incorrectly > 8031703: Missing post-barrier in ReferenceProcessor > 8029162: G1: Shared SATB queue never enabled > 8029255: G1: Reference processing should not enqueue references on the > shared SATB queue > 8024634: gc/startup_warnings tests can fail due to unrelated warnings > 8024632: Description of InitialSurvivorRatio flag in globals.hpp is > incorrect > 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full gcs, > expect 0 full gcs > 8024974: Incorrect use of GC_locker::is_active() > 8014022: G1: Non Java threads should lock the shared SATB queue lock > without safepoint checks > From alejandro.murillo at oracle.com Tue May 26 19:14:30 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 26 May 2015 13:14:30 -0600 Subject: jdk9-dev: HotSpot Message-ID: <5564C616.7080004@oracle.com> jdk9-hs-2015-05-21 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/47fc9b0ab31b http://hg.openjdk.java.net/jdk9/dev/corba/rev/ce7dfdd6b142 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/eb76189435bb http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/d5963ccce28d http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/1232f4013417 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8fe0dd7d5b45 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7ef02ad5d342 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/9fba27631f21 Component : VM Status : Go for integration Date : 05/26/2015 at 18:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2015-05-22-001543.amurillo.jdk9-hs-2015-05-21-snapshot Testing:http://surl.us.oracle.com/pit_jdk9_b66_summary 103 new failures, 2166 known failures, 401529 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 6811960: x86 biasedlocking epoch expired rare bug 8025979: [TESTBUG] Write test to exercise uninitialized strings from JNI code 8029098: Exclude javax/management/remote/mandatory/notif/ListenerScaleTest.java from running on fastdebug builds 8033445: [TESTBUG] Add test case for calling default methods from JNI 8035496: G1 ARM: missing remset entry noticed by VerifyAfterGC for vm/gc/concurrent/lp50yp10rp70mr30st0 8046869: Several java/lang/instrument/PremainClass/* tests fail due to timeout 8047330: Remove unrolled card loops in G1 SparsePRTEntry 8051045: HotSpot fails to wrap Exceptions from invokedynamic in a BootstrapMethodError 8058265: No callers of ReferenceProcessor::clear_discovered_references 8075288: malloc without free in VM_PopulateDumpSharedSpace::doit() 8075926: Add a sun.management.JMXConnectorServer perf counter to track its state 8077620: [TESTBUG] Some of the hotspot tests require at least compact profile 3 8077866: [TESTBUG] Some of java.lang tests cannot be run on compact profiles 1, 2 8078143: java/lang/management/ThreadMXBean/AllThreadIds.java fails intermittently 8078470: [Linux] Replace syscall use in os::fork_and_exec with glibc fork() and execve() 8078834: [TESTBUG] Tests fails on ARM64 due to unknown hardware 8079216: Remove undefined method oopDesc::is_null(Klass *) 8079644: memory stomping error with ResourceManagement and TestAgentStress.java 8079792: GC directory structure cleanup 8080190: PPC64: Fix wrong rotate instructions in the .ad file 8080281: 8068945 changes break building the zero JVM variant 8080308: TypeProfileLevel on SPARC platform should enable JSR292-only profiling level 8080483: Incorrect test execution string at SumRed_Long.java 8080581: Align SA with new GC directory structure 8080584: isGCActiveMark.hpp should not include parallelScavengeHeap.hpp 8080585: concurrentGCThread.hpp should not include suspendibleThreadSet.hpp 8080600: AARCH64: testlibrary does not support AArch64 8080692: lots of jstack tests failing in pit -- Alejandro From jon.masamitsu at oracle.com Tue May 26 22:03:01 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 26 May 2015 15:03:01 -0700 Subject: CFV: New JDK 9 Reviewer: Per =?UTF-8?B?TGlkw6lu?= In-Reply-To: <5564414D.6040808@oracle.com> References: <5564414D.6040808@oracle.com> Message-ID: <5564ED95.1050905@oracle.com> Vote: yes On 05/26/2015 02:47 AM, Stefan Karlsson wrote: > I hereby nominate Per Lid?n to JDK 9 Reviewer. > > Per is a member of the HotSpot GC team and has contributed 41 patches > to HotSpot [4]. He is also the author of "String Deduplication in G1" > [3]. > > Votes are due by 11:45 AM CEST, Tuesday June 9, 2015. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/jeps/192 > [4] List of patches: > 8080930: SA changes broke bootcycle-images builds > 8080584: isGCActiveMark.hpp should not include parallelScavengeHeap.hpp > 8080585: concurrentGCThread.hpp should not include > suspendibleThreadSet.hpp > 8080581: Align SA with new GC directory structure > 8079792: GC directory structure cleanup > 8079579: Add SuspendibleThreadSetLeaver and make > SuspendibleThreadSet::joint()/leave() private > 8079330: Circular dependency between G1CollectedHeap and > G1BlockOffsetSharedArray > 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit > PtrQueue::_index > 8079148: Fix incorrect include guards > 8068582: UseSerialGC not always set up properly > 8077417: Cleanup of Universe::initialize_heap() > 8077415: Remove duplicate variables holding the CollectedHeap > 8077413: Avoid use of Universe::heap() inside collectors > 8076534: CollectedHeapName in SA agent incorrect > 8076447: Remove unused MemoryManager::kind() > 8076294: Cleanup of CollectedHeap::kind() > 8076231: Remove unused is_in_partial_collection() > 8046231: G1: Code root location ... from nmethod ... not in strong > code roots for region > 8044796: G1: Enable G1CollectedHeap::stop() > 8044768: Backout fix for JDK-8040807 > 8040807: G1: Enable G1CollectedHeap::stop() > 8042310: TestStringDeduplicationMemoryUsage test failing > 8044132: Quarantine unstable/broken GC tests > 8039042: G1: Phantom zeros in cardtable > 8040804: G1: Concurrent mark stuck in loop calling os::elapsedVTime() > 8040803: G1: Concurrent mark hangs when mark stack overflows > 8040245: G1: VM hangs during shutdown > 8039147: Cleanup SuspendibleThreadSet > 8037112: gc/g1/TestHumongousAllocInitialMark.java caused SIGSEGV > 8038461: Test gc/g1/TestStringDeduplicationMemoryUsage.java fails with > unexpected memory usage > 8029075: String deduplication in G1 > 8036673: G1: Abort weak reference processing if mark stack overflows > 8036672: G1: alloc_purpose in copy_to_survivor_space() used incorrectly > 8031703: Missing post-barrier in ReferenceProcessor > 8029162: G1: Shared SATB queue never enabled > 8029255: G1: Reference processing should not enqueue references on the > shared SATB queue > 8024634: gc/startup_warnings tests can fail due to unrelated warnings > 8024632: Description of InitialSurvivorRatio flag in globals.hpp is > incorrect > 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full > gcs, expect 0 full gcs > 8024974: Incorrect use of GC_locker::is_active() > 8014022: G1: Non Java threads should lock the shared SATB queue lock > without safepoint checks > From david.holmes at oracle.com Wed May 27 00:36:16 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 May 2015 10:36:16 +1000 Subject: CFV: New JDK 9 Reviewer: Per =?UTF-8?B?TGlkw6lu?= In-Reply-To: <5564414D.6040808@oracle.com> References: <5564414D.6040808@oracle.com> Message-ID: <55651180.9080300@oracle.com> Vote: yes David On 26/05/2015 7:47 PM, Stefan Karlsson wrote: > I hereby nominate Per Lid?n to JDK 9 Reviewer. > > Per is a member of the HotSpot GC team and has contributed 41 patches to > HotSpot [4]. He is also the author of "String Deduplication in G1" [3]. > > Votes are due by 11:45 AM CEST, Tuesday June 9, 2015. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/jeps/192 > [4] List of patches: > 8080930: SA changes broke bootcycle-images builds > 8080584: isGCActiveMark.hpp should not include parallelScavengeHeap.hpp > 8080585: concurrentGCThread.hpp should not include suspendibleThreadSet.hpp > 8080581: Align SA with new GC directory structure > 8079792: GC directory structure cleanup > 8079579: Add SuspendibleThreadSetLeaver and make > SuspendibleThreadSet::joint()/leave() private > 8079330: Circular dependency between G1CollectedHeap and > G1BlockOffsetSharedArray > 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit > PtrQueue::_index > 8079148: Fix incorrect include guards > 8068582: UseSerialGC not always set up properly > 8077417: Cleanup of Universe::initialize_heap() > 8077415: Remove duplicate variables holding the CollectedHeap > 8077413: Avoid use of Universe::heap() inside collectors > 8076534: CollectedHeapName in SA agent incorrect > 8076447: Remove unused MemoryManager::kind() > 8076294: Cleanup of CollectedHeap::kind() > 8076231: Remove unused is_in_partial_collection() > 8046231: G1: Code root location ... from nmethod ... not in strong code > roots for region > 8044796: G1: Enable G1CollectedHeap::stop() > 8044768: Backout fix for JDK-8040807 > 8040807: G1: Enable G1CollectedHeap::stop() > 8042310: TestStringDeduplicationMemoryUsage test failing > 8044132: Quarantine unstable/broken GC tests > 8039042: G1: Phantom zeros in cardtable > 8040804: G1: Concurrent mark stuck in loop calling os::elapsedVTime() > 8040803: G1: Concurrent mark hangs when mark stack overflows > 8040245: G1: VM hangs during shutdown > 8039147: Cleanup SuspendibleThreadSet > 8037112: gc/g1/TestHumongousAllocInitialMark.java caused SIGSEGV > 8038461: Test gc/g1/TestStringDeduplicationMemoryUsage.java fails with > unexpected memory usage > 8029075: String deduplication in G1 > 8036673: G1: Abort weak reference processing if mark stack overflows > 8036672: G1: alloc_purpose in copy_to_survivor_space() used incorrectly > 8031703: Missing post-barrier in ReferenceProcessor > 8029162: G1: Shared SATB queue never enabled > 8029255: G1: Reference processing should not enqueue references on the > shared SATB queue > 8024634: gc/startup_warnings tests can fail due to unrelated warnings > 8024632: Description of InitialSurvivorRatio flag in globals.hpp is > incorrect > 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full gcs, > expect 0 full gcs > 8024974: Incorrect use of GC_locker::is_active() > 8014022: G1: Non Java threads should lock the shared SATB queue lock > without safepoint checks > From stefan.johansson at oracle.com Wed May 27 08:54:19 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 27 May 2015 10:54:19 +0200 Subject: JEPs proposed to target JDK 9 (2015/5/21) In-Reply-To: References: <20150521150533.791873@eggemoggin.niobe.net> Message-ID: <5565863B.3060906@oracle.com> Hi Ben, Did you follow the discussion when the JEP was presented as a candidate [1]? That discussion shows both sides of the coin, some think changing the default is good, some don't. It's important to remember that we do not remove any of the other collectors and specifying -XX:+UseParallelGC will make the VM behave like before the change. For customers specifying a GC explicitly the change will have no effect, and the expectation is that most customers tuning for performance do this. Thanks, Stefan [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/018322.html On 2015-05-22 02:15, Ben Evans wrote: > Hi Mark, > > I've mostly been very pleased with the JEPs targeted at JDK 9. > However, I have to object to: > > 248: Make G1 the Default Garbage Collector > > My reasoning is as follows: > > I have been working with G1 for ~5 years, ever since it was > experimental (& highly crash-prone in JDK 6). > > In the intervening time, I have seen dozens (if not hundreds) of > installations, across a wide range of customers. I have participated > in, or been consulted on at least a dozen direct trials of GC > alternatives. > > It is only in the last 18 months that I have seen *any* real-life > workload on G1 beat the alternatives, and only in the last 12 months > that I've had any customer prepared to go live with G1 in production. > > From my experience, I think that G1 is a fine collector, with a bright > future that should be pursued. However, I haven't seen anything that > would make a switch to it as default collector seem compelling in the > JDK 9 timeframe. > > Obviously, my experience is not universal, so I'd like to ask you / Oracle: > > 1) Can you explain the survey methodology and customer testing that > you performed to arrive at the conclusion that G1 is ready to become > default? > > 2) Can you share aggregate results of the surveying ("We worked with X > customers and ran Y tests of G1 vs alternatives, and in Z% of cases, > G1 worked better by W margin")? > > 3) Can you ask some of the customers you worked with to speak publicly > about the trials you ran with them? > > Thanks, > > Ben > > > On Fri, May 22, 2015 at 7:05 AM, wrote: >> The following JEPs have been placed into the "Proposed to Target" >> state by their owners after discussion and review: >> >> 233: Generate Run-Time Compiler Tests Automatically >> http://openjdk.java.net/jeps/233 >> >> 246: Leverage CPU Instructions for GHASH and RSA >> http://openjdk.java.net/jeps/246 >> >> 248: Make G1 the Default Garbage Collector >> http://openjdk.java.net/jeps/248 >> >> 249: OCSP Stapling for TLS >> http://openjdk.java.net/jeps/249 >> >> 250: Store Interned Strings in CDS Archives >> http://openjdk.java.net/jeps/250 >> >> 252: Use CLDR Locale Data by Default >> http://openjdk.java.net/jeps/252 >> >> Feedback on these proposals is more than welcome, as are reasoned >> objections. If no such objections are raised by 23:00 UTC next >> Thursday, 28 May, or if they're raised and then satisfactorily >> answered, then per the JEP 2.0 process proposal [1] I'll target >> these JEPs to JDK 9. >> >> (This information is also available on the JDK 9 Project Page [2]). >> >> - Mark >> >> >> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >> [2] http://openjdk.java.net/projects/jdk9/ From benjamin.john.evans at gmail.com Wed May 27 09:25:23 2015 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Wed, 27 May 2015 17:25:23 +0800 Subject: JEPs proposed to target JDK 9 (2015/5/21) In-Reply-To: <5565863B.3060906@oracle.com> References: <20150521150533.791873@eggemoggin.niobe.net> <5565863B.3060906@oracle.com> Message-ID: Hi Stefan, Thanks for the link - I was travelling at that time & had very limited internet access & completely missed that discussion (catching up on all my non-direct email after more than day or two is just not practical, so it's bulk "Mark as Read" for all lists, and this means important stuff falls through the cracks). I'll read the whole thread, but I do think that if Oracle is sure that G1 is ready to be default, some actual numbers & stats from studies run isn't a great deal to ask, and if those numbers don't exist, then I'd consider this way too risky. Thanks, Ben On Wed, May 27, 2015 at 4:54 PM, Stefan Johansson wrote: > Hi Ben, > > Did you follow the discussion when the JEP was presented as a candidate [1]? > That discussion shows both sides of the coin, some think changing the > default is good, some don't. It's important to remember that we do not > remove any of the other collectors and specifying -XX:+UseParallelGC will > make the VM behave like before the change. For customers specifying a GC > explicitly the change will have no effect, and the expectation is that most > customers tuning for performance do this. > > Thanks, > Stefan > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/018322.html > > > On 2015-05-22 02:15, Ben Evans wrote: >> >> Hi Mark, >> >> I've mostly been very pleased with the JEPs targeted at JDK 9. >> However, I have to object to: >> >> 248: Make G1 the Default Garbage Collector >> >> My reasoning is as follows: >> >> I have been working with G1 for ~5 years, ever since it was >> experimental (& highly crash-prone in JDK 6). >> >> In the intervening time, I have seen dozens (if not hundreds) of >> installations, across a wide range of customers. I have participated >> in, or been consulted on at least a dozen direct trials of GC >> alternatives. >> >> It is only in the last 18 months that I have seen *any* real-life >> workload on G1 beat the alternatives, and only in the last 12 months >> that I've had any customer prepared to go live with G1 in production. >> >> From my experience, I think that G1 is a fine collector, with a bright >> future that should be pursued. However, I haven't seen anything that >> would make a switch to it as default collector seem compelling in the >> JDK 9 timeframe. >> >> Obviously, my experience is not universal, so I'd like to ask you / >> Oracle: >> >> 1) Can you explain the survey methodology and customer testing that >> you performed to arrive at the conclusion that G1 is ready to become >> default? >> >> 2) Can you share aggregate results of the surveying ("We worked with X >> customers and ran Y tests of G1 vs alternatives, and in Z% of cases, >> G1 worked better by W margin")? >> >> 3) Can you ask some of the customers you worked with to speak publicly >> about the trials you ran with them? >> >> Thanks, >> >> Ben >> >> >> On Fri, May 22, 2015 at 7:05 AM, wrote: >>> >>> The following JEPs have been placed into the "Proposed to Target" >>> state by their owners after discussion and review: >>> >>> 233: Generate Run-Time Compiler Tests Automatically >>> http://openjdk.java.net/jeps/233 >>> >>> 246: Leverage CPU Instructions for GHASH and RSA >>> http://openjdk.java.net/jeps/246 >>> >>> 248: Make G1 the Default Garbage Collector >>> http://openjdk.java.net/jeps/248 >>> >>> 249: OCSP Stapling for TLS >>> http://openjdk.java.net/jeps/249 >>> >>> 250: Store Interned Strings in CDS Archives >>> http://openjdk.java.net/jeps/250 >>> >>> 252: Use CLDR Locale Data by Default >>> http://openjdk.java.net/jeps/252 >>> >>> Feedback on these proposals is more than welcome, as are reasoned >>> objections. If no such objections are raised by 23:00 UTC next >>> Thursday, 28 May, or if they're raised and then satisfactorily >>> answered, then per the JEP 2.0 process proposal [1] I'll target >>> these JEPs to JDK 9. >>> >>> (This information is also available on the JDK 9 Project Page [2]). >>> >>> - Mark >>> >>> >>> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >>> [2] http://openjdk.java.net/projects/jdk9/ > > From yasuenag at gmail.com Wed May 27 09:37:49 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 27 May 2015 18:37:49 +0900 Subject: JDK-8081295: Build failed with GCC 5.1.1 Message-ID: <5565906D.4010508@gmail.com> Hi all, I don't know where should I post this issue - so I post jdk9-dev. I tried to build jdk9/dev on Fedora22 with GCC 5.1.1, however, it was failed. I found several problems: System: Fedora release 22 (Twenty Two) x86_64 - gcc-5.1.1-1.fc22.x86_64 Problems: 1. Array bounds check in GCC - jdk/src/java.desktop/share/native/libjavajpeg/jcmaster.c - jdk/src/java.desktop/share/native/libjavajpeg/jquant1.c - jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_64.c - jdk/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp_f.c It seems to be bug of GCC: Bug 59124: [4.8/4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds" https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 I think implementations of these files have no problem. So I propose to ignore warning(s) of compiler through pragma option as workaround when we use GCC [1]. 2. Local variables might be clobbered - jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c SplashDecodePng() calls setjmp(3). Some local variables initialize before setjmp() call, and use after it. Their initial values are only used at cleanup code (*done* label) and actual values are stored only after setjmp() call. So I think we can ignore this error through pragma option [1]. However, cleanup code (*done* label) might be occurred runtime error in libc when some pointers are NULL. So I add NULL check in it. 3. Incorrect condition - jdk/src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c searchAllSourceNames() returns int value. However, branch condition in eventFilterRestricted_passesFilter() treats it as boolean value. I've created patch for this enhancement. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8081295/webrev.00/ I'm jdk9 committer, but I'm not employee at Oracle. So I need a Sponsor. Thanks, Yasumasa [1] https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html From david.holmes at oracle.com Wed May 27 12:57:19 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 May 2015 22:57:19 +1000 Subject: JDK-8081295: Build failed with GCC 5.1.1 In-Reply-To: <5565906D.4010508@gmail.com> References: <5565906D.4010508@gmail.com> Message-ID: <5565BF2F.7000504@oracle.com> Hi Yasumasa, As Erik wrote in the CR each part of this needs to be reviewed by the appropriate component team - this seems to be mostly client-libs with a dash of serviceability. Also note that only hotspot pushes need a sponsor as they have to go in via our JPRT build/test system. In other areas any JDK9 committer can push reviewed changes directly (with assumed sufficient build/test coverage). David On 27/05/2015 7:37 PM, Yasumasa Suenaga wrote: > Hi all, > > I don't know where should I post this issue - so I post jdk9-dev. > > I tried to build jdk9/dev on Fedora22 with GCC 5.1.1, however, it was failed. > I found several problems: > > > System: > Fedora release 22 (Twenty Two) x86_64 > - gcc-5.1.1-1.fc22.x86_64 > > > Problems: > 1. Array bounds check in GCC > - jdk/src/java.desktop/share/native/libjavajpeg/jcmaster.c > - jdk/src/java.desktop/share/native/libjavajpeg/jquant1.c > - jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_64.c > - jdk/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp_f.c > > It seems to be bug of GCC: > Bug 59124: [4.8/4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds" > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 > > I think implementations of these files have no problem. > So I propose to ignore warning(s) of compiler through pragma option as > workaround when we use GCC [1]. > > > 2. Local variables might be clobbered > - jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c > > SplashDecodePng() calls setjmp(3). > Some local variables initialize before setjmp() call, and use after it. > Their initial values are only used at cleanup code (*done* label) and > actual values are stored only after setjmp() call. > So I think we can ignore this error through pragma option [1]. > > However, cleanup code (*done* label) might be occurred runtime error in > libc when some pointers are NULL. So I add NULL check in it. > > > 3. Incorrect condition > - jdk/src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c > > searchAllSourceNames() returns int value. However, branch condition in > eventFilterRestricted_passesFilter() treats it as boolean value. > > > I've created patch for this enhancement. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8081295/webrev.00/ > > > I'm jdk9 committer, but I'm not employee at Oracle. > So I need a Sponsor. > > > Thanks, > > Yasumasa > > > [1] https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html > From openjdk at duigou.org Wed May 27 18:59:37 2015 From: openjdk at duigou.org (Mike Duigou) Date: Wed, 27 May 2015 11:59:37 -0700 Subject: CFV: New JDK 9 Reviewer: Per =?UTF-8?Q?Lid=3Fn?= In-Reply-To: References: Message-ID: <9cf6cd485f13d6a95b693e6042b76695@sonic.net> Vote: YES From jigarjm at gmail.com Wed May 27 19:02:14 2015 From: jigarjm at gmail.com (Jigar Joshi) Date: Wed, 27 May 2015 12:02:14 -0700 Subject: CFV: New JDK 9 Reviewer: Per Lid?n In-Reply-To: <9cf6cd485f13d6a95b693e6042b76695@sonic.net> References: <9cf6cd485f13d6a95b693e6042b76695@sonic.net> Message-ID: not sure my vote counts :) but vote: YES On Wed, May 27, 2015 at 11:59 AM, Mike Duigou wrote: > Vote: YES > > -- -- Jigar From lana.steuck at oracle.com Wed May 27 19:03:56 2015 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 27 May 2015 12:03:56 -0700 (PDT) Subject: jdk9-b66: dev Message-ID: <201505271903.t4RJ3uqY027717@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/dc6e8336f51b http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/9dd95cff9dae http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/fd6bda430d96 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4fbcca8ab812 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/1232f4013417 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/d5963ccce28d http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/197e94e0dacd http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/44ee68f7dbac --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8080535 core-libs (ch) Expected size of Character.UnicodeBlock.map is not optimal JDK-8080589 core-libs (fs) FileChannel.force should use fcntl(F_FULLFSYNC) instead of fsync JDK-8080629 core-libs (fs) Re-enable ability to fsync() on directories even though read()s o JDK-8076543 core-libs Add @modules as needed to the langtools tests JDK-8079424 core-libs Code generator emits an extra POP for discarded boolean logical operat JDK-8080248 core-libs Coding regression in HKSCS charsets JDK-8080623 core-libs CPU overhead in FJ due to spinning in awaitWork JDK-8080848 core-libs delete of bound Java method property results in crash JDK-8078414 core-libs Don't create impossible converters for ScriptObjectMirror JDK-8075284 core-libs fix up miscellaneous TM constructions JDK-8080471 core-libs fix usage of replace and file separator in Nashorn tests JDK-8077846 core-libs Improve locking strategy for readConfiguration(), reset(), and initial JDK-8078136 core-libs Incorrect figure number in reference to Hacker's Delight book in Long. JDK-8074002 core-libs java.time.ZoneId.systemDefault() should be faster JDK-8055269 core-libs java/lang/invoke/MethodHandles/CatchExceptionTest.java fails intermitt JDK-8078582 core-libs java/lang/Runtime/exec/LotsOfOutput.java fails intermittently with Pro JDK-8080598 core-libs Javadoc warnings in Global.java after lazy initialization JDK-8079145 core-libs jdk.nashorn.internal.runtime.arrays.IntArrayData.convert assertion JDK-8049300 core-libs jjs scripting: need way to quote $EXEC command arguments to protect sp JDK-8077155 core-libs LoginContext Subject ignored by jdk8 sun.net.www.protocol.http.HttpURL JDK-8074657 core-libs Missing space on a boundary of concatenated strings JDK-8071571 core-libs Move substring of same string to slow path JDK-8080711 core-libs Prepare sun/nio/cs/FindEncoderBugs.java to find intermittent failures JDK-8072853 core-libs SimpleScriptContext used by NashornScriptEngine doesn't completely com JDK-8080422 core-libs Some docs cleanup for core libs JDK-8080680 core-libs sun/nio/cs/TestCompoundTest.java should be removed from TEST.groups JDK-8072002 core-libs The spec on javax.script.Compilable contains a typo and confusing inco JDK-8080658 core-libs Update sun/nio/cs/FindDecoderBugs.java to use random number generator JDK-8079559 core-svc Exclude demo/jvmti/hprof tests JDK-8059047 core-svc Extract parser/validator from jhat for use in tests JDK-8079890 core-svc heapdump/JMapHeap should be unquarantined JDK-8080538 core-svc hprof does not work well with multiple agents on non-Solaris platforms JDK-8076524 core-svc Remove jhat tests and help library from JDK JDK-8076473 core-svc Remove the jhat code and update makefiles JDK-8079120 core-svc serviceability/dcmd/gc/HeapDumpAllTest.java: compilation failed JDK-6755586 core-svc Test com/sun/jdi/NoLaunchOptionTest.java may erroneously fail JDK-8078436 hotspot java/util/stream/boottest/java/util/stream/UnorderedTest.java crashed JDK-8079545 hotspot [TESTBUG] hotspot_basicvmtest doesn't fail even if VM crashes JDK-8079112 hotspot [TESTBUG] hotspot_jprt group in TEST.groups refers to non-existent gro JDK-8078558 hotspot [TESTBUG] Merge hotspot_wbapitest with existing jtreg jprt job JDK-8033561 hotspot [TESTBUG] Nightly test metaspace/gc/firstGC_99m timeout JDK-8078593 hotspot [TESTBUG] ppc: Enable jtreg tests for new features JDK-8077529 hotspot [TESTBUG] Remove hotspot.internalvmtests from jprt config JDK-8030680 hotspot 292 cleanup from default method code assessment JDK-8080586 hotspot aarch64: hotspot test compiler/codegen/7184394/TestAESMain.java fails JDK-8079561 hotspot Add a method to convert counters to milliseconds JDK-8076276 hotspot Add support for AVX512 JDK-8079579 hotspot Add SuspendibleThreadSetLeaver and make SuspendibleThreadSet::joint()/ JDK-8077276 hotspot allocating heap with UseLargePages and HugeTLBFS may trash existing me JDK-8079797 hotspot assert(index >= 0 && index < _count) failed: check JDK-8079360 hotspot AttachProviderImpl could not be instantiated JDK-8079556 hotspot BACKOUT - Determining the desired PLAB size adjusts to the the number JDK-8076998 hotspot BadHandshakeTest.java fails due to warnings in output JDK-8078497 hotspot C2's superword optimization causes unaligned memory accesses JDK-8079330 hotspot Circular dependency between G1CollectedHeap and G1BlockOffsetSharedArr JDK-8078897 hotspot Clean out unused code in G1MMUTracker JDK-8080420 hotspot Compilation of TestVectorizationWithInvariant fails with "error: packa JDK-8080100 hotspot compiler/rtm/* tests fail due to Compilation failed JDK-8079080 hotspot ConcurrentMark::mark_stack_push(oop) is unused JDK-8079343 hotspot Crash in PhaseIdealLoop with "assert(!had_error) failed: bad dominance JDK-8073204 hotspot Determining the desired PLAB size adjusts to the the number of threads JDK-8079280 hotspot Fix format warning/error in vm_version_ppc.cpp JDK-8079200 hotspot Fix heapdump tests to validate heapdump after jhat is removed JDK-8079148 hotspot Fix incorrect include guards JDK-8079337 hotspot Format string issues in workgroup.cpp and taskqueue.cpp JDK-8076542 hotspot G1 does not print heap page size information with -XX:+TracePageSizes JDK-8073476 hotspot G1 logging ignores changes to PrintGC* flags via MXBeans JDK-8013171 hotspot G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index JDK-7006810 hotspot G1: Introduce peace-of-mind checking in the Suspendible Thread Set JDK-8079840 hotspot G1StringDedupTable::deduplicate() reset String hash value unnecessaril JDK-6407976 hotspot GC worker number should be unsigned JDK-8076995 hotspot gc/ergonomics/TestDynamicNumberOfGCThreads.java failed with java.lang. JDK-8073669 hotspot gc/TestSoftReferencesBehaviorOnOOME.java times out in nightlies JDK-8078613 hotspot HAS_BEEN_MOVED has been moved JDK-8078405 hotspot Heap decommit failed in TestShrinkAuxiliaryData tests JDK-8069005 hotspot Hotspot crashes in System.out.println with assert(resolved_method->met JDK-8076284 hotspot Improve vectorization of parallel streams JDK-8078628 hotspot linux-zero does not build without precompiled header JDK-8073632 hotspot Make auxiliary data structures know their own translation factor JDK-8078345 hotspot Move PSParallelCompact::mark_and_push to ParCompactionManager JDK-8064458 hotspot OopMap class could be more compact JDK-8076188 hotspot Optimize arraycopy out for non escaping destination JDK-8076579 hotspot Popping a stack frame after exception breakpoint sets last method para JDK-8078601 hotspot print_concurrent_locks should be guarded with INCLUDE_SERVICES JDK-8079275 hotspot Remove CollectedHeap::use_parallel_gc_threads JDK-8079091 hotspot Remove dictionary NULL check on common path of BlockFreeList methods JDK-8071462 hotspot Remove G1ParGCAllocator::alloc_buffer_waste JDK-8078341 hotspot Remove the unused PSParallelCompact::_updated_int_array_klass_obj JDK-8078340 hotspot Remove the unused PSParallelCompact::KeepAliveClosure JDK-8031401 hotspot Remove unused code in the reference processor JDK-8076177 hotspot Remove usage of stack.inline.hpp functions from taskqueue.hpp JDK-8067013 hotspot Rename the com.oracle.java.testlibary package JDK-8078563 hotspot Restrict reduction optimization JDK-8075215 hotspot SATB buffer processing found reclaimed humongous object JDK-8076318 hotspot split verifier needs to add TraceClassResolution JDK-8079263 hotspot Suppress warning about disabling adaptive size policy when enabling Us JDK-8080048 hotspot Test jdk/test/com/sun/jdi/NoLaunchOptionTest.java was merged incorrect JDK-8075492 hotspot update IGV in hs-comp JDK-8075966 hotspot Update ProjectCreator to create projects using Visual Studio 2013 tool JDK-8079564 hotspot Use FP register as proper frame pointer in JIT compiled code on aarch6 JDK-8074016 infrastructure Add convenient way of adding custom test targets to hotspot's test mak JDK-8080630 infrastructure Stop doing sed manipulation of manifest files in SetupJavaCompilation JDK-8079693 security-libs Add support for ECDSA P-384 and P-521 curves to XML Signature JDK-8079138 security-libs Additional negative tests for XML signature processing JDK-8077102 security-libs dns_lookup_realm should be false by default JDK-8079140 security-libs IgnoreAllErrorHandler should use doPrivileged when it reads system pro JDK-8048820 security-libs Implement tests for SecretKeyFactory JDK-8080522 security-libs Optimize string operations in java.base/share/classes/sun/security/x50 JDK-8072578 security-libs ProbeKeystores.java creates files in test.src JDK-8048599 security-libs Tests for key wrap and unwrap operations JDK-8055753 security-libs Use ConcurrentHashMap to map ProtectionDomain to PermissionCollection JDK-8079613 tools Deeply chained expressions + several overloads + unnecessary inference JDK-8068464 tools Group 10d: golden files for tests in tools/javac dir JDK-8068465 tools Group 10e: golden files for tests in tools/javac dir JDK-8074387 tools Group 11: golden files for coin tests in tools/javac dir JDK-8074408 tools Group 12: golden files for tests in tools/javac dir JDK-8074417 tools Group 13a: golden files for tests in tools/javac/generics dir JDK-8074425 tools Group 13b: golden files for tests in tools/javac/generics dir JDK-8074502 tools Group 13c: golden files for tests in tools/javac/generics dir JDK-8074514 tools Group 13d: golden files for tests in tools/javac/generics dir JDK-8075163 tools Group 14a: golden files for tests in tools/javac/generics/wildcards di JDK-8075164 tools Group 14b: golden files for tests in tools/javac/generics/wildcards di JDK-8075165 tools Group 14c: golden files for tests in tools/javac/generics/wildcards di JDK-8075166 tools Group 14d: golden files for tests in tools/javac/generics/wildcards di JDK-8077822 tools javac does not recognize '*.java' as file if '-J' option is specified JDK-8080572 tools langtools/test/tools/javac/generics/T5011073.java failing JDK-8080870 tools Open up Dependencies for use from other packages JDK-8080539 tools Remove few test files that did not get removed with the patch JDK-8080897 tools tests broken in bad merge From yasuenag at gmail.com Thu May 28 03:21:41 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 28 May 2015 12:21:41 +0900 Subject: JDK-8081295: Build failed with GCC 5.1.1 In-Reply-To: <5565BF2F.7000504@oracle.com> References: <5565906D.4010508@gmail.com> <5565BF2F.7000504@oracle.com> Message-ID: <556689C5.3020504@gmail.com> Hi David, I posted email to 2d-dev and serviceability-dev. If my patch is reviewed, I will push it to jdk9/client . Thanks, Yasumasa On 2015/05/27 21:57, David Holmes wrote: > Hi Yasumasa, > > As Erik wrote in the CR each part of this needs to be reviewed by the > appropriate component team - this seems to be mostly client-libs with a > dash of serviceability. > > Also note that only hotspot pushes need a sponsor as they have to go in > via our JPRT build/test system. In other areas any JDK9 committer can > push reviewed changes directly (with assumed sufficient build/test > coverage). > > David > > On 27/05/2015 7:37 PM, Yasumasa Suenaga wrote: >> Hi all, >> >> I don't know where should I post this issue - so I post jdk9-dev. >> >> I tried to build jdk9/dev on Fedora22 with GCC 5.1.1, however, it was failed. >> I found several problems: >> >> >> System: >> Fedora release 22 (Twenty Two) x86_64 >> - gcc-5.1.1-1.fc22.x86_64 >> >> >> Problems: >> 1. Array bounds check in GCC >> - jdk/src/java.desktop/share/native/libjavajpeg/jcmaster.c >> - jdk/src/java.desktop/share/native/libjavajpeg/jquant1.c >> - jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_64.c >> - jdk/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp_f.c >> >> It seems to be bug of GCC: >> Bug 59124: [4.8/4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds" >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 >> >> I think implementations of these files have no problem. >> So I propose to ignore warning(s) of compiler through pragma option as >> workaround when we use GCC [1]. >> >> >> 2. Local variables might be clobbered >> - jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c >> >> SplashDecodePng() calls setjmp(3). >> Some local variables initialize before setjmp() call, and use after it. >> Their initial values are only used at cleanup code (*done* label) and >> actual values are stored only after setjmp() call. >> So I think we can ignore this error through pragma option [1]. >> >> However, cleanup code (*done* label) might be occurred runtime error in >> libc when some pointers are NULL. So I add NULL check in it. >> >> >> 3. Incorrect condition >> - jdk/src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c >> >> searchAllSourceNames() returns int value. However, branch condition in >> eventFilterRestricted_passesFilter() treats it as boolean value. >> >> >> I've created patch for this enhancement. >> Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8081295/webrev.00/ >> >> >> I'm jdk9 committer, but I'm not employee at Oracle. >> So I need a Sponsor. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html >> From peter.levart at gmail.com Thu May 28 13:51:15 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 28 May 2015 15:51:15 +0200 Subject: JDK-8081295: Build failed with GCC 5.1.1 In-Reply-To: <556689C5.3020504@gmail.com> References: <5565906D.4010508@gmail.com> <5565BF2F.7000504@oracle.com> <556689C5.3020504@gmail.com> Message-ID: <55671D53.5040708@gmail.com> On 05/28/2015 05:21 AM, Yasumasa Suenaga wrote: > Hi David, > > I posted email to 2d-dev and serviceability-dev. > If my patch is reviewed, I will push it to jdk9/client . > > > Thanks, > > Yasumasa Hi Yasumasa, I think you have the same problem as I and I already filed an issue for it: https://bugs.openjdk.java.net/browse/JDK-8080695 The fix has already been approved. I'll push it shortly to jdk9/client. Regards, Peter > > On 2015/05/27 21:57, David Holmes wrote: >> Hi Yasumasa, >> >> As Erik wrote in the CR each part of this needs to be reviewed by the >> appropriate component team - this seems to be mostly client-libs with a >> dash of serviceability. >> >> Also note that only hotspot pushes need a sponsor as they have to go in >> via our JPRT build/test system. In other areas any JDK9 committer can >> push reviewed changes directly (with assumed sufficient build/test >> coverage). >> >> David >> >> On 27/05/2015 7:37 PM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> I don't know where should I post this issue - so I post jdk9-dev. >>> >>> I tried to build jdk9/dev on Fedora22 with GCC 5.1.1, however, it was failed. >>> I found several problems: >>> >>> >>> System: >>> Fedora release 22 (Twenty Two) x86_64 >>> - gcc-5.1.1-1.fc22.x86_64 >>> >>> >>> Problems: >>> 1. Array bounds check in GCC >>> - jdk/src/java.desktop/share/native/libjavajpeg/jcmaster.c >>> - jdk/src/java.desktop/share/native/libjavajpeg/jquant1.c >>> - jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_64.c >>> - jdk/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp_f.c >>> >>> It seems to be bug of GCC: >>> Bug 59124: [4.8/4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds" >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 >>> >>> I think implementations of these files have no problem. >>> So I propose to ignore warning(s) of compiler through pragma option as >>> workaround when we use GCC [1]. >>> >>> >>> 2. Local variables might be clobbered >>> - jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c >>> >>> SplashDecodePng() calls setjmp(3). >>> Some local variables initialize before setjmp() call, and use after it. >>> Their initial values are only used at cleanup code (*done* label) and >>> actual values are stored only after setjmp() call. >>> So I think we can ignore this error through pragma option [1]. >>> >>> However, cleanup code (*done* label) might be occurred runtime error in >>> libc when some pointers are NULL. So I add NULL check in it. >>> >>> >>> 3. Incorrect condition >>> - jdk/src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c >>> >>> searchAllSourceNames() returns int value. However, branch condition in >>> eventFilterRestricted_passesFilter() treats it as boolean value. >>> >>> >>> I've created patch for this enhancement. >>> Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8081295/webrev.00/ >>> >>> >>> I'm jdk9 committer, but I'm not employee at Oracle. >>> So I need a Sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html >>> From peter.levart at gmail.com Thu May 28 14:01:04 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 28 May 2015 16:01:04 +0200 Subject: JDK-8081295: Build failed with GCC 5.1.1 In-Reply-To: <55671D53.5040708@gmail.com> References: <5565906D.4010508@gmail.com> <5565BF2F.7000504@oracle.com> <556689C5.3020504@gmail.com> <55671D53.5040708@gmail.com> Message-ID: <55671FA0.40400@gmail.com> On 05/28/2015 03:51 PM, Peter Levart wrote: > > On 05/28/2015 05:21 AM, Yasumasa Suenaga wrote: >> Hi David, >> >> I posted email to 2d-dev and serviceability-dev. >> If my patch is reviewed, I will push it to jdk9/client . >> >> >> Thanks, >> >> Yasumasa > Hi Yasumasa, > > I think you have the same problem as I and I already filed an issue for it: > > https://bugs.openjdk.java.net/browse/JDK-8080695 > > The fix has already been approved. I'll push it shortly to jdk9/client. Well, my fix is only for the issue in JDK-8080695. I simply marked the locals as volatile. Do you know for sure that the variables can't be clobbered by longjump if you just disable the warning? I can pull my fix back in favor of yours which covers other issues too, if you want. Regards, Peter > > Regards, Peter > >> On 2015/05/27 21:57, David Holmes wrote: >>> Hi Yasumasa, >>> >>> As Erik wrote in the CR each part of this needs to be reviewed by the >>> appropriate component team - this seems to be mostly client-libs with a >>> dash of serviceability. >>> >>> Also note that only hotspot pushes need a sponsor as they have to go in >>> via our JPRT build/test system. In other areas any JDK9 committer can >>> push reviewed changes directly (with assumed sufficient build/test >>> coverage). >>> >>> David >>> >>> On 27/05/2015 7:37 PM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> I don't know where should I post this issue - so I post jdk9-dev. >>>> >>>> I tried to build jdk9/dev on Fedora22 with GCC 5.1.1, however, it was failed. >>>> I found several problems: >>>> >>>> >>>> System: >>>> Fedora release 22 (Twenty Two) x86_64 >>>> - gcc-5.1.1-1.fc22.x86_64 >>>> >>>> >>>> Problems: >>>> 1. Array bounds check in GCC >>>> - jdk/src/java.desktop/share/native/libjavajpeg/jcmaster.c >>>> - jdk/src/java.desktop/share/native/libjavajpeg/jquant1.c >>>> - jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_64.c >>>> - jdk/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp_f.c >>>> >>>> It seems to be bug of GCC: >>>> Bug 59124: [4.8/4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds" >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 >>>> >>>> I think implementations of these files have no problem. >>>> So I propose to ignore warning(s) of compiler through pragma option as >>>> workaround when we use GCC [1]. >>>> >>>> >>>> 2. Local variables might be clobbered >>>> - jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c >>>> >>>> SplashDecodePng() calls setjmp(3). >>>> Some local variables initialize before setjmp() call, and use after it. >>>> Their initial values are only used at cleanup code (*done* label) and >>>> actual values are stored only after setjmp() call. >>>> So I think we can ignore this error through pragma option [1]. >>>> >>>> However, cleanup code (*done* label) might be occurred runtime error in >>>> libc when some pointers are NULL. So I add NULL check in it. >>>> >>>> >>>> 3. Incorrect condition >>>> - jdk/src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c >>>> >>>> searchAllSourceNames() returns int value. However, branch condition in >>>> eventFilterRestricted_passesFilter() treats it as boolean value. >>>> >>>> >>>> I've created patch for this enhancement. >>>> Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8081295/webrev.00/ >>>> >>>> >>>> I'm jdk9 committer, but I'm not employee at Oracle. >>>> So I need a Sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html >>>> From yasuenag at gmail.com Thu May 28 14:48:33 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 28 May 2015 23:48:33 +0900 Subject: JDK-8081295: Build failed with GCC 5.1.1 In-Reply-To: <55671FA0.40400@gmail.com> References: <5565906D.4010508@gmail.com> <5565BF2F.7000504@oracle.com> <556689C5.3020504@gmail.com> <55671D53.5040708@gmail.com> <55671FA0.40400@gmail.com> Message-ID: <55672AC1.7050107@gmail.com> Hi Peter, I CC'ed this email to 2d-dev and Alexander. > I can pull my fix back in favor of yours which covers other issues too, > if you want. I think libsplashscreen should be fixed on JDK-8080695. I posted new webrev about JDK-8081295 which exclude libsplashscreen [1]. And Alexxander suggested fix about JDK-8080695 [2]. I prefer to fix as so. Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005453.html [2] http://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005448.html On 2015/05/28 23:01, Peter Levart wrote: > > > On 05/28/2015 03:51 PM, Peter Levart wrote: >> >> On 05/28/2015 05:21 AM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>> I posted email to 2d-dev and serviceability-dev. >>> If my patch is reviewed, I will push it to jdk9/client . >>> >>> >>> Thanks, >>> >>> Yasumasa >> Hi Yasumasa, >> >> I think you have the same problem as I and I already filed an issue for it: >> >> https://bugs.openjdk.java.net/browse/JDK-8080695 >> >> The fix has already been approved. I'll push it shortly to jdk9/client. > > Well, my fix is only for the issue in JDK-8080695. I simply marked the > locals as volatile. Do you know for sure that the variables can't be > clobbered by longjump if you just disable the warning? > > I can pull my fix back in favor of yours which covers other issues too, > if you want. > > Regards, Peter > >> >> Regards, Peter >> >>> On 2015/05/27 21:57, David Holmes wrote: >>>> Hi Yasumasa, >>>> >>>> As Erik wrote in the CR each part of this needs to be reviewed by the >>>> appropriate component team - this seems to be mostly client-libs with a >>>> dash of serviceability. >>>> >>>> Also note that only hotspot pushes need a sponsor as they have to go in >>>> via our JPRT build/test system. In other areas any JDK9 committer can >>>> push reviewed changes directly (with assumed sufficient build/test >>>> coverage). >>>> >>>> David >>>> >>>> On 27/05/2015 7:37 PM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> I don't know where should I post this issue - so I post jdk9-dev. >>>>> >>>>> I tried to build jdk9/dev on Fedora22 with GCC 5.1.1, however, it was failed. >>>>> I found several problems: >>>>> >>>>> >>>>> System: >>>>> Fedora release 22 (Twenty Two) x86_64 >>>>> - gcc-5.1.1-1.fc22.x86_64 >>>>> >>>>> >>>>> Problems: >>>>> 1. Array bounds check in GCC >>>>> - jdk/src/java.desktop/share/native/libjavajpeg/jcmaster.c >>>>> - jdk/src/java.desktop/share/native/libjavajpeg/jquant1.c >>>>> - jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_64.c >>>>> - jdk/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp_f.c >>>>> >>>>> It seems to be bug of GCC: >>>>> Bug 59124: [4.8/4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds" >>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 >>>>> >>>>> I think implementations of these files have no problem. >>>>> So I propose to ignore warning(s) of compiler through pragma option as >>>>> workaround when we use GCC [1]. >>>>> >>>>> >>>>> 2. Local variables might be clobbered >>>>> - jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c >>>>> >>>>> SplashDecodePng() calls setjmp(3). >>>>> Some local variables initialize before setjmp() call, and use after it. >>>>> Their initial values are only used at cleanup code (*done* label) and >>>>> actual values are stored only after setjmp() call. >>>>> So I think we can ignore this error through pragma option [1]. >>>>> >>>>> However, cleanup code (*done* label) might be occurred runtime error in >>>>> libc when some pointers are NULL. So I add NULL check in it. >>>>> >>>>> >>>>> 3. Incorrect condition >>>>> - jdk/src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c >>>>> >>>>> searchAllSourceNames() returns int value. However, branch condition in >>>>> eventFilterRestricted_passesFilter() treats it as boolean value. >>>>> >>>>> >>>>> I've created patch for this enhancement. >>>>> Could you review it? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8081295/webrev.00/ >>>>> >>>>> >>>>> I'm jdk9 committer, but I'm not employee at Oracle. >>>>> So I need a Sponsor. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html >>>>> > From mark.reinhold at oracle.com Thu May 28 23:35:07 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 28 May 2015 16:35:07 -0700 Subject: JEPs proposed to target JDK 9 (2015/5/21) In-Reply-To: <20150521150533.791873@eggemoggin.niobe.net> References: <20150521150533.791873@eggemoggin.niobe.net> Message-ID: <20150528163507.327964@eggemoggin.niobe.net> 2015/5/21 3:05 -0700, mark.reinhold at oracle.com: > The following JEPs have been placed into the "Proposed to Target" > state by their owners after discussion and review: > > 233: Generate Run-Time Compiler Tests Automatically > http://openjdk.java.net/jeps/233 > > 246: Leverage CPU Instructions for GHASH and RSA > http://openjdk.java.net/jeps/246 > > 248: Make G1 the Default Garbage Collector > http://openjdk.java.net/jeps/248 > > 249: OCSP Stapling for TLS > http://openjdk.java.net/jeps/249 > > 250: Store Interned Strings in CDS Archives > http://openjdk.java.net/jeps/250 > > 252: Use CLDR Locale Data by Default > http://openjdk.java.net/jeps/252 > > Feedback on these proposals is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC next > Thursday, 28 May, or if they're raised and then satisfactorily > answered, then per the JEP 2.0 process proposal [1] I'll target > these JEPs to JDK 9. I've heard no objection to JEPs 233, 246, 249, 250, and 252, so I've targeted them to JDK 9. A discussion of JEP 248 (Make G1 the Default Garbage Collector) is ongoing, so I'll hold off on that one for now. - Mark From magnus.ihse.bursie at oracle.com Fri May 29 10:19:20 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 29 May 2015 12:19:20 +0200 Subject: CFV: New JDK 9 Reviewer: Per =?UTF-8?B?TGlkw6lu?= In-Reply-To: <5564414D.6040808@oracle.com> References: <5564414D.6040808@oracle.com> Message-ID: <55683D28.4020706@oracle.com> Vote: yes /Magnus On 2015-05-26 11:47, Stefan Karlsson wrote: > I hereby nominate Per Lid?n to JDK 9 Reviewer. > > Per is a member of the HotSpot GC team and has contributed 41 patches > to HotSpot [4]. He is also the author of "String Deduplication in G1" > [3]. > > Votes are due by 11:45 AM CEST, Tuesday June 9, 2015. > > Only current JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/jeps/192 > [4] List of patches: > 8080930: SA changes broke bootcycle-images builds > 8080584: isGCActiveMark.hpp should not include parallelScavengeHeap.hpp > 8080585: concurrentGCThread.hpp should not include > suspendibleThreadSet.hpp > 8080581: Align SA with new GC directory structure > 8079792: GC directory structure cleanup > 8079579: Add SuspendibleThreadSetLeaver and make > SuspendibleThreadSet::joint()/leave() private > 8079330: Circular dependency between G1CollectedHeap and > G1BlockOffsetSharedArray > 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit > PtrQueue::_index > 8079148: Fix incorrect include guards > 8068582: UseSerialGC not always set up properly > 8077417: Cleanup of Universe::initialize_heap() > 8077415: Remove duplicate variables holding the CollectedHeap > 8077413: Avoid use of Universe::heap() inside collectors > 8076534: CollectedHeapName in SA agent incorrect > 8076447: Remove unused MemoryManager::kind() > 8076294: Cleanup of CollectedHeap::kind() > 8076231: Remove unused is_in_partial_collection() > 8046231: G1: Code root location ... from nmethod ... not in strong > code roots for region > 8044796: G1: Enable G1CollectedHeap::stop() > 8044768: Backout fix for JDK-8040807 > 8040807: G1: Enable G1CollectedHeap::stop() > 8042310: TestStringDeduplicationMemoryUsage test failing > 8044132: Quarantine unstable/broken GC tests > 8039042: G1: Phantom zeros in cardtable > 8040804: G1: Concurrent mark stuck in loop calling os::elapsedVTime() > 8040803: G1: Concurrent mark hangs when mark stack overflows > 8040245: G1: VM hangs during shutdown > 8039147: Cleanup SuspendibleThreadSet > 8037112: gc/g1/TestHumongousAllocInitialMark.java caused SIGSEGV > 8038461: Test gc/g1/TestStringDeduplicationMemoryUsage.java fails with > unexpected memory usage > 8029075: String deduplication in G1 > 8036673: G1: Abort weak reference processing if mark stack overflows > 8036672: G1: alloc_purpose in copy_to_survivor_space() used incorrectly > 8031703: Missing post-barrier in ReferenceProcessor > 8029162: G1: Shared SATB queue never enabled > 8029255: G1: Reference processing should not enqueue references on the > shared SATB queue > 8024634: gc/startup_warnings tests can fail due to unrelated warnings > 8024632: Description of InitialSurvivorRatio flag in globals.hpp is > incorrect > 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full > gcs, expect 0 full gcs > 8024974: Incorrect use of GC_locker::is_active() > 8014022: G1: Non Java threads should lock the shared SATB queue lock > without safepoint checks > From marcus.lagergren at oracle.com Fri May 29 16:04:20 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 29 May 2015 18:04:20 +0200 Subject: =?utf-8?Q?Re=3A_CFV=3A_New_JDK_9_Reviewer=3A_Per_Lid=C3=A9n?= In-Reply-To: <55683D28.4020706@oracle.com> References: <5564414D.6040808@oracle.com> <55683D28.4020706@oracle.com> Message-ID: Vote yes: /M (Totally, yes! Having been instrumental in prying away Per from Ericsson in 2009 (which only took six months, thanks to swift Oracle hiring policies), and having worked alongside with Per for 3 years, I am confident that he is a wizard and can do anything!) /M > On 29 May 2015, at 12:19, Magnus Ihse Bursie wrote: > > Vote: yes > > /Magnus > > On 2015-05-26 11:47, Stefan Karlsson wrote: >> I hereby nominate Per Lid?n to JDK 9 Reviewer. >> >> Per is a member of the HotSpot GC team and has contributed 41 patches to HotSpot [4]. He is also the author of "String Deduplication in G1" [3]. >> >> Votes are due by 11:45 AM CEST, Tuesday June 9, 2015. >> >> Only current JDK 9 Reviewers [1] are eligible to vote >> on this nomination. Votes must be cast in the open by replying >> to this mailing list. >> >> For Three-Vote Consensus voting instructions, see [2]. >> >> Stefan Karlsson >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#reviewer-vote >> [3] http://openjdk.java.net/jeps/192 >> [4] List of patches: >> 8080930: SA changes broke bootcycle-images builds >> 8080584: isGCActiveMark.hpp should not include parallelScavengeHeap.hpp >> 8080585: concurrentGCThread.hpp should not include suspendibleThreadSet.hpp >> 8080581: Align SA with new GC directory structure >> 8079792: GC directory structure cleanup >> 8079579: Add SuspendibleThreadSetLeaver and make SuspendibleThreadSet::joint()/leave() private >> 8079330: Circular dependency between G1CollectedHeap and G1BlockOffsetSharedArray >> 8013171: G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index >> 8079148: Fix incorrect include guards >> 8068582: UseSerialGC not always set up properly >> 8077417: Cleanup of Universe::initialize_heap() >> 8077415: Remove duplicate variables holding the CollectedHeap >> 8077413: Avoid use of Universe::heap() inside collectors >> 8076534: CollectedHeapName in SA agent incorrect >> 8076447: Remove unused MemoryManager::kind() >> 8076294: Cleanup of CollectedHeap::kind() >> 8076231: Remove unused is_in_partial_collection() >> 8046231: G1: Code root location ... from nmethod ... not in strong code roots for region >> 8044796: G1: Enable G1CollectedHeap::stop() >> 8044768: Backout fix for JDK-8040807 >> 8040807: G1: Enable G1CollectedHeap::stop() >> 8042310: TestStringDeduplicationMemoryUsage test failing >> 8044132: Quarantine unstable/broken GC tests >> 8039042: G1: Phantom zeros in cardtable >> 8040804: G1: Concurrent mark stuck in loop calling os::elapsedVTime() >> 8040803: G1: Concurrent mark hangs when mark stack overflows >> 8040245: G1: VM hangs during shutdown >> 8039147: Cleanup SuspendibleThreadSet >> 8037112: gc/g1/TestHumongousAllocInitialMark.java caused SIGSEGV >> 8038461: Test gc/g1/TestStringDeduplicationMemoryUsage.java fails with unexpected memory usage >> 8029075: String deduplication in G1 >> 8036673: G1: Abort weak reference processing if mark stack overflows >> 8036672: G1: alloc_purpose in copy_to_survivor_space() used incorrectly >> 8031703: Missing post-barrier in ReferenceProcessor >> 8029162: G1: Shared SATB queue never enabled >> 8029255: G1: Reference processing should not enqueue references on the shared SATB queue >> 8024634: gc/startup_warnings tests can fail due to unrelated warnings >> 8024632: Description of InitialSurvivorRatio flag in globals.hpp is incorrect >> 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full gcs, expect 0 full gcs >> 8024974: Incorrect use of GC_locker::is_active() >> 8014022: G1: Non Java threads should lock the shared SATB queue lock without safepoint checks >> > From denji0k at gmail.com Sat May 30 00:36:52 2015 From: denji0k at gmail.com (Denis Denisov) Date: Sat, 30 May 2015 03:36:52 +0300 Subject: Bug jdk-9 b66 detect broken (macosx 27/May/2015) Message-ID: After installing the b65-b66 OSX ceased to define a new version of java and uses java 6 always! The problem with any software, the last working version of it JDK9 (b63). - http://i.imgur.com/EAXW9Bz.png JVMVersion 1.9+,1.6*,1.7+ JDK9 (b64 - b66) # javac -version javac 1.6.0_65 JDK9 (b63) # javac -version # javac 1.9.0-ea # sw_vers ProductName: Mac OS X ProductVersion: 10.10.4 BuildVersion: 14E26a -- Sincerely, Denis Denisov