March 2016 - core-libs-dev

JEP 285: Spin-Wait Hints
by mark.reinhold＠oracle.com 04 Mar '16

04 Mar '16

New JEP Candidate: http://openjdk.java.net/jeps/285 - Mark

1 0

JDK 9 RFR of JDK-8151286: Remove intermittent key from TestLocalTime.java and move back to tier1
by Amy Lu 04 Mar '16

04 Mar '16

java/util/zip/TestLocalTime.java This test was failing intermittently (reported in JDK-8135108). JDK-8135108 has been resolved and no open bug (no failure reported) till now. This patch is to remove @key intermittent from the test and move it back to tier1. bug: https://bugs.openjdk.java.net/browse/JDK-8151286 webrev: http://cr.openjdk.java.net/~amlu/8151286/webrev.01/ Thanks, Amy --- old/test/TEST.groups 2016-03-04 22:22:13.000000000 +0800 +++ new/test/TEST.groups 2016-03-04 22:22:13.000000000 +0800 @@ -28,7 +28,6 @@ tier1 = \ :jdk_lang \ -java/lang/ProcessHandle/TreeTest.java \ - -java/util/zip/TestLocalTime.java \ :jdk_util \ -java/util/WeakHashMap/GCDuringIteration.java \ -java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ @@ -40,7 +39,6 @@ tier2 = \ java/lang/ProcessHandle/TreeTest.java \ - java/util/zip/TestLocalTime.java \ java/util/WeakHashMap/GCDuringIteration.java \ java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ java/util/concurrent/forkjoin/FJExceptionTableLeak.java \ --- old/test/java/util/zip/TestLocalTime.java 2016-03-04 22:22:13.000000000 +0800 +++ new/test/java/util/zip/TestLocalTime.java 2016-03-04 22:22:13.000000000 +0800 @@ -24,7 +24,6 @@ /* * @test * @bug 8075526 8135108 - * @key intermittent * @summary Test timestamp via ZipEntry.get/setTimeLocal() */

2 1

JDK 9 RFR of JDK-8151263: Mark java/rmi test LeaseCheckInterval.java as intermittently failing
by Amy Lu 04 Mar '16

04 Mar '16

java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java This test is known to fail intermittently (JDK-8078587). This patch is to mark the test accordingly with keyword 'intermittent'. bug: https://bugs.openjdk.java.net/browse/JDK-8151263 webrev: http://cr.openjdk.java.net/~amlu/8151263/webrev.00/ Thanks, Amy --- old/test/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java 2016-03-04 22:49:09.000000000 +0800 +++ new/test/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java 2016-03-04 22:49:09.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -43,6 +43,7 @@ * java.rmi/sun.rmi.transport.tcp * @build TestLibrary JavaVM LeaseCheckInterval_Stub SelfTerminator * @run main/othervm LeaseCheckInterval + * @key intermittent */ import java.rmi.Remote;

2 1

RFR-8148748: ArrayList.subList().spliterator() is not late-binding
by Tagir F. Valeev 04 Mar '16

04 Mar '16

