August 2015 - core-libs-dev

RFR - 8027634: Support @argfiles for java command-line tool
by Henry Jen 23 Aug '15

23 Aug '15

Hi, Please review proposed patch for JDK-8027634[1]. This patch is to enable java support command line argument file like javac does. The implementation use the same syntax rule, which is implemented in CommandLine.java[3] with java.io.StreamTokenizer. Some early comment is that we probably don’t need such complexity to support same syntax, also require to quote whole token is a little inconvenient. For example, must be -cp “c:\\foo bar\\lib;c:\\lib” instead of -cp c:\”foo bar”\lib;c:\lib. I am debating if such compatibility is necessary useful, after all, easy and intuitive is more important, and with simpler rule, the implementation will be cleaner as well. Anyhow, with the patch out, at least developer can build idk and have something to test with to see if this can fulfill their use cases. Also, for tools other than java that use launcher, it’s possible to use -J@argfile to pass arguments. For example, if want to pass -J options to javac, it’s now possible to do so with javac -J@argfile, and put -J options in the argfile. If the consensus is that such syntax compatibility is not important, we will go ahead remove the escaping support(except probably enable escape for quote itself) in quote, and maybe add support of quote within a token. CCing build-dev for build changes, jdk9-dev for wider audience for tools. Cheers, Henry [1] https://bugs.openjdk.java.net/browse/JDK-8027634 [2] http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#com… [3] http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/03e083639ee9/src/jdk.co…

5 25

Custom spliterator for Collections.nCopies(n, obj).stream()
by Tagir F. Valeev 22 Aug '15

22 Aug '15

Hello! Current implementation of Collections.nCopies().stream() is as follows: http://hg.openjdk.java.net/jdk9/dev/jdk/file/f160dec9a350/src/java.base/sha… public Stream<E> stream() { return IntStream.range(0, n).mapToObj(i -> element); } @Override public Stream<E> parallelStream() { return IntStream.range(0, n).parallel().mapToObj(i -> element); } The problem is that it adds a lambda expression to the RangeIntSpliterator type profile which can be polluted by some other code and vice versa: using nCopies().stream() may pollute the type profile for other code making it slower. Another thing which is missing in current implementation is unordered mode. This collection is unordered by nature, its stream is similar to Stream.generate(), so to my opinion it should be unordered which may improve the parallel reduction in some cases. This can be improved by introducing the custom spliterator class which is quite simple: https://gist.github.com/amaembo/62f3efee9923b1468e86 On pre-polluted type profile with simple mapping and reduction using custom spliterator is about 25-30% faster in both parallel and sequential cases as benchmarking shows (performed on 4-core cpu). What do you think? With best regards, Tagir Valeev.

2 5

Where is Tristan
by Tristan Yan 22 Aug '15

22 Aug '15

I will be OOO from Aug 24th to Sept 7th. I will be checking Email intermittently but I won't be online. Drop me a mail if you need something from me. Tristan

1 0

RFR 8133939: javadoc clarification for java.sql.Date.toLocalDate()
by Lance Andersen 21 Aug '15

21 Aug '15

