August 2014 - core-libs-dev

A List from Iterator
by Pavel Rappo 29 Aug '14

29 Aug '14

Hi everyone, Is there any particular reason why there's no convenience method for iterators similar to j.u.Collections.list for enumerations? Or at least the one that adapts Iterator to Enumeration and vice versa. Thanks. -Pavel

5 5

RFR: [8056310] Cleanup in WinNTFileSystem_md.c
by Ivan Gerasimov 29 Aug '14

29 Aug '14

Hello! This is a proposal to make some minor cleanup in WinNTFileSystem_md.c: - fix a typo in error message, - use wide char constant for consistency, - avoid an array reallocation for power-of-two sizes, - avoid a very unlikely memory leak (when frompath != NULL && topath == NULL). BUGURL: https://bugs.openjdk.java.net/browse/JDK-8056310 WEBREV: http://cr.openjdk.java.net/~igerasim/8056310/0/webrev/ Sincerely yours, Ivan

2 1

Review request: 8055856: checkdeps build target doesn't work for cross-compilation builds
by Mandy Chung 29 Aug '14

29 Aug '14

JDK-8055856: checkdeps build target doesn't work for cross-compilation builds JDK-8056113: [build] tools.jar missing modules.xml Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055856/ This patch fixes a few things about modules.xml 1. jdeps is invoked at build time to verify the module boundaries. For cross-compilation, it has to run on the host system. jdeps is added in the langtools interim build so that it can run with the BOOT_JDK. jdeps is also modified to support a system property to specify the path to modules.xml generated later. 2. The generated modules.xml is solely for jdeps to use until the module system is in place. The build tool takes the modules.xml in the top repo and generates a new file to include the module membership for jdeps to use. It is better to name it differently to jdeps-modules.xml to avoid confusion as Magnus suggests. 3. main-jars is missing the dependency of modules-xml target and thus jdeps in the JDK images fails. To help catch this issue, jdeps now throws an exception if jdeps-modules.xml is missing. thanks Mandy

3 11

[7u-dev] Request for Approval and Review: 8017212: File.createTempFile requires unnecessary "read" permission
by Ivan Gerasimov 28 Aug '14

28 Aug '14

Hello! I'd like to ask an approval to backport 8017212 into 7u-dev. The patch does not apply cleanly, however the required modifications are quite small. Nevertheless, I will need a peer review for this. The webrev for jdk7: http://cr.openjdk.java.net/~igerasim/8017212/0/webrev/ The difference, compared to jdk8 is: src/share/classes/java/io/File.java -- curly bracket at the end of the line test/java/io/File/createTempFile/SpecialTempFile.java -- there were conflicts due to backport of 8025128, so the test was just copied verbatim from the latest jdk8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8017212 Jdk8 changeset: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/10d2a4b1e576 Jdk8 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018354.html The change was tested with jprt on all supported platforms. All the io tests, including added and updated, passed. Sincerely yours, Ivan

3 4

Re: Impact of code difference in Collection#contains() worth improving?
by John Rose 27 Aug '14

27 Aug '14

On Aug 27, 2014, at 6:48 AM, Fabian Lange <lange.fabian(a)gmail.com> wrote: > Hi all, > I have been involved recently in some theoretical or nonsensical > discussions about microbenchmarking, jit compiling assemblies and so fort. > One example was LinkedList vs ArrayList. > > What I noticed is that those two have a different implementation for > contains(): > > ArrayList: > > *public* *boolean* contains(Object o) { > *return* indexOf(o) >= 0; > } > > LinkedList: > > *public* *boolean* contains(Object o) { > *return* indexOf(o) != -1; > } > > Logically this is of course identical due to the contract of contains which > returns either -1 or the >=0 index of the element. > > This code has been like this almost forever, and I was wondering if this > actually makes a difference in CPU cycles. If it makes a difference, (a) that difference is unimportant, and (b) it is not controllable at the source code level. Ad (a), the only time the choice of an instruction or two would make even a slight difference is if the list is empty. Otherwise, the cost of traversing the list and testing each element will swamp any small difference in the comparison. Ad (b), the JIT will unrecognizably optimize both codes into surprising instruction sequences. If they differ, the differences will be suprising, and depend on stuff you weren't looking at, such as branch frequencies or the complexity of nearby code structures. > And in fact this code compiles into different assembler instructions. The > array list does a test against 0 and conditional move, while the linked > list does a jump equals on -1. On Thursdays, they compile to the same thing. On every full moon, they swap instruction sequences. ...That's not strictly true, but you get the idea. Changing the Java source code operators in response to observed instruction sequences is a losing game, unless there is a large profit directly available. So what's the winning game? That might be to file a bug against the optimizer (server compiler) if you see truly bad instructions. But the "badness" has to be more than speculative. Unless it must has a measurable and significant cost, for plausibly applications (not nanobenchmarks), the bug will not (and should not) get time from compiler engineers. Often, as with a bit of dust on your camera lens, the best course is not to touch it at all, for fear of making things worse. — John > Again that is not surprising, because the actual java source is different. > But I wonder if both options are equally good in cold performance and when > jitted based on parameter values. > > Wouldn't one implementation be better than the other? And why is not the > "better" implementation taken in both classes (and maybe other Collections > which use indexOf) ? > > Is the answer that this has always been like this and the benefit is not > worth the risk of touching ancient code? > > And if not for performance, would code clarify and similarity be an > argument? > > Or can the answer be found on a different mailing list? Then let me know :) > > > Fabian

1 0

Re: Impact of code difference in Collection#contains() worth improving?
by Mike Duigou 27 Aug '14

27 Aug '14

