August 2016 - core-libs-dev

JDK-8067661: transferTo proposal for Appendable
by Patrick Reinhart 15 Nov '17

15 Nov '17

Hi Chris & Pavel, Based on the transferTo Method on the InputStream I would propose to introduce a default method on the Readable interface. In that way the method can be used for all existing implementations of Readable and still be implemented in a special way by a individual implementer. /** * Reads all characters from this readable and writes the characters to * the given appendable in the order that they are read. On return, this * readable will be at end its data. * <p> * This method may block indefinitely reading from the readable, or * writing to the appendable. The behavior for the case where the readable * and/or appendable is <i>asynchronously closed</i>, or the thread * interrupted during the transfer, is highly readable and appendable * specific, and therefore not specified. * <p> * If an I/O error occurs reading from the readable or writing to the * appendable, then it may do so after some characters have been read or * written. Consequently the readable may not be at end of its data and * one, or both participants may be in an inconsistent state. It is strongly * recommended that both readable and appendable be promptly closed * if needed and an I/O error occurs. * * @param out the appendable, non-null * @return the number of characters transferred * @throws IOException if an I/O error occurs when reading or writing * @throws NullPointerException if {@code out} is {@code null} * * @since 1.9 */ default long transferTo(Appendable out) throws IOException { .... } -Patrick

5 26

RFR 8145635 : Add TCP_QUICKACK socket option
by vyom 12 Oct '17

12 Oct '17

Hi All, Please review my code changes for the below issue. Bug: JDK-8145635 : Add TCP_QUICKACK socket option Webrev: http://cr.openjdk.java.net/~vtewari/8145635/webrev0.0/index.html <http://cr.openjdk.java.net/%7Evtewari/8145635/webrev0.0/index.html> Currently TCP_QUICKACK is only supported on Linux( since Linux 2.4.4) so i implemented is as "ExtendedSocketOption". Thanks, Vyom

5 8

ISO-8859-16 charset/decoder/encoder
by Charles Oliver Nutter 25 Aug '17

25 Aug '17

Again, apologies if this is not the right list. OpenJDK does not currently contain support for encoding/decoding ISO-8859-16. A JRuby user recently reported that they needed this encoding. So, I implemented it. Here's a link to the charset/decoder/encoder in JRuby's repository: https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/uti… I tried to follow the general form of the other ISO-8859 charsets, but there's probably more reuse possible (I believe they use sun.nio.cs classes I can't access). Happy to contribute this. Unsure of the process. - Charlie

4 5

Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed
by Mandy Chung 14 Mar '17

14 Mar '17

Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.00/index.html StackFrame::getFileName and StackFrame::getLineNumber are originally proposed with the view of any stack walking code can migrate to the StackWalker API without the use of StackTraceElement. File name and line number are useful for debugging and troubleshooting purpose. It has additional overhead to map from a method and BCI to look up the file name and line number. StackFrame::toStackTraceElement method returns StackTraceElement that includes the file name and line number. There is no particular benefit to duplicate getFileName and getLineNumber methods in StackFrame. It is equivalently convenient to call StackFrame.toStackTraceElement().getFileName() (or getLineNumber). This patch proposes to remove StackFrame::getFileName and StackFrame::getLineNumber methods since such information can be obtained from StackFrame.toStackTraceElement(). Mandy

7 45

Proposal: java.lang.reflect.Proxy and default methods
by Peter Levart 03 Mar '17

03 Mar '17