Hello! Here's the webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8148748/r1/ I noticed that list == null checks are never true, thus redundant, so I removed them. The list field is final and always assigned to the outer ArrayList instance. So it seems quite natural to make ArrayListSpliterator non-static instead. Also I added one more field into ArrayListSpliterator to hold the SubList reference. Hopefully such footprint increase is acceptable. The offset field is initialized eagerly as it does not change during the SubList lifetime. Also I replaced "if (action == null)" checks with "Objects.requireNonNull". Some more thoughts about forEachRemaining: To me it seems that if ((a = lst.elementData) != null) is a redundant check as well as in current ArrayList implementation elementData is never null. So it can be replaced with simple assignment. Also this check: (i = index) >= 0 I don't see the case when i could be negative. Should it be removed as well? Or probably it's added to aid JIT to elimitate bounds-checking? With best regards, Tagir Valeev. PS> Hi Tagir, PS> Last-binding while adding some complexity to the implementation PS> is an important property, as it is to fail-fast on a best effort basis. PS> When one has mutable collections that can be structurally PS> modified and lazy views over those collections (Streams/Iterators) PS> then those views really need to act on the most up to date PS> structure and not a snapshot (structural or otherwise) when the PS> view was created. Otherwise, it is a potential source of bugs PS> producing incorrect results or exceptions, or another form of PS> complexity for the implementation to maintain integrity under such conditions. PS> We took a short-cut here to reuse the existing top-level PS> spliterator in a non-late-binding manner by specifying the PS> absolute fence. We should fix it. PS> Glancing at the code i believe there is a simple fix. When -1 is PS> passed as the fence to the ArrayList.ArrayListSpliterator then the PS> fence is created lazily and should be the result of offset + PS> list.size e.g. in the constructor: PS> hi = fence = offset + lst.size; PS> The forEach impl also needs updating. PS> — PS> Sublists are also tricky beasts. See documentation on List.subList: PS> * The semantics of the list returned by this method become undefined if PS> * the backing list (i.e., this list) is <i>structurally modified</i> in PS> * any way other than via the returned list. (Structural modifications are PS> * those that change the size of this list, or otherwise perturb it in such PS> * a fashion that iterations in progress may yield incorrect results.) PS> Paul. >> On 29 Jan 2016, at 05:32, Tagir F. Valeev <amaembo(a)gmail.com> wrote: >> >> Hello! >> >> When reviewing 8079136 I noticed that >> ArrayList.subList().spliterator() is not late-binding: >> >> List<Integer> list = new ArrayList<>(Arrays.asList(1,2,3,4)).subList(0, 3); >> Stream<Integer> s = list.stream(); >> list.add(5); >> s.findFirst(); >> --> Exception in thread "main" java.util.ConcurrentModificationException >> >> This works correctly for other list implementation (for example, >> replacing ArrayList with LinkedList makes this code working). As >> Collection.spliterator() spec says: >> >>> In order to preserve expected laziness behavior for the stream() and >>> parallelStream() methods, spliterators should either have the >>> characteristic of IMMUTABLE or CONCURRENT, or be late-binding. If >>> none of these is practical, the overriding class should describe the >>> spliterator's documented policy of binding and structural >>> interference, and should override the stream() and parallelStream() >>> methods to create streams using a Supplier of the spliterator >> >> None of these is true for ArrayList.subList().spliterator(): it's not >> IMMUTABLE, not CONCURRENT, not late-binding, the binding policy is not >> documented and stream()/parallelStream() methods are not overridden. >> >> Is this an issue? >> >> Actually to my opinion late-binding spliterator behavior is a mistake. >> Nobody cares about it as nobody modifies the source between stream >> creation and terminal operation call. On the other hand, this >> requirement adds implementation complexity and I already found the >> second late-binding problem in existing code (the first one was with >> Pattern.splitAsStream). Also it's not documented that Stream.concat >> may bind the late-binding source, but nobody cares anyways. Life would >> be easier without late-binding spliterators. >> >> With best regards, >> Tagir Valeev. >> ===8<===========End of original message text=========== -- Best regards, Tagir mailto:amaembo@gmail.com

3 11

[9] RFR: 8151182: HttpHeaders.allValues should return unmodifiable List as per JavaDoc
by vaibhav x.choudhary 04 Mar '16

04 Mar '16

Hi, Please review :- Review Link :- http://cr.openjdk.java.net/~ntv/vaibhav/JDK8151182/webrev.00/ Bug ID: https://bugs.openjdk.java.net/browse/JDK-8151182 -- Thank You, Vaibhav Choudhary http://blogs.oracle.com/vaibhav

4 3

RFR 8150840: Add an internal system property to control the default level of System.Logger when java.logging is not present.
by Daniel Fuchs 04 Mar '16

04 Mar '16

Hi, Please find below a patch for: https://bugs.openjdk.java.net/browse/JDK-8150840 8150840: Add an internal system property to control the default level of System.Logger when java.logging is not present. This patch also introduces a better separation between the SimpleConsoleLogger (created by the DefaultLoggerFinder when java.logging is not there), and the SurrogateLogger, which emulates the behavior of java.util.logging.Logger when java.logging is present but there is no custom configuration (used to be PlatformLogger.DefaultLoggerProxy). best regards, -- daniel

1 0

RFR:JDK-8032051:"ZonedDateTime" class "parse" method fails with short time zone offset ("+01")
by nadeesh tv 04 Mar '16

04 Mar '16

Hi all, Please review a fix for Bug Id https://bugs.openjdk.java.net/browse/JDK-8032051 webrev http://cr.openjdk.java.net/~ntv/8032051/webrev.01/ -- Thanks and Regards, Nadeesh TV

3 16

RFR 8150679: closed/javax/crypto/CryptoPermission/CallerIdentification.sh fails after fix for JDK-8132734
by Steve Drach 04 Mar '16

04 Mar '16

Please review the following fix for JDK-8150679 webrev: http://cr.openjdk.java.net/~sdrach/8150679/webrev/ <http://cr.openjdk.java.net/~sdrach/8150679/webrev/> issue: https://bugs.openjdk.java.net/browse/JDK-8150679 <https://bugs.openjdk.java.net/browse/JDK-8150679> The test was modified to demonstrate the problem.

