June 2015 - core-libs-dev

[8u-dev] Review request : JDK-8062904: TEST_BUG: Tests java/lang/invoke/LFCaching fail when run with -Xcomp option
by Konstantin Shefov 05 Jun '15

05 Jun '15

Hello, Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8062904 Webrev is http://cr.openjdk.java.net/~kshefov/8062904/webrev.01/ Test fails only against JDK 8u and passes against JDK 9. Thanks -Konstantin

2 12

[8u60] approval request for JDK-8066188: BaseRowSet returns the wrong default value for escape processing
by Maxim Soloviev 05 Jun '15

05 Jun '15

Please approve direct backport. bug: https://bugs.openjdk.java.net/browse/JDK-8066188 jdk9 change set: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f619341171c0 Thanks, Maxim

2 1

[8u60] approval request for JDK-8059411: RowSetWarning does not correctly chain warnings
by Maxim Soloviev 05 Jun '15

05 Jun '15

Please approve direct backport. bug: https://bugs.openjdk.java.net/browse/JDK-8059411 jdk9 change set: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4110a7627857 Thanks, Maxim

2 1

[8u60] approval request for JDK-8062198: Add RowSetMetaDataImpl Tests and add column range validation to isdefinitlyWritable
by Maxim Soloviev 05 Jun '15

05 Jun '15

Please approve direct backport. bug: https://bugs.openjdk.java.net/browse/JDK-8062198 jdk9 change set: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4162bcc663dc Thanks, Maxim

2 1

Patch to improve primitives Array.sort()
by Chan, Sunny 05 Jun '15

05 Jun '15

We are proposing a patch to improve the performance for the DualPivotQuickSort use by Array.sort to sort primitives array. We have identified two area for optimization: Firstly, we have changed the algorithm to determine what a "run" is. A "run" is how long you go through the array with it being in order. For example, an array of 1, 2, 3, 5, 4, 3 would have a run count equal to 2 (two parts that are in order). The JDK implementation stops looking for runs if it comes across two equal numbers at the beginning of a run, eg. 1, 1, 1, 1, 2, 3, 4, 4, 4, 4, 4, 4, 5 And then sorts the whole array, as seen in this part of the algorithm: } else { // equal for (int m = MAX_RUN_LENGTH; ++k <= right && a[k - 1] == a[k]; ) { if (--m == 0) { sort(a, left, right, true); return; } } } Instead, we detect and equal beginning of a run at the top of the for loop, as shown here: while (k < right && a[k] == a[++k]); //equal so the array mentioned above would instead have one run, be determined already sorted, and sort would not be called as it would in the original JDK implementation. Second optimization is in the case of an array that is descending, and then ascending. Since the algorithm does swapping in the case of descending numbers, by the end of all swapping the array is sorted. We detect this through this if statement: if (run[count] > left && a[run[count]] >= a[run[count] - 1]) { count--; } And will stop sorting, unlike the JDK. I have attached a webrev.zip containing the patch and unit test that verifies the sort is correct. We also have a couple of JMH based performance tests which is not included. If the JMH is available we can also make those performance test available as well. The patch is author by Kristen O'Leary (Kristen.o'leary(a)gs.com) and myself. Please attribute both of us when committing. You can find my OCA entry under Goldman Sachs and as we are not authors yet we can't raise a bug report in the database. Please let us know if you need further clarification or modification to the patch. Sunny Chan, Executive Director, Technology Goldman Sachs (Asia) L.L.C. | 68th Floor | Cheung Kong Center | 2 Queens Road Central | Hong Kong email: sunny.chan(a)gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633 This message may contain information that is confidential or privileged. If you are not the intended recipient, please advise the sender immediately and delete this message. See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks inherent in electronic communication.

5 20

[8u60] approval request for JDK-8068416: LFGarbageCollectedTest.java fails with OOME: "GC overhead limit exceeded"
by Konstantin Shefov 05 Jun '15

05 Jun '15

Please approve direct backport. bug: https://bugs.openjdk.java.net/browse/JDK-8068416 jdk9 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/033998.html jdk8u-dev webrev: http://cr.openjdk.java.net/~kshefov/8068416/webrev.02 Thanks, -Konstantin

2 1

RFR 8072773 (fs) Files.lines needs a better splitting implementation for stream source
by Paul Sandoz 05 Jun '15

05 Jun '15

Hi, Please review an optimization for Files.lines for certain charsets: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8072773-File-lines/webrev/ If a charset is say US-ASCII or UTF-8 it is possible to implement an efficient splitting Spliterator that scans bytes from a mid-point to search for line feed characters. Splitting uses a mapped byte buffer. Traversal uses FileChannel.reads at an offset. In previous incarnations i tried to use mapped byte buffer for both, but for some reason the traversal performance was not good (both on Mac and x86). In any case i am happy with the current approach as there is minimal layering between the FileChannel and BufferedReader leveraged to read the lines. Sequential performance is similar (same or better) than the current approach. Parallel performance is much better than the current approach. Some advice on two aspects would be most appreciated: 1) Is there an easy way to determine the sub-set of supported charsets that are applicable? 2) We should try and explicitly unmap the mapped byte buffer when the stream is closed, using some sort of shared secret. How can i do that? Paul.