Hi, Since Java SE 8 introduced default methods in interfaces there was a question what to do with java.lang.reflect.Proxy API. Nothing was done to the API at that time, so the default behavior is to proxy default methods too. InvocationHandler gets invoked for default methods, but it has not provision to forward such calls to the default implementations in the interfaces. I propose a simple API addition that allows calling super default methods in proxy instances: http://cr.openjdk.java.net/~plevart/jdk9-dev/Proxy.invokeSuperDefaults/webr… With this addition one can simply decide in the InvocationHandler what to do with invocations to default methods and can forward such invocation to the default implementation: public class Test { interface I1 { default void m() { System.out.println(" default I1.m() called"); } } interface I2 { default void m() { System.out.println(" default I2.m() called"); } } interface I12 extends I1, I2 { @Override void m(); default int sum(int a, int b) { return a + b; } default Object[] concat(Object first, Object... rest) { Object[] result = new Object[1 + rest.length]; result[0] = first; System.arraycopy(rest, 0, result, 1, rest.length); return result; } } public static void main(String[] args) { InvocationHandler h = (proxy, method, params) -> { System.out.println("\nInvocationHandler called for: " + method + " with parameters: " + Arrays.toString(params)); if (method.isDefault()) { try { return Proxy.invokeSuper(proxy, method, params); } catch (InvocationTargetException e) { throw e.getCause(); } } else { switch (method.getName()) { case "m": System.out.println(" abstract I12.m(): called"); return null; default: throw new UnsupportedOperationException( "Unsupported method: " + method); } } }; I1 i1 = (I1) Proxy.newProxyInstance( I1.class.getClassLoader(), new Class<?>[]{I1.class}, h); i1.m(); I2 i2 = (I2) Proxy.newProxyInstance( I2.class.getClassLoader(), new Class<?>[]{I2.class}, h); i2.m(); I12 i12 = (I12) Proxy.newProxyInstance( I12.class.getClassLoader(), new Class<?>[]{I12.class}, h); i12.m(); System.out.println(" 1 + 2 = " + i12.sum(1, 2)); System.out.println(" [1] concat [2, 3, 4] = " + Arrays.toString(i12.concat(1, 2, 3, 4))); } } I know FC date is over, but this is really a small change and I have heard several people that such feature is missing from the Proxy API. I'm prepared to create jtreg tests covering the specification if this proposal is accepted. Regards, Peter

7 11

RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are incorrect
by Brent Christian 31 Jan '17

31 Jan '17

Hi, Please review this StackWalker fix in hotspot for 8156073, "2-slot LiveStackFrame locals (long and double) are incorrect" Bug: https://bugs.openjdk.java.net/browse/JDK-8156073 Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.01/ The experimental LiveStackFrame[1] interface for StackWalker provides access to stack frames' local variables, returned in an Object[] from LiveStackFrame.getLocals(). Long and double primitives are returned using two array slots (similar to JVMS section 2.6.1 [2]). This works as indicated on 32-bit JDKs, but needs some fixing on 64-bit. AFAICT under 64-bit, StackValueCollection stores the entire long/double in the 2nd (64-bit) slot: jlong StackValueCollection::long_at(int slot) const { #ifdef _LP64 return at(slot+1)->get_int(); #else ... The first slot goes unused and contains 0, instead of holding half of the long value as stackwalker expects. So stackwalker needs to take care splitting the value between the two slots. The fix examines StackValueCollection::long_at(i), checks for an unexpected 0 value from StackValueCollection::int_at(i), and copies the needed 32-bits (depending on native byte ordering) into the first slot as needed. (The 2nd slot gets truncated to 32-bits in create_primitive_value_instance()). Here's the fix in action on linux_x64 with the updated LocalsAndOperands.java test. Slots 4+5 contain a long, 6+7 contain a double. Before the fix: ... local 3: himom type java.lang.String local 4: 0 type I <-- local 5: 65535 type I local 6: 0 type I <-- local 7: 1293080650 type I local 8: 0 type I After the fix: ... local 3: himom type java.lang.String local 4: 1023 type I <-- local 5: 65535 type I local 6: 1074340347 type I <-- local 7: 1293080650 type I local 8: 0 type I This change also fixes 8158879, "Add new test for verifying 2-slot locals in LiveStackFrame". Thanks to Fabio Tudone (fabio(a)paralleluniverse.co) for the test case. I only test unused ("dead") local variables with -Xint, because they are removed in compiled frames. An automated build & test run on all platforms looks good. It would be good to also do more testing of LiveStackFrame.getStack(), but right now I want to focus on getting this getLocals() fix in. Testing of LiveStackFrame.getStack() will happen in a follow-up issue (8163825). Thanks, -Brent 1. http://hg.openjdk.java.net/jdk9/hs/jdk/file/1efce54b06b7/src/java.base/shar… 2. https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.6.1

5 11

Reading subprocess stdout susceptible to deadlock
by Vitaly Davidovich 23 Jan '17

23 Jan '17