6 6

RFR: Regex exponential backtracking issue
by Xueming Shen 04 Mar '16

04 Mar '16

Hi, webrev: http://cr.openjdk.java.net/~sherman/regexBacktracking/webrev/ Backtracking is the powerful and popular feature provided by Java regex engine when the regex pattern contains optional quantifiers or alternations, in which the regex engine can return to the previous saved state (backtracking) to continue matching/finding other alternative when the current try fails. However it is also a "well known" issue that some not-well-written regex might trigger "exponential backtraking" in situation like there is no possible match can be found after exhaustive search, in the worst case the regex engine will just keep going forever, hangup the vm. We have various reports in the past as showed in RegexFun.java <http://cr.openjdk.java.net/%7Esherman/regexBacktracking/RegexFun.java> [1] for this issue. For example following is the one reported in JDK-6693451. regex: "^(\\s*foo\\s*)*$" input: "foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo fo", In which the "group" (\\s*foo\\s*)*$" can alternatively match any one of the "foo", "foo ", " foo" and " foo ". The regex works fine and runs normally if it can find a match (replace the last "fo" in the input to "foo" for example). But in this case because the input text ends with a "fo", the regex actually can never match the input, it always fails at last one, nothing in the regex can match the "fo". Given the nature of the "greedy quantifier", the engine will be backtracking/bouncing among these 4 choices at each/every iteration/level and keep searching to the end of the input exhaustively, fail, backtrack, and try again recursively. Based on the number of "foo" in the input, it can run forever until the end of the world. There are lots of suggestions on how to avoid this kind of runaway regex. One is to use the possessive quantifier, if possible, to replace the greedy quantifier ( * -> *+ for example ) to workaround this kind of catastrophic backtracking, and it normally meets the real need and makes the exponential backtracking go away. The observation of these exponential backtracking cases indicates that most of these "exponential backtracking" however are actually not necessary in most cases. Even we can't solve all of these catastrophic backtracking, it might be possible, with a small cost, we can actually workaround most of the "cases", in particular (1) when the "exponential backtracking" happens at the top level group + greedy quantifier, and (2) there is no group ref in the pattern. The "group + greedy repetition" in j.u.regex is implemented via three nodes, "Prolog + Loop + body node", in wihch the body takes care of (\\s*foo\\s*), the Loop takes care of the looping for "*", and the Prolog, as its name, just a starter to kick of the looping (read source for more details). The normal matching sequence works as Prolog.match() -> Prolog.loop.matchInit() -> body.match() -> loop.match() -> body.match() -> loop.match() -> body.match() -> loop.match() ... -> body.match() -> loop.match() -> loop.next.match() The "body.match() -> loop.match -> body.match() -> loop.match() ..." is looping on the runtime call stack "recursively" (the body.next is pointing to loop). If we take the "recursive looping" part that we are interested (we only care about the "count >= cmin" situation, as it is where the exponential backtracking happens) out of Loop.match(), the loop.match is as simple as boolean match(Matcher matcher, int i, CharSequence seq) { ---> Before boolean b = body.match(matcher, i, seq); // If match failed we must backtrack, so // the loop count should NOT be incremented if (b) return true; matcher.locals[countIndex] = count; ---> After return next.match(matcher, i, seq); } It appears that each of the repetitive "body.match() + loop.match()" looping (though actually recursive on the runtime stack) actually is matching the input text kind of "linearly" in the order of loop counter, if this is a "top level" group repetition (not an inner group inside another repetitive group) ... foo foo foo foo foo foo foo... |_ i = n, (body-loop)(body-loop)(body-loop).... ->next() given the nature of its "greediness", the engine will exhausts all the possible match of "body+loop+ loop.next" from any given starting position "i". We can actually assume that if we have failed to match A "body + loop + its down-stream matching" last time at position "i", next time if we come back here again (after backtracking the "up stream" and come down here again), and if we are at exactly the same position "i", we no longer need to try it again, the result will not change (failed). With the assumption that we DO NOT have a group ref in the pattern (the result/content of the group ref can change, if the down-stream contains the group ref, we can't assume the result going forward will be the same, even start at the same position "i"). for example for the above sample, when we backtrack to loop counter "n", we can dance among 4 choices "foo", " foo", "foo " and " foo ", but when we pick one and more on to the next iteration/loop at n + 1, the only possible choice is either "foo..." or " foo" (with a leading space character), if we have tried either of them (or both) last time and it failed, we no longer need to try the same "down stream" again . And the good thing is that this "position-lookup-table" can be shared by all cmin <= n <= cmax iterations, again, because the nature of greediness. In last failed try, the engine has tried/exhausted all possible combinations of body->loop->body->loop...body->loop->next at "i", including the possilble exhaustive backtracking done by the embedded inner nodes of this group. So we are here at the same position 'i" again, the result will be the same. So here is my propoased workaround solution. We introduce in a "hashmap" (home-made hashmap for "int", supposed to be cheap and faster) to memorize all the tried-and-failed position "i", and check this hashmap before starting a new round of loop. boolean match(Matcher matcher, int i, CharSequence seq) { ---------------- if (posIndex != -1 && matcher.localsPos[posIndex].contains(i)) { return next.match(matcher, i, seq); } ---------------- boolean b = body.match(matcher, i, seq); // If match failed we must backtrack, so // the loop count should NOT be incremented if (b) return true; matcher.locals[countIndex] = count; ---------------- if (posIndex != -1) { matcher.localsPos[posIndex].add(i); } ---------------- return next.match(matcher, i, seq); } This makes most of the exponential backtracking failures in RegexFun.java [1] go away, except the two issues. (1) the exponential backtracking starts/happens at the second inner group level, in which the proposed change might help, but does not make it go away regex: "(h|h|ih(((i|a|c|c|a|i|i|j|b|a|i|b|a|a|j))+h)ahbfhba|c|i)*" input: "hchcchicihcchciiicichhcichcihcchiihichiciiiihhcchicchhcihchcihiihciichhccciccichcichiihcchcihhicchcciicchcccihiiihhihihihichicihhcciccchihhhcchichchciihiicihciihcccciciccicciiiiiiiiicihhhiiiihchccchchhhhiiihchihcccchhhiiiiiiiicicichicihcciciihichhhhchihciiihhiccccccciciihhichiccchhicchicihihccichicciihcichccihhiciccccccccichhhhihihhcchchihihiihhihihihicichihiiiihhhhihhhchhichiicihhiiiiihchccccchichci" (2) it's a {n, m} greedy case. This one probably can be handled the same way as the */+ but need a little more testing. regex: "(\\w|_){1,64}@" input: "______________________________" There are another kind of "abusing" case that overly and repeatitively uses ".*" or ".+", such as reported in jdk-5014450 http://cr.openjdk.java.net/~sherman/regexBacktracking/RegexFun3.java regex: "^\\s*sites\\[sites\\.length\\+\\+\\]\\s*=\\s*new\\s+Array\\(.*" + "\\s*//\\s*(\\d+).*" + "\\s*//\\s*([^-]+).*" + "\\s*//\\s*([^-]+).*" + "\\s*//\\s*([^-]+).*" + "/(?sui).*$" text "\tsites[sites.length++] = new Array(\n" + "// 1079193366647 - creation time\n" + "// 1078902678663 1078852539723 1078753482632 0 0 0 0 0 0 0 0 0 0 0 - creation time last 14 days\n" + "// 0 1 0 0 0 0 0 0 0 0 0 0 0 0 - bad\n" + "// 0.0030 0.0080 0.01 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 -\n\n", The performance can be much/much better if we can apply the similar optimization for top-level dot-greedy-curly nodes as well, as showed at http://cr.openjdk.java.net/~sherman/regexBacktracking/webrev2/ But I'm a little concerned the possibility that the extra checks might slowdown the normal case and just wonder if it is worth the cost. So leave it out for now. Another optimization included is for the "CharProperty + Curly" combination, normally this is what you get for the for regex construct .*, \w* \s*. The new GreedyCharProperty node now takes advantage of the fact that we are iterating char/codepoint by char/codepoint, the matching implementation is more smooth and much faster. Anyway, please help review and comment. thanks, Sherman [1] http://cr.openjdk.java.net/~sherman/regexBacktracking/RegexFun.java

1 0

JDK 9 RFR of JDK-8151226: Mark UdpTest.java as intermittently failing
by joe darcy 03 Mar '16

03 Mar '16

Hello, The test java/net/ipv6tests/UdpTest.java has been observed to intermittently fail (JDK-8143998, JDK-8143097). Until these problems are addressed, the test should be marked accordingly. Please review the patch below which marks the test. Thanks, -Joe diff -r a603b1f1d9a1 test/java/net/ipv6tests/UdpTest.java --- a/test/java/net/ipv6tests/UdpTest.java Thu Mar 03 12:49:12 2016 -0800 +++ b/test/java/net/ipv6tests/UdpTest.java Thu Mar 03 15:01:29 2016 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -24,6 +24,7 @@ /* * @test * @bug 4868820 + * @key intermittent * @summary IPv6 support for Windows XP and 2003 server */

2 1