Hi Fabian; The correct mailing list for this discussion would be core-libs-dev(a)openjdk.java.net The difference between these two implementations is probably of not much consequence though it seems that one or the other could be promoted to AbstractList. This implementation would be marginally better than that offered by AbstractCollection.contains() by generally avoiding creation of an Iterator. There is always some risk associated with making a change even when we believe that the regression testing adequately exercises the functionality. In this case the factors which have resulted in different implementations are; lack of attention, effort relative to benefit and the extremely small but non-zero risk. A nano-benchmark would tell the tale of which of the two implementations is more efficient though I suspect that the difference is negligible if even measurable. Mike On Aug 27 2014, at 06:48 , Fabian Lange <lange.fabian(a)gmail.com> wrote: > Hi all, > I have been involved recently in some theoretical or nonsensical > discussions about microbenchmarking, jit compiling assemblies and so fort. > One example was LinkedList vs ArrayList. > > What I noticed is that those two have a different implementation for > contains(): > > ArrayList: > > *public* *boolean* contains(Object o) { > *return* indexOf(o) >= 0; > } > > LinkedList: > > *public* *boolean* contains(Object o) { > *return* indexOf(o) != -1; > } > > Logically this is of course identical due to the contract of contains which > returns either -1 or the >=0 index of the element. > > This code has been like this almost forever, and I was wondering if this > actually makes a difference in CPU cycles. > > And in fact this code compiles into different assembler instructions. The > array list does a test against 0 and conditional move, while the linked > list does a jump equals on -1. > > Again that is not surprising, because the actual java source is different. > But I wonder if both options are equally good in cold performance and when > jitted based on parameter values. > > Wouldn't one implementation be better than the other? And why is not the > "better" implementation taken in both classes (and maybe other Collections > which use indexOf) ? > > Is the answer that this has always been like this and the benefit is not > worth the risk of touching ancient code? > > And if not for performance, would code clarify and similarity be an > argument? > > Or can the answer be found on a different mailing list? Then let me know :) > > > Fabian

1 0

RFR: [8054714] Use StringJoiner where it makes the code cleaner
by Ivan Gerasimov 27 Aug '14

27 Aug '14

Hello everyone! This is a follower of the recently fixed [8051382] -- Optimize java.lang.reflect.Modifier.toString(). I found a dozen+ other places in jdk, where using the StringJoiner makes the code shorter and cleaner. Would you please help review the fix? http://cr.openjdk.java.net/~igerasim/8054714/0/webrev/ Sincerely yours, Ivan

4 5

The future of Serialization
by Peter Firmstone 27 Aug '14

27 Aug '14

I've noticed there's not much interest in improving Serialization on these lists. This makes me wonder if java Serialization has lost relevance in recent years with the rise of protocol buffers apache thrift and other means of data transfer over byte streams. The burden of implementing Serializable can significantly hamper developers efforts when refactoring, it's quite common for some projects to make no guarantee regarding Serialization compatibility between releases. Also implementation of Serializable can double project development hours, hamper future development and increase software maintenance costs. Serialization also presents opportunities for attackers and has been responsible for a number of zero day exploits. I don't know if isolates will be included with JDK 9 for Jigsaw, or whether ClassLoaders alone will provide isolation for modules. The ability to limit visibility and provide isolation of implementation classes as well as providing limits on memory and threads for isolated modules would also improve platform security. Serialization may provide a means to hot upgrade modules, but more flexible options that doesn't cause serial data lock in need to be developed. Should Serializable eventually be deprecated? Should Serialization be disabled by default? Should a new mechanism be developed? If a new mechanism is developed, what about circular object relationships? Regards, Peter.

4 9

Exposing LZ77 sliding window size in the java.util.zip.[Inflator|Defaltor] API
by Mark Thomas 26 Aug '14

26 Aug '14

Hi, I'm currently working on the implementation of the WebSocket permessage-deflate extension for Apache Tomcat. I am using the JRE provided classes java.util.zip.[Inflator|Defaltor] to do the compression and decompression. I have a working implementation but there is one feature I can't implement because the necessary API isn't available. The WebSocket permessage-deflate specification [1] allows both the client and server to specify a number between 8 to 15 inclusive indicating the base-2 logarithm of the LZ77 sliding window size. The purpose of this feature is to enable both the client and the server to limit the size of the buffer they need to maintain to reduce their memory footprint per connection. Would it be possible for the java.util.zip.Inflator and java.util.zip.Defaltor API to be extended to expose the LZ77 window size? My suggestion would be an additional constructor for each class that took and additional int parameter for window size but I'd be happy with any API that provided control of the window size. Cheers, Mark [1] http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-18

3 2

Trusted service?
by Wang Weijun 25 Aug '14

25 Aug '14

Hi All I'm working on "8038089: TLS optional support for Kerberos cipher suites needs to be re-examine" which will separate the implementation of Kerberos-related TLS ciphersuites from the other TLS codes. I am thinking of defining a ServiceLoader interface called ExternalCipherSuiteProvider inside the TLS module and implement a Krb5CipherSuiteProvider in the JGSS module. Now if the JGSS module is installed, it will be found and thus supports the TLS_KRB5_* ciphersuites. However, it looks like any application can include an implementation and register it by adding its own $CLASSPATH/META-INF/services line. Is there anyway I can find out which is the "trusted" one? I've looked at some ServiceLoader example inside JDK and it looks like they first load an implementation specified by a system property and then do the ServiceLoader.load() loop. Is that system property meant to provide the "trusted" or "builtin" implementation? I wonder if it still works now because even if we define a system property (or security property), the implementation class will be invisible in a different module. Thanks Max

4 8