4 6

[9] Review request : JDK-8068416: LFGarbageCollectedTest.java fails with OOME: "GC overhead limit exceeded"
by Konstantin Shefov 05 Jun '15

05 Jun '15

Hello, Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8068416 Webrev is http://cr.openjdk.java.net/~kshefov/8068416/webrev.01/ Test failure is caused by JDK-8078602 [1]. Suggestion is to exclude the test until [1] is fixed. [1] https://bugs.openjdk.java.net/browse/JDK-8078602 Thanks -Konstantin

2 3

JDK 9 RFR of JDK-8085879: Mark intermittently failing: java/util/Arrays/ParallelPrefix.java
by Amy Lu 05 Jun '15

05 Jun '15

java/util/Arrays/ParallelPrefix.java This test has been observed to fail intermittently. This fix is to mark it accordingly with keyword 'intermittent'. bug: https://bugs.openjdk.java.net/browse/JDK-8085879 webrev: http://cr.openjdk.java.net/~amlu/8085879/webrev.00/ Thanks, Amy --- old/test/java/util/Arrays/ParallelPrefix.java 2015-06-05 13:44:24.000000000 +0800 +++ new/test/java/util/Arrays/ParallelPrefix.java 2015-06-05 13:44:24.000000000 +0800 @@ -26,6 +26,7 @@ * @summary unit test for Arrays.ParallelPrefix(). * @author Tristan Yan * @run testng ParallelPrefix + * @key intermittent */ import java.util.Arrays;

2 1

Re: [9] RFR (XS) JDK-8081771: ProcessTool.createJavaProcessBuilder() needs new addTestVmAndJavaOptions argument
by David Holmes 05 Jun '15

05 Jun '15

Hi Chris, On 5/06/2015 9:34 AM, Chris Plummer wrote: > On 6/3/15 11:31 PM, David Holmes wrote: >> Typo ... >> >> On 4/06/2015 4:04 PM, David Holmes wrote: >>> Hi Chris, >>> >>> On 3/06/2015 1:20 PM, Chris Plummer wrote: >>>> Please review the following: >>>> >>>> Webrev: http://cr.openjdk.java.net/~cjplummer/8054386/webrev.02/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8081771 >>>> >>>> This review only concerns the changes to ProcessTool.java. The >>> >>> Your new method needs javadoc explaining its usage, and in particular >>> what addTestVmAndJavaOptions actually refers to. Also a comment on why >>> the explicit -cp is added, but on under that arg, would be useful. >> >> but only under that arg ... > Hi David, > > Here's an updated webrev: > > http://cr.openjdk.java.net/~cjplummer/8054386/webrev.04/ > > Note, this is the first time I've ever done javadocs, and I'm not even > sure how to build the javadocs to make sure it formats correctly. So if > anything looks suspicious and you think needs verification, please let > me know how. I've never built javadocs for the tests/testlibrary either, but simply read them as code comments. What you have done is consistent with the other doc comments in the file (which have some style inconsistencies with other JDK code, but not enough to worry about here). The comment on -cp is somewhat longer than I had anticipated - might be one of the rare occasions where a reference to the CR would be better. But unless someone else complains ... Thanks, David > thanks, > > Chris >> >> David >> >>> Thanks, >>> David >>> >>> >>> >>>> CDSJDITests and filemapp.cpp changes will be committed under CR >>>> JDK-8054386, but they rely on this change to ProcessTool.java, so both >>>> CRs will be pushed together. See the following thread for the >>>> JDK-8054386 review: >>>> >>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-June/014923… >>>> >>>> >>>> >>>> >>>> thanks, >>>> >>>> Chris >

1 0