Hi, It seems that doing a blocking read on a subprocess's stdout can lead to deadlock between the thread doing the read and the process reaper thread. The deadlock occurs because the reader is synchronized on the ProcessPipeInputStream, blocks for more data to consume, and process reaper comes along trying to call processExited, which also synchronizes on the same PPIS. The reader appears stuck because it's not seeing the EOF due to process reaper not being able to close the stream. I couldn't find any existing reports of this via quick search, which makes me wonder if I'm missing something. Is this a known issue? Thanks -- Sent from my phone

2 4

Unexpected BindException in Endpoint.publish
by KUBOTA Yuji 05 Dec '16

05 Dec '16

Hi Miroslav and all, Could you please review the below issue and patch? I got the advice by Alan at net-dev. So I want to ask you. http://mail.openjdk.java.net/pipermail/net-dev/2015-December/009361.html ---- I'm at the HackerGarten @ JavaOne15, and write a patch for OpenJDK community. This's second times from JavaOne14. :) We find an unexpected exception in JAX-WS, so I write a patch to fix it. We think that this issue may block the migration to JDK9 from JDK7. If we bind 0.0.0.0 ( using as wildcard ) to publish multiple as the following test code, JDK9 (and JDK8) returns "java.net.BindException: Address already in use.” as the below. But JDK7 does NOT return the exception. - Test code for reproduce --- import javax.jws.*; import javax.xml.ws.*; public class WSTest{ @WebService public static class Method1{ @WebMethod public String getMethod1Value(){ return "from Method1"; } } @WebService public static class Method2{ @WebMethod public String getMethod2Value(){ return "from Method2"; } } public static void main(String[] args) throws Exception{ Endpoint endPoint1 = Endpoint.publish("http://0.0.0.0:8081/method1", new Method1()); Endpoint endPoint2 = Endpoint.publish("http://0.0.0.0:8081/method2", new Method2()); System.out.println("Sleep 3 secs..."); Thread.sleep(3000); endPoint2.stop(); endPoint1.stop(); } } --- - StackTrace --- Exception in thread "main" com.sun.xml.internal.ws.server.ServerRtException: Server Runtime Error: java.net.BindException: Address already in use at com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:117) at com.sun.xml.internal.ws.transport.http.server.HttpEndpoint.publish(HttpEndpoint.java:64) at com.sun.xml.internal.ws.transport.http.server.EndpointImpl.publish(EndpointImpl.java:232) at com.sun.xml.internal.ws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:126) at javax.xml.ws.Endpoint.publish(Endpoint.java:240) at wstest.WSTest.main(WSTest.java:27) Caused by: java.net.BindException: Address already in use at sun.nio.ch.Net.bind0(Native Method) at sun.nio.ch.Net.bind(Net.java:432) at sun.nio.ch.Net.bind(Net.java:424) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) at sun.net.httpserver.ServerImpl.<init>(ServerImpl.java:102) at sun.net.httpserver.HttpServerImpl.<init>(HttpServerImpl.java:50) at sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:35) at com.sun.net.httpserver.HttpServer.create(HttpServer.java:130) at com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:86) ... 5 more ----- To publishes the Endpoint, JAX-WS checks whether the HttpContext has been created by given address, then creates a HttpContext if do not exist. If we sets 0.0.0.0 as given address, JAX-WS checks by ServerSocket#getLocalSocketAddress() (server local address), so returns BindException when 0.0.0.0 has been blinded already. Why so? JAX_WS-941[1] fixes NPE in Endpoint.stop but do not think about above situation. And JAX_WS-941 does not back port to JDK7. So I write a patch which is based jdk9/dev/jaxws (changeset:637:2d84c6f4cbba) to fix the BindException with JAX_WS-941. Please review this patch :) [1]: https://java.net/jira/browse/JAX_WS-941 - Patch --- diff -r 2d84c6f4cbba src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java --- a/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java Thu Oct 22 08:47:47 2015 -0700 +++ b/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java Tue Oct 27 19:48:35 2015 +0900 @@ -38,6 +38,7 @@ import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.logging.Logger; +import java.util.Optional; /** * Manages all the WebService HTTP servers created by JAXWS runtime. @@ -81,24 +82,38 @@ synchronized(servers) { state = servers.get(inetAddress); if (state == null) { - logger.fine("Creating new HTTP Server at "+inetAddress); - // Creates server with default socket backlog - server = HttpServer.create(inetAddress, 0); - server.setExecutor(Executors.newCachedThreadPool()); - String path = url.toURI().getPath(); - logger.fine("Creating HTTP Context at = "+path); - HttpContext context = server.createContext(path); - server.start(); + final int finalPortNum = port; + Optional<ServerState> stateOpt = + servers.values() + .stream() + .filter(s -> s.getServer() + .getAddress() + .getPort() == finalPortNum) + .findAny(); - // we have to get actual inetAddress from server, which can differ from the original in some cases. - // e.g. A port number of zero will let the system pick up an ephemeral port in a bind operation, - // or IP: 0.0.0.0 - which is used to monitor network traffic from any valid IP address - inetAddress = server.getAddress(); + if (inetAddress.getAddress().isAnyLocalAddress() && + stateOpt.isPresent()) { + state = stateOpt.get(); + } else { + logger.fine("Creating new HTTP Server at "+inetAddress); + // Creates server with default socket backlog + server = HttpServer.create(inetAddress, 0); + server.setExecutor(Executors.newCachedThreadPool()); + String path = url.toURI().getPath(); + logger.fine("Creating HTTP Context at = "+path); + HttpContext context = server.createContext(path); + server.start(); - logger.fine("HTTP server started = "+inetAddress); - state = new ServerState(server, path); - servers.put(inetAddress, state); - return context; + // we have to get actual inetAddress from server, which can differ from the original in some cases. + // e.g. A port number of zero will let the system pick up an ephemeral port in a bind operation, + // or IP: 0.0.0.0 - which is used to monitor network traffic from any valid IP address + inetAddress = server.getAddress(); + + logger.fine("HTTP server started = "+inetAddress); + state = new ServerState(server, path); + servers.put(inetAddress, state); + return context; + } } } server = state.getServer(); --- Thanks, Yuji