Hi, Here is a minor javadoc update for java.sql.Date.toLocalDate(). The ccc has been approved. Best Lance hg diff Date.java diff -r 562b349a85da src/java.sql/share/classes/java/sql/Date.java --- a/src/java.sql/share/classes/java/sql/Date.java Tue Aug 18 20:30:15 2015 -0700 +++ b/src/java.sql/share/classes/java/sql/Date.java Wed Aug 19 10:03:58 2015 -0400 @@ -295,11 +295,8 @@ } /** - * Converts this {@code Date} object to a {@code LocalDate} - * <p> - * The conversion creates a {@code LocalDate} that represents the same - * date value as this {@code Date} in local time zone - * + * Creates a {@code LocalDate} instance using the year, month and day + * from this {@code Date} object. * @return a {@code LocalDate} object representing the same date value * * @since 1.8 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen(a)oracle.com

2 1

RFR 8133939: javadoc clarification for java.sql.Date.toLocalDate()
by Lance Andersen 21 Aug '15

21 Aug '15

Hi, Here is a minor javadoc update for java.sql.Date.toLocalDate(). The ccc has been approved. Best Lance hg diff Date.java diff -r 562b349a85da src/java.sql/share/classes/java/sql/Date.java --- a/src/java.sql/share/classes/java/sql/Date.java Tue Aug 18 20:30:15 2015 -0700 +++ b/src/java.sql/share/classes/java/sql/Date.java Wed Aug 19 10:03:58 2015 -0400 @@ -295,11 +295,8 @@ } /** - * Converts this {@code Date} object to a {@code LocalDate} - * <p> - * The conversion creates a {@code LocalDate} that represents the same - * date value as this {@code Date} in local time zone - * + * Creates a {@code LocalDate} instance using the year, month and day + * from this {@code Date} object. * @return a {@code LocalDate} object representing the same date value * * @since 1.8 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen(a)oracle.com

1 0

RFR(XS): 8133830: [solaris] Fix for potential memory leak in TimeZone_md.c, function findJavaTZ_md()
by Langer, Christoph 20 Aug '15

20 Aug '15

Hi all, as per the discussion in thread "Fix for small leak in TimeZone_md.c" in jdk9-dev, I would like to get the following tiny change reviewed: Bug: https://bugs.openjdk.java.net/browse/JDK-8133830 Webrev: http://cr.openjdk.java.net/~asiebenborn/christoph/webrev/ I also need a sponsor since I can't commit yet. Thanks Christoph

2 1

RFR/RFA (8u-dev) 8133253: [TESTBUG] java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java fails on compact profile
by Ivan Gerasimov 20 Aug '15

20 Aug '15

Hi! The test FieldSetAccessibleTest.java fails when testing with compact3 even after fixing JDK-8080524. The reason is that the test tries to access classes which are only available in full jdk. The proposed fix is to include the test in the corresponding group in TEST.groups file. Would you please help review the fix and approve pushing it into jdk8u-dev repo? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8133253 WEBREV: http://cr.openjdk.java.net/~igerasim/8133253/00/webrev/ Sincerely yours, Ivan

4 3

Unneeded size/fstat system call in sun.nio.ch.FileChannelImpl#transferTo for linux?
by Adrian 20 Aug '15

20 Aug '15

Hello, I was looking at FileChannelImpl#transferTo, and noticed there were always two system calls - fstat and sendfile. Looking the source code (e.g. http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7u40…) the JVM checks that the position is not past the end of the file to read. On Linux, the size translates to a fstat system call, and the native function transferTo0 translates to a sendfile system call, and I believe sendfile already checks the offsets and will only read as many bytes as available, similar to the read system call. As of linux 2.6.23, sendfile is implemented using splice. Just following the latest source for example: - sendfile (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/fs/rea…) - do_sendfile - do_splice_direct (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/fs/spl…) - splice_direct_to_actor - do_splice_to - default_file_splice_read - kernel_readv - vfs_readv (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/fs/rea…) Which is the same vfs_readv used when defining the read system call I didn't find the exact code where it checks the position and length, as vfs_readv calls file->f_op->read, but: - the read system call (which also uses vfs_readv) is documented as "attempting to read up to count bytes" - all the code uses the return value as the "actual length", not the parameter passed in - the man page for splice says it returns "the number of bytes spliced to/from the pipe" Manually testing this on linux and OSX seems to confirm the behaviour (that manually checking the position/length is unnecessary because sendfile/splice will only return how many bytes it managed to read/write) - by calling sendfile with an offset beyond EOF (returns 0) or with a count size larger than the size of the file (returns number of bytes left). I also looked at the JVM windows source, which uses the TransmitFile API. I didn't look into this in detail - the docs are unclear, but it seems you will only get an error if the number of bytes to send is greater than 2 ^ 31 - 1 Doing some benchmarks with a 64KB buffer/transfer size (compiling minimally modified JDK), FileChannelImpl#size averaged ~12us, and FileChannelImpl#transferToDirectly averaged ~33us. The whole FileChannelImpl#transferTo took ~48us. I know microbenchmarks need to be done very carefully, but I think it gives a general idea of the performance impact for something that should be (?) unecessary Of course, I could be wrong, or more needs to be considered, but I thought it was worth bringing up and get some feedback. Maybe someone could confirm the behaviour of sendfile/splice, or explain the reasoning for checking the size in the JVM? Thank you for your time! Best regards, Adrian

2 1

Reponse to bug report (spurious ConcurrentModificationException in ArrayList)
by Cyrille Artho 20 Aug '15

20 Aug '15

Dear all, I'd like to write a response to my bug report at https://bugs.openjdk.java.net/browse/JDK-8114832 but I didn't get an OpenJDK login when I submitted the report. In this particular case, it should be noted that my test was minimal. If one has at least one element in the list before the iterator is created, then it.next() throws no exception when used on any collection except ArrayList/Stack/Vector. This means that ArrayList and its legacy brethren are the only classes that generate a spurious exception, and only after list.remove(-1) was called before using the iterator. The spurious exception prevents future access to data where other containers work as expected. Currently it is being considered to keep the current (faulty) behavior, but based on the new test case, I strongly advise correcting this bug. With the new test case, the information about the bug becomes: EXPECTED - it.next() returns 42 ACTUAL - ConcurrentModificationException REPRODUCIBILITY : This bug can be reproduced always. ---------- BEGIN SOURCE ---------- import java.util.ArrayList; import java.util.LinkedList; import java.util.ConcurrentModificationException; import java.util.Iterator; import java.util.NoSuchElementException; public class iterator_test { public static void main(String[] argv) { /* BUG: Sequence of arrayList.iterator, arrayList.add(new Integer(1)), arrayList.remove(-1), iterator.next produces ConcurrentModificationException. */ ArrayList<Integer> testArrayList = new ArrayList<Integer>(); testArrayList.add(new Integer(42)); Iterator<Integer> it = testArrayList.iterator(); try { testArrayList.remove(-1); } catch (IndexOutOfBoundsException e) { } try { Integer result = it.next(); assert(result == 42); } catch (ConcurrentModificationException e) { System.err.println("Should be 42!"); } } } ---------- END SOURCE ---------- -- Regards, Cyrille Artho - http://artho.com/ Those who will not reason, are bigots, those who cannot, are fools, and those who dare not, are slaves. -- George Gordon Noel Byron

2 1

Review request: 8132944: test java/lang/ClassLoader/GetSystemPackage.java writes stuff to Agent stdout
by Mandy Chung 19 Aug '15

19 Aug '15

A trivial one - this takes out the unnecessary debug statement to clean up the test output. diff --git a/test/java/lang/ClassLoader/GetSystemPackage.java b/test/java/lang/ClassLoader/GetSystemPackage.java --- a/test/java/lang/ClassLoader/GetSystemPackage.java +++ b/test/java/lang/ClassLoader/GetSystemPackage.java @@ -181,7 +181,6 @@ private static Package findPackage(String name) { Package[] packages = Package.getPackages(); for (Package p : packages) { - System.out.println(p); if (p.getName().equals(name)) { return p; } Mandy

2 1