3 7

RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale
by Bhanu Gopularam 21 Nov '16

21 Nov '16

Hi all, May I request you to review fix for following issue Bug id: https://bugs.openjdk.java.net/browse/JDK-8158880 Solution: To avoid test failure in non english locales, set the default locale while initial test setup Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.00/ Thanks, Bhanu

4 8

Proposal for adding O_DIRECT support into JDK 9
by Lu, Yingqi 14 Oct '16

14 Oct '16

Dear All, This is a proposal for adding O_DIRECT support into JDK 9 for reading/writing from/to a file on Linux platform. O_DIRECT is a file-open flag to pass to OPEN (2). It tries to minimize cache effects of the I/O to and from this file. File I/O is done directly to/from user-space buffers. Please refer to http://man7.org/linux/man-pages/man2/open.2.html for more details. The advantage of this feature is to provide consistent and predictable IO throughput, bypassing the influence of Linux filesystem cache. It is useful for applications which already have their own caching layers, such as databases Apache HBase and Apache Cassandra. In addition, for applications like Apache Spark shuffle phase that have random file accesses and no access locality (read the file only once from a random location), this feature also helps performance by minimizing trashing the filesystem cache. The proposal adds 4 API methods to java/io/FileInputStream.java, java/io/OutputStream.java to enable the feature. In addition, it add O_DIRECT with two more modes "ro" (read-only and direct) and "rwo" (read-write and direct) to java/io/RandomAccessFile.java. public FileInputStream(String name, boolean direct) throws FileNotFoundException public FileInputStream(File file, boolean direct) throws FileNotFoundException public FileOutputStream(String name, boolean append, boolean direct) throws FileNotFoundException public FileOutputStream(File file, boolean append, boolean direct) throws FileNotFoundException Many database applications written in C/C++ such as MySQL and MongoDB have already used O_DIRECT for certain DB operations. Many Java based BigData applications such as Cassandra are already using it from third party library named JNA. (https://github.com/java-native-access/jna) Our internal version of Hadoop Distributed File System (HDFS) that has O_DIRECT enabled via JNI functions also show significant throughput improvements. We opened a JBS ticket at https://bugs.openjdk.java.net/browse/JDK-8164900 and the initial version of the JDK9 patch is available at http://cr.openjdk.java.net/~vdeshpande/8164900/webrev.00/. By using this patch, we saw good results up to 1.8x improvement on random read throughput on a micro workload named IOMeter with both SATA SSDs and Intel PCIeSSDs. The workload is available at https://github.com/persado/iometer/blob/master/src/main/java/com/persado/os… Please review the patch and let us know your feedback. Thanks, Yingqi Lu (Lucy)

8 22