From daniel.fuchs at oracle.com Tue Nov 1 10:43:29 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 1 Nov 2016 10:43:29 +0000 Subject: RFR: 8152515: (logging) LogManager.resetLogger should ignore LinkageError In-Reply-To: <415297a7-4d20-6680-b36e-df6a5041713e@oracle.com> References: <850f971b-bffc-10d4-3097-979beb302351@oracle.com> <415297a7-4d20-6680-b36e-df6a5041713e@oracle.com> Message-ID: <60b37e7a-eef0-69a8-4b80-f1c185a55984@oracle.com> On 28/10/16 20:32, David Holmes wrote: > Hi Daniel, > > I've read the bug report on this and this issue "smells" to me. > LinkageError should not be a special case IMHO. The existing code was > trying to go the "ignore everything but 'serious errors' " route - but > without really considering what constitutes a "serious error". I think > the fact a LinkageError can turn up here reflects a bug in the code that > throws it - or possibly in something in between. > > There should be a very clear exception handling policy for this code, > and not special cases IMHO. Having that policy depend on whether > shutdown is in progress is okay to me as we know that things can behave > unexpectedly in that case. So I would advocate for a more general > > + } catch (Throwable e) { > + // Ignore all exceptions while shutting down > + if (globalHandlersState != STATE_SHUTDOWN) { > + throw e; > + } > Hi David, This is something I had been considering too. In the end it made me feel uneasy to trap all errors - like OOME or IllegalAccessError (swallowing IAE is not great when one migrates from JDK 8 to JDK 9 where IAE helps diagnose encapsulation issues) - so I opted for the minimal fix. I agree that just trapping LinkageError is a bit strange, but we do have a use case for that - which AFAIU is not uncommon. Anyway, if you ask me then the root of the problem is that the various shutdown hook can run in parallel and in unspecified order - so making the reset() more robust by trapping all errors might not be such a bad idea after all... Here is an updated webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8152515/webrev.02/ } catch (Exception ex) { // Problems closing a handler? Keep going... + } catch (Error e) { + // ignore Errors while shutting down + if (globalHandlersState != STATE_SHUTDOWN) { + throw e; + } } best regards, -- daniel > Cheers, > David > > On 28/10/2016 9:51 PM, Daniel Fuchs wrote: >> Hi, >> >> Please find below a trivial patch for: >> >> 8152515: (logging) LogManager.resetLogger should ignore LinkageError >> https://bugs.openjdk.java.net/browse/JDK-8152515 >> >> >> Patch: >> http://cr.openjdk.java.net/~dfuchs/webrev_8152515/webrev.00/ >> >> The issue might occur at shutdown, when a handler that makes uses >> of some APIs provided by an OSGI bundle which was already closed >> by the shutdown process is in turn closed by the LogManager.Cleaner >> thread. In that case some subclasses of LinkageError may be thrown, >> interrupting the reset process and preventing other handlers from >> being closed properly. >> >> The patch proposes to trivially ignore LinkageError at shutdown while >> the LogManager.Cleaner thread is running. >> >> best regards, >> >> -- daniel From Alan.Bateman at oracle.com Tue Nov 1 10:52:39 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 1 Nov 2016 10:52:39 +0000 Subject: [9] RFR: 8168923: Use unsigned random long in a temp directory name In-Reply-To: References: Message-ID: <10af846d-1e78-29ef-c4a1-fbf481c878da@oracle.com> On 30/10/2016 03:43, Ivan Gerasimov wrote: > Hello everyone! > > When File.createTempFile() is called, a random long value is > generated, which is then made positive with Math.abs() and then used > as a part of the directory name. > > Instead of using Math.abs() and Long.toString(), it would be better to > use Long.toUnsignedString(): > 1) no need to deal with the corner case of Long.MIN_VALUE, > 2) increase the space of random values by the factor of 2. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8168923 > WEBREV: http://cr.openjdk.java.net/~igerasim/8168923/00/webrev/ Looks okay, this code predates Long.toUnsignedString of course. -Alan From daniel.fuchs at oracle.com Tue Nov 1 11:14:29 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 1 Nov 2016 11:14:29 +0000 Subject: RFR 9: JDK-8168862:Tighten permissions granted to the jdk.zipfs module In-Reply-To: <5817A8E7.2070203@oracle.com> References: <5817A8E7.2070203@oracle.com> Message-ID: Hi Sherman, Disclaimer: I don't know anything about zipfs. However, I find it suspicious that it doesn't need a read permission for the "user.dir" system property. Isn't that a permission that any file system provider would need? My experience is that tests which deal with files and instantiate a security manager will usually grant that permission to all code bases, so it would be an easy permission to miss. best regards, -- daniel On 31/10/16 20:26, Xueming Shen wrote: > Please help review the change for > > issue: https://bugs.openjdk.java.net/browse/JDK-8168862 > webre: http://cr.openjdk.java.net/~sherman/8168862 > > The change is to tighten the permission to read "os.name" only. > > Thanks, > Xueming From chris.hegarty at oracle.com Tue Nov 1 11:33:26 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 1 Nov 2016 11:33:26 +0000 Subject: RFR 8168980 [9]: Reinstate sun.reflect.ReflectionFactory.newConstructorForSerialization(Class, Constructor) Message-ID: Recent changes for 8164908 [1] inadvertently removed the 2-arg newConstructorForSerialization method. This should be reinstated. https://bugs.openjdk.java.net/browse/JDK-8168980 http://cr.openjdk.java.net/~chegar/8168980/ -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8164908 From Alan.Bateman at oracle.com Tue Nov 1 11:55:03 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 1 Nov 2016 11:55:03 +0000 Subject: RFR 8168980 [9]: Reinstate sun.reflect.ReflectionFactory.newConstructorForSerialization(Class, Constructor) In-Reply-To: References: Message-ID: On 01/11/2016 11:33, Chris Hegarty wrote: > Recent changes for 8164908 [1] inadvertently removed the 2-arg > newConstructorForSerialization method. This should be reinstated. > > https://bugs.openjdk.java.net/browse/JDK-8168980 > http://cr.openjdk.java.net/~chegar/8168980/ > > Looks okay. -Alan From amaembo at gmail.com Tue Nov 1 13:58:59 2016 From: amaembo at gmail.com (Tagir F. Valeev) Date: Tue, 1 Nov 2016 20:58:59 +0700 Subject: 8168841 The JavaDoc of java.util.stream.Collectors method collectingAndThen has incorrect code snippet In-Reply-To: <3D33F959-13F9-4322-8AAA-B6A7012F28B8@oracle.com> References: <3D33F959-13F9-4322-8AAA-B6A7012F28B8@oracle.com> Message-ID: <312942275.20161101205859@gmail.com> Looks good. PS> Hi, PS> Please review the following JavDoc fix for PS> j.u.stream.Collectors:: collectingAndThen. PS> Thanks, PS> Paul. PS> diff -r 2e076c7e72d6 PS> src/java.base/share/classes/java/util/stream/Collectors.java PS> --- PS> a/src/java.base/share/classes/java/util/stream/Collectors.java Mon Oct 31 14:51:23 2016 -0700 PS> +++ PS> b/src/java.base/share/classes/java/util/stream/Collectors.java Mon Oct 31 14:55:16 2016 -0700 PS> @@ -508,7 +508,7 @@ PS> * transformation. For example, one could adapt the {@link #toList()} PS> * collector to always produce an immutable list with: PS> * 
{@code
PS> -     *     List people
PS> +     *     List list
PS>       *         =
PS> people.stream().collect(collectingAndThen(toList(), Collections::unmodifiableList));
PS>       * }
PS> * From jason_mehrens at hotmail.com Tue Nov 1 14:42:43 2016 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 1 Nov 2016 14:42:43 +0000 Subject: RFR: 8152515: (logging) LogManager.resetLogger should ignore LinkageError In-Reply-To: <60b37e7a-eef0-69a8-4b80-f1c185a55984@oracle.com> References: <850f971b-bffc-10d4-3097-979beb302351@oracle.com> <415297a7-4d20-6680-b36e-df6a5041713e@oracle.com>, <60b37e7a-eef0-69a8-4b80-f1c185a55984@oracle.com> Message-ID: The only other fix would be to collect all errors thrown (using addSuppressed) during close and throw only after the we have attempted to close all handlers. Then we would retain the behavior of always throwing errors. Jason ________________________________________ From: Daniel Fuchs Sent: Tuesday, November 01, 2016 5:43 AM To: David Holmes; core-libs-dev Cc: Jason Mehrens Subject: Re: RFR: 8152515: (logging) LogManager.resetLogger should ignore LinkageError On 28/10/16 20:32, David Holmes wrote: > Hi Daniel, > > I've read the bug report on this and this issue "smells" to me. > LinkageError should not be a special case IMHO. The existing code was > trying to go the "ignore everything but 'serious errors' " route - but > without really considering what constitutes a "serious error". I think > the fact a LinkageError can turn up here reflects a bug in the code that > throws it - or possibly in something in between. > > There should be a very clear exception handling policy for this code, > and not special cases IMHO. Having that policy depend on whether > shutdown is in progress is okay to me as we know that things can behave > unexpectedly in that case. So I would advocate for a more general > > + } catch (Throwable e) { > + // Ignore all exceptions while shutting down > + if (globalHandlersState != STATE_SHUTDOWN) { > + throw e; > + } > Hi David, This is something I had been considering too. In the end it made me feel uneasy to trap all errors - like OOME or IllegalAccessError (swallowing IAE is not great when one migrates from JDK 8 to JDK 9 where IAE helps diagnose encapsulation issues) - so I opted for the minimal fix. I agree that just trapping LinkageError is a bit strange, but we do have a use case for that - which AFAIU is not uncommon. Anyway, if you ask me then the root of the problem is that the various shutdown hook can run in parallel and in unspecified order - so making the reset() more robust by trapping all errors might not be such a bad idea after all... Here is an updated webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8152515/webrev.02/ } catch (Exception ex) { // Problems closing a handler? Keep going... + } catch (Error e) { + // ignore Errors while shutting down + if (globalHandlersState != STATE_SHUTDOWN) { + throw e; + } } best regards, -- daniel > Cheers, > David > > On 28/10/2016 9:51 PM, Daniel Fuchs wrote: >> Hi, >> >> Please find below a trivial patch for: >> >> 8152515: (logging) LogManager.resetLogger should ignore LinkageError >> https://bugs.openjdk.java.net/browse/JDK-8152515 >> >> >> Patch: >> http://cr.openjdk.java.net/~dfuchs/webrev_8152515/webrev.00/ >> >> The issue might occur at shutdown, when a handler that makes uses >> of some APIs provided by an OSGI bundle which was already closed >> by the shutdown process is in turn closed by the LogManager.Cleaner >> thread. In that case some subclasses of LinkageError may be thrown, >> interrupting the reset process and preventing other handlers from >> being closed properly. >> >> The patch proposes to trivially ignore LinkageError at shutdown while >> the LogManager.Cleaner thread is running. >> >> best regards, >> >> -- daniel From daniel.fuchs at oracle.com Tue Nov 1 14:52:07 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 1 Nov 2016 14:52:07 +0000 Subject: RFR: 8152515: (logging) LogManager.resetLogger should ignore LinkageError In-Reply-To: References: <850f971b-bffc-10d4-3097-979beb302351@oracle.com> <415297a7-4d20-6680-b36e-df6a5041713e@oracle.com> <60b37e7a-eef0-69a8-4b80-f1c185a55984@oracle.com> Message-ID: On 01/11/16 14:42, Jason Mehrens wrote: > The only other fix would be to collect all errors thrown (using addSuppressed) during close and throw only after the we have attempted to close all handlers. Then we would retain the behavior of always throwing errors. > Yes - that's also a possibility. Would that satisfy the issue with JavaMail as described in https://bugs.openjdk.java.net/browse/JDK-8152515 ? It is still unsure what should be done for OOME in this case though. I think I might still be attracted by the solution that brings the least code & behavioral change - so let's see if we can get away with special-casing shutdown to trap errors... best regards, -- daniel From alexandre.iline at oracle.com Tue Nov 1 17:31:57 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Tue, 1 Nov 2016 10:31:57 -0700 Subject: RFR: 8159523. Fix tests depending on absence of -limitmods in VM arguments. In-Reply-To: References: <94D737C6-A265-4657-B93E-4A2271617D27@oracle.com> <955f21c4-8d21-1186-f623-477356236a20@oracle.com> <3FCA900B-3A27-4E43-84C3-09789B25B813@oracle.com> <580936aa-3f94-1904-439e-5440cfc81e43@oracle.com> <383FAF53-1678-4685-9888-0F7A0A71BD4C@oracle.com> <1AC8A30B-B5B5-489E-97E5-FC1C3C1F70B4@oracle.com> <894b5aa6-100e-f819-8cfe-fce7096f6e84@oracle.com> Message-ID: Alan, For me, having module and package parameters separate makes it a lot easier: public JavaTask addExports(String module, String package, String? targetModules) Consider this: .addExports(JAVA_BASE, JDK_MISC, ALL_UNNAMED) where, needless to say, JAVA_BASE and JDK_MISC are constants defined in the test, or, perhaps, library class and presumably used in other cases. To me, this is better for obvious reasons, such as code completion in IDE and compile-time control over the mistakes. I also will be able to avoid concatenation all over the code: .addExports(JAVA_BASE + ?/? + JDK_MISC, ALL_UNNAMED) Similarly, for the same reasons, I prefer .addExports(JAVA_BASE, JDK_MISC, M1, M2) What do others think? To get everybody on the same page, we are discussing this webrev, which is introducing new task builder API to the JDK test library: http://cr.openjdk.java.net/~shurailine/8159523/webrev.04 This is the review request: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-October/009627.html Shura > On Nov 1, 2016, at 3:26 AM, Alan Bateman wrote: > > > > On 01/11/2016 10:23, Alan Bateman wrote: >> : >> >> .addExports("java.base", "jdk.internal.misc=ALL-UNNAMED") >> .addOpens("java.base", "jdk.internal.misc=m1,m2") > Oops, a typo here, I meant this of course: > > .addExports("java.base/jdk.internal.misc", "ALL-UNNAMED") > .addOpens("java.base/jdk.internal.misc", m1,m2") > > -Alan. From paul.sandoz at oracle.com Tue Nov 1 19:00:21 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 1 Nov 2016 12:00:21 -0700 Subject: RFR 8167974 MethodHandles.iteratedLoop(...) fails with CCE in the case of iterating over array In-Reply-To: <5817D188.7080103@oracle.com> References: <6A383F19-410E-495E-96DB-BC747C9FDB8E@oracle.com> <5817D188.7080103@oracle.com> Message-ID: > On 31 Oct 2016, at 16:19, Claes Redestad wrote: > > Hi, > > On 2016-10-31 22:47, Paul Sandoz wrote: >> Hi, >> >> And? 8167966 MethodHandles.iteratedLoop fails with IAE in the case of correct arguments. >> >> The two issues are closely intertwined in terms of the fix. Please review: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8167974-mhs-iterated-loop-no-arrays/webrev/ > > I think this imposes a reasonable restriction and nicely cleans up the > current specification. +1 > > I guess the if (!Iterable.class.isAssignableFrom(iterableType)) could > be moved inside the preceding else without losing readability. > I did that. Thanks, Paul. From claes.redestad at oracle.com Tue Nov 1 19:01:37 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 1 Nov 2016 20:01:37 +0100 Subject: RFR 8167974 MethodHandles.iteratedLoop(...) fails with CCE in the case of iterating over array In-Reply-To: References: <6A383F19-410E-495E-96DB-BC747C9FDB8E@oracle.com> <5817D188.7080103@oracle.com> Message-ID: <3f453d6f-6456-3458-f1b1-542cb17fc6e4@oracle.com> +1 /Claes On 2016-11-01 20:00, Paul Sandoz wrote: >> On 31 Oct 2016, at 16:19, Claes Redestad wrote: >> >> Hi, >> >> On 2016-10-31 22:47, Paul Sandoz wrote: >>> Hi, >>> >>> And? 8167966 MethodHandles.iteratedLoop fails with IAE in the case of correct arguments. >>> >>> The two issues are closely intertwined in terms of the fix. Please review: >>> >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8167974-mhs-iterated-loop-no-arrays/webrev/ >> I think this imposes a reasonable restriction and nicely cleans up the >> current specification. +1 >> >> I guess the if (!Iterable.class.isAssignableFrom(iterableType)) could >> be moved inside the preceding else without losing readability. >> > I did that. > > Thanks, > Paul. From claes.redestad at oracle.com Tue Nov 1 21:22:45 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 1 Nov 2016 22:22:45 +0100 Subject: RFR 8163553 java.lang.LinkageError from test java/lang/ThreadGroup/Stop.java In-Reply-To: <8C56B19F-22EC-4E1E-AA47-E0D629231B07@oracle.com> References: <5EA4A44D-3E66-4B76-8160-163580606FF1@oracle.com> <8C56B19F-22EC-4E1E-AA47-E0D629231B07@oracle.com> Message-ID: <581907A5.8020600@oracle.com> +1 /Claes On 2016-10-27 21:24, Paul Sandoz wrote: > Gentle reminder. > > Paul. > >> On 18 Oct 2016, at 11:41, Paul Sandoz wrote: >> >> Hi, >> >> Please review: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8163553-vh-mh-link-errors-not-wrapped/webrev/ >> >> This is the issue that motivated a change in the behaviour of indy wrapping Errors in BootstrapMethodError, JDK-8166974. I plan to push this issue with JDK-8166974 to hs, since they are related in behaviour even though there is no direct dependency between the patches. >> >> >> When invoking signature-polymorphic methods a similar but hardcoded dance occurs, with an appeal to Java code, to link the call site. >> >> - MethodHandle.invoke/invokeExact (and the VH methods) would wrap all Errors in LinkageError. Now they are passed through, thus an Error like ThreadDeath is not wrapped. >> >> - MethodHandle.invoke/invokeExact/invokeBasic throw Throwable, and in certain cases the Throwable is wrapped in an InternalError. In many other cases Error and RuntimeException are propagated, which i think in general is the right pattern, so i consistently applied that. >> >> - I updated StringConcatFactory to also pass through Errors and avoid unduly wrapping StringConcatException in another instance of StringConcatException. (LambdaMetafactory and associated classes required no changes.) >> >> Thanks, >> Paul. > From david.holmes at oracle.com Wed Nov 2 02:17:38 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Nov 2016 12:17:38 +1000 Subject: RFR: 8152515: (logging) LogManager.resetLogger should ignore LinkageError In-Reply-To: <60b37e7a-eef0-69a8-4b80-f1c185a55984@oracle.com> References: <850f971b-bffc-10d4-3097-979beb302351@oracle.com> <415297a7-4d20-6680-b36e-df6a5041713e@oracle.com> <60b37e7a-eef0-69a8-4b80-f1c185a55984@oracle.com> Message-ID: Hi Daniel, This change seems fine to me. Given there is an inadequate specification for the public reset() method in regards to possible exceptions occurring whilst it attempts all its task, I think this is as far as we should go at this time. Thanks, David On 1/11/2016 8:43 PM, Daniel Fuchs wrote: > On 28/10/16 20:32, David Holmes wrote: >> Hi Daniel, >> >> I've read the bug report on this and this issue "smells" to me. >> LinkageError should not be a special case IMHO. The existing code was >> trying to go the "ignore everything but 'serious errors' " route - but >> without really considering what constitutes a "serious error". I think >> the fact a LinkageError can turn up here reflects a bug in the code that >> throws it - or possibly in something in between. >> >> There should be a very clear exception handling policy for this code, >> and not special cases IMHO. Having that policy depend on whether >> shutdown is in progress is okay to me as we know that things can behave >> unexpectedly in that case. So I would advocate for a more general >> >> + } catch (Throwable e) { >> + // Ignore all exceptions while shutting down >> + if (globalHandlersState != STATE_SHUTDOWN) { >> + throw e; >> + } >> > > Hi David, > > This is something I had been considering too. > > In the end it made me feel uneasy to trap all errors - like OOME > or IllegalAccessError (swallowing IAE is not great when > one migrates from JDK 8 to JDK 9 where IAE helps diagnose > encapsulation issues) - so I opted for the minimal fix. > > I agree that just trapping LinkageError is a bit strange, > but we do have a use case for that - which AFAIU is not > uncommon. > > Anyway, if you ask me then the root of the problem is > that the various shutdown hook can run in parallel and in > unspecified order - so making the reset() more robust by > trapping all errors might not be such a bad idea after all... > Here is an updated webrev: > > http://cr.openjdk.java.net/~dfuchs/webrev_8152515/webrev.02/ > > > } catch (Exception ex) { > // Problems closing a handler? Keep going... > + } catch (Error e) { > + // ignore Errors while shutting down > + if (globalHandlersState != STATE_SHUTDOWN) { > + throw e; > + } > } > > best regards, > > -- daniel > > >> Cheers, >> David >> >> On 28/10/2016 9:51 PM, Daniel Fuchs wrote: >>> Hi, >>> >>> Please find below a trivial patch for: >>> >>> 8152515: (logging) LogManager.resetLogger should ignore LinkageError >>> https://bugs.openjdk.java.net/browse/JDK-8152515 >>> >>> >>> Patch: >>> http://cr.openjdk.java.net/~dfuchs/webrev_8152515/webrev.00/ >>> >>> The issue might occur at shutdown, when a handler that makes uses >>> of some APIs provided by an OSGI bundle which was already closed >>> by the shutdown process is in turn closed by the LogManager.Cleaner >>> thread. In that case some subclasses of LinkageError may be thrown, >>> interrupting the reset process and preventing other handlers from >>> being closed properly. >>> >>> The patch proposes to trivially ignore LinkageError at shutdown while >>> the LogManager.Cleaner thread is running. >>> >>> best regards, >>> >>> -- daniel > From amy.lu at oracle.com Wed Nov 2 02:47:44 2016 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 2 Nov 2016 10:47:44 +0800 Subject: JDK 9 RFR of JDK-8151511: Test case in CollectionAndMapModifyStreamTest for LinkedHashMap overrides that for HashMap Message-ID: Please review the patch for fixing typo in steam tests: bug: https://bugs.openjdk.java.net/browse/JDK-8151511 webrev: http://cr.openjdk.java.net/~amlu/8151511/webrev.00/ 1) In CollectionAndMapModifyStreamTest.java maps.put(HashMap.class.getName(), () -> new LinkedHashMap<>(content)); should be maps.put(LinkedHashMap.class.getName(), () -> new LinkedHashMap<>(content)); 2) ThowableHelper.java renamed to ThrowableHelper.java Thanks, Amy From amy.lu at oracle.com Wed Nov 2 09:43:21 2016 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 2 Nov 2016 17:43:21 +0800 Subject: JDK 9 RFR of JDK-8143097: Test java/net/ipv6tests/UdpTest.java fails Message-ID: Please reviewthe patch for java/net/ipv6tests/UdpTest.java bug: https://bugs.openjdk.java.net/browse/JDK-8143097 webrev: http://cr.openjdk.java.net/~amlu/8143097/webrev.00/ This test fails intermittently in a test scenario for checking DatagramSocket (with SO_TIMEOUT enabled) 'receive'works even after a delay (but within the specified timeout): 120 static void test2 () throws Exception { 121 s1 = new DatagramSocket (); ...... 151 s1.setSoTimeout(10000); 152 runAfter (2000, new Runnable () { <<<< --- run after the given time (2000) has elapsed 153 public void run () { ...... 156 s.send (p); ...... 158 } 159 }); 160 t1 = System.currentTimeMillis(); 161 s1.receive (new DatagramPacket (new byte [128], 128)); <<<< ---receive should works here 162 checkTime (System.currentTimeMillis() - t1, 4000); The final checkTime method is for checking the time got (System.currentTimeMillis() - t1) is equal to (with 50% tolerance) the time expected (4000). This assumption is not correct. Test should check that the time got (System.currentTimeMillis() - t1) is between 2000 (the given delay) and 10000 (the given timeout). Thanks, Amy From chris.hegarty at oracle.com Wed Nov 2 10:17:10 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 2 Nov 2016 10:17:10 +0000 Subject: JDK 9 RFR of JDK-8143097: Test java/net/ipv6tests/UdpTest.java fails In-Reply-To: References: Message-ID: <45C45C48-BBAC-4034-A27B-5C76DB59136A@oracle.com> Amy, > On 2 Nov 2016, at 09:43, Amy Lu wrote: > > Please reviewthe patch for java/net/ipv6tests/UdpTest.java > > bug: https://bugs.openjdk.java.net/browse/JDK-8143097 > webrev: http://cr.openjdk.java.net/~amlu/8143097/webrev.00/ I think what you have will probably be ok, given the 50% tolerance, but should?t the end time be 10_000 + 2_000 ( the delay + the socket timeout )? -Chris. > This test fails intermittently in a test scenario for checking DatagramSocket (with SO_TIMEOUT enabled) 'receive'works even after a delay (but within the specified timeout): > > 120 static void test2 () throws Exception { > 121 s1 = new DatagramSocket (); > ...... > 151 s1.setSoTimeout(10000); > 152 runAfter (2000, new Runnable () { <<<< --- run after the given time (2000) has elapsed > 153 public void run () { > ...... > 156 s.send (p); > ...... > 158 } > 159 }); > 160 t1 = System.currentTimeMillis(); > 161 s1.receive (new DatagramPacket (new byte [128], 128)); <<<< ---receive should works here > 162 checkTime (System.currentTimeMillis() - t1, 4000); > > The final checkTime method is for checking the time got (System.currentTimeMillis() - t1) is equal to (with 50% tolerance) the time expected (4000). This assumption is not correct. Test should check that the time got (System.currentTimeMillis() - t1) is between 2000 (the given delay) and 10000 (the given timeout). From scolebourne at joda.org Wed Nov 2 10:34:19 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 2 Nov 2016 10:34:19 +0000 Subject: RFR: JDK-8167618: DateTimeFormatter.format() uses exceptions for flow control. In-Reply-To: <58137592.1000207@oracle.com> References: <58137592.1000207@oracle.com> Message-ID: I agree with Nadeesh, the updated code can still throw DateTimeException from the call to getLong(). Unlike before, this DateTimeException is desired. Stephen On 28 October 2016 at 16:58, nadeesh tv wrote: > > Hi Anubhav, > > > - * @throws DateTimeException if the field is not available and the > section is not optional > > > I think you should not remove the DTException since still there is a chance > of throwing DTE > Regards, > Nadeesh > > On 10/28/2016 12:18 AM, Anubhav Meena wrote: >> >> Hi all, >> >> Please review. Please ignore last mail as links not working properly >> there. >> >> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8167618 >> >> Issue: DateTimeFormatter.format() uses exceptions for flow control. >> Webrev: http://cr.openjdk.java.net/~rchamyal/anmeena/8167618/webrev.00/ >> > > > -- > Thanks and Regards, > Nadeesh TV > From amy.lu at oracle.com Wed Nov 2 11:06:47 2016 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 2 Nov 2016 19:06:47 +0800 Subject: JDK 9 RFR of JDK-8143097: Test java/net/ipv6tests/UdpTest.java fails In-Reply-To: <45C45C48-BBAC-4034-A27B-5C76DB59136A@oracle.com> References: <45C45C48-BBAC-4034-A27B-5C76DB59136A@oracle.com> Message-ID: <74f0c260-68c4-dd6c-55a2-8937454ddb4c@oracle.com> On 11/2/16 6:17 PM, Chris Hegarty wrote: > Amy, > >> On 2 Nov 2016, at 09:43, Amy Lu wrote: >> >> Please reviewthe patch for java/net/ipv6tests/UdpTest.java >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8143097 >> webrev: http://cr.openjdk.java.net/~amlu/8143097/webrev.00/ > I think what you have will probably be ok, given the 50% tolerance, but should?t > the end time be 10_000 + 2_000 ( the delay + the socket timeout )? Thanks for your review, Chris. Let me try explain more. The end time here is for s1 socket timeout: s1.setSoTimeout(10000); No matter how long the delay is in runAfter (which is for s.send(p)), s1.receive works when < 10000 (the given timeout); otherwise it will throw SocketTimeoutException. Thanks, Amy > > -Chris. > >> This test fails intermittently in a test scenario for checking DatagramSocket (with SO_TIMEOUT enabled) 'receive'works even after a delay (but within the specified timeout): >> >> 120 static void test2 () throws Exception { >> 121 s1 = new DatagramSocket (); >> ...... >> 151 s1.setSoTimeout(10000); >> 152 runAfter (2000, new Runnable () { <<<< --- run after the given time (2000) has elapsed >> 153 public void run () { >> ...... >> 156 s.send (p); >> ...... >> 158 } >> 159 }); >> 160 t1 = System.currentTimeMillis(); >> 161 s1.receive (new DatagramPacket (new byte [128], 128)); <<<< ---receive should works here >> 162 checkTime (System.currentTimeMillis() - t1, 4000); >> >> The final checkTime method is for checking the time got (System.currentTimeMillis() - t1) is equal to (with 50% tolerance) the time expected (4000). This assumption is not correct. Test should check that the time got (System.currentTimeMillis() - t1) is between 2000 (the given delay) and 10000 (the given timeout). > From chris.hegarty at oracle.com Wed Nov 2 11:20:53 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 2 Nov 2016 11:20:53 +0000 Subject: JDK 9 RFR of JDK-8151511: Test case in CollectionAndMapModifyStreamTest for LinkedHashMap overrides that for HashMap In-Reply-To: References: Message-ID: On 2 Nov 2016, at 02:47, Amy Lu wrote: > > Please review the patch for fixing typo in steam tests: > > bug: https://bugs.openjdk.java.net/browse/JDK-8151511 > webrev: http://cr.openjdk.java.net/~amlu/8151511/webrev.00/ This looks good. Thanks Amy. -Chris. > 1) In CollectionAndMapModifyStreamTest.java > maps.put(HashMap.class.getName(), () -> new LinkedHashMap<>(content)); > should be > maps.put(LinkedHashMap.class.getName(), () -> new LinkedHashMap<>(content)); > > 2) ThowableHelper.java renamed to ThrowableHelper.java > > Thanks, > Amy From sergei.kovalev at oracle.com Wed Nov 2 11:22:34 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Wed, 2 Nov 2016 14:22:34 +0300 Subject: RFR(s): 8169055: [TESTBUG] : java/io/Serializable/serialFilter/ tests have undeclared dependency on jdk.jdeps module Message-ID: Hi team, Please review a very small fix for tests related to java/io/Serializable pack. BugID: https://bugs.openjdk.java.net/browse/JDK-8169055 WebRev: http://cr.openjdk.java.net/~skovalev/8169055/webrev.00/ Issue: Several tests failing in case usage of "--limit-modules" command line option. Solution: add missed declaration into test jtreg header. -- With best regards, Sergei From chris.hegarty at oracle.com Wed Nov 2 11:25:01 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 2 Nov 2016 11:25:01 +0000 Subject: JDK 9 RFR of JDK-8143097: Test java/net/ipv6tests/UdpTest.java fails In-Reply-To: <74f0c260-68c4-dd6c-55a2-8937454ddb4c@oracle.com> References: <45C45C48-BBAC-4034-A27B-5C76DB59136A@oracle.com> <74f0c260-68c4-dd6c-55a2-8937454ddb4c@oracle.com> Message-ID: <30D0F3D8-03EB-4A62-A842-4B1A4A5306BA@oracle.com> On 2 Nov 2016, at 11:06, Amy Lu wrote: > > On 11/2/16 6:17 PM, Chris Hegarty wrote: >> Amy, >> >>> On 2 Nov 2016, at 09:43, Amy Lu wrote: >>> >>> Please reviewthe patch for java/net/ipv6tests/UdpTest.java >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8143097 >>> webrev: http://cr.openjdk.java.net/~amlu/8143097/webrev.00/ >> I think what you have will probably be ok, given the 50% tolerance, but should?t >> the end time be 10_000 + 2_000 ( the delay + the socket timeout )? > > Thanks for your review, Chris. > > Let me try explain more. > > The end time here is for s1 socket timeout: > s1.setSoTimeout(10000); > No matter how long the delay is in runAfter (which is for s.send(p)), s1.receive works when < 10000 (the given timeout); otherwise it will throw SocketTimeoutException. Ah ok. So we do not expect receive to throw, it should actually receive the data. In which case the 10,000 is really just an upper bound. Ok got it. Your changes are fine as are. -Chris. > Thanks, > Amy > >> >> -Chris. >> >>> This test fails intermittently in a test scenario for checking DatagramSocket (with SO_TIMEOUT enabled) 'receive'works even after a delay (but within the specified timeout): >>> >>> 120 static void test2 () throws Exception { >>> 121 s1 = new DatagramSocket (); >>> ...... >>> 151 s1.setSoTimeout(10000); >>> 152 runAfter (2000, new Runnable () { <<<< --- run after the given time (2000) has elapsed >>> 153 public void run () { >>> ...... >>> 156 s.send (p); >>> ...... >>> 158 } >>> 159 }); >>> 160 t1 = System.currentTimeMillis(); >>> 161 s1.receive (new DatagramPacket (new byte [128], 128)); <<<< ---receive should works here >>> 162 checkTime (System.currentTimeMillis() - t1, 4000); >>> >>> The final checkTime method is for checking the time got (System.currentTimeMillis() - t1) is equal to (with 50% tolerance) the time expected (4000). This assumption is not correct. Test should check that the time got (System.currentTimeMillis() - t1) is between 2000 (the given delay) and 10000 (the given timeout). >> > From daniel.fuchs at oracle.com Wed Nov 2 11:45:09 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 2 Nov 2016 11:45:09 +0000 Subject: RFR(s): 8169055: [TESTBUG] : java/io/Serializable/serialFilter/ tests have undeclared dependency on jdk.jdeps module In-Reply-To: References: Message-ID: <6b58427b-5a15-f297-b778-5ac88cf2d408@oracle.com> Hi Sergey, I do not see any dependency on jdk.jdeps in the test sources. What I do see is a dependency on java.compiler though. So why @modules jdk.jdeps and not @modules java.compiler? best regards, -- daniel On 02/11/16 11:22, Sergei Kovalev wrote: > Hi team, > > Please review a very small fix for tests related to java/io/Serializable > pack. > > BugID: https://bugs.openjdk.java.net/browse/JDK-8169055 > WebRev: http://cr.openjdk.java.net/~skovalev/8169055/webrev.00/ > > Issue: Several tests failing in case usage of "--limit-modules" command > line option. > Solution: add missed declaration into test jtreg header. > From sergei.kovalev at oracle.com Wed Nov 2 12:31:17 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Wed, 2 Nov 2016 15:31:17 +0300 Subject: RFR(s): 8169055: [TESTBUG] : java/io/Serializable/serialFilter/ tests have undeclared dependency on jdk.jdeps module In-Reply-To: <6b58427b-5a15-f297-b778-5ac88cf2d408@oracle.com> References: <6b58427b-5a15-f297-b778-5ac88cf2d408@oracle.com> Message-ID: <2cbab563-6748-3e57-538f-3bae2a99a8f3@oracle.com> Hi Daniel, Thank you for looking this. We have six java files: CheckInputOrderTest.java, FilterWithSecurityManagerTest.java, GlobalFilterTest.java, MixedFiltersTest.java, SerialFilterTest.java. Last one has declared import: import javax.lang.model.SourceVersion; that is a part of jdk.jdeps module. All other java files has a line like: "@build FilterWithSecurityManagerTest SerialFilterTest" that means that the test requires the SerialFilterTest.java being compiled and therefore it depends on jdeps module too. Could you please point me which particular imports belong to jdk.compiler module? For execution I've use the command line jtreg -jdk:/home/skovalev/TRASH/jdk9_latest -verbose:all -javaoptions:"--limit-modules java.base,jdk.jdeps" -javacoptions:"--limit-modules java.base,jdk.jdeps" /home/skovalev/repos/jdk9-dev/jdk/test/java/io/Serializable/serialFilter and the tests compiled successfully without jdk.compiler. What should I change in my environment to highlight dependency from the module? 02.11.16 14:45, Daniel Fuchs wrote: > Hi Sergey, > > I do not see any dependency on jdk.jdeps in the test sources. > What I do see is a dependency on java.compiler though. > > So why @modules jdk.jdeps and not @modules java.compiler? > > best regards, > > -- daniel > > > On 02/11/16 11:22, Sergei Kovalev wrote: >> Hi team, >> >> Please review a very small fix for tests related to java/io/Serializable >> pack. >> >> BugID: https://bugs.openjdk.java.net/browse/JDK-8169055 >> WebRev: http://cr.openjdk.java.net/~skovalev/8169055/webrev.00/ >> >> Issue: Several tests failing in case usage of "--limit-modules" command >> line option. >> Solution: add missed declaration into test jtreg header. >> > -- With best regards, Sergei From chris.hegarty at oracle.com Wed Nov 2 12:34:30 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 2 Nov 2016 12:34:30 +0000 Subject: RFR(s): 8169055: [TESTBUG] : java/io/Serializable/serialFilter/ tests have undeclared dependency on jdk.jdeps module In-Reply-To: <2cbab563-6748-3e57-538f-3bae2a99a8f3@oracle.com> References: <6b58427b-5a15-f297-b778-5ac88cf2d408@oracle.com> <2cbab563-6748-3e57-538f-3bae2a99a8f3@oracle.com> Message-ID: <7C8CC4B0-B12C-4172-BD16-3EEE223EA629@oracle.com> > On 2 Nov 2016, at 12:31, Sergei Kovalev wrote: > > javax.lang.model.SourceVersion This type is in the java.compiler module. -Chris. From sergei.kovalev at oracle.com Wed Nov 2 12:51:19 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Wed, 2 Nov 2016 15:51:19 +0300 Subject: RFR(s): 8169055: [TESTBUG] : java/io/Serializable/serialFilter/ tests have undeclared dependency on jdk.jdeps module In-Reply-To: <7C8CC4B0-B12C-4172-BD16-3EEE223EA629@oracle.com> References: <6b58427b-5a15-f297-b778-5ac88cf2d408@oracle.com> <2cbab563-6748-3e57-538f-3bae2a99a8f3@oracle.com> <7C8CC4B0-B12C-4172-BD16-3EEE223EA629@oracle.com> Message-ID: <02f2aaea-1538-340a-905c-8e471bc04778@oracle.com> Fixed http://cr.openjdk.java.net/~skovalev/8169055/webrev.01/ 02.11.16 15:34, Chris Hegarty wrote: >> On 2 Nov 2016, at 12:31, Sergei Kovalev wrote: >> >> javax.lang.model.SourceVersion > This type is in the java.compiler module. > > -Chris. -- With best regards, Sergei From roger.riggs at oracle.com Wed Nov 2 13:07:24 2016 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 2 Nov 2016 09:07:24 -0400 Subject: RFR(s): 8169055: [TESTBUG] : java/io/Serializable/serialFilter/ tests have undeclared dependency on jdk.jdeps module In-Reply-To: <02f2aaea-1538-340a-905c-8e471bc04778@oracle.com> References: <6b58427b-5a15-f297-b778-5ac88cf2d408@oracle.com> <2cbab563-6748-3e57-538f-3bae2a99a8f3@oracle.com> <7C8CC4B0-B12C-4172-BD16-3EEE223EA629@oracle.com> <02f2aaea-1538-340a-905c-8e471bc04778@oracle.com> Message-ID: <413232c3-e399-c443-11ae-ff7d5c5dbdd5@oracle.com> Hi, Instead of adding more dependencies, let me look and see if there is way to remove the dependency. Roger On 11/2/16 8:51 AM, Sergei Kovalev wrote: > Fixed > > http://cr.openjdk.java.net/~skovalev/8169055/webrev.01/ > > > 02.11.16 15:34, Chris Hegarty wrote: >>> On 2 Nov 2016, at 12:31, Sergei Kovalev >>> wrote: >>> >>> javax.lang.model.SourceVersion >> This type is in the java.compiler module. >> >> -Chris. > From goetz.lindenmaier at sap.com Wed Nov 2 13:16:08 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 2 Nov 2016 13:16:08 +0000 Subject: RFR{S}: 8166837: [TESTBUG] Fix tests on Linux/s390x Message-ID: <57dc005898984b3a92397542534d0152@derote13de14.global.corp.sap> Hi, This are the changes needed to the tests in the jdk repository to work with s390. In test/sun/tools/jhsdb I just use the other Platform.java which gets it's shouldSAAttach() method changed to return 'false' on S390. (I sent that part of the change to the hs-compiler list.) test/java/awt/JAWT/JAWT.sh is just skipped. Please review this change. http://cr.openjdk.java.net/~goetz/wr16/8166837-jtreg_fixes/jdk-wr.01/ Best regards, Goetz. From daniel.fuchs at oracle.com Wed Nov 2 13:24:21 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 2 Nov 2016 13:24:21 +0000 Subject: RFR(s): 8169055: [TESTBUG] : java/io/Serializable/serialFilter/ tests have undeclared dependency on jdk.jdeps module In-Reply-To: <2cbab563-6748-3e57-538f-3bae2a99a8f3@oracle.com> References: <6b58427b-5a15-f297-b778-5ac88cf2d408@oracle.com> <2cbab563-6748-3e57-538f-3bae2a99a8f3@oracle.com> Message-ID: Hi Sergey, On 02/11/16 12:31, Sergei Kovalev wrote: > Hi Daniel, > > Thank you for looking this. > > We have six java files: CheckInputOrderTest.java, > FilterWithSecurityManagerTest.java, GlobalFilterTest.java, > MixedFiltersTest.java, SerialFilterTest.java. > > Last one has declared import: > > import javax.lang.model.SourceVersion; > > that is a part of jdk.jdeps module. All other java files has a line > like: "@build FilterWithSecurityManagerTest SerialFilterTest" that means > that the test requires the SerialFilterTest.java being compiled and > therefore it depends on jdeps module too. > > Could you please point me which particular imports belong to > jdk.compiler module? javax.lang.model is exported by java.compiler, not jdk.jdeps. http://hg.openjdk.java.net/jdk9/dev/langtools/file/tip/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java > > For execution I've use the command line > > jtreg -jdk:/home/skovalev/TRASH/jdk9_latest -verbose:all > -javaoptions:"--limit-modules java.base,jdk.jdeps" > -javacoptions:"--limit-modules java.base,jdk.jdeps" > /home/skovalev/repos/jdk9-dev/jdk/test/java/io/Serializable/serialFilter > > and the tests compiled successfully without jdk.compiler. What should I > change in my environment to highlight dependency from the module? jdk.jdeps requires java.compiler, and IMO this is why this working. But as far as I can tell nothing depends on jdk.jdeps in these tests. cheers, -- daniel > > 02.11.16 14:45, Daniel Fuchs wrote: >> Hi Sergey, >> >> I do not see any dependency on jdk.jdeps in the test sources. >> What I do see is a dependency on java.compiler though. >> >> So why @modules jdk.jdeps and not @modules java.compiler? >> >> best regards, >> >> -- daniel >> >> >> On 02/11/16 11:22, Sergei Kovalev wrote: >>> Hi team, >>> >>> Please review a very small fix for tests related to java/io/Serializable >>> pack. >>> >>> BugID: https://bugs.openjdk.java.net/browse/JDK-8169055 >>> WebRev: http://cr.openjdk.java.net/~skovalev/8169055/webrev.00/ >>> >>> Issue: Several tests failing in case usage of "--limit-modules" command >>> line option. >>> Solution: add missed declaration into test jtreg header. >>> >> > > -- > With best regards, > Sergei > From daniel.fuchs at oracle.com Wed Nov 2 13:25:36 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 2 Nov 2016 13:25:36 +0000 Subject: RFR(s): 8169055: [TESTBUG] : java/io/Serializable/serialFilter/ tests have undeclared dependency on jdk.jdeps module In-Reply-To: <02f2aaea-1538-340a-905c-8e471bc04778@oracle.com> References: <6b58427b-5a15-f297-b778-5ac88cf2d408@oracle.com> <2cbab563-6748-3e57-538f-3bae2a99a8f3@oracle.com> <7C8CC4B0-B12C-4172-BD16-3EEE223EA629@oracle.com> <02f2aaea-1538-340a-905c-8e471bc04778@oracle.com> Message-ID: <10290ff6-0416-c375-550a-720ba6b35f08@oracle.com> Hi Sergey, Why jdk.compiler? Why not simply java.compiler? best regards, -- daniel On 02/11/16 12:51, Sergei Kovalev wrote: > Fixed > > http://cr.openjdk.java.net/~skovalev/8169055/webrev.01/ > > > 02.11.16 15:34, Chris Hegarty wrote: >>> On 2 Nov 2016, at 12:31, Sergei Kovalev >>> wrote: >>> >>> javax.lang.model.SourceVersion >> This type is in the java.compiler module. >> >> -Chris. > From sergei.kovalev at oracle.com Wed Nov 2 13:31:05 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Wed, 2 Nov 2016 16:31:05 +0300 Subject: RFR(s): 8169055: [TESTBUG] : java/io/Serializable/serialFilter/ tests have undeclared dependency on jdk.jdeps module In-Reply-To: <10290ff6-0416-c375-550a-720ba6b35f08@oracle.com> References: <6b58427b-5a15-f297-b778-5ac88cf2d408@oracle.com> <2cbab563-6748-3e57-538f-3bae2a99a8f3@oracle.com> <7C8CC4B0-B12C-4172-BD16-3EEE223EA629@oracle.com> <02f2aaea-1538-340a-905c-8e471bc04778@oracle.com> <10290ff6-0416-c375-550a-720ba6b35f08@oracle.com> Message-ID: Thank you all, java.compiler is enough. http://cr.openjdk.java.net/~skovalev/8169055/webrev.02/ 02.11.16 16:25, Daniel Fuchs wrote: > Hi Sergey, > > Why jdk.compiler? Why not simply java.compiler? > > best regards, > > -- daniel > > On 02/11/16 12:51, Sergei Kovalev wrote: >> Fixed >> >> http://cr.openjdk.java.net/~skovalev/8169055/webrev.01/ >> >> >> 02.11.16 15:34, Chris Hegarty wrote: >>>> On 2 Nov 2016, at 12:31, Sergei Kovalev >>>> wrote: >>>> >>>> javax.lang.model.SourceVersion >>> This type is in the java.compiler module. >>> >>> -Chris. >> > -- With best regards, Sergei From volker.simonis at gmail.com Wed Nov 2 14:21:43 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 2 Nov 2016 15:21:43 +0100 Subject: RFR{S}: 8166837: [TESTBUG] Fix tests on Linux/s390x In-Reply-To: <57dc005898984b3a92397542534d0152@derote13de14.global.corp.sap> References: <57dc005898984b3a92397542534d0152@derote13de14.global.corp.sap> Message-ID: Hi Goetz, the change looks good except the two throws declarations in: test/sun/tools/jhsdb/BasicLauncherTest.java test/sun/tools/jhsdb/HeapDumpTest.java I think "throws Exception" should be enough - we don't need "throws IOException, Exception". Thanks, Volker PS: we should really get rid of jdk/test/lib/testlibrary/jdk/testlibrary/Platform.java in favour of test/lib/jdk/test/lib/Platform.java. Does anybody know if there's already a bug to track that? On Wed, Nov 2, 2016 at 2:16 PM, Lindenmaier, Goetz wrote: > Hi, > > This are the changes needed to the tests in the jdk repository > to work with s390. > In test/sun/tools/jhsdb I just use the other Platform.java which > gets it's shouldSAAttach() method changed to return 'false' on > S390. (I sent that part of the change to the hs-compiler list.) > > test/java/awt/JAWT/JAWT.sh is just skipped. > > Please review this change. > http://cr.openjdk.java.net/~goetz/wr16/8166837-jtreg_fixes/jdk-wr.01/ > > Best regards, > Goetz. From ivan.gerasimov at oracle.com Wed Nov 2 14:39:56 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 2 Nov 2016 17:39:56 +0300 Subject: [9] RFR: 8168923: Use unsigned random long in a temp directory name In-Reply-To: <8DFC271F-F855-47FC-AEBE-1DB1E8B3BD85@oracle.com> References: <8DFC271F-F855-47FC-AEBE-1DB1E8B3BD85@oracle.com> Message-ID: Thank you Brian for review! On 31.10.2016 21:23, Brian Burkhalter wrote: > One more thing ? > > In [1] lines 58-59 could be corrected in the same way. Yes, right. Thanks for catching it! Here's the updated webrev: http://cr.openjdk.java.net/~igerasim/8168923/01/webrev/ > Thanks, > > Brian > > [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/0086eb10182b/src/java.base/share/classes/java/nio/file/TempFileHelper.java > > On Oct 31, 2016, at 9:00 AM, Brian Burkhalter wrote: > >> Hello, Ivan, >> >> Aside from the inevitable copyright year update this looks fine to me. >> What effect does it have on the regression test run? Tested (jdk_io|jdk_nio) on all platforms, no failures. With kind regards, Ivan >> Thanks, >> >> Brian >> >> On Oct 29, 2016, at 8:43 PM, Ivan Gerasimov wrote: >> >>> Hello everyone! >>> >>> When File.createTempFile() is called, a random long value is generated, which is then made positive with Math.abs() and then used as a part of the directory name. >>> >>> Instead of using Math.abs() and Long.toString(), it would be better to use Long.toUnsignedString(): >>> 1) no need to deal with the corner case of Long.MIN_VALUE, >>> 2) increase the space of random values by the factor of 2. >>> >>> Would you please help review the fix? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8168923 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8168923/00/webrev/ >>> >>> With kind regards, >>> Ivan > From brian.burkhalter at oracle.com Wed Nov 2 14:51:05 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 2 Nov 2016 07:51:05 -0700 Subject: [9] RFR: 8168923: Use unsigned random long in a temp directory name In-Reply-To: References: <8DFC271F-F855-47FC-AEBE-1DB1E8B3BD85@oracle.com> Message-ID: <217BF5DD-B564-4F32-B91C-3763D5ADA385@oracle.com> Hi Ivan, This all looks good. +1. Thanks, Brian On Nov 2, 2016, at 7:39 AM, Ivan Gerasimov wrote: > Thank you Brian for review! > > > On 31.10.2016 21:23, Brian Burkhalter wrote: >> One more thing ? >> >> In [1] lines 58-59 could be corrected in the same way. > > Yes, right. Thanks for catching it! > > Here's the updated webrev: > http://cr.openjdk.java.net/~igerasim/8168923/01/webrev/ > >> Thanks, >> >> Brian >> >> [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/0086eb10182b/src/java.base/share/classes/java/nio/file/TempFileHelper.java >> >> On Oct 31, 2016, at 9:00 AM, Brian Burkhalter wrote: >> >>> Hello, Ivan, >>> >>> Aside from the inevitable copyright year update this looks fine to me. >>> What effect does it have on the regression test run? > > Tested (jdk_io|jdk_nio) on all platforms, no failures. From david.holmes at oracle.com Wed Nov 2 15:27:50 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Nov 2016 01:27:50 +1000 Subject: Documentation for ForkJoinPool class In-Reply-To: <25171478100024@web6g.yandex.ru> References: <25171478100024@web6g.yandex.ru> Message-ID: <70846a90-6045-a536-f176-6d84569ee098@oracle.com> Moving discussion to core-libs-dev. Please follow-up there. Thanks, David On 3/11/2016 1:20 AM, Dmitry Zhikharev wrote: > Hi! > > ForkJoinPool class documentation says nothing about it using daemon threads since Java 8 (https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ForkJoinPool.html, see also http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/0086eb10182b/src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java). > It was there in Java 7 documentation: https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ForkJoinPool.html (see "Sample Usage"). > > I think it's an important note about ForkJoinPool and should be added back. > > Regards, Dmitry Zhikharev > From ivan.gerasimov at oracle.com Wed Nov 2 15:58:17 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 2 Nov 2016 18:58:17 +0300 Subject: [9] RFR: 8168921: Inconsistent Annotation.toString() In-Reply-To: <1f7a2326-c39b-62e2-173d-9ab9d3df0ec8@oracle.com> References: <82ad25c8-bf50-6842-3d1a-19a4e7e53bb6@oracle.com> <1f7a2326-c39b-62e2-173d-9ab9d3df0ec8@oracle.com> Message-ID: <4dd5160c-c14f-cd60-d524-aa36d7abc8b8@oracle.com> Thank you Joe for review! On 31.10.2016 20:11, joe darcy wrote: > Hi Ivan, > > The code change in src look fine, but please update the existing test > > test/java/lang/annotation/AnnotationToStringTest.java > > rather than introducing a new test file. > Yes, right, this is better. Here's the updated webrev: http://cr.openjdk.java.net/~igerasim/8168921/01/webrev/ With kind regards, Ivan > Thanks, > > -Joe > > > On 10/29/2016 6:42 PM, Ivan Gerasimov wrote: >> Hello! >> >> Suppose an annotation is of form >> >> @interface MyAnnotation { >> long value(); >> } >> >> Create the annotation object with >> sun.reflect.annotation.AnnotationParser.annotationForMap(MyAnnotation.class, >> Map.of("value", some_value)). >> >> Annotation.toString() method, called for the object, will produce a >> string containing that 'some_value' with the optional 'L' suffix >> appended. >> Normally, the suffix is not appended for values that can be >> represented with int, and is appended otherwise. >> However, the logic does not hold for values Long.MIN_VALUE and >> Integer.MIN_VALUE: For the former the suffix is not appended and for >> the later the suffix L is appended. >> >> Would you please help review the fix, which removes this tiny >> inconsistency? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8168921 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8168921/00/webrev/ >> >> I also took a chance to perform some pico-optimizations around the >> modified code. >> >> With kind regards, >> Ivan >> > > From claes.redestad at oracle.com Wed Nov 2 16:03:34 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 2 Nov 2016 17:03:34 +0100 Subject: [9] RFR: 8168921: Inconsistent Annotation.toString() In-Reply-To: <4dd5160c-c14f-cd60-d524-aa36d7abc8b8@oracle.com> References: <82ad25c8-bf50-6842-3d1a-19a4e7e53bb6@oracle.com> <1f7a2326-c39b-62e2-173d-9ab9d3df0ec8@oracle.com> <4dd5160c-c14f-cd60-d524-aa36d7abc8b8@oracle.com> Message-ID: <581A0E56.6070008@oracle.com> On 2016-11-02 16:58, Ivan Gerasimov wrote: > Thank you Joe for review! > > > On 31.10.2016 20:11, joe darcy wrote: >> Hi Ivan, >> >> The code change in src look fine, but please update the existing test >> >> test/java/lang/annotation/AnnotationToStringTest.java >> >> rather than introducing a new test file. >> > > Yes, right, this is better. Here's the updated webrev: > http://cr.openjdk.java.net/~igerasim/8168921/01/webrev/ +1 /Claes From Roger.Riggs at Oracle.com Wed Nov 2 17:39:00 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 2 Nov 2016 13:39:00 -0400 Subject: RFR(s): 8169055: [TESTBUG] : java/io/Serializable/serialFilter/ tests have undeclared dependency on jdk.jdeps module In-Reply-To: References: <6b58427b-5a15-f297-b778-5ac88cf2d408@oracle.com> <2cbab563-6748-3e57-538f-3bae2a99a8f3@oracle.com> <7C8CC4B0-B12C-4172-BD16-3EEE223EA629@oracle.com> <02f2aaea-1538-340a-905c-8e471bc04778@oracle.com> <10290ff6-0416-c375-550a-720ba6b35f08@oracle.com> Message-ID: Hi, I would rather switch the test to use a type in the base module. Switching from SourceVersion to javax.net.ssl.SSLEngineResult enables the test to run without additional @modules. Webrev/patch: http://cr.openjdk.java.net/~rriggs/webrev-filter-classes-8169055/ Roger On 11/2/2016 9:31 AM, Sergei Kovalev wrote: > Thank you all, > > java.compiler is enough. > > http://cr.openjdk.java.net/~skovalev/8169055/webrev.02/ > > > 02.11.16 16:25, Daniel Fuchs wrote: >> Hi Sergey, >> >> Why jdk.compiler? Why not simply java.compiler? >> >> best regards, >> >> -- daniel >> >> On 02/11/16 12:51, Sergei Kovalev wrote: >>> Fixed >>> >>> http://cr.openjdk.java.net/~skovalev/8169055/webrev.01/ >>> >>> >>> 02.11.16 15:34, Chris Hegarty wrote: >>>>> On 2 Nov 2016, at 12:31, Sergei Kovalev >>>>> wrote: >>>>> >>>>> javax.lang.model.SourceVersion >>>> This type is in the java.compiler module. >>>> >>>> -Chris. >>> >> > From joe.darcy at oracle.com Wed Nov 2 17:42:35 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 02 Nov 2016 10:42:35 -0700 Subject: [9] RFR: 8168921: Inconsistent Annotation.toString() In-Reply-To: <4dd5160c-c14f-cd60-d524-aa36d7abc8b8@oracle.com> References: <82ad25c8-bf50-6842-3d1a-19a4e7e53bb6@oracle.com> <1f7a2326-c39b-62e2-173d-9ab9d3df0ec8@oracle.com> <4dd5160c-c14f-cd60-d524-aa36d7abc8b8@oracle.com> Message-ID: <581A258B.20405@oracle.com> Looks good Ivan; thanks, -Joe On 11/2/2016 8:58 AM, Ivan Gerasimov wrote: > Thank you Joe for review! > > > On 31.10.2016 20:11, joe darcy wrote: >> Hi Ivan, >> >> The code change in src look fine, but please update the existing test >> >> test/java/lang/annotation/AnnotationToStringTest.java >> >> rather than introducing a new test file. >> > > Yes, right, this is better. Here's the updated webrev: > http://cr.openjdk.java.net/~igerasim/8168921/01/webrev/ > > With kind regards, > Ivan > >> Thanks, >> >> -Joe >> >> >> On 10/29/2016 6:42 PM, Ivan Gerasimov wrote: >>> Hello! >>> >>> Suppose an annotation is of form >>> >>> @interface MyAnnotation { >>> long value(); >>> } >>> >>> Create the annotation object with >>> sun.reflect.annotation.AnnotationParser.annotationForMap(MyAnnotation.class, >>> Map.of("value", some_value)). >>> >>> Annotation.toString() method, called for the object, will produce a >>> string containing that 'some_value' with the optional 'L' suffix >>> appended. >>> Normally, the suffix is not appended for values that can be >>> represented with int, and is appended otherwise. >>> However, the logic does not hold for values Long.MIN_VALUE and >>> Integer.MIN_VALUE: For the former the suffix is not appended and >>> for the later the suffix L is appended. >>> >>> Would you please help review the fix, which removes this tiny >>> inconsistency? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8168921 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8168921/00/webrev/ >>> >>> I also took a chance to perform some pico-optimizations around the >>> modified code. >>> >>> With kind regards, >>> Ivan >>> >> >> > From lance.andersen at oracle.com Wed Nov 2 18:04:59 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 2 Nov 2016 14:04:59 -0400 Subject: RFR: 8169020: Add since element to JDBC deprecated methods Message-ID: <844BADBE-7868-4E8D-9EFE-4D5F785C7D3B@oracle.com> Hi all, The diff below takes advantage the since element that was added to the Deprecated annotation to clarify when the JDBC methods where deprecated in Java SE. The CCC has been approved Best Lance ??????? ljanders-mac:jdk ljanders$ hg diff diff -r 77f35eef4ef9 src/java.sql/share/classes/java/sql/CallableStatement.java --- a/src/java.sql/share/classes/java/sql/CallableStatement.java Mon Oct 31 16:41:41 2016 +0800 +++ b/src/java.sql/share/classes/java/sql/CallableStatement.java Tue Nov 01 17:11:23 2016 -0400 @@ -295,7 +295,7 @@ * or getBigDecimal(String parameterName) * @see #setBigDecimal */ - @Deprecated + @Deprecated(since="1.2") BigDecimal getBigDecimal(int parameterIndex, int scale) throws SQLException; diff -r 77f35eef4ef9 src/java.sql/share/classes/java/sql/Date.java --- a/src/java.sql/share/classes/java/sql/Date.java Mon Oct 31 16:41:41 2016 +0800 +++ b/src/java.sql/share/classes/java/sql/Date.java Tue Nov 01 17:11:23 2016 -0400 @@ -58,7 +58,7 @@ * @param day 1 to 31 * @deprecated instead use the constructor Date(long date) */ - @Deprecated + @Deprecated(since="1.2") public Date(int year, int month, int day) { super(year, month, day); } @@ -199,7 +199,7 @@ * @exception java.lang.IllegalArgumentException if this method is invoked * @see #setHours */ - @Deprecated + @Deprecated(since="1.2") public int getHours() { throw new java.lang.IllegalArgumentException(); } @@ -212,7 +212,7 @@ * @exception java.lang.IllegalArgumentException if this method is invoked * @see #setMinutes */ - @Deprecated + @Deprecated(since="1.2") public int getMinutes() { throw new java.lang.IllegalArgumentException(); } @@ -225,7 +225,7 @@ * @exception java.lang.IllegalArgumentException if this method is invoked * @see #setSeconds */ - @Deprecated + @Deprecated(since="1.2") public int getSeconds() { throw new java.lang.IllegalArgumentException(); } @@ -238,7 +238,7 @@ * @exception java.lang.IllegalArgumentException if this method is invoked * @see #getHours */ - @Deprecated + @Deprecated(since="1.2") public void setHours(int i) { throw new java.lang.IllegalArgumentException(); } @@ -251,7 +251,7 @@ * @exception java.lang.IllegalArgumentException if this method is invoked * @see #getMinutes */ - @Deprecated + @Deprecated(since="1.2") public void setMinutes(int i) { throw new java.lang.IllegalArgumentException(); } @@ -264,7 +264,7 @@ * @exception java.lang.IllegalArgumentException if this method is invoked * @see #getSeconds */ - @Deprecated + @Deprecated(since="1.2") public void setSeconds(int i) { throw new java.lang.IllegalArgumentException(); } diff -r 77f35eef4ef9 src/java.sql/share/classes/java/sql/DriverManager.java --- a/src/java.sql/share/classes/java/sql/DriverManager.java Mon Oct 31 16:41:41 2016 +0800 +++ b/src/java.sql/share/classes/java/sql/DriverManager.java Tue Nov 01 17:11:23 2016 -0400 @@ -515,7 +515,7 @@ * @see SecurityManager#checkPermission * @see #getLogStream */ - @Deprecated + @Deprecated(since="1.2") public static void setLogStream(java.io.PrintStream out) { SecurityManager sec = System.getSecurityManager(); @@ -538,7 +538,7 @@ * @deprecated Use {@code getLogWriter} * @see #setLogStream */ - @Deprecated + @Deprecated(since="1.2") public static java.io.PrintStream getLogStream() { return logStream; } diff -r 77f35eef4ef9 src/java.sql/share/classes/java/sql/PreparedStatement.java --- a/src/java.sql/share/classes/java/sql/PreparedStatement.java Mon Oct 31 16:41:41 2016 +0800 +++ b/src/java.sql/share/classes/java/sql/PreparedStatement.java Tue Nov 01 17:11:23 2016 -0400 @@ -344,7 +344,7 @@ * this method * @deprecated Use {@code setCharacterStream} */ - @Deprecated + @Deprecated(since="1.2") void setUnicodeStream(int parameterIndex, java.io.InputStream x, int length) throws SQLException; diff -r 77f35eef4ef9 src/java.sql/share/classes/java/sql/ResultSet.java --- a/src/java.sql/share/classes/java/sql/ResultSet.java Mon Oct 31 16:41:41 2016 +0800 +++ b/src/java.sql/share/classes/java/sql/ResultSet.java Tue Nov 01 17:11:23 2016 -0400 @@ -358,7 +358,7 @@ * @deprecated Use {@code getBigDecimal(int columnIndex)} * or {@code getBigDecimal(String columnLabel)} */ - @Deprecated + @Deprecated(since="1.2") BigDecimal getBigDecimal(int columnIndex, int scale) throws SQLException; /** @@ -478,7 +478,7 @@ * @deprecated use getCharacterStream in place of * getUnicodeStream */ - @Deprecated + @Deprecated(since="1.2") java.io.InputStream getUnicodeStream(int columnIndex) throws SQLException; /** @@ -646,7 +646,7 @@ * @deprecated Use {@code getBigDecimal(int columnIndex)} * or {@code getBigDecimal(String columnLabel)} */ - @Deprecated + @Deprecated(since="1.2") BigDecimal getBigDecimal(String columnLabel, int scale) throws SQLException; /** @@ -764,7 +764,7 @@ * this method * @deprecated use getCharacterStream instead */ - @Deprecated + @Deprecated(since="1.2") java.io.InputStream getUnicodeStream(String columnLabel) throws SQLException; /** diff -r 77f35eef4ef9 src/java.sql/share/classes/java/sql/Time.java --- a/src/java.sql/share/classes/java/sql/Time.java Mon Oct 31 16:41:41 2016 +0800 +++ b/src/java.sql/share/classes/java/sql/Time.java Tue Nov 01 17:11:23 2016 -0400 @@ -60,7 +60,7 @@ * @deprecated Use the constructor that takes a milliseconds value * in place of this constructor */ - @Deprecated + @Deprecated(since="1.2") public Time(int hour, int minute, int second) { super(70, 0, 1, hour, minute, second); } @@ -146,7 +146,7 @@ * method is invoked * @see #setYear */ - @Deprecated + @Deprecated(since="1.2") public int getYear() { throw new java.lang.IllegalArgumentException(); } @@ -160,7 +160,7 @@ * method is invoked * @see #setMonth */ - @Deprecated + @Deprecated(since="1.2") public int getMonth() { throw new java.lang.IllegalArgumentException(); } @@ -173,7 +173,7 @@ * @exception java.lang.IllegalArgumentException if this * method is invoked */ - @Deprecated + @Deprecated(since="1.2") public int getDay() { throw new java.lang.IllegalArgumentException(); } @@ -187,7 +187,7 @@ * method is invoked * @see #setDate */ - @Deprecated + @Deprecated(since="1.2") public int getDate() { throw new java.lang.IllegalArgumentException(); } @@ -201,7 +201,7 @@ * method is invoked * @see #getYear */ - @Deprecated + @Deprecated(since="1.2") public void setYear(int i) { throw new java.lang.IllegalArgumentException(); } @@ -215,7 +215,7 @@ * method is invoked * @see #getMonth */ - @Deprecated + @Deprecated(since="1.2") public void setMonth(int i) { throw new java.lang.IllegalArgumentException(); } @@ -229,7 +229,7 @@ * method is invoked * @see #getDate */ - @Deprecated + @Deprecated(since="1.2") public void setDate(int i) { throw new java.lang.IllegalArgumentException(); } diff -r 77f35eef4ef9 src/java.sql/share/classes/java/sql/Timestamp.java --- a/src/java.sql/share/classes/java/sql/Timestamp.java Mon Oct 31 16:41:41 2016 +0800 +++ b/src/java.sql/share/classes/java/sql/Timestamp.java Tue Nov 01 17:11:23 2016 -0400 @@ -88,7 +88,7 @@ * @deprecated instead use the constructor {@code Timestamp(long millis)} * @exception IllegalArgumentException if the nano argument is out of bounds */ - @Deprecated + @Deprecated(since="1.2") public Timestamp(int year, int month, int date, int hour, int minute, int second, int nano) { super(year, month, date, hour, minute, second); ljanders-mac:jdk ljanders$ -------------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Wed Nov 2 18:05:33 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 2 Nov 2016 11:05:33 -0700 Subject: RFR(s): 8169055: [TESTBUG] : java/io/Serializable/serialFilter/ tests have undeclared dependency on jdk.jdeps module In-Reply-To: References: <6b58427b-5a15-f297-b778-5ac88cf2d408@oracle.com> <2cbab563-6748-3e57-538f-3bae2a99a8f3@oracle.com> <7C8CC4B0-B12C-4172-BD16-3EEE223EA629@oracle.com> <02f2aaea-1538-340a-905c-8e471bc04778@oracle.com> <10290ff6-0416-c375-550a-720ba6b35f08@oracle.com> Message-ID: <2734C529-E795-453A-89B5-A722F2325DB3@oracle.com> jdeps now has a new option [1] to make it easy to analyze the test dependency; ?-list-deps and ?-list-reduced-deps $ jdeps --list-deps -cp testng.jar JTwork/classes/java/io/Serializable/serialFilter/ java.base java.compiler unnamed module: testng.jar This will also list internal APIs if referenced in the form for @modules consumption. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8167057 > On Nov 2, 2016, at 10:39 AM, Roger Riggs wrote: > > Hi, > > I would rather switch the test to use a type in the base module. > Switching from SourceVersion to javax.net.ssl.SSLEngineResult enables the test to run > without additional @modules. > > Webrev/patch: > http://cr.openjdk.java.net/~rriggs/webrev-filter-classes-8169055/ > > Roger > > > On 11/2/2016 9:31 AM, Sergei Kovalev wrote: >> Thank you all, >> >> java.compiler is enough. >> >> http://cr.openjdk.java.net/~skovalev/8169055/webrev.02/ >> >> >> 02.11.16 16:25, Daniel Fuchs wrote: >>> Hi Sergey, >>> >>> Why jdk.compiler? Why not simply java.compiler? >>> >>> best regards, >>> >>> -- daniel >>> >>> On 02/11/16 12:51, Sergei Kovalev wrote: >>>> Fixed >>>> >>>> http://cr.openjdk.java.net/~skovalev/8169055/webrev.01/ >>>> >>>> >>>> 02.11.16 15:34, Chris Hegarty wrote: >>>>>> On 2 Nov 2016, at 12:31, Sergei Kovalev >>>>>> wrote: >>>>>> >>>>>> javax.lang.model.SourceVersion >>>>> This type is in the java.compiler module. >>>>> >>>>> -Chris. >>>> >>> >> > From joe.darcy at oracle.com Wed Nov 2 18:13:27 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 02 Nov 2016 11:13:27 -0700 Subject: RFR: 8169020: Add since element to JDBC deprecated methods In-Reply-To: <844BADBE-7868-4E8D-9EFE-4D5F785C7D3B@oracle.com> References: <844BADBE-7868-4E8D-9EFE-4D5F785C7D3B@oracle.com> Message-ID: <581A2CC7.4000707@oracle.com> Looks fine Lance; cheers, -Joe On 11/2/2016 11:04 AM, Lance Andersen wrote: > Hi all, > > The diff below takes advantage the since element that was added to the Deprecated annotation to clarify when the JDBC methods where deprecated in Java SE. > > The CCC has been approved > > Best > Lance > > ??????? > ljanders-mac:jdk ljanders$ hg diff > diff -r 77f35eef4ef9 src/java.sql/share/classes/java/sql/CallableStatement.java > --- a/src/java.sql/share/classes/java/sql/CallableStatement.java Mon Oct 31 16:41:41 2016 +0800 > +++ b/src/java.sql/share/classes/java/sql/CallableStatement.java Tue Nov 01 17:11:23 2016 -0400 > @@ -295,7 +295,7 @@ > * or getBigDecimal(String parameterName) > * @see #setBigDecimal > */ > - @Deprecated > + @Deprecated(since="1.2") > BigDecimal getBigDecimal(int parameterIndex, int scale) > throws SQLException; > > diff -r 77f35eef4ef9 src/java.sql/share/classes/java/sql/Date.java > --- a/src/java.sql/share/classes/java/sql/Date.java Mon Oct 31 16:41:41 2016 +0800 > +++ b/src/java.sql/share/classes/java/sql/Date.java Tue Nov 01 17:11:23 2016 -0400 > @@ -58,7 +58,7 @@ > * @param day 1 to 31 > * @deprecated instead use the constructor Date(long date) > */ > - @Deprecated > + @Deprecated(since="1.2") > public Date(int year, int month, int day) { > super(year, month, day); > } > @@ -199,7 +199,7 @@ > * @exception java.lang.IllegalArgumentException if this method is invoked > * @see #setHours > */ > - @Deprecated > + @Deprecated(since="1.2") > public int getHours() { > throw new java.lang.IllegalArgumentException(); > } > @@ -212,7 +212,7 @@ > * @exception java.lang.IllegalArgumentException if this method is invoked > * @see #setMinutes > */ > - @Deprecated > + @Deprecated(since="1.2") > public int getMinutes() { > throw new java.lang.IllegalArgumentException(); > } > @@ -225,7 +225,7 @@ > * @exception java.lang.IllegalArgumentException if this method is invoked > * @see #setSeconds > */ > - @Deprecated > + @Deprecated(since="1.2") > public int getSeconds() { > throw new java.lang.IllegalArgumentException(); > } > @@ -238,7 +238,7 @@ > * @exception java.lang.IllegalArgumentException if this method is invoked > * @see #getHours > */ > - @Deprecated > + @Deprecated(since="1.2") > public void setHours(int i) { > throw new java.lang.IllegalArgumentException(); > } > @@ -251,7 +251,7 @@ > * @exception java.lang.IllegalArgumentException if this method is invoked > * @see #getMinutes > */ > - @Deprecated > + @Deprecated(since="1.2") > public void setMinutes(int i) { > throw new java.lang.IllegalArgumentException(); > } > @@ -264,7 +264,7 @@ > * @exception java.lang.IllegalArgumentException if this method is invoked > * @see #getSeconds > */ > - @Deprecated > + @Deprecated(since="1.2") > public void setSeconds(int i) { > throw new java.lang.IllegalArgumentException(); > } > diff -r 77f35eef4ef9 src/java.sql/share/classes/java/sql/DriverManager.java > --- a/src/java.sql/share/classes/java/sql/DriverManager.java Mon Oct 31 16:41:41 2016 +0800 > +++ b/src/java.sql/share/classes/java/sql/DriverManager.java Tue Nov 01 17:11:23 2016 -0400 > @@ -515,7 +515,7 @@ > * @see SecurityManager#checkPermission > * @see #getLogStream > */ > - @Deprecated > + @Deprecated(since="1.2") > public static void setLogStream(java.io.PrintStream out) { > > SecurityManager sec = System.getSecurityManager(); > @@ -538,7 +538,7 @@ > * @deprecated Use {@code getLogWriter} > * @see #setLogStream > */ > - @Deprecated > + @Deprecated(since="1.2") > public static java.io.PrintStream getLogStream() { > return logStream; > } > diff -r 77f35eef4ef9 src/java.sql/share/classes/java/sql/PreparedStatement.java > --- a/src/java.sql/share/classes/java/sql/PreparedStatement.java Mon Oct 31 16:41:41 2016 +0800 > +++ b/src/java.sql/share/classes/java/sql/PreparedStatement.java Tue Nov 01 17:11:23 2016 -0400 > @@ -344,7 +344,7 @@ > * this method > * @deprecated Use {@code setCharacterStream} > */ > - @Deprecated > + @Deprecated(since="1.2") > void setUnicodeStream(int parameterIndex, java.io.InputStream x, > int length) throws SQLException; > > diff -r 77f35eef4ef9 src/java.sql/share/classes/java/sql/ResultSet.java > --- a/src/java.sql/share/classes/java/sql/ResultSet.java Mon Oct 31 16:41:41 2016 +0800 > +++ b/src/java.sql/share/classes/java/sql/ResultSet.java Tue Nov 01 17:11:23 2016 -0400 > @@ -358,7 +358,7 @@ > * @deprecated Use {@code getBigDecimal(int columnIndex)} > * or {@code getBigDecimal(String columnLabel)} > */ > - @Deprecated > + @Deprecated(since="1.2") > BigDecimal getBigDecimal(int columnIndex, int scale) throws SQLException; > > /** > @@ -478,7 +478,7 @@ > * @deprecated use getCharacterStream in place of > * getUnicodeStream > */ > - @Deprecated > + @Deprecated(since="1.2") > java.io.InputStream getUnicodeStream(int columnIndex) throws SQLException; > > /** > @@ -646,7 +646,7 @@ > * @deprecated Use {@code getBigDecimal(int columnIndex)} > * or {@code getBigDecimal(String columnLabel)} > */ > - @Deprecated > + @Deprecated(since="1.2") > BigDecimal getBigDecimal(String columnLabel, int scale) throws SQLException; > > /** > @@ -764,7 +764,7 @@ > * this method > * @deprecated use getCharacterStream instead > */ > - @Deprecated > + @Deprecated(since="1.2") > java.io.InputStream getUnicodeStream(String columnLabel) throws SQLException; > > /** > diff -r 77f35eef4ef9 src/java.sql/share/classes/java/sql/Time.java > --- a/src/java.sql/share/classes/java/sql/Time.java Mon Oct 31 16:41:41 2016 +0800 > +++ b/src/java.sql/share/classes/java/sql/Time.java Tue Nov 01 17:11:23 2016 -0400 > @@ -60,7 +60,7 @@ > * @deprecated Use the constructor that takes a milliseconds value > * in place of this constructor > */ > - @Deprecated > + @Deprecated(since="1.2") > public Time(int hour, int minute, int second) { > super(70, 0, 1, hour, minute, second); > } > @@ -146,7 +146,7 @@ > * method is invoked > * @see #setYear > */ > - @Deprecated > + @Deprecated(since="1.2") > public int getYear() { > throw new java.lang.IllegalArgumentException(); > } > @@ -160,7 +160,7 @@ > * method is invoked > * @see #setMonth > */ > - @Deprecated > + @Deprecated(since="1.2") > public int getMonth() { > throw new java.lang.IllegalArgumentException(); > } > @@ -173,7 +173,7 @@ > * @exception java.lang.IllegalArgumentException if this > * method is invoked > */ > - @Deprecated > + @Deprecated(since="1.2") > public int getDay() { > throw new java.lang.IllegalArgumentException(); > } > @@ -187,7 +187,7 @@ > * method is invoked > * @see #setDate > */ > - @Deprecated > + @Deprecated(since="1.2") > public int getDate() { > throw new java.lang.IllegalArgumentException(); > } > @@ -201,7 +201,7 @@ > * method is invoked > * @see #getYear > */ > - @Deprecated > + @Deprecated(since="1.2") > public void setYear(int i) { > throw new java.lang.IllegalArgumentException(); > } > @@ -215,7 +215,7 @@ > * method is invoked > * @see #getMonth > */ > - @Deprecated > + @Deprecated(since="1.2") > public void setMonth(int i) { > throw new java.lang.IllegalArgumentException(); > } > @@ -229,7 +229,7 @@ > * method is invoked > * @see #getDate > */ > - @Deprecated > + @Deprecated(since="1.2") > public void setDate(int i) { > throw new java.lang.IllegalArgumentException(); > } > diff -r 77f35eef4ef9 src/java.sql/share/classes/java/sql/Timestamp.java > --- a/src/java.sql/share/classes/java/sql/Timestamp.java Mon Oct 31 16:41:41 2016 +0800 > +++ b/src/java.sql/share/classes/java/sql/Timestamp.java Tue Nov 01 17:11:23 2016 -0400 > @@ -88,7 +88,7 @@ > * @deprecated instead use the constructor {@code Timestamp(long millis)} > * @exception IllegalArgumentException if the nano argument is out of bounds > */ > - @Deprecated > + @Deprecated(since="1.2") > public Timestamp(int year, int month, int date, > int hour, int minute, int second, int nano) { > super(year, month, date, hour, minute, second); > ljanders-mac:jdk ljanders$ > -------------------- > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From daniel.fuchs at oracle.com Wed Nov 2 18:14:17 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 2 Nov 2016 18:14:17 +0000 Subject: RFR(s): 8169055: [TESTBUG] : java/io/Serializable/serialFilter/ tests have undeclared dependency on jdk.jdeps module In-Reply-To: References: <6b58427b-5a15-f297-b778-5ac88cf2d408@oracle.com> <2cbab563-6748-3e57-538f-3bae2a99a8f3@oracle.com> <7C8CC4B0-B12C-4172-BD16-3EEE223EA629@oracle.com> <02f2aaea-1538-340a-905c-8e471bc04778@oracle.com> <10290ff6-0416-c375-550a-720ba6b35f08@oracle.com> Message-ID: <8fc5fc9f-298c-585a-2777-530ba26a6864@oracle.com> On 02/11/16 17:39, Roger Riggs wrote: > Hi, > > I would rather switch the test to use a type in the base module. > Switching from SourceVersion to javax.net.ssl.SSLEngineResult enables > the test to run > without additional @modules. > > Webrev/patch: > http://cr.openjdk.java.net/~rriggs/webrev-filter-classes-8169055/ +1 -- daniel > > Roger > > > On 11/2/2016 9:31 AM, Sergei Kovalev wrote: >> Thank you all, >> >> java.compiler is enough. >> >> http://cr.openjdk.java.net/~skovalev/8169055/webrev.02/ >> >> >> 02.11.16 16:25, Daniel Fuchs wrote: >>> Hi Sergey, >>> >>> Why jdk.compiler? Why not simply java.compiler? >>> >>> best regards, >>> >>> -- daniel >>> >>> On 02/11/16 12:51, Sergei Kovalev wrote: >>>> Fixed >>>> >>>> http://cr.openjdk.java.net/~skovalev/8169055/webrev.01/ >>>> >>>> >>>> 02.11.16 15:34, Chris Hegarty wrote: >>>>>> On 2 Nov 2016, at 12:31, Sergei Kovalev >>>>>> wrote: >>>>>> >>>>>> javax.lang.model.SourceVersion >>>>> This type is in the java.compiler module. >>>>> >>>>> -Chris. >>>> >>> >> > From paul.sandoz at oracle.com Wed Nov 2 18:41:36 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 2 Nov 2016 11:41:36 -0700 Subject: JDK 9 RFR of JDK-8151511: Test case in CollectionAndMapModifyStreamTest for LinkedHashMap overrides that for HashMap In-Reply-To: References: Message-ID: <959837D8-6AC8-434C-94EB-54610947F2B2@oracle.com> Hi Amy Oops. Looks good. Paul. > On 1 Nov 2016, at 19:47, Amy Lu wrote: > > Please review the patch for fixing typo in steam tests: > > bug: https://bugs.openjdk.java.net/browse/JDK-8151511 > webrev: http://cr.openjdk.java.net/~amlu/8151511/webrev.00/ > > 1) In CollectionAndMapModifyStreamTest.java > maps.put(HashMap.class.getName(), () -> new LinkedHashMap<>(content)); > should be > maps.put(LinkedHashMap.class.getName(), () -> new LinkedHashMap<>(content)); > > 2) ThowableHelper.java renamed to ThrowableHelper.java > > Thanks, > Amy From chris.hegarty at oracle.com Wed Nov 2 22:19:42 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 2 Nov 2016 22:19:42 +0000 Subject: RFR(s): 8169055: [TESTBUG] : java/io/Serializable/serialFilter/ tests have undeclared dependency on jdk.jdeps module In-Reply-To: <8fc5fc9f-298c-585a-2777-530ba26a6864@oracle.com> References: <6b58427b-5a15-f297-b778-5ac88cf2d408@oracle.com> <2cbab563-6748-3e57-538f-3bae2a99a8f3@oracle.com> <7C8CC4B0-B12C-4172-BD16-3EEE223EA629@oracle.com> <02f2aaea-1538-340a-905c-8e471bc04778@oracle.com> <10290ff6-0416-c375-550a-720ba6b35f08@oracle.com> <8fc5fc9f-298c-585a-2777-530ba26a6864@oracle.com> Message-ID: <44F4E68D-34B9-4490-AAFE-9ECACED17CBC@oracle.com> > On 2 Nov 2016, at 18:14, Daniel Fuchs wrote: > > On 02/11/16 17:39, Roger Riggs wrote: >> Hi, >> >> I would rather switch the test to use a type in the base module. >> Switching from SourceVersion to javax.net.ssl.SSLEngineResult enables >> the test to run >> without additional @modules. >> >> Webrev/patch: >> http://cr.openjdk.java.net/~rriggs/webrev-filter-classes-8169055/ > > +1 ++1 -Chris. > -- daniel > >> >> Roger >> >> >> On 11/2/2016 9:31 AM, Sergei Kovalev wrote: >>> Thank you all, >>> >>> java.compiler is enough. >>> >>> http://cr.openjdk.java.net/~skovalev/8169055/webrev.02/ >>> >>> >>> 02.11.16 16:25, Daniel Fuchs wrote: >>>> Hi Sergey, >>>> >>>> Why jdk.compiler? Why not simply java.compiler? >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 02/11/16 12:51, Sergei Kovalev wrote: >>>>> Fixed >>>>> >>>>> http://cr.openjdk.java.net/~skovalev/8169055/webrev.01/ >>>>> >>>>> >>>>> 02.11.16 15:34, Chris Hegarty wrote: >>>>>>> On 2 Nov 2016, at 12:31, Sergei Kovalev >>>>>>> wrote: >>>>>>> >>>>>>> javax.lang.model.SourceVersion >>>>>> This type is in the java.compiler module. >>>>>> >>>>>> -Chris. >>>>> >>>> >>> >> > From yingqi.lu at intel.com Wed Nov 2 23:34:49 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Wed, 2 Nov 2016 23:34:49 +0000 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <006c75c4-1404-d66b-737d-e07ea2b493fd@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5134F66@ORSMSX113.amr.corp.intel.com> <062c589c-fa54-1652-683a-4e779816391d@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513500C@ORSMSX113.amr.corp.intel.com> <542288c7-b0b1-5b41-4c45-d07730e3cddf@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5139A26@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513CE96@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA51447D9@ORSMSX113.amr.corp.intel.com> <006c75c4-1404-d66b-737d-e07ea2b493fd@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> Hi All, Our most recent DirectIO patch is available at http://cr.openjdk.java.net/~igraves/8164900-3/ In this version, we made following changes: 1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to the FileChannelImpl class. 2. Provided a way for user to allocate a page aligned direct ByteBuffer. 1) Added a constructor DirectByteBuffer(int cap, boolean direct) to allocate a direct ByteBuffer that is aligned to the page size. 2) Added Util.getTemporaryAlignedDirectBuffer(int size) 3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is aligned before doing native IO with it. 3. Moved all the alignment check from C code to Java code (mainly FileChannelImpl and IOUtil.java). 4. Made the DirectIO functionality consistent between read and write operations. With current version of the patch, user would be responsible for the alignment with file offset and IO size. 5. Made the API for DirectIO more extensible to all the supporting platforms. 1) Unix OS specific code are done through UnixConstants.java.template and FileChannelImpl.c. 2) Coded and tested for Linux and OS X (OS X testing is done through VirtualBox with OS X VM on top of Linux OS). 3) Coded for Solaris. We do not have environment to test it so that we commented the changes out. 6. We added 4 test cases following the existing non-direct IO examples. 7. We did jtreg test for the entire nio package and no errors were found due to our changes. Please let us know your feedback and comment. Thank you very much for your time and consideration! Thanks, Lucy >-----Original Message----- >From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >Sent: Monday, October 17, 2016 7:59 AM >To: Lu, Yingqi >Cc: nio-dev at openjdk.java.net; Kaczmarek, Eric ; >Kharbas, Kishor >Subject: Re: Proposal for adding O_DIRECT support into JDK 9 > >On 12/10/2016 17:41, Lu, Yingqi wrote: > >> : >> >> You are correct about the "extra copy" with DirectIO. Will it be acceptable if we >add a function "Util.getAlignedTemporaryDirectBuffer" and use that for the >DirectIO operation? In this case, I think we should be able to avoid the additional >copy? >> >Yes, that should work but it still lacks a way for the user to get an aligned buffer >and so you will always be copying in and out of an aligned buffer. The other thing >is the sizing of the I/O operation where I think you will also need a way to expose >the multiple (or block size) to the user. > >-Alan. From joe.darcy at oracle.com Thu Nov 3 00:51:51 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 2 Nov 2016 17:51:51 -0700 Subject: JDK 9 RFR of JDK-8168681: Correct deprecation text for Class.newInstance Message-ID: <60935111-d558-f45a-38f9-014a501fa7be@oracle.com> Hello, As found by Phil Race, the original substitution text for Class.newInstance (JDK-8159330) is not equivalent in all cases. This should be addressed. The current suggested replacement text is "The call clazz.newInstance() can be replaced by clazz.getConstructor().newInstance()" The getConstructor call only returns *public* constructors while newInstance can call non-public constructors too, subject to the appropriate security checks. Therefore, using "getDeclaredConstructor()" is a better replacement since it should be able to find and call non-public constructors when that is permissible. The patch for this is: --- a/src/java.base/share/classes/java/lang/Class.java Wed Nov 02 16:24:43 2016 -0700 +++ b/src/java.base/share/classes/java/lang/Class.java Wed Nov 02 17:36:25 2016 -0700 @@ -485,7 +485,7 @@ * can be replaced by * * 
{@code
-     * clazz.getConstructor().newInstance()
+     * clazz.getDeclaredConstructor().newInstance()
       * }
* * The latter sequence of calls is inferred to be able to throw I wrote a simple program to try calling constructors with different access levels private, protected, package (default), and public in different settings and in the cases I tested clazz.newInstance() and clazz.getConstructor().newInstance() agreed on both returning an object or both throwing an exception. This property also held when a security manager was enabled. Doing a quick examination of the sources of java.lang.Class, public T newInstance() throws InstantiationException, IllegalAccessException { if (System.getSecurityManager() != null) { checkMemberAccess(Member.PUBLIC, Reflection.getCallerClass(), false); } // various things elided... try { Class[] empty = {}; final Constructor c = getConstructor0(empty, Member.DECLARED); // various more things elided... } catch (NoSuchMethodException e) { throw (InstantiationException) new InstantiationException(getName()).initCause(e); } } // still more things elided } compared to public Constructor getDeclaredConstructor(Class... parameterTypes) throws NoSuchMethodException, SecurityException { checkMemberAccess(Member.DECLARED, Reflection.getCallerClass(), true); return getConstructor0(parameterTypes, Member.DECLARED); } Both alternatives are wrappers around the lower-level getConstructor0 method. Thanks to Phil for noticing the problem with the existing text. Cheers, -Joe From mandy.chung at oracle.com Thu Nov 3 05:01:00 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 2 Nov 2016 22:01:00 -0700 Subject: JDK 9 RFR of JDK-8168681: Correct deprecation text for Class.newInstance In-Reply-To: <60935111-d558-f45a-38f9-014a501fa7be@oracle.com> References: <60935111-d558-f45a-38f9-014a501fa7be@oracle.com> Message-ID: <7CC2183D-19CC-4D7A-BCF5-AE05B7EF9FBC@oracle.com> > On Nov 2, 2016, at 5:51 PM, joe darcy wrote: > > : > The getConstructor call only returns *public* constructors while newInstance can call non-public constructors too, subject to the appropriate security checks. > > > Therefore, using "getDeclaredConstructor()" is a better replacement since it should be able to find and call non-public constructors when that is permissible. The patch for this is: > > --- a/src/java.base/share/classes/java/lang/Class.java Wed Nov 02 16:24:43 2016 -0700 > +++ b/src/java.base/share/classes/java/lang/Class.java Wed Nov 02 17:36:25 2016 -0700 > @@ -485,7 +485,7 @@ > * can be replaced by > * > * 
{@code
> -     * clazz.getConstructor().newInstance()
> +     * clazz.getDeclaredConstructor().newInstance()
>      * }
> * > * The latter sequence of calls is inferred to be able to throw > +1 Mandy From peter.levart at gmail.com Thu Nov 3 08:32:27 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 3 Nov 2016 09:32:27 +0100 Subject: RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more In-Reply-To: <34B4C0BE-A333-4865-9C24-C6A9DBBF3D35@oracle.com> References: <9ddc7fc5-68fe-bb78-b54d-6ba55880c018@gmail.com> <1F5607C1-9EFC-4881-A3A9-31CB948FE67C@oracle.com> <1a075ccc-bdd9-ffe9-6a7b-2e734c6233e8@gmail.com> <0c67ae84-7bab-5944-1665-129dc451f3da@oracle.com> <07a6e24e-7dbc-6582-015f-62fd3fda24bd@gmail.com> <9ff4b8bc-c924-3cc9-8976-0cc10ca6804a@oracle.com> <34B4C0BE-A333-4865-9C24-C6A9DBBF3D35@oracle.com> Message-ID: <11cfb990-622d-10b1-5f85-7445f114073e@gmail.com> Hi Mandy, On 10/18/2016 04:14 PM, Peter Levart wrote: > I have tried to capture the precise behavior in the changed javadocs > that I present here: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.06/ > > On 11/02/2016 04:12 AM, Mandy Chung wrote: > 1786 * (clearly, it M's and N's declaring types are the same type, then > 1957 * (clearly, it M's and N's declaring types are the same type, then > > typo: s/it/if > > There are phrases such as "methods are kept? - what about ?select? instead of ?keep?? AFAICT, the algorithm is correct. I feel that the spec wording could be improved a little but that can be done later. I think this version is good for CCC submission. > > When you update the source, you use
    ,
  1. capital letters - our convention uses lowercase
      ,
    1. etc. > > One leftover IDE-specific suppress warnings: > 111 @SuppressWarnings("StringEquality?) > > The patch looks good to me. I will do one more pass and reply to the open. > > Mandy > On 11/02/2016 04:43 AM, Mandy Chung wrote: > A few other comments for consideration: > methods with same VM signature (return type, name, parameter types) > > Would it be better to say "methods with the signature (name and parameter types) and with same return type"? > > declared public methods (including static) > > Alternatively, you could say: > declared public static and instance methods > > ? Include the results of invoking this algorithm recursively on all direct superinterfaces of C, excluding any static methods. > > An alternative: > All public instance methods of all direct superinterfaces of C > > Mandy > Here is a webrev incorporating your suggestions: http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.07/ I think this could be used as a submission for CCC. Regards, Peter From goetz.lindenmaier at sap.com Thu Nov 3 09:03:15 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 3 Nov 2016 09:03:15 +0000 Subject: RFR{S}: 8166837: [TESTBUG] Fix tests on Linux/s390x In-Reply-To: References: <57dc005898984b3a92397542534d0152@derote13de14.global.corp.sap> Message-ID: <8b13ff8917c34de19bab979e7de3c645@derote13de14.global.corp.sap> Hi Volker, I removed the two exceptions: http://cr.openjdk.java.net/~goetz/wr16/8166837-jtreg_fixes/jdk-wr.02 Thanks for reviewing! Best regards, Goetz > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Mittwoch, 2. November 2016 15:22 > To: Lindenmaier, Goetz > Cc: core-libs-dev at openjdk.java.net > Subject: Re: RFR{S}: 8166837: [TESTBUG] Fix tests on Linux/s390x > > Hi Goetz, > > the change looks good except the two throws declarations in: > > test/sun/tools/jhsdb/BasicLauncherTest.java > test/sun/tools/jhsdb/HeapDumpTest.java > > I think "throws Exception" should be enough - we don't need "throws > IOException, Exception". > > Thanks, > Volker > > PS: we should really get rid of > jdk/test/lib/testlibrary/jdk/testlibrary/Platform.java in favour of > test/lib/jdk/test/lib/Platform.java. Does anybody know if there's > already a bug to track that? > > On Wed, Nov 2, 2016 at 2:16 PM, Lindenmaier, Goetz > wrote: > > Hi, > > > > This are the changes needed to the tests in the jdk repository > > to work with s390. > > In test/sun/tools/jhsdb I just use the other Platform.java which > > gets it's shouldSAAttach() method changed to return 'false' on > > S390. (I sent that part of the change to the hs-compiler list.) > > > > test/java/awt/JAWT/JAWT.sh is just skipped. > > > > Please review this change. > > http://cr.openjdk.java.net/~goetz/wr16/8166837-jtreg_fixes/jdk-wr.01/ > > > > Best regards, > > Goetz. From sergei.kovalev at oracle.com Thu Nov 3 09:13:08 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Thu, 3 Nov 2016 12:13:08 +0300 Subject: RFR(s): 8169055: [TESTBUG] : java/io/Serializable/serialFilter/ tests have undeclared dependency on jdk.jdeps module In-Reply-To: <2734C529-E795-453A-89B5-A722F2325DB3@oracle.com> References: <6b58427b-5a15-f297-b778-5ac88cf2d408@oracle.com> <2cbab563-6748-3e57-538f-3bae2a99a8f3@oracle.com> <7C8CC4B0-B12C-4172-BD16-3EEE223EA629@oracle.com> <02f2aaea-1538-340a-905c-8e471bc04778@oracle.com> <10290ff6-0416-c375-550a-720ba6b35f08@oracle.com> <2734C529-E795-453A-89B5-A722F2325DB3@oracle.com> Message-ID: <3ae088c1-26c4-672f-b849-7a5f7207305c@oracle.com> Hi Mandy, Thank you. This really helpful. -- With best regards, Sergei 02.11.16 21:05, Mandy Chung wrote: > jdeps now has a new option [1] to make it easy to analyze the test dependency; > ?-list-deps and ?-list-reduced-deps > > $ jdeps --list-deps -cp testng.jar JTwork/classes/java/io/Serializable/serialFilter/ > > java.base > java.compiler > unnamed module: testng.jar > > This will also list internal APIs if referenced in the form for @modules consumption. > > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8167057 > >> On Nov 2, 2016, at 10:39 AM, Roger Riggs wrote: >> >> Hi, >> >> I would rather switch the test to use a type in the base module. >> Switching from SourceVersion to javax.net.ssl.SSLEngineResult enables the test to run >> without additional @modules. >> >> Webrev/patch: >> http://cr.openjdk.java.net/~rriggs/webrev-filter-classes-8169055/ >> >> Roger >> >> >> On 11/2/2016 9:31 AM, Sergei Kovalev wrote: >>> Thank you all, >>> >>> java.compiler is enough. >>> >>> http://cr.openjdk.java.net/~skovalev/8169055/webrev.02/ >>> >>> >>> 02.11.16 16:25, Daniel Fuchs wrote: >>>> Hi Sergey, >>>> >>>> Why jdk.compiler? Why not simply java.compiler? >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 02/11/16 12:51, Sergei Kovalev wrote: >>>>> Fixed >>>>> >>>>> http://cr.openjdk.java.net/~skovalev/8169055/webrev.01/ >>>>> >>>>> >>>>> 02.11.16 15:34, Chris Hegarty wrote: >>>>>>> On 2 Nov 2016, at 12:31, Sergei Kovalev >>>>>>> wrote: >>>>>>> >>>>>>> javax.lang.model.SourceVersion >>>>>> This type is in the java.compiler module. >>>>>> >>>>>> -Chris. From volker.simonis at gmail.com Thu Nov 3 09:45:38 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 3 Nov 2016 10:45:38 +0100 Subject: RFR{S}: 8166837: [TESTBUG] Fix tests on Linux/s390x In-Reply-To: <8b13ff8917c34de19bab979e7de3c645@derote13de14.global.corp.sap> References: <57dc005898984b3a92397542534d0152@derote13de14.global.corp.sap> <8b13ff8917c34de19bab979e7de3c645@derote13de14.global.corp.sap> Message-ID: Looks good! Thanks, Volker On Thu, Nov 3, 2016 at 10:03 AM, Lindenmaier, Goetz wrote: > Hi Volker, > > I removed the two exceptions: > http://cr.openjdk.java.net/~goetz/wr16/8166837-jtreg_fixes/jdk-wr.02 > > Thanks for reviewing! > > Best regards, > Goetz > >> -----Original Message----- >> From: Volker Simonis [mailto:volker.simonis at gmail.com] >> Sent: Mittwoch, 2. November 2016 15:22 >> To: Lindenmaier, Goetz >> Cc: core-libs-dev at openjdk.java.net >> Subject: Re: RFR{S}: 8166837: [TESTBUG] Fix tests on Linux/s390x >> >> Hi Goetz, >> >> the change looks good except the two throws declarations in: >> >> test/sun/tools/jhsdb/BasicLauncherTest.java >> test/sun/tools/jhsdb/HeapDumpTest.java >> >> I think "throws Exception" should be enough - we don't need "throws >> IOException, Exception". >> >> Thanks, >> Volker >> >> PS: we should really get rid of >> jdk/test/lib/testlibrary/jdk/testlibrary/Platform.java in favour of >> test/lib/jdk/test/lib/Platform.java. Does anybody know if there's >> already a bug to track that? >> >> On Wed, Nov 2, 2016 at 2:16 PM, Lindenmaier, Goetz >> wrote: >> > Hi, >> > >> > This are the changes needed to the tests in the jdk repository >> > to work with s390. >> > In test/sun/tools/jhsdb I just use the other Platform.java which >> > gets it's shouldSAAttach() method changed to return 'false' on >> > S390. (I sent that part of the change to the hs-compiler list.) >> > >> > test/java/awt/JAWT/JAWT.sh is just skipped. >> > >> > Please review this change. >> > http://cr.openjdk.java.net/~goetz/wr16/8166837-jtreg_fixes/jdk-wr.01/ >> > >> > Best regards, >> > Goetz. From roman.grigoriadi at oracle.com Thu Nov 3 11:53:15 2016 From: roman.grigoriadi at oracle.com (Roman Grigoriadi) Date: Thu, 3 Nov 2016 12:53:15 +0100 Subject: RFR: 8164479: Update JAX-WS RI integration to latest version In-Reply-To: <4ff0efee-19fe-8125-163c-5f2981941e39@oracle.com> References: <1c63a0dc-d38d-0148-016c-30b15721d6a6@oracle.com> <3F91468F-78B2-4D3D-80D2-E429D8FAFC61@oracle.com> <57E5909E.3050702@oracle.com> <5754D4FE-0D20-4527-B163-E9224E3A4FDD@oracle.com> <5ac5eeec-fe39-0728-1ee4-2bc8684722d1@oracle.com> <435c44ae-51fc-c727-915c-6acb499d72a9@oracle.com> <4bbb97c4-4423-30b3-b906-95ff56dda779@oracle.com> <4ff0efee-19fe-8125-163c-5f2981941e39@oracle.com> Message-ID: <01423715-826e-8b53-0060-93a2e513138c@oracle.com> CCC for CommandInfo changes is now approved (http://ccc.us.oracle.com/8047773), you can find new webrev here: http://cr.openjdk.java.net/~aefimov/8164479/03/ Is there anything else to be solved? Thanks, Roman On 09/27/2016 05:52 PM, Roman Grigoriadi wrote: > Thanks for pointing Mandy, > > this package naming does apply to xerces types. I am not aware of any > xerces package inside JAX-WS components. > > I checked saaj-ri code and commented on issue (JDK-8166745). If > elimination of com.sun.org.apache.xerces.internal.* is possible, it > would not be an easy fix to include with this code sync. > > Roman > > On 09/26/2016 10:41 PM, Mandy Chung wrote: >> I brought this up a while back. SAAJ uses the java.xml's internal >> dom implementation. >> >> Just to double check: >> Is the standalone referencing com.sun.org.apache.xerces.internal.**? >> Does the package naming apply only to the JAX-WS types (but not these >> xerces types)? >> >> I couldn?t find any issue tracking it and will file one. > From dl at cs.oswego.edu Thu Nov 3 11:58:38 2016 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 3 Nov 2016 07:58:38 -0400 Subject: Documentation for ForkJoinPool class In-Reply-To: <70846a90-6045-a536-f176-6d84569ee098@oracle.com> References: <25171478100024@web6g.yandex.ru> <70846a90-6045-a536-f176-6d84569ee098@oracle.com> Message-ID: <940c7053-3fcd-778c-4cfa-b9e858a1bf7c@cs.oswego.edu> On 11/02/2016 11:27 AM, David Holmes wrote: > Moving discussion to core-libs-dev. Please follow-up there. > > Thanks, > David > > On 3/11/2016 1:20 AM, Dmitry Zhikharev wrote: >> Hi! >> >> ForkJoinPool class documentation says nothing about it using daemon >> threads since Java 8 >> (https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ForkJoinPool.html, Right; thanks. The sentence previously mentioning this in passing was changed, leaving no mention of daemon status. We should add one: *************** *** 37,43 **** * tasks are submitted to the pool from external clients. Especially * when setting asyncMode to true in constructors, {@code * ForkJoinPool}s may also be appropriate for use with event-style ! * tasks that are never joined. * *

      A static {@link #commonPool()} is available and appropriate for * most applications. The common pool is used by any ForkJoinTask that --- 37,44 ---- * tasks are submitted to the pool from external clients. Especially * when setting asyncMode to true in constructors, {@code * ForkJoinPool}s may also be appropriate for use with event-style ! * tasks that are never joined. All worker threads are initialized ! * with {@link Thread#isDaemon} set {@code true}. * *

      A static {@link #commonPool()} is available and appropriate for * most applications. The common pool is used by any ForkJoinTask that >> see also >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/0086eb10182b/src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java). >> >> It was there in Java 7 documentation: >> https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ForkJoinPool.html >> (see "Sample Usage"). >> >> I think it's an important note about ForkJoinPool and should be added >> back. >> >> Regards, Dmitry Zhikharev >> > From amy.lu at oracle.com Thu Nov 3 11:58:44 2016 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 3 Nov 2016 19:58:44 +0800 Subject: JDK 9 RFR of JDK-8037278: sun/rmi/runtime/Log/6409194/NoConsoleOutput.java fails Intermittently: unexpected subprocess output Message-ID: Please review the patch for test sun/rmi/runtime/Log/6409194/NoConsoleOutput.java bug: https://bugs.openjdk.java.net/browse/JDK-8037278 webrev: http://cr.openjdk.java.net/~amlu/8037278/webrev.00/ This test fails whenever there?s extra output from System.out (from the test application DoRMIStuff). But actually this test is for checking RMI logging messages and that are from System.err. Test should ignore the output from System.out. Thanks, Amy From david.lloyd at redhat.com Thu Nov 3 12:14:42 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 3 Nov 2016 07:14:42 -0500 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5134F66@ORSMSX113.amr.corp.intel.com> <062c589c-fa54-1652-683a-4e779816391d@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513500C@ORSMSX113.amr.corp.intel.com> <542288c7-b0b1-5b41-4c45-d07730e3cddf@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5139A26@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513CE96@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA51447D9@ORSMSX113.amr.corp.intel.com> <006c75c4-1404-d66b-737d-e07ea2b493fd@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> Message-ID: What happens if you're using large pages? Are the direct buffers always allocated off of small pages? On 11/02/2016 06:34 PM, Lu, Yingqi wrote: > Hi All, > > Our most recent DirectIO patch is available at http://cr.openjdk.java.net/~igraves/8164900-3/ > > In this version, we made following changes: > > 1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to the FileChannelImpl class. > > 2. Provided a way for user to allocate a page aligned direct ByteBuffer. > 1) Added a constructor DirectByteBuffer(int cap, boolean direct) to allocate a direct ByteBuffer that is aligned to the page size. > 2) Added Util.getTemporaryAlignedDirectBuffer(int size) > 3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is aligned before doing native IO with it. > > 3. Moved all the alignment check from C code to Java code (mainly FileChannelImpl and IOUtil.java). > > 4. Made the DirectIO functionality consistent between read and write operations. With current version of the patch, user would be responsible for the alignment with file offset and IO size. > > 5. Made the API for DirectIO more extensible to all the supporting platforms. > 1) Unix OS specific code are done through UnixConstants.java.template and FileChannelImpl.c. > 2) Coded and tested for Linux and OS X (OS X testing is done through VirtualBox with OS X VM on top of Linux OS). > 3) Coded for Solaris. We do not have environment to test it so that we commented the changes out. > > 6. We added 4 test cases following the existing non-direct IO examples. > > 7. We did jtreg test for the entire nio package and no errors were found due to our changes. > > Please let us know your feedback and comment. Thank you very much for your time and consideration! > > Thanks, > Lucy > >> -----Original Message----- >> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >> Sent: Monday, October 17, 2016 7:59 AM >> To: Lu, Yingqi >> Cc: nio-dev at openjdk.java.net; Kaczmarek, Eric ; >> Kharbas, Kishor >> Subject: Re: Proposal for adding O_DIRECT support into JDK 9 >> >> On 12/10/2016 17:41, Lu, Yingqi wrote: >> >>> : >>> >>> You are correct about the "extra copy" with DirectIO. Will it be acceptable if we >> add a function "Util.getAlignedTemporaryDirectBuffer" and use that for the >> DirectIO operation? In this case, I think we should be able to avoid the additional >> copy? >>> >> Yes, that should work but it still lacks a way for the user to get an aligned buffer >> and so you will always be copying in and out of an aligned buffer. The other thing >> is the sizing of the I/O operation where I think you will also need a way to expose >> the multiple (or block size) to the user. >> >> -Alan. -- - DML From daniel.fuchs at oracle.com Thu Nov 3 12:37:10 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 3 Nov 2016 12:37:10 +0000 Subject: JDK 9 RFR of JDK-8037278: sun/rmi/runtime/Log/6409194/NoConsoleOutput.java fails Intermittently: unexpected subprocess output In-Reply-To: References: Message-ID: Hi Amy, I think it might still be useful to see what the subprocess prints on System.out in case of failure. I would leave lines 83, 86 and 87 unchanged. best regards, -- daniel On 03/11/16 11:58, Amy Lu wrote: > Please review the patch for test > sun/rmi/runtime/Log/6409194/NoConsoleOutput.java > > bug: https://bugs.openjdk.java.net/browse/JDK-8037278 > webrev: http://cr.openjdk.java.net/~amlu/8037278/webrev.00/ > > This test fails whenever there?s extra output from System.out (from the > test application DoRMIStuff). But actually this test is for checking RMI > logging messages and that are from System.err. Test should ignore the > output from System.out. > > Thanks, > Amy From amy.lu at oracle.com Thu Nov 3 13:22:59 2016 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 3 Nov 2016 21:22:59 +0800 Subject: JDK 9 RFR of JDK-8037278: sun/rmi/runtime/Log/6409194/NoConsoleOutput.java fails Intermittently: unexpected subprocess output In-Reply-To: References: Message-ID: <7bbecf74-9c8a-4d33-665f-17c4f3986920@oracle.com> Thank you Daniel for your review. Yes, agree and reverted those three lines. webrev updated: http://cr.openjdk.java.net/~amlu/8037278/webrev.01 Thanks, Amy On 11/3/16 8:37 PM, Daniel Fuchs wrote: > Hi Amy, > > I think it might still be useful to see what the subprocess > prints on System.out in case of failure. > I would leave lines 83, 86 and 87 unchanged. > > best regards, > > -- daniel > > On 03/11/16 11:58, Amy Lu wrote: >> Please review the patch for test >> sun/rmi/runtime/Log/6409194/NoConsoleOutput.java >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8037278 >> webrev: http://cr.openjdk.java.net/~amlu/8037278/webrev.00/ >> >> This test fails whenever there?s extra output from System.out (from the >> test application DoRMIStuff). But actually this test is for checking RMI >> logging messages and that are from System.err. Test should ignore the >> output from System.out. >> >> Thanks, >> Amy > From denis.kononenko at oracle.com Thu Nov 3 13:29:36 2016 From: denis.kononenko at oracle.com (Denis Kononenko) Date: Thu, 3 Nov 2016 16:29:36 +0300 Subject: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options In-Reply-To: <6b4570ad-e700-4f38-df8d-c91ea8130bad@oracle.com> References: <6b4570ad-e700-4f38-df8d-c91ea8130bad@oracle.com> Message-ID: <42f98564-d908-159c-4531-f45e75c504d3@oracle.com> Hi, I've done some rework accordingly to Alan's and Shura's comments: 1) removed overlapped tests from JImageToolTest.java; 2) added new tests JImageVerifyTest.java for jimage verify; 3) reorganized jtreg's tags; The new WEBREV can be found here: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/ Thank you, Denis. On 06.10.2016 19:37, Denis Kononenko wrote: > Hi, > > Could someone please review these new tests for jimage utility. > > There're 5 new files containing tests to cover use cases for 'info', > 'list', 'extract' and other options. No new tests for 'verify'. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/ > > > Thank you, > Denis. From james.laskey at oracle.com Thu Nov 3 13:34:58 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 3 Nov 2016 10:34:58 -0300 Subject: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options In-Reply-To: <42f98564-d908-159c-4531-f45e75c504d3@oracle.com> References: <6b4570ad-e700-4f38-df8d-c91ea8130bad@oracle.com> <42f98564-d908-159c-4531-f45e75c504d3@oracle.com> Message-ID: Nice work. +1 > On Nov 3, 2016, at 10:29 AM, Denis Kononenko wrote: > > Hi, > > I've done some rework accordingly to Alan's and Shura's comments: > > 1) removed overlapped tests from JImageToolTest.java; > > 2) added new tests JImageVerifyTest.java for jimage verify; > > 3) reorganized jtreg's tags; > > The new WEBREV can be found here: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/ > > Thank you, > Denis. > > On 06.10.2016 19:37, Denis Kononenko wrote: >> Hi, >> >> Could someone please review these new tests for jimage utility. >> >> There're 5 new files containing tests to cover use cases for 'info', 'list', 'extract' and other options. No new tests for 'verify'. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 >> WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/ >> >> >> Thank you, >> Denis. > From daniel.fuchs at oracle.com Thu Nov 3 13:35:15 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 3 Nov 2016 13:35:15 +0000 Subject: JDK 9 RFR of JDK-8037278: sun/rmi/runtime/Log/6409194/NoConsoleOutput.java fails Intermittently: unexpected subprocess output In-Reply-To: <7bbecf74-9c8a-4d33-665f-17c4f3986920@oracle.com> References: <7bbecf74-9c8a-4d33-665f-17c4f3986920@oracle.com> Message-ID: Hi Amy, Looks good to me. -- daniel On 03/11/16 13:22, Amy Lu wrote: > Thank you Daniel for your review. > > Yes, agree and reverted those three lines. > > webrev updated: > http://cr.openjdk.java.net/~amlu/8037278/webrev.01 > > Thanks, > Amy > > On 11/3/16 8:37 PM, Daniel Fuchs wrote: >> Hi Amy, >> >> I think it might still be useful to see what the subprocess >> prints on System.out in case of failure. >> I would leave lines 83, 86 and 87 unchanged. >> >> best regards, >> >> -- daniel >> >> On 03/11/16 11:58, Amy Lu wrote: >>> Please review the patch for test >>> sun/rmi/runtime/Log/6409194/NoConsoleOutput.java >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8037278 >>> webrev: http://cr.openjdk.java.net/~amlu/8037278/webrev.00/ >>> >>> This test fails whenever there?s extra output from System.out (from the >>> test application DoRMIStuff). But actually this test is for checking RMI >>> logging messages and that are from System.err. Test should ignore the >>> output from System.out. >>> >>> Thanks, >>> Amy >> > From daniel.fuchs at oracle.com Thu Nov 3 13:42:53 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 3 Nov 2016 13:42:53 +0000 Subject: JDK 9 RFR of JDK-8037278: sun/rmi/runtime/Log/6409194/NoConsoleOutput.java fails Intermittently: unexpected subprocess output In-Reply-To: References: <7bbecf74-9c8a-4d33-665f-17c4f3986920@oracle.com> Message-ID: <4b1378e2-58ec-2ced-eb86-c5294e79a4e5@oracle.com> On 03/11/16 13:35, Daniel Fuchs wrote: > Hi Amy, > > Looks good to me. Maybe a followup should be logged to try and no longer call TestLibrary.getUnusedRandomPort(), as this the method that is causing the rogue output (and I see that it might print things to System.err as well). best regards, -- daniel > > -- daniel > > On 03/11/16 13:22, Amy Lu wrote: >> Thank you Daniel for your review. >> >> Yes, agree and reverted those three lines. >> >> webrev updated: >> http://cr.openjdk.java.net/~amlu/8037278/webrev.01 >> >> Thanks, >> Amy >> >> On 11/3/16 8:37 PM, Daniel Fuchs wrote: >>> Hi Amy, >>> >>> I think it might still be useful to see what the subprocess >>> prints on System.out in case of failure. >>> I would leave lines 83, 86 and 87 unchanged. >>> >>> best regards, >>> >>> -- daniel >>> >>> On 03/11/16 11:58, Amy Lu wrote: >>>> Please review the patch for test >>>> sun/rmi/runtime/Log/6409194/NoConsoleOutput.java >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037278 >>>> webrev: http://cr.openjdk.java.net/~amlu/8037278/webrev.00/ >>>> >>>> This test fails whenever there?s extra output from System.out (from the >>>> test application DoRMIStuff). But actually this test is for checking >>>> RMI >>>> logging messages and that are from System.err. Test should ignore the >>>> output from System.out. >>>> >>>> Thanks, >>>> Amy >>> >> > From amy.lu at oracle.com Thu Nov 3 13:51:07 2016 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 3 Nov 2016 21:51:07 +0800 Subject: JDK 9 RFR of JDK-8037278: sun/rmi/runtime/Log/6409194/NoConsoleOutput.java fails Intermittently: unexpected subprocess output In-Reply-To: References: <7bbecf74-9c8a-4d33-665f-17c4f3986920@oracle.com> Message-ID: <5a3f8870-391a-f2ee-dbf6-2e7a0344f263@oracle.com> Thank you Daniel. I'll push webrev.01 Thanks, Amy On 11/3/16 9:35 PM, Daniel Fuchs wrote: > Hi Amy, > > Looks good to me. > > -- daniel > > On 03/11/16 13:22, Amy Lu wrote: >> Thank you Daniel for your review. >> >> Yes, agree and reverted those three lines. >> >> webrev updated: >> http://cr.openjdk.java.net/~amlu/8037278/webrev.01 >> >> Thanks, >> Amy >> >> On 11/3/16 8:37 PM, Daniel Fuchs wrote: >>> Hi Amy, >>> >>> I think it might still be useful to see what the subprocess >>> prints on System.out in case of failure. >>> I would leave lines 83, 86 and 87 unchanged. >>> >>> best regards, >>> >>> -- daniel >>> >>> On 03/11/16 11:58, Amy Lu wrote: >>>> Please review the patch for test >>>> sun/rmi/runtime/Log/6409194/NoConsoleOutput.java >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037278 >>>> webrev: http://cr.openjdk.java.net/~amlu/8037278/webrev.00/ >>>> >>>> This test fails whenever there?s extra output from System.out (from >>>> the >>>> test application DoRMIStuff). But actually this test is for >>>> checking RMI >>>> logging messages and that are from System.err. Test should ignore the >>>> output from System.out. >>>> >>>> Thanks, >>>> Amy >>> >> > From amy.lu at oracle.com Thu Nov 3 13:52:21 2016 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 3 Nov 2016 21:52:21 +0800 Subject: JDK 9 RFR of JDK-8037278: sun/rmi/runtime/Log/6409194/NoConsoleOutput.java fails Intermittently: unexpected subprocess output In-Reply-To: <4b1378e2-58ec-2ced-eb86-c5294e79a4e5@oracle.com> References: <7bbecf74-9c8a-4d33-665f-17c4f3986920@oracle.com> <4b1378e2-58ec-2ced-eb86-c5294e79a4e5@oracle.com> Message-ID: <5128e31f-e45a-8e49-5fc6-3d0274a61b95@oracle.com> On 11/3/16 9:42 PM, Daniel Fuchs wrote: > On 03/11/16 13:35, Daniel Fuchs wrote: >> Hi Amy, >> >> Looks good to me. > > Maybe a followup should be logged to try > and no longer call TestLibrary.getUnusedRandomPort(), > as this the method that is causing the rogue > output (and I see that it might print things > to System.err as well). Will think about it too. (System.err from TestLibrary is fine as in that case test run into issue and will fail anyway) Thanks, Amy > > best regards, > > -- daniel > > >> >> -- daniel >> >> On 03/11/16 13:22, Amy Lu wrote: >>> Thank you Daniel for your review. >>> >>> Yes, agree and reverted those three lines. >>> >>> webrev updated: >>> http://cr.openjdk.java.net/~amlu/8037278/webrev.01 >>> >>> Thanks, >>> Amy >>> >>> On 11/3/16 8:37 PM, Daniel Fuchs wrote: >>>> Hi Amy, >>>> >>>> I think it might still be useful to see what the subprocess >>>> prints on System.out in case of failure. >>>> I would leave lines 83, 86 and 87 unchanged. >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 03/11/16 11:58, Amy Lu wrote: >>>>> Please review the patch for test >>>>> sun/rmi/runtime/Log/6409194/NoConsoleOutput.java >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037278 >>>>> webrev: http://cr.openjdk.java.net/~amlu/8037278/webrev.00/ >>>>> >>>>> This test fails whenever there?s extra output from System.out >>>>> (from the >>>>> test application DoRMIStuff). But actually this test is for checking >>>>> RMI >>>>> logging messages and that are from System.err. Test should ignore the >>>>> output from System.out. >>>>> >>>>> Thanks, >>>>> Amy >>>> >>> >> > From brunoaiss at gmail.com Thu Nov 3 14:35:45 2016 From: brunoaiss at gmail.com (Brunoais) Date: Thu, 3 Nov 2016 14:35:45 +0000 Subject: Request/discussion: BufferedReader reading using async API while providing sync API In-Reply-To: <6fe864bb-bc46-59fd-a7db-c9328e9ea71f@gmail.com> References: <077bf6e8-14ae-5588-b1a4-03fb4333c15b@gmail.com> <8AB1350F-F3EE-4756-923C-4178263BEBF5@oracle.com> <48cd729d-7922-3de5-3983-cc7486b5a9d3@gmail.com> <4bf67d65-7b2d-59a7-cd4a-19d84a062799@gmail.com> <10318b41-0383-d68a-3145-bdc57ae78450@gmail.com> <7f977d1d-3aa7-ec2e-6df5-51e8ac6473e5@gmail.com> <6fe864bb-bc46-59fd-a7db-c9328e9ea71f@gmail.com> Message-ID: Any information you can give on this? On 29/10/2016 19:10, Brunoais wrote: > Here's my try on going async. > > On my tests on my local windows 10 machine (I don't have access to the > linux one without a VM ATM) , now with 1GB file, I noticed: > > ~2s of speed improvement from BufferedInputStream to > BufferedNonBlockStream when BufferedNonBlockStream is at its most > advantageous state (with CPU work between reads). Otherwise, it has > ~0.3s speed improvement; maybe less. > > ~0.8s of speed improvement from BufferedNonBlockStream to > BufferedAsyncStream when BufferedNonBlockStream/BufferedAsyncStream is > at its most advantageous state. Otherwise, ~0 speed improvement. > > I noticed: Until you process as fast as you read, both > BufferedNonBlockStream and BufferedAsyncStream gain advantage towards > BufferedInputStream. From the point as you take longer to process than > to I/O, BufferedNonBlockStream and BufferedAsyncStream tend to keep > the advantage. > > If the file is in cache, BufferedInputStream takes ~1.6-1.9s to read > the file, BufferedNonBlockStream takes a steady ~2.05-2.1s to read the > file and BufferedAsyncStream ~1.2s. > > BufferedNonBlockStream and BufferedAsyncStream win more when given > more buffer memory than BufferedInputStream but only until a certain > limit. On my hardware, the best speed I got was with 655360B for the > new ones. Any more than that was not producing any visible results. I > guess it is due to the speed data was processing for the test. > > On 28/10/2016 09:16, Brunoais wrote: >> I'll try going back to a previous version I worked on which used the >> java7's AsynchronousFileChannel and work from there. My small >> research shows it can also work with AsynchronousFileChannel mostly >> without changes. >> >> For now, 1 question: >> Is Thread.sleep() a possible way of dealing the block requirements of >> read()? Do I need to use LockSupport.park() or something like that? >> >> I'll call back here when it is done. >> >> >> On 27/10/2016 22:09, David Holmes wrote: >>> You might try discussing on net-dev rather than core-libs-dev, to >>> get additional historical info related to the io and nio file APIs. >>> >>> David >>> >>> On 28/10/2016 5:08 AM, Brunoais wrote: >>>> You are right. Even in windows it does not set the flags for async >>>> reads. It seems like it is windows itself that does the decision to >>>> buffer the contents based on its own heuristics. >>>> >>>> But... Why? Why won't it be? Why is there no API for it? How am I >>>> getting 100% HDD use and faster times when I fake work to delay >>>> getting >>>> more data and I only have a fluctuating 60-90% (always going up and >>>> down) when I use an InputStream? >>>> Is it related to how both classes cache and how frequently and how >>>> much >>>> each one asks for data? >>>> >>>> I really would prefer not having to read the source code because it >>>> takes a real long time T.T. >>>> >>>> I end up reinstating... And wondering... >>>> >>>> Why doesn't java provide a single-threaded non-block API for file >>>> reads >>>> for all OS that support it? I simply cannot find that information no >>>> matter how much I search on google, bing, duck duck go... Can any >>>> of you >>>> point me to whomever knows? >>>> >>>> On 27/10/2016 14:11, Vitaly Davidovich wrote: >>>>> I don't know about Windows specifically, but generally file systems >>>>> across major OS's will implement readahead in their IO scheduler when >>>>> they detect sequential scans. >>>>> >>>>> On Linux, you can also strace your test to confirm which syscalls are >>>>> emitted (you should be seeing plain read()'s there, with >>>>> FileInputStream and FileChannel). >>>>> >>>>> On Thu, Oct 27, 2016 at 9:06 AM, Brunoais >>>> > wrote: >>>>> >>>>> Thanks for the heads up. >>>>> >>>>> I'll try that later. These tests are still useful then. >>>>> Meanwhile, >>>>> I'll end up also checking how FileChannel queries the OS on >>>>> windows. I'm getting 100% HDD reads... Could it be that the OS >>>>> reads the file ahead on its own?... Anyway, I'll look into it. >>>>> Thanks for the heads up. >>>>> >>>>> >>>>> On 27/10/2016 13:53, Vitaly Davidovich wrote: >>>>>> >>>>>> >>>>>> On Thu, Oct 27, 2016 at 8:34 AM, Brunoais >>>>> > wrote: >>>>>> >>>>>> Oh... I see. In that case, it means something is terribly >>>>>> wrong. It can be my initial tests, though. >>>>>> >>>>>> I'm testing on both linux and windows and I'm getting >>>>>> performance gains from using the FileChannel compared to >>>>>> using FileInputStream... The tests also make sense based on >>>>>> my predictions O_O... >>>>>> >>>>>> FileInputStream requires copying native buffers holding the read >>>>>> data to the java byte[]. If you're using direct ByteBuffer for >>>>>> FileChannel, that whole memcpy is skipped. Try comparing >>>>>> FileChannel with HeapByteBuffer instead. >>>>>> >>>>>> >>>>>> On 27/10/2016 11:47, Vitaly Davidovich wrote: >>>>>>> >>>>>>> >>>>>>> On Thursday, October 27, 2016, Brunoais >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Did you read the C code? >>>>>>> >>>>>>> I looked at the Linux code in the JDK. >>>>>>> >>>>>>> Have you got any idea how many functions Windows or >>>>>>> Linux (nearly all flavors) have for the read operation >>>>>>> towards a file? >>>>>>> >>>>>>> I do. >>>>>>> >>>>>>> >>>>>>> I have already done that homework myself. I may not >>>>>>> have >>>>>>> read JVM's source code but I know well that there's >>>>>>> functions on both Windows and Linux that provide such >>>>>>> interface I mentioned although they require a slightly >>>>>>> different treatment (and different constants). >>>>>>> >>>>>>> You should read the JDK (native) source code instead of >>>>>>> guessing/assuming. On Linux, it doesn't use aio facilities >>>>>>> for files. The kernel io scheduler may issue readahead >>>>>>> behind the scenes, but there's no nonblocking file io >>>>>>> that's >>>>>>> at the heart of your premise. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 27/10/2016 00:06, Vitaly Davidovich wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wednesday, October 26, 2016, Brunoais >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> It is actually based on the premise that: >>>>>>> >>>>>>> 1. The first call to >>>>>>> ReadableByteChannel.read(ByteBuffer) sets the OS >>>>>>> buffer size to fill in as the same size as >>>>>>> ByteBuffer. >>>>>>> >>>>>>> Why do you say that? AFAICT, it issues a read >>>>>>> syscall and that will block if the data isn't in >>>>>>> page cache. >>>>>>> >>>>>>> 2. The consecutive calls to >>>>>>> ReadableByteChannel.read(ByteBuffer) >>>>>>> orders >>>>>>> the JVM to order the OS to execute memcpy() >>>>>>> to copy from its memory >>>>>>> to the shared memory created at ByteBuffer >>>>>>> instantiation (in >>>>>>> java 8) >>>>>>> using Unsafe and then for the JVM to update >>>>>>> the ByteBuffer fields. >>>>>>> >>>>>>> I think subsequent reads just invoke the same read >>>>>>> syscall, passing the current file offset maintained >>>>>>> by the file channel instance. >>>>>>> >>>>>>> 3. The call will not block waiting for I/O and >>>>>>> it won't take longer >>>>>>> than the JNI interface if no new data >>>>>>> exists. >>>>>>> However, it will >>>>>>> block >>>>>>> waiting for the OS to execute memcpy() to >>>>>>> the >>>>>>> shared memory. >>>>>>> >>>>>>> So why do you think it won't block? >>>>>>> >>>>>>> >>>>>>> Is my premise wrong? >>>>>>> >>>>>>> If I read correctly, if I don't use a >>>>>>> DirectBuffer, there would be >>>>>>> even another intermediate buffer to copy >>>>>>> data to >>>>>>> before giving it >>>>>>> to the "user" which would be useless. >>>>>>> >>>>>>> If you use a HeapByteBuffer, then there's an extra >>>>>>> copy from the native buffer to the Java buffer. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 26/10/2016 11:57, Pavel Rappo wrote: >>>>>>> >>>>>>> I believe I see where you coming from. >>>>>>> Please correct me if >>>>>>> I'm wrong. >>>>>>> >>>>>>> Your implementation is based on the premise >>>>>>> that a call to >>>>>>> ReadableByteChannel.read() >>>>>>> _initiates_ the operation and returns >>>>>>> immediately. The OS then >>>>>>> continues to fill >>>>>>> the buffer while there's a free space in >>>>>>> the >>>>>>> buffer and the >>>>>>> channel hasn't encountered EOF. >>>>>>> >>>>>>> Is that right? >>>>>>> >>>>>>> On 25 Oct 2016, at 22:16, Brunoais >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> Thank you for your time. I'll try to >>>>>>> explain it. I hope I >>>>>>> can clear it up. >>>>>>> First of it, I made a meaning mistake >>>>>>> between asynchronous >>>>>>> and non-blocking. This implementation >>>>>>> uses a non-blocking >>>>>>> algorithm internally while providing a >>>>>>> blocking-like >>>>>>> algorithm on the surface. It is >>>>>>> single-threaded and not >>>>>>> multi-threaded where one thread fetches >>>>>>> data and blocks >>>>>>> waiting and the other accumulates it >>>>>>> and >>>>>>> provides to >>>>>>> whichever wants it. >>>>>>> >>>>>>> Second of it, I had made a mistake of >>>>>>> going after >>>>>>> BufferedReader instead of going after >>>>>>> BufferedInputStream. >>>>>>> If you want me to go after >>>>>>> BufferedReader it's ok but I >>>>>>> only thought that going after >>>>>>> BufferedInputStream would be >>>>>>> more generically useful than >>>>>>> BufferedReaderwhen I started >>>>>>> the poc. >>>>>>> >>>>>>> On to my code: >>>>>>> Short answers: >>>>>>> ? The sleep(int) exists because >>>>>>> I don't know how >>>>>>> to wait until more data exists in the >>>>>>> buffer which is part >>>>>>> of read()'s contract. >>>>>>> ? The ByteBuffer gives a buffer >>>>>>> that is filled by >>>>>>> the OS (what I believe Channels do) >>>>>>> instead of getting >>>>>>> data only by demand (what I >>>>>>> believe Streams do). >>>>>>> Full answers: >>>>>>> The blockingFill(boolean) method is a >>>>>>> method for a busy >>>>>>> wait for a fill which is used >>>>>>> exclusively by the read() >>>>>>> method. All other methods use the >>>>>>> version that does not >>>>>>> sleep (fill(boolean)). >>>>>>> blockingFill(boolean)'s existance like that is only >>>>>>> because the read() method must not >>>>>>> return unless either: >>>>>>> >>>>>>> ? The stream ended. >>>>>>> ? The next byte is ready for >>>>>>> reading. >>>>>>> Additionally, statistically, that while >>>>>>> loop will rarely >>>>>>> evaluate to true as reads are in chunks >>>>>>> so readPos will be >>>>>>> behind writePos most of the time. >>>>>>> I have no idea if an interrupt will >>>>>>> ever >>>>>>> happen, to be >>>>>>> honest. The main reasons why I'm >>>>>>> using a >>>>>>> sleep is because >>>>>>> I didn't want a hog onto the CPU in a >>>>>>> full thread usage >>>>>>> busy wait and because I didn't find any >>>>>>> way of doing a >>>>>>> thread sleep in order to wake up later >>>>>>> when the buffer >>>>>>> managed by native code has more data. >>>>>>> The Non-blocking part is managed by the >>>>>>> buffer the OS >>>>>>> keeps filling most if not all the time. >>>>>>> That buffer is the >>>>>>> field >>>>>>> >>>>>>> ByteBuffer readBuffer >>>>>>> That's the gaining part against the >>>>>>> plain old Buffered >>>>>>> classes. >>>>>>> >>>>>>> >>>>>>> Did that make sense to you? Feel >>>>>>> free to >>>>>>> ask anything else >>>>>>> you need. >>>>>>> >>>>>>> On 25/10/2016 20:52, Pavel Rappo wrote: >>>>>>> >>>>>>> I've skimmed through the code and >>>>>>> I'm not sure I can >>>>>>> see any asynchronicity >>>>>>> (you were pointing at the lack >>>>>>> of it >>>>>>> in BufferedReader). >>>>>>> And the mechanics of this is very >>>>>>> puzzling to me, to >>>>>>> be honest: >>>>>>> void blockingFill(boolean >>>>>>> forced) throws >>>>>>> IOException { >>>>>>> fill(forced); >>>>>>> while (readPos == >>>>>>> writePos) { >>>>>>> try { >>>>>>> Thread.sleep(100); >>>>>>> } catch >>>>>>> (InterruptedException e) { >>>>>>> // An interrupt may mean more data is >>>>>>> available >>>>>>> } >>>>>>> fill(forced); >>>>>>> } >>>>>>> } >>>>>>> I thought you were suggesting that >>>>>>> we should utilize >>>>>>> the tools which OS provides >>>>>>> more efficiently. Instead we have >>>>>>> something that looks >>>>>>> very similarly to a >>>>>>> "busy loop" and... also who and >>>>>>> when >>>>>>> is supposed to >>>>>>> interrupt Thread.sleep()? >>>>>>> Sorry, I'm not following. Could you >>>>>>> please explain how >>>>>>> this is supposed to work? >>>>>>> >>>>>>> On 24 Oct 2016, at 15:59, >>>>>>> Brunoais >>>>>>> >>>>>>> wrote: >>>>>>> Attached and sending! >>>>>>> On 24/10/2016 13:48, Pavel >>>>>>> Rappo >>>>>>> wrote: >>>>>>> >>>>>>> Could you please send a new >>>>>>> email on this list >>>>>>> with the source attached >>>>>>> as a >>>>>>> text file? >>>>>>> >>>>>>> On 23 Oct 2016, at >>>>>>> 19:14, Brunoais >>>>>>> >>>>>>> wrote: >>>>>>> Here's my poc/prototype: >>>>>>> >>>>>>> http://pastebin.com/WRpYWDJF >>>>>>> >>>>>>> I've implemented the >>>>>>> bare minimum of the >>>>>>> class that follows the same contract of >>>>>>> BufferedReader while signaling all issues >>>>>>> I think it may have or >>>>>>> has in comments. >>>>>>> I also wrote some >>>>>>> javadoc to help guiding >>>>>>> through the class. >>>>>>> I could have used more >>>>>>> fields from >>>>>>> BufferedReader but the names were so >>>>>>> minimalistic that were confusing me. I >>>>>>> intent to change them before sending this >>>>>>> to openJDK. >>>>>>> One of the major >>>>>>> problems this has is long >>>>>>> overflowing. It is major because it is >>>>>>> hidden, it will be extremely rare and it >>>>>>> takes a really long time to reproduce. >>>>>>> There are different ways of dealing with >>>>>>> it. From just >>>>>>> documenting to actually >>>>>>> making code that works with it. >>>>>>> I built a simple test >>>>>>> code for it to have >>>>>>> some ideas about >>>>>>> performance and correctness. >>>>>>> >>>>>>> http://pastebin.com/eh6LFgwT >>>>>>> >>>>>>> This doesn't do a >>>>>>> through test if it is >>>>>>> actually working correctly but I see no >>>>>>> reason for it not working correctly after >>>>>>> fixing the 2 bugs that test found. >>>>>>> I'll also leave here >>>>>>> some conclusions >>>>>>> about speed and resource consumption I found. >>>>>>> I made tests with >>>>>>> default buffer sizes, >>>>>>> 5000B 15_000B and 500_000B. I noticed >>>>>>> that, with my hardware, with the 1 530 000 >>>>>>> 000B file, I was >>>>>>> getting >>>>>>> around: >>>>>>> In all buffers and fake >>>>>>> work: 10~15s speed >>>>>>> improvement ( from 90% HDD speed to 100% >>>>>>> HDD speed) >>>>>>> In all buffers and no >>>>>>> fake work: 1~2s >>>>>>> speed improvement ( from 90% HDD speed to >>>>>>> 100% HDD speed) >>>>>>> Changing the buffer size was giving >>>>>>> different reading speeds but both were >>>>>>> quite equal in how much they would change >>>>>>> when changing the >>>>>>> buffer >>>>>>> size. >>>>>>> Finally, I could always confirm that I/O >>>>>>> was always the slowest >>>>>>> thing while this >>>>>>> code was running. >>>>>>> For the ones wondering >>>>>>> about the file >>>>>>> size; it is both to avoid OS cache and to >>>>>>> make the reading at the >>>>>>> main use-case >>>>>>> these objects are for (large streams of >>>>>>> bytes). >>>>>>> @Pavel, are you open for discussion now >>>>>>> ;)? Need anything else? >>>>>>> On 21/10/2016 19:21, >>>>>>> Pavel Rappo wrote: >>>>>>> >>>>>>> Just to append to my previous email. >>>>>>> BufferedReader wraps any Reader out there. >>>>>>> Not specifically FileReader. While >>>>>>> you're talking about the case of effective >>>>>>> reading from a file. >>>>>>> I guess there's one existing >>>>>>> possibility to provide exactly what >>>>>>> you need (as I >>>>>>> understand it) under this method: >>>>>>> /** >>>>>>> * Opens a file for reading, >>>>>>> returning a {@code BufferedReader} to >>>>>>> read text >>>>>>> * from the file in an efficient >>>>>>> manner... >>>>>>> ... >>>>>>> */ >>>>>>> >>>>>>> java.nio.file.Files#newBufferedReader(java.nio.file.Path) >>>>>>> It can return _anything_ as long as it >>>>>>> is a BufferedReader. We can do it, but it >>>>>>> needs to be investigated not only for >>>>>>> your favorite OS but for other OSes as >>>>>>> well. Feel free to prototype this and >>>>>>> we can discuss it on the list later. >>>>>>> Thanks, >>>>>>> -Pavel >>>>>>> >>>>>>> On 21 Oct 2016, at 18:56, Brunoais >>>>>>> >>>>>>> wrote: >>>>>>> Pavel is right. >>>>>>> In reality, I was expecting such >>>>>>> BufferedReader to use only a >>>>>>> single buffer and have that Buffer >>>>>>> being filled asynchronously, not >>>>>>> in a different Thread. >>>>>>> Additionally, I don't have the >>>>>>> intention of having a larger >>>>>>> buffer than before unless stated >>>>>>> through the API (the constructor). >>>>>>> In my idea, internally, it is >>>>>>> supposed to use >>>>>>> java.nio.channels.AsynchronousFileChannel >>>>>>> or equivalent. >>>>>>> It does not prevent having two >>>>>>> buffers and I do not intent to >>>>>>> change BufferedReader itself. I'd >>>>>>> do an BufferedAsyncReader of sorts >>>>>>> (any name suggestion is welcome as >>>>>>> I'm an awful namer). >>>>>>> On 21/10/2016 18:38, Roger Riggs >>>>>>> wrote: >>>>>>> >>>>>>> Hi Pavel, >>>>>>> I think Brunoais asking for a >>>>>>> double buffering scheme in >>>>>>> which the implementation of >>>>>>> BufferReader fills (a second >>>>>>> buffer) in parallel with the >>>>>>> application reading from the >>>>>>> 1st buffer >>>>>>> and managing the swaps and >>>>>>> async reads transparently. >>>>>>> It would not change the API >>>>>>> but would change the >>>>>>> interactions between the >>>>>>> buffered reader >>>>>>> and the underlying stream. It >>>>>>> would also increase memory >>>>>>> requirements and processing >>>>>>> by introducing or using a >>>>>>> separate thread and the >>>>>>> necessary synchronization. >>>>>>> Though I think the formal >>>>>>> interface semantics could be >>>>>>> maintained, I have doubts >>>>>>> about compatibility and its >>>>>>> unintended consequences on >>>>>>> existing subclasses, >>>>>>> applications and libraries. >>>>>>> $.02, Roger >>>>>>> On 10/21/16 1:22 PM, Pavel >>>>>>> Rappo wrote: >>>>>>> >>>>>>> Off the top of my head, I >>>>>>> would say it's not >>>>>>> possible to change the >>>>>>> design of an >>>>>>> _extensible_ type that has >>>>>>> been out there for 20 or >>>>>>> so years. All these I/O >>>>>>> streams from java.io >>>>>>> were >>>>>>> designed for simple >>>>>>> synchronous use case. >>>>>>> It's not that their design >>>>>>> is flawed in some way, >>>>>>> it's that they doesn't seem to >>>>>>> suit your needs. Have you >>>>>>> considered using >>>>>>> java.nio.channels.AsynchronousFileChannel >>>>>>> in your applications? >>>>>>> -Pavel >>>>>>> >>>>>>> On 21 Oct 2016, at >>>>>>> 17:08, Brunoais >>>>>>> >>>>>>> wrote: >>>>>>> Any feedback on this? >>>>>>> I'm really interested >>>>>>> in implementing such >>>>>>> BufferedReader/BufferedStreamReader >>>>>>> to allow speeding up >>>>>>> my applications >>>>>>> without having to >>>>>>> think in an >>>>>>> asynchronous way or >>>>>>> multi-threading while >>>>>>> programming with it. >>>>>>> That's why I'm asking >>>>>>> this here. >>>>>>> On 13/10/2016 14:45, >>>>>>> Brunoais wrote: >>>>>>> >>>>>>> Hi, >>>>>>> I looked at >>>>>>> BufferedReader >>>>>>> source code for >>>>>>> java 9 long with >>>>>>> the source code of >>>>>>> the >>>>>>> channels/streams >>>>>>> used. I noticed >>>>>>> that, like in java >>>>>>> 7, BufferedReader >>>>>>> does not use an >>>>>>> Async API to load >>>>>>> data from files, >>>>>>> instead, the data >>>>>>> loading is all >>>>>>> done synchronously >>>>>>> even when the OS >>>>>>> allows requesting >>>>>>> a file to be read >>>>>>> and getting a >>>>>>> warning later when >>>>>>> the file is >>>>>>> effectively read. >>>>>>> Why Is >>>>>>> BufferedReader not >>>>>>> async while >>>>>>> providing a sync API? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- Sent from my phone >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- Sent from my phone >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > From yingqi.lu at intel.com Thu Nov 3 18:10:57 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Thu, 3 Nov 2016 18:10:57 +0000 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5134F66@ORSMSX113.amr.corp.intel.com> <062c589c-fa54-1652-683a-4e779816391d@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513500C@ORSMSX113.amr.corp.intel.com> <542288c7-b0b1-5b41-4c45-d07730e3cddf@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5139A26@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513CE96@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA51447D9@ORSMSX113.amr.corp.intel.com> <006c75c4-1404-d66b-737d-e07ea2b493fd@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA51675D0@ORSMSX113.amr.corp.intel.com> We tried to minimize the changes to native C code and put alignment at Java level. We borrow the same approach being used for VM.isDirectMemoryPageAligned here for DirectByteBuffer alignment. Thanks, Lucy From: Jon V. [mailto:sybersnake at gmail.com] Sent: Thursday, November 03, 2016 5:23 AM To: David M. Lloyd Cc: Lu, Yingqi ; Alan Bateman ; nio-dev at openjdk.java.net; Kaczmarek, Eric ; core-libs-dev at openjdk.java.net; Kharbas, Kishor Subject: Re: Proposal for adding O_DIRECT support into JDK 9 Why not call aligned_alloc for doing page alignment? It should waste much less memory. http://en.cppreference.com/w/c/memory/aligned_alloc On Thu, Nov 3, 2016 at 8:14 AM, David M. Lloyd > wrote: What happens if you're using large pages? Are the direct buffers always allocated off of small pages? On 11/02/2016 06:34 PM, Lu, Yingqi wrote: Hi All, Our most recent DirectIO patch is available at http://cr.openjdk.java.net/~igraves/8164900-3/ In this version, we made following changes: 1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to the FileChannelImpl class. 2. Provided a way for user to allocate a page aligned direct ByteBuffer. 1) Added a constructor DirectByteBuffer(int cap, boolean direct) to allocate a direct ByteBuffer that is aligned to the page size. 2) Added Util.getTemporaryAlignedDirectBuffer(int size) 3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is aligned before doing native IO with it. 3. Moved all the alignment check from C code to Java code (mainly FileChannelImpl and IOUtil.java). 4. Made the DirectIO functionality consistent between read and write operations. With current version of the patch, user would be responsible for the alignment with file offset and IO size. 5. Made the API for DirectIO more extensible to all the supporting platforms. 1) Unix OS specific code are done through UnixConstants.java.template and FileChannelImpl.c. 2) Coded and tested for Linux and OS X (OS X testing is done through VirtualBox with OS X VM on top of Linux OS). 3) Coded for Solaris. We do not have environment to test it so that we commented the changes out. 6. We added 4 test cases following the existing non-direct IO examples. 7. We did jtreg test for the entire nio package and no errors were found due to our changes. Please let us know your feedback and comment. Thank you very much for your time and consideration! Thanks, Lucy -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Monday, October 17, 2016 7:59 AM To: Lu, Yingqi > Cc: nio-dev at openjdk.java.net; Kaczmarek, Eric >; Kharbas, Kishor > Subject: Re: Proposal for adding O_DIRECT support into JDK 9 On 12/10/2016 17:41, Lu, Yingqi wrote: : You are correct about the "extra copy" with DirectIO. Will it be acceptable if we add a function "Util.getAlignedTemporaryDirectBuffer" and use that for the DirectIO operation? In this case, I think we should be able to avoid the additional copy? Yes, that should work but it still lacks a way for the user to get an aligned buffer and so you will always be copying in and out of an aligned buffer. The other thing is the sizing of the I/O operation where I think you will also need a way to expose the multiple (or block size) to the user. -Alan. -- - DML From yingqi.lu at intel.com Thu Nov 3 18:14:21 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Thu, 3 Nov 2016 18:14:21 +0000 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5134F66@ORSMSX113.amr.corp.intel.com> <062c589c-fa54-1652-683a-4e779816391d@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513500C@ORSMSX113.amr.corp.intel.com> <542288c7-b0b1-5b41-4c45-d07730e3cddf@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5139A26@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513CE96@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA51447D9@ORSMSX113.amr.corp.intel.com> <006c75c4-1404-d66b-737d-e07ea2b493fd@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA51675E9@ORSMSX113.amr.corp.intel.com> I think DirectByteBuffer do not use large page. Please refer to https://bugs.openjdk.java.net/browse/JDK-8021829 for more details. Our code changes are done for alignment. I think they should not impact the usage of either small pages or large pages. Thanks, Lucy >-----Original Message----- >From: David M. Lloyd [mailto:david.lloyd at redhat.com] >Sent: Thursday, November 03, 2016 5:15 AM >To: Lu, Yingqi ; Alan Bateman >Cc: nio-dev at openjdk.java.net; Kharbas, Kishor ; >core-libs-dev at openjdk.java.net; Kaczmarek, Eric >Subject: Re: Proposal for adding O_DIRECT support into JDK 9 > >What happens if you're using large pages? Are the direct buffers always >allocated off of small pages? > >On 11/02/2016 06:34 PM, Lu, Yingqi wrote: >> Hi All, >> >> Our most recent DirectIO patch is available at >> http://cr.openjdk.java.net/~igraves/8164900-3/ >> >> In this version, we made following changes: >> >> 1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to the >FileChannelImpl class. >> >> 2. Provided a way for user to allocate a page aligned direct ByteBuffer. >> 1) Added a constructor DirectByteBuffer(int cap, boolean direct) to allocate a >direct ByteBuffer that is aligned to the page size. >> 2) Added Util.getTemporaryAlignedDirectBuffer(int size) >> 3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is aligned >before doing native IO with it. >> >> 3. Moved all the alignment check from C code to Java code (mainly >FileChannelImpl and IOUtil.java). >> >> 4. Made the DirectIO functionality consistent between read and write >operations. With current version of the patch, user would be responsible for the >alignment with file offset and IO size. >> >> 5. Made the API for DirectIO more extensible to all the supporting platforms. >> 1) Unix OS specific code are done through UnixConstants.java.template and >FileChannelImpl.c. >> 2) Coded and tested for Linux and OS X (OS X testing is done through >VirtualBox with OS X VM on top of Linux OS). >> 3) Coded for Solaris. We do not have environment to test it so that we >commented the changes out. >> >> 6. We added 4 test cases following the existing non-direct IO examples. >> >> 7. We did jtreg test for the entire nio package and no errors were found due to >our changes. >> >> Please let us know your feedback and comment. Thank you very much for your >time and consideration! >> >> Thanks, >> Lucy >> >>> -----Original Message----- >>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >>> Sent: Monday, October 17, 2016 7:59 AM >>> To: Lu, Yingqi >>> Cc: nio-dev at openjdk.java.net; Kaczmarek, Eric >>> ; Kharbas, Kishor >>> >>> Subject: Re: Proposal for adding O_DIRECT support into JDK 9 >>> >>> On 12/10/2016 17:41, Lu, Yingqi wrote: >>> >>>> : >>>> >>>> You are correct about the "extra copy" with DirectIO. Will it be >>>> acceptable if we >>> add a function "Util.getAlignedTemporaryDirectBuffer" and use that >>> for the DirectIO operation? In this case, I think we should be able >>> to avoid the additional copy? >>>> >>> Yes, that should work but it still lacks a way for the user to get an >>> aligned buffer and so you will always be copying in and out of an >>> aligned buffer. The other thing is the sizing of the I/O operation >>> where I think you will also need a way to expose the multiple (or block size) to >the user. >>> >>> -Alan. > >-- >- DML From alexandre.iline at oracle.com Thu Nov 3 18:47:01 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Thu, 3 Nov 2016 11:47:01 -0700 Subject: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options In-Reply-To: <42f98564-d908-159c-4531-f45e75c504d3@oracle.com> References: <6b4570ad-e700-4f38-df8d-c91ea8130bad@oracle.com> <42f98564-d908-159c-4531-f45e75c504d3@oracle.com> Message-ID: <2130E34C-1373-4E69-BDC7-AEB478237DE0@oracle.com> Denis, I can see that you have switched to the top level test library with this change. With that you are getting more module dependencies than just java.base. First of all, it would probably make sense to build only the classes you needed (which would be jdk.test.lib.process.ProcessTools, I assume), but even if you only build that, jdk.test.lib.process.ProcessTools has dependencies outside java.base module. You either have to declare @modules in your test or go back to the jdk/test/lib/testlibrary. Then, of course, unneeded module dependencies are questionable. Shura > On Nov 3, 2016, at 6:29 AM, Denis Kononenko wrote: > > Hi, > > I've done some rework accordingly to Alan's and Shura's comments: > > 1) removed overlapped tests from JImageToolTest.java; > > 2) added new tests JImageVerifyTest.java for jimage verify; > > 3) reorganized jtreg's tags; > > The new WEBREV can be found here: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/ > > Thank you, > Denis. > > On 06.10.2016 19:37, Denis Kononenko wrote: >> Hi, >> >> Could someone please review these new tests for jimage utility. >> >> There're 5 new files containing tests to cover use cases for 'info', 'list', 'extract' and other options. No new tests for 'verify'. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 >> WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/ >> >> >> Thank you, >> Denis. > From peter.levart at gmail.com Thu Nov 3 19:38:54 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 3 Nov 2016 20:38:54 +0100 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5134F66@ORSMSX113.amr.corp.intel.com> <062c589c-fa54-1652-683a-4e779816391d@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513500C@ORSMSX113.amr.corp.intel.com> <542288c7-b0b1-5b41-4c45-d07730e3cddf@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5139A26@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513CE96@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA51447D9@ORSMSX113.amr.corp.intel.com> <006c75c4-1404-d66b-737d-e07ea2b493fd@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> Message-ID: <4d4c5ae5-06f9-40a9-f29c-56d0a44e671d@gmail.com> Hi Lucy, Did you know that in JDK 9 the following two methods have been added to java.nio.ByteBuffer: /** @return The indexed byte's memory address modulus the unit size */ public final int alignmentOffset(int index, int unitSize); /** @return new byte buffer whose content is a shared and aligned subsequence of this buffer's content */ public final ByteBuffer alignedSlice(int unitSize); So you could express your proposed methods ByteBuffer.allocateDirectAligned() and ByteBuffer.isAligned() with the above two methods in the following way: instead of: ByteBuffer bb = ByteBuffer.allocateDirectAligned(capacity) you could do: int pageSize = ... ByteBuffer bb = ByteBuffer.allocateDirect(capacity + pageSize - 1).alignedSlice(pageSize); And instead of: bb.isAligned() you could do: bb.alignmentOffset(pageSize) == 0 The only thing that needs to be added is a public API to return the pageSize (i.e. Bits.pageSize()). What do you think? Regards, Peter On 11/03/2016 12:34 AM, Lu, Yingqi wrote: > Hi All, > > Our most recent DirectIO patch is available at http://cr.openjdk.java.net/~igraves/8164900-3/ > > In this version, we made following changes: > > 1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to the FileChannelImpl class. > > 2. Provided a way for user to allocate a page aligned direct ByteBuffer. > 1) Added a constructor DirectByteBuffer(int cap, boolean direct) to allocate a direct ByteBuffer that is aligned to the page size. > 2) Added Util.getTemporaryAlignedDirectBuffer(int size) > 3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is aligned before doing native IO with it. > > 3. Moved all the alignment check from C code to Java code (mainly FileChannelImpl and IOUtil.java). > > 4. Made the DirectIO functionality consistent between read and write operations. With current version of the patch, user would be responsible for the alignment with file offset and IO size. > > 5. Made the API for DirectIO more extensible to all the supporting platforms. > 1) Unix OS specific code are done through UnixConstants.java.template and FileChannelImpl.c. > 2) Coded and tested for Linux and OS X (OS X testing is done through VirtualBox with OS X VM on top of Linux OS). > 3) Coded for Solaris. We do not have environment to test it so that we commented the changes out. > > 6. We added 4 test cases following the existing non-direct IO examples. > > 7. We did jtreg test for the entire nio package and no errors were found due to our changes. > > Please let us know your feedback and comment. Thank you very much for your time and consideration! > > Thanks, > Lucy > >> -----Original Message----- >> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >> Sent: Monday, October 17, 2016 7:59 AM >> To: Lu, Yingqi >> Cc: nio-dev at openjdk.java.net; Kaczmarek, Eric ; >> Kharbas, Kishor >> Subject: Re: Proposal for adding O_DIRECT support into JDK 9 >> >> On 12/10/2016 17:41, Lu, Yingqi wrote: >> >>> : >>> >>> You are correct about the "extra copy" with DirectIO. Will it be acceptable if we >> add a function "Util.getAlignedTemporaryDirectBuffer" and use that for the >> DirectIO operation? In this case, I think we should be able to avoid the additional >> copy? >> Yes, that should work but it still lacks a way for the user to get an aligned buffer >> and so you will always be copying in and out of an aligned buffer. The other thing >> is the sizing of the I/O operation where I think you will also need a way to expose >> the multiple (or block size) to the user. >> >> -Alan. From paul.sandoz at oracle.com Thu Nov 3 19:45:48 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 3 Nov 2016 12:45:48 -0700 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <4d4c5ae5-06f9-40a9-f29c-56d0a44e671d@gmail.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5134F66@ORSMSX113.amr.corp.intel.com> <062c589c-fa54-1652-683a-4e779816391d@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513500C@ORSMSX113.amr.corp.intel.com> <542288c7-b0b1-5b41-4c45-d07730e3cddf@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5139A26@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513CE96@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA51447D9@ORSMSX113.amr.corp.intel.com> <006c75c4-1404-d66b-737d-e07ea2b493fd@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> <4d4c5ae5-06f9-40a9-f29c-56d0a44e671d@! gmail.com> Message-ID: Hi Peter, Thanks for pointing this out, you beat me to it :-) Note that the alignment for a unit size corresponding to page size will only be stable for direct byte buffers, since for heap byte buffers the GC can move the underlying byte array and the alignment properties may change. Paul. > On 3 Nov 2016, at 12:38, Peter Levart wrote: > > Hi Lucy, > > Did you know that in JDK 9 the following two methods have been added to java.nio.ByteBuffer: > > /** @return The indexed byte's memory address modulus the unit size > */ > public final int alignmentOffset(int index, int unitSize); > > /** @return new byte buffer whose content is a shared and aligned subsequence of this buffer's content > */ > public final ByteBuffer alignedSlice(int unitSize); > > > So you could express your proposed methods ByteBuffer.allocateDirectAligned() and ByteBuffer.isAligned() with the above two methods in the following way: > > instead of: > > ByteBuffer bb = ByteBuffer.allocateDirectAligned(capacity) > > you could do: > > int pageSize = ... > ByteBuffer bb = ByteBuffer.allocateDirect(capacity + pageSize - 1).alignedSlice(pageSize); > > And instead of: > > bb.isAligned() > > you could do: > > bb.alignmentOffset(pageSize) == 0 > > > > The only thing that needs to be added is a public API to return the pageSize (i.e. Bits.pageSize()). > > > What do you think? > > Regards, Peter > > On 11/03/2016 12:34 AM, Lu, Yingqi wrote: >> Hi All, >> >> Our most recent DirectIO patch is available at http://cr.openjdk.java.net/~igraves/8164900-3/ >> >> In this version, we made following changes: >> >> 1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to the FileChannelImpl class. >> >> 2. Provided a way for user to allocate a page aligned direct ByteBuffer. >> 1) Added a constructor DirectByteBuffer(int cap, boolean direct) to allocate a direct ByteBuffer that is aligned to the page size. >> 2) Added Util.getTemporaryAlignedDirectBuffer(int size) >> 3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is aligned before doing native IO with it. >> >> 3. Moved all the alignment check from C code to Java code (mainly FileChannelImpl and IOUtil.java). >> >> 4. Made the DirectIO functionality consistent between read and write operations. With current version of the patch, user would be responsible for the alignment with file offset and IO size. >> >> 5. Made the API for DirectIO more extensible to all the supporting platforms. >> 1) Unix OS specific code are done through UnixConstants.java.template and FileChannelImpl.c. >> 2) Coded and tested for Linux and OS X (OS X testing is done through VirtualBox with OS X VM on top of Linux OS). >> 3) Coded for Solaris. We do not have environment to test it so that we commented the changes out. >> >> 6. We added 4 test cases following the existing non-direct IO examples. >> >> 7. We did jtreg test for the entire nio package and no errors were found due to our changes. >> >> Please let us know your feedback and comment. Thank you very much for your time and consideration! >> >> Thanks, >> Lucy >> >>> -----Original Message----- >>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com ] >>> Sent: Monday, October 17, 2016 7:59 AM >>> To: Lu, Yingqi >>> Cc: nio-dev at openjdk.java.net ; Kaczmarek, Eric ; >>> Kharbas, Kishor >>> Subject: Re: Proposal for adding O_DIRECT support into JDK 9 >>> >>> On 12/10/2016 17:41, Lu, Yingqi wrote: >>> >>>> : >>>> >>>> You are correct about the "extra copy" with DirectIO. Will it be acceptable if we >>> add a function "Util.getAlignedTemporaryDirectBuffer" and use that for the >>> DirectIO operation? In this case, I think we should be able to avoid the additional >>> copy? >>> Yes, that should work but it still lacks a way for the user to get an aligned buffer >>> and so you will always be copying in and out of an aligned buffer. The other thing >>> is the sizing of the I/O operation where I think you will also need a way to expose >>> the multiple (or block size) to the user. >>> >>> -Alan. > From yingqi.lu at intel.com Thu Nov 3 19:49:57 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Thu, 3 Nov 2016 19:49:57 +0000 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5134F66@ORSMSX113.amr.corp.intel.com> <062c589c-fa54-1652-683a-4e779816391d@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513500C@ORSMSX113.amr.corp.intel.com> <542288c7-b0b1-5b41-4c45-d07730e3cddf@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5139A26@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513CE96@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA51447D9@ORSMSX113.amr.corp.intel.com> <006c75c4-1404-d66b-737d-e07ea2b493fd@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> <4d4c5ae5-06f9-40a9-f29c-56d0a44e671d@! gmail.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA516782E@ORSMSX113.amr.corp.intel.com> Hi Paul and Peter, Thank you very much for pointing this out. We did not know about it :) We will modify the patch accordingly and will send it here for review. Thanks, Lucy From: Paul Sandoz [mailto:paul.sandoz at oracle.com] Sent: Thursday, November 03, 2016 12:46 PM To: Peter Levart Cc: Lu, Yingqi ; Alan Bateman ; nio-dev at openjdk.java.net; Kaczmarek, Eric ; core-libs-dev at openjdk.java.net; Kharbas, Kishor Subject: Re: Proposal for adding O_DIRECT support into JDK 9 Hi Peter, Thanks for pointing this out, you beat me to it :-) Note that the alignment for a unit size corresponding to page size will only be stable for direct byte buffers, since for heap byte buffers the GC can move the underlying byte array and the alignment properties may change. Paul. On 3 Nov 2016, at 12:38, Peter Levart > wrote: Hi Lucy, Did you know that in JDK 9 the following two methods have been added to java.nio.ByteBuffer: /** @return The indexed byte's memory address modulus the unit size */ public final int alignmentOffset(int index, int unitSize); /** @return new byte buffer whose content is a shared and aligned subsequence of this buffer's content */ public final ByteBuffer alignedSlice(int unitSize); So you could express your proposed methods ByteBuffer.allocateDirectAligned() and ByteBuffer.isAligned() with the above two methods in the following way: instead of: ByteBuffer bb = ByteBuffer.allocateDirectAligned(capacity) you could do: int pageSize = ... ByteBuffer bb = ByteBuffer.allocateDirect(capacity + pageSize - 1).alignedSlice(pageSize); And instead of: bb.isAligned() you could do: bb.alignmentOffset(pageSize) == 0 The only thing that needs to be added is a public API to return the pageSize (i.e. Bits.pageSize()). What do you think? Regards, Peter On 11/03/2016 12:34 AM, Lu, Yingqi wrote: Hi All, Our most recent DirectIO patch is available at http://cr.openjdk.java.net/~igraves/8164900-3/ In this version, we made following changes: 1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to the FileChannelImpl class. 2. Provided a way for user to allocate a page aligned direct ByteBuffer. 1) Added a constructor DirectByteBuffer(int cap, boolean direct) to allocate a direct ByteBuffer that is aligned to the page size. 2) Added Util.getTemporaryAlignedDirectBuffer(int size) 3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is aligned before doing native IO with it. 3. Moved all the alignment check from C code to Java code (mainly FileChannelImpl and IOUtil.java). 4. Made the DirectIO functionality consistent between read and write operations. With current version of the patch, user would be responsible for the alignment with file offset and IO size. 5. Made the API for DirectIO more extensible to all the supporting platforms. 1) Unix OS specific code are done through UnixConstants.java.template and FileChannelImpl.c. 2) Coded and tested for Linux and OS X (OS X testing is done through VirtualBox with OS X VM on top of Linux OS). 3) Coded for Solaris. We do not have environment to test it so that we commented the changes out. 6. We added 4 test cases following the existing non-direct IO examples. 7. We did jtreg test for the entire nio package and no errors were found due to our changes. Please let us know your feedback and comment. Thank you very much for your time and consideration! Thanks, Lucy -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Monday, October 17, 2016 7:59 AM To: Lu, Yingqi Cc: nio-dev at openjdk.java.net; Kaczmarek, Eric ; Kharbas, Kishor Subject: Re: Proposal for adding O_DIRECT support into JDK 9 On 12/10/2016 17:41, Lu, Yingqi wrote: : You are correct about the "extra copy" with DirectIO. Will it be acceptable if we add a function "Util.getAlignedTemporaryDirectBuffer" and use that for the DirectIO operation? In this case, I think we should be able to avoid the additional copy? Yes, that should work but it still lacks a way for the user to get an aligned buffer and so you will always be copying in and out of an aligned buffer. The other thing is the sizing of the I/O operation where I think you will also need a way to expose the multiple (or block size) to the user. -Alan. From mandy.chung at oracle.com Thu Nov 3 20:37:12 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Nov 2016 13:37:12 -0700 Subject: RFR: 8164479: Update JAX-WS RI integration to latest version In-Reply-To: <01423715-826e-8b53-0060-93a2e513138c@oracle.com> References: <1c63a0dc-d38d-0148-016c-30b15721d6a6@oracle.com> <3F91468F-78B2-4D3D-80D2-E429D8FAFC61@oracle.com> <57E5909E.3050702@oracle.com> <5754D4FE-0D20-4527-B163-E9224E3A4FDD@oracle.com> <5ac5eeec-fe39-0728-1ee4-2bc8684722d1@oracle.com> <435c44ae-51fc-c727-915c-6acb499d72a9@oracle.com> <4bbb97c4-4423-30b3-b906-95ff56dda779@oracle.com> <4ff0efee-19fe-8125-163c-5f2981941e39@oracle.com> <01423715-826e-8b53-0060-93a2e513138c@oracle.com> Message-ID: <4E89C684-9EE0-468A-8068-412A8BBF991E@oracle.com> > On Nov 3, 2016, at 4:53 AM, Roman Grigoriadi wrote: > > CCC for CommandInfo changes is now approved (http://ccc.us.oracle.com/8047773), you can find new webrev here: > > http://cr.openjdk.java.net/~aefimov/8164479/03/ > javax/activation/CommandInfo.java 92 * When java.beans.Beans is not visible (when java.desktop module is not Formatting nit: ?java.beans.Beans? and ?java.desktop? can be wrapped with {@code?} 218 Class beanClass = Class.forName(cn, true, loader); I suggest to not to initialize the class in the Class::forName call (i.e. s/true/false) 220 return beanClass.newInstance(); Class::newInstance is deprecated in JDK 9. Can you replace it with Class::getDeclaredConstructor and Constructor::newInstance What does wsimport and xjc -m option do? 67 private static final String JAXWS_PACKAGE = "java.xml.ws?; - Is it a module name, not package name? Does java.xml.ws module still require java.rmi? Should it be updated? Otherwise, looks okay to me. Mandy From paul.sandoz at oracle.com Thu Nov 3 22:37:35 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 3 Nov 2016 15:37:35 -0700 Subject: RFRs for 8166914, 8165782 and 8166735 related to multi-release JAR specification Message-ID: <27C18583-EC4A-49C3-B930-2D0A5E39D6C4@oracle.com> Hi, Please review these specification clarifications for multi-release JARs. They are small and two are closely interrelated so though it would be best to aggregate them in one email. Thanks, Paul. 8166914 URLClassLoader spec needs to mention that it's MR-aware diff -r 52d732262bfa src/java.base/share/classes/java/net/URLClassLoader.java --- a/src/java.base/share/classes/java/net/URLClassLoader.java Thu Nov 03 13:06:24 2016 -0700 +++ b/src/java.base/share/classes/java/net/URLClassLoader.java Thu Nov 03 15:35:29 2016 -0700 @@ -71,6 +71,10 @@ *

      * The classes that are loaded are by default granted permission only to * access the URLs specified when the URLClassLoader was created. + *

      + * This class loader supports the loading of classes from the contents of a + * multi-release JAR file that is referred to by a given URL. (See + * {@link JarFile} for further details on multi-release JAR files.) * * @author David Connelly * @since 1.2 8165782 java.util.jar.JarFile.runtimeVersion() spec needs clarification diff -r 3faad5a1703e src/java.base/share/classes/java/util/jar/JarFile.java --- a/src/java.base/share/classes/java/util/jar/JarFile.java Thu Nov 03 14:45:14 2016 -0700 +++ b/src/java.base/share/classes/java/util/jar/JarFile.java Thu Nov 03 15:35:07 2016 -0700 @@ -192,9 +192,10 @@ public static final String MANIFEST_NAME = META_INF + "MANIFEST.MF"; /** - * The version that represents the unversioned configuration of a multi-release jar file. + * Returns the version that represents the unversioned configuration of a + * multi-release jar file. * - * @return Runtime.Version that represents the unversioned configuration + * @return the version that represents the unversioned configuration * * @since 9 */ @@ -203,13 +204,16 @@ } /** - * The version that represents the effective runtime versioned configuration of a - * multi-release jar file. In most cases, {@code runtimeVersion()} is equal to - * {@code Runtime.version()}. However, if the {@code jdk.util.jar.version} property is set, - * {@code runtimeVersion()} is derived from that property and may not be equal to - * {@code Runtime.version()}. + * Returns the version that represents the effective runtime versioned + * configuration of a multi-release jar file. + *

      + * By default the major version number of the returned {@code Version} will + * be equal to the major version number of {@code Runtime.version()}. + * However, if the {@code jdk.util.jar.version} property is set, the + * returned {@code Version} is derived from that property and major version + * numbers may not be equal. * - * @return Runtime.Version that represents the runtime versioned configuration + * @return the version that represents the runtime versioned configuration * * @since 9 */ 8166735 JarFile#getVersion spec clarification for unversioned jars diff -r 605bff618963 src/java.base/share/classes/java/util/jar/JarFile.java --- a/src/java.base/share/classes/java/util/jar/JarFile.java Thu Nov 03 15:04:13 2016 -0700 +++ b/src/java.base/share/classes/java/util/jar/JarFile.java Thu Nov 03 15:27:29 2016 -0700 @@ -339,6 +339,10 @@ /** * Returns the maximum version used when searching for versioned entries. + *

      + * If this {@code JarFile} is not a multi-release jar file or is not + * configured to be processed as such, then the version returned will be the + * same as that returned from {@link #baseVersion()}. * * @return the maximum version * @since 9 From mandy.chung at oracle.com Fri Nov 4 00:52:08 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Nov 2016 17:52:08 -0700 Subject: RFRs for 8166914, 8165782 and 8166735 related to multi-release JAR specification In-Reply-To: <27C18583-EC4A-49C3-B930-2D0A5E39D6C4@oracle.com> References: <27C18583-EC4A-49C3-B930-2D0A5E39D6C4@oracle.com> Message-ID: Looks fine overall. I think it?s useful to add a section header ?Multi-Release JAR File? in JarFile class specification that URLClassLoader can link to directly when referring ?multi-release JAR file? and other specs can make use of too. Then the following statement is not needed. > (See {@link JarFile} for further details on multi-release JAR files.) Mandy > On Nov 3, 2016, at 3:37 PM, Paul Sandoz wrote: > > Hi, > > Please review these specification clarifications for multi-release JARs. They are small and two are closely interrelated so though it would be best to aggregate them in one email. > > Thanks, > Paul. > > > 8166914 URLClassLoader spec needs to mention that it's MR-aware > > diff -r 52d732262bfa src/java.base/share/classes/java/net/URLClassLoader.java > --- a/src/java.base/share/classes/java/net/URLClassLoader.java Thu Nov 03 13:06:24 2016 -0700 > +++ b/src/java.base/share/classes/java/net/URLClassLoader.java Thu Nov 03 15:35:29 2016 -0700 > @@ -71,6 +71,10 @@ > *

      > * The classes that are loaded are by default granted permission only to > * access the URLs specified when the URLClassLoader was created. > + *

      > + * This class loader supports the loading of classes from the contents of a > + * multi-release JAR file that is referred to by a given URL. (See > + * {@link JarFile} for further details on multi-release JAR files.) > * > * @author David Connelly > * @since 1.2 > > > > 8165782 java.util.jar.JarFile.runtimeVersion() spec needs clarification > > diff -r 3faad5a1703e src/java.base/share/classes/java/util/jar/JarFile.java > --- a/src/java.base/share/classes/java/util/jar/JarFile.java Thu Nov 03 14:45:14 2016 -0700 > +++ b/src/java.base/share/classes/java/util/jar/JarFile.java Thu Nov 03 15:35:07 2016 -0700 > @@ -192,9 +192,10 @@ > public static final String MANIFEST_NAME = META_INF + "MANIFEST.MF"; > > /** > - * The version that represents the unversioned configuration of a multi-release jar file. > + * Returns the version that represents the unversioned configuration of a > + * multi-release jar file. > * > - * @return Runtime.Version that represents the unversioned configuration > + * @return the version that represents the unversioned configuration > * > * @since 9 > */ > @@ -203,13 +204,16 @@ > } > > /** > - * The version that represents the effective runtime versioned configuration of a > - * multi-release jar file. In most cases, {@code runtimeVersion()} is equal to > - * {@code Runtime.version()}. However, if the {@code jdk.util.jar.version} property is set, > - * {@code runtimeVersion()} is derived from that property and may not be equal to > - * {@code Runtime.version()}. > + * Returns the version that represents the effective runtime versioned > + * configuration of a multi-release jar file. > + *

      > + * By default the major version number of the returned {@code Version} will > + * be equal to the major version number of {@code Runtime.version()}. > + * However, if the {@code jdk.util.jar.version} property is set, the > + * returned {@code Version} is derived from that property and major version > + * numbers may not be equal. > * > - * @return Runtime.Version that represents the runtime versioned configuration > + * @return the version that represents the runtime versioned configuration > * > * @since 9 > */ > > > > 8166735 JarFile#getVersion spec clarification for unversioned jars > > diff -r 605bff618963 src/java.base/share/classes/java/util/jar/JarFile.java > --- a/src/java.base/share/classes/java/util/jar/JarFile.java Thu Nov 03 15:04:13 2016 -0700 > +++ b/src/java.base/share/classes/java/util/jar/JarFile.java Thu Nov 03 15:27:29 2016 -0700 > @@ -339,6 +339,10 @@ > > /** > * Returns the maximum version used when searching for versioned entries. > + *

      > + * If this {@code JarFile} is not a multi-release jar file or is not > + * configured to be processed as such, then the version returned will be the > + * same as that returned from {@link #baseVersion()}. > * > * @return the maximum version > * @since 9 From stuart.marks at oracle.com Fri Nov 4 02:08:58 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 3 Nov 2016 19:08:58 -0700 Subject: RFR(s): 8156079: make empty instances singletons Message-ID: Hi all, Please review this small set of changes to the immutable collections to make the zero-size instances singletons. (JDK-8156079) This also includes a couple other small optimizations (JDK-8169222) to change the expansion factor from floating point to integer, and also to avoid creating a single-use Random instance to compute the hash salt value at startup. Webrev: http://cr.openjdk.java.net/~smarks/reviews/8156079/webrev.0/ Thanks, s'marks From mandy.chung at oracle.com Fri Nov 4 03:00:38 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Nov 2016 20:00:38 -0700 Subject: RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more In-Reply-To: <11cfb990-622d-10b1-5f85-7445f114073e@gmail.com> References: <9ddc7fc5-68fe-bb78-b54d-6ba55880c018@gmail.com> <1F5607C1-9EFC-4881-A3A9-31CB948FE67C@oracle.com> <1a075ccc-bdd9-ffe9-6a7b-2e734c6233e8@gmail.com> <0c67ae84-7bab-5944-1665-129dc451f3da@oracle.com> <07a6e24e-7dbc-6582-015f-62fd3fda24bd@gmail.com> <9ff4b8bc-c924-3cc9-8976-0cc10ca6804a@oracle.com> <34B4C0BE-A333-4865-9C24-C6A9DBBF3D35@oracle.com> <11cfb990-622d-10b1-5f85-7445f114073e@gmail.com> Message-ID: > On Nov 3, 2016, at 1:32 AM, Peter Levart wrote: > > > Here is a webrev incorporating your suggestions: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.07/ This looks really good. I went through the test output and the expected result looks right to me as far as I can focus (there are many many combination there). As for the spec, it is clear and there may be some wordsmithing we could do but it?s fine to leave it for the future. Nit: "sub-sets? should it be ?subsets? (no hyphen)? Mandy From forax at univ-mlv.fr Fri Nov 4 07:08:32 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 04 Nov 2016 07:08:32 +0000 Subject: RFR(s): 8156079: make empty instances singletons In-Reply-To: References: Message-ID: Looks good, the static methods in ImmutableCollections do not need to be final there are already static. R?mi On November 4, 2016 3:08:58 AM GMT+01:00, Stuart Marks wrote: >Hi all, > >Please review this small set of changes to the immutable collections to >make the >zero-size instances singletons. (JDK-8156079) > >This also includes a couple other small optimizations (JDK-8169222) to >change >the expansion factor from floating point to integer, and also to avoid >creating >a single-use Random instance to compute the hash salt value at startup. > >Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8156079/webrev.0/ > >Thanks, > >s'marks -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From amy.lu at oracle.com Fri Nov 4 13:27:56 2016 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 4 Nov 2016 21:27:56 +0800 Subject: JDK 9 RFR of JDK-8037278: sun/rmi/runtime/Log/6409194/NoConsoleOutput.java fails Intermittently: unexpected subprocess output In-Reply-To: <4b1378e2-58ec-2ced-eb86-c5294e79a4e5@oracle.com> References: <7bbecf74-9c8a-4d33-665f-17c4f3986920@oracle.com> <4b1378e2-58ec-2ced-eb86-c5294e79a4e5@oracle.com> Message-ID: <516d61dd-1871-3840-f62a-88db74f1d870@oracle.com> Hi, Daniel I updated webrev, removed the test dependency on TestLibrary. (RMI logging still be triggered thus no change to testing purpose.) Please review again: http://cr.openjdk.java.net/~amlu/8037278/webrev.02/ Thanks, Amy On 11/3/16 9:42 PM, Daniel Fuchs wrote: > On 03/11/16 13:35, Daniel Fuchs wrote: >> Hi Amy, >> >> Looks good to me. > > Maybe a followup should be logged to try > and no longer call TestLibrary.getUnusedRandomPort(), > as this the method that is causing the rogue > output (and I see that it might print things > to System.err as well). > > best regards, > > -- daniel > > >> >> -- daniel >> >> On 03/11/16 13:22, Amy Lu wrote: >>> Thank you Daniel for your review. >>> >>> Yes, agree and reverted those three lines. >>> >>> webrev updated: >>> http://cr.openjdk.java.net/~amlu/8037278/webrev.01 >>> >>> Thanks, >>> Amy >>> >>> On 11/3/16 8:37 PM, Daniel Fuchs wrote: >>>> Hi Amy, >>>> >>>> I think it might still be useful to see what the subprocess >>>> prints on System.out in case of failure. >>>> I would leave lines 83, 86 and 87 unchanged. >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 03/11/16 11:58, Amy Lu wrote: >>>>> Please review the patch for test >>>>> sun/rmi/runtime/Log/6409194/NoConsoleOutput.java >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037278 >>>>> webrev: http://cr.openjdk.java.net/~amlu/8037278/webrev.00/ >>>>> >>>>> This test fails whenever there?s extra output from System.out >>>>> (from the >>>>> test application DoRMIStuff). But actually this test is for checking >>>>> RMI >>>>> logging messages and that are from System.err. Test should ignore the >>>>> output from System.out. >>>>> >>>>> Thanks, >>>>> Amy >>>> >>> >> > From daniel.fuchs at oracle.com Fri Nov 4 13:33:38 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 4 Nov 2016 13:33:38 +0000 Subject: JDK 9 RFR of JDK-8037278: sun/rmi/runtime/Log/6409194/NoConsoleOutput.java fails Intermittently: unexpected subprocess output In-Reply-To: <516d61dd-1871-3840-f62a-88db74f1d870@oracle.com> References: <7bbecf74-9c8a-4d33-665f-17c4f3986920@oracle.com> <4b1378e2-58ec-2ced-eb86-c5294e79a4e5@oracle.com> <516d61dd-1871-3840-f62a-88db74f1d870@oracle.com> Message-ID: <164b18f2-ab62-e84d-f570-bc3b2a59770a@oracle.com> Hi Amy, Looks good to me. Might be good to have confirmation from Roger or Stuart that no longer using the registry is OK WRT to the purpose of this test. If so then this looks like the ideal solution :-) best regards, -- daniel On 04/11/16 13:27, Amy Lu wrote: > Hi, Daniel > > I updated webrev, removed the test dependency on TestLibrary. > (RMI logging still be triggered thus no change to testing purpose.) > > Please review again: > http://cr.openjdk.java.net/~amlu/8037278/webrev.02/ > > Thanks, > Amy > > On 11/3/16 9:42 PM, Daniel Fuchs wrote: >> On 03/11/16 13:35, Daniel Fuchs wrote: >>> Hi Amy, >>> >>> Looks good to me. >> >> Maybe a followup should be logged to try >> and no longer call TestLibrary.getUnusedRandomPort(), >> as this the method that is causing the rogue >> output (and I see that it might print things >> to System.err as well). >> >> best regards, >> >> -- daniel >> >> >>> >>> -- daniel >>> >>> On 03/11/16 13:22, Amy Lu wrote: >>>> Thank you Daniel for your review. >>>> >>>> Yes, agree and reverted those three lines. >>>> >>>> webrev updated: >>>> http://cr.openjdk.java.net/~amlu/8037278/webrev.01 >>>> >>>> Thanks, >>>> Amy >>>> >>>> On 11/3/16 8:37 PM, Daniel Fuchs wrote: >>>>> Hi Amy, >>>>> >>>>> I think it might still be useful to see what the subprocess >>>>> prints on System.out in case of failure. >>>>> I would leave lines 83, 86 and 87 unchanged. >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>>> >>>>> On 03/11/16 11:58, Amy Lu wrote: >>>>>> Please review the patch for test >>>>>> sun/rmi/runtime/Log/6409194/NoConsoleOutput.java >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037278 >>>>>> webrev: http://cr.openjdk.java.net/~amlu/8037278/webrev.00/ >>>>>> >>>>>> This test fails whenever there?s extra output from System.out >>>>>> (from the >>>>>> test application DoRMIStuff). But actually this test is for checking >>>>>> RMI >>>>>> logging messages and that are from System.err. Test should ignore the >>>>>> output from System.out. >>>>>> >>>>>> Thanks, >>>>>> Amy >>>>> >>>> >>> >> > From Roger.Riggs at Oracle.com Fri Nov 4 13:51:26 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 4 Nov 2016 09:51:26 -0400 Subject: JDK 9 RFR of JDK-8037278: sun/rmi/runtime/Log/6409194/NoConsoleOutput.java fails Intermittently: unexpected subprocess output In-Reply-To: <164b18f2-ab62-e84d-f570-bc3b2a59770a@oracle.com> References: <7bbecf74-9c8a-4d33-665f-17c4f3986920@oracle.com> <4b1378e2-58ec-2ced-eb86-c5294e79a4e5@oracle.com> <516d61dd-1871-3840-f62a-88db74f1d870@oracle.com> <164b18f2-ab62-e84d-f570-bc3b2a59770a@oracle.com> Message-ID: Hi Amy, yes, this looks fine; no need for the RMI Registry in the test. Perhaps you can fix the typo: line 54: "Exdecute" =-> "Execute"; no need for another webrev. Thanks, Roger On 11/4/2016 9:33 AM, Daniel Fuchs wrote: > Hi Amy, > > Looks good to me. > > Might be good to have confirmation from Roger or Stuart > that no longer using the registry is OK WRT to the > purpose of this test. If so then this looks like > the ideal solution :-) > > best regards, > > -- daniel > > On 04/11/16 13:27, Amy Lu wrote: >> Hi, Daniel >> >> I updated webrev, removed the test dependency on TestLibrary. >> (RMI logging still be triggered thus no change to testing purpose.) >> >> Please review again: >> http://cr.openjdk.java.net/~amlu/8037278/webrev.02/ >> >> Thanks, >> Amy >> >> On 11/3/16 9:42 PM, Daniel Fuchs wrote: >>> On 03/11/16 13:35, Daniel Fuchs wrote: >>>> Hi Amy, >>>> >>>> Looks good to me. >>> >>> Maybe a followup should be logged to try >>> and no longer call TestLibrary.getUnusedRandomPort(), >>> as this the method that is causing the rogue >>> output (and I see that it might print things >>> to System.err as well). >>> >>> best regards, >>> >>> -- daniel >>> >>> >>>> >>>> -- daniel >>>> >>>> On 03/11/16 13:22, Amy Lu wrote: >>>>> Thank you Daniel for your review. >>>>> >>>>> Yes, agree and reverted those three lines. >>>>> >>>>> webrev updated: >>>>> http://cr.openjdk.java.net/~amlu/8037278/webrev.01 >>>>> >>>>> Thanks, >>>>> Amy >>>>> >>>>> On 11/3/16 8:37 PM, Daniel Fuchs wrote: >>>>>> Hi Amy, >>>>>> >>>>>> I think it might still be useful to see what the subprocess >>>>>> prints on System.out in case of failure. >>>>>> I would leave lines 83, 86 and 87 unchanged. >>>>>> >>>>>> best regards, >>>>>> >>>>>> -- daniel >>>>>> >>>>>> On 03/11/16 11:58, Amy Lu wrote: >>>>>>> Please review the patch for test >>>>>>> sun/rmi/runtime/Log/6409194/NoConsoleOutput.java >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037278 >>>>>>> webrev: http://cr.openjdk.java.net/~amlu/8037278/webrev.00/ >>>>>>> >>>>>>> This test fails whenever there?s extra output from System.out >>>>>>> (from the >>>>>>> test application DoRMIStuff). But actually this test is for >>>>>>> checking >>>>>>> RMI >>>>>>> logging messages and that are from System.err. Test should >>>>>>> ignore the >>>>>>> output from System.out. >>>>>>> >>>>>>> Thanks, >>>>>>> Amy >>>>>> >>>>> >>>> >>> >> > From amy.lu at oracle.com Fri Nov 4 13:57:34 2016 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 4 Nov 2016 21:57:34 +0800 Subject: JDK 9 RFR of JDK-8037278: sun/rmi/runtime/Log/6409194/NoConsoleOutput.java fails Intermittently: unexpected subprocess output In-Reply-To: References: <7bbecf74-9c8a-4d33-665f-17c4f3986920@oracle.com> <4b1378e2-58ec-2ced-eb86-c5294e79a4e5@oracle.com> <516d61dd-1871-3840-f62a-88db74f1d870@oracle.com> <164b18f2-ab62-e84d-f570-bc3b2a59770a@oracle.com> Message-ID: <02a4f615-0853-5dd7-cf60-ceb059fae229@oracle.com> Thank you Roger and Daniel for reviewing. I'll push webrev.02 with the fix for line 54 typo :-) Thanks, Amy On 11/4/16 9:51 PM, Roger Riggs wrote: > Hi Amy, > > yes, this looks fine; no need for the RMI Registry in the test. > > Perhaps you can fix the typo: line 54: "Exdecute" =-> "Execute"; > no need for another webrev. > > Thanks, Roger > > > On 11/4/2016 9:33 AM, Daniel Fuchs wrote: >> Hi Amy, >> >> Looks good to me. >> >> Might be good to have confirmation from Roger or Stuart >> that no longer using the registry is OK WRT to the >> purpose of this test. If so then this looks like >> the ideal solution :-) >> >> best regards, >> >> -- daniel >> >> On 04/11/16 13:27, Amy Lu wrote: >>> Hi, Daniel >>> >>> I updated webrev, removed the test dependency on TestLibrary. >>> (RMI logging still be triggered thus no change to testing purpose.) >>> >>> Please review again: >>> http://cr.openjdk.java.net/~amlu/8037278/webrev.02/ >>> >>> Thanks, >>> Amy >>> >>> On 11/3/16 9:42 PM, Daniel Fuchs wrote: >>>> On 03/11/16 13:35, Daniel Fuchs wrote: >>>>> Hi Amy, >>>>> >>>>> Looks good to me. >>>> >>>> Maybe a followup should be logged to try >>>> and no longer call TestLibrary.getUnusedRandomPort(), >>>> as this the method that is causing the rogue >>>> output (and I see that it might print things >>>> to System.err as well). >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> >>>>> >>>>> -- daniel >>>>> >>>>> On 03/11/16 13:22, Amy Lu wrote: >>>>>> Thank you Daniel for your review. >>>>>> >>>>>> Yes, agree and reverted those three lines. >>>>>> >>>>>> webrev updated: >>>>>> http://cr.openjdk.java.net/~amlu/8037278/webrev.01 >>>>>> >>>>>> Thanks, >>>>>> Amy >>>>>> >>>>>> On 11/3/16 8:37 PM, Daniel Fuchs wrote: >>>>>>> Hi Amy, >>>>>>> >>>>>>> I think it might still be useful to see what the subprocess >>>>>>> prints on System.out in case of failure. >>>>>>> I would leave lines 83, 86 and 87 unchanged. >>>>>>> >>>>>>> best regards, >>>>>>> >>>>>>> -- daniel >>>>>>> >>>>>>> On 03/11/16 11:58, Amy Lu wrote: >>>>>>>> Please review the patch for test >>>>>>>> sun/rmi/runtime/Log/6409194/NoConsoleOutput.java >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037278 >>>>>>>> webrev: http://cr.openjdk.java.net/~amlu/8037278/webrev.00/ >>>>>>>> >>>>>>>> This test fails whenever there?s extra output from System.out >>>>>>>> (from the >>>>>>>> test application DoRMIStuff). But actually this test is for >>>>>>>> checking >>>>>>>> RMI >>>>>>>> logging messages and that are from System.err. Test should >>>>>>>> ignore the >>>>>>>> output from System.out. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Amy >>>>>>> >>>>>> >>>>> >>>> >>> >> > From claes.redestad at oracle.com Fri Nov 4 15:34:45 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 4 Nov 2016 16:34:45 +0100 Subject: RFR(s): 8156079: make empty instances singletons In-Reply-To: References: Message-ID: +1 /Claes On 2016-11-04 03:08, Stuart Marks wrote: > Hi all, > > Please review this small set of changes to the immutable collections > to make the zero-size instances singletons. (JDK-8156079) > > This also includes a couple other small optimizations (JDK-8169222) to > change the expansion factor from floating point to integer, and also > to avoid creating a single-use Random instance to compute the hash > salt value at startup. > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8156079/webrev.0/ > > Thanks, > > s'marks From stuart.marks at oracle.com Fri Nov 4 15:39:10 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 4 Nov 2016 08:39:10 -0700 Subject: RFR(s): 8156079: make empty instances singletons In-Reply-To: References: Message-ID: On 11/4/16 12:08 AM, Remi Forax wrote: > the static methods in ImmutableCollections do not need to be final there are > already static. Oh yes, good point. I'll fix it. Thanks. s'marks From Alan.Bateman at oracle.com Fri Nov 4 15:41:38 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Nov 2016 15:41:38 +0000 Subject: RFRs for 8166914, 8165782 and 8166735 related to multi-release JAR specification In-Reply-To: References: <27C18583-EC4A-49C3-B930-2D0A5E39D6C4@oracle.com> Message-ID: <41f69bee-4c40-889f-ac89-c282e93731f5@oracle.com> On 04/11/2016 00:52, Mandy Chung wrote: > Looks fine overall. I think it?s useful to add a section header ?Multi-Release JAR File? in JarFile class specification that URLClassLoader can link to directly when referring ?multi-release JAR file? and other specs can make use of too. > > The javadoc changes looks okay to me too. I agree that a section in the class description for MR JARs would be good to have, I think we suggested a while back too. -Alan From Alan.Bateman at oracle.com Fri Nov 4 15:43:43 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Nov 2016 15:43:43 +0000 Subject: RFR(s): 8156079: make empty instances singletons In-Reply-To: References: Message-ID: <6306a020-c207-d365-48af-e7ccdd62eac6@oracle.com> On 04/11/2016 02:08, Stuart Marks wrote: > Hi all, > > Please review this small set of changes to the immutable collections > to make the zero-size instances singletons. (JDK-8156079) > > This also includes a couple other small optimizations (JDK-8169222) to > change the expansion factor from floating point to integer, and also > to avoid creating a single-use Random instance to compute the hash > salt value at startup. > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8156079/webrev.0/ This looks good (I find myself using these a lot lately, really nice to use). -Alan From sybersnake at gmail.com Thu Nov 3 12:22:54 2016 From: sybersnake at gmail.com (Jon V.) Date: Thu, 3 Nov 2016 08:22:54 -0400 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5134F66@ORSMSX113.amr.corp.intel.com> <062c589c-fa54-1652-683a-4e779816391d@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513500C@ORSMSX113.amr.corp.intel.com> <542288c7-b0b1-5b41-4c45-d07730e3cddf@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5139A26@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513CE96@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA51447D9@ORSMSX113.amr.corp.intel.com> <006c75c4-1404-d66b-737d-e07ea2b493fd@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> Message-ID: Why not call aligned_alloc for doing page alignment? It should waste much less memory. http://en.cppreference.com/w/c/memory/aligned_alloc On Thu, Nov 3, 2016 at 8:14 AM, David M. Lloyd wrote: > What happens if you're using large pages? Are the direct buffers always > allocated off of small pages? > > > On 11/02/2016 06:34 PM, Lu, Yingqi wrote: > >> Hi All, >> >> Our most recent DirectIO patch is available at >> http://cr.openjdk.java.net/~igraves/8164900-3/ >> >> In this version, we made following changes: >> >> 1. Removed the flag "direct" from FileDescriptor class. Instead, moved it >> to the FileChannelImpl class. >> >> 2. Provided a way for user to allocate a page aligned direct ByteBuffer. >> 1) Added a constructor DirectByteBuffer(int cap, boolean direct) to >> allocate a direct ByteBuffer that is aligned to the page size. >> 2) Added Util.getTemporaryAlignedDirectBuffer(int size) >> 3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer >> is aligned before doing native IO with it. >> >> 3. Moved all the alignment check from C code to Java code (mainly >> FileChannelImpl and IOUtil.java). >> >> 4. Made the DirectIO functionality consistent between read and write >> operations. With current version of the patch, user would be responsible >> for the alignment with file offset and IO size. >> >> 5. Made the API for DirectIO more extensible to all the supporting >> platforms. >> 1) Unix OS specific code are done through UnixConstants.java.template >> and FileChannelImpl.c. >> 2) Coded and tested for Linux and OS X (OS X testing is done through >> VirtualBox with OS X VM on top of Linux OS). >> 3) Coded for Solaris. We do not have environment to test it so that >> we commented the changes out. >> >> 6. We added 4 test cases following the existing non-direct IO examples. >> >> 7. We did jtreg test for the entire nio package and no errors were found >> due to our changes. >> >> Please let us know your feedback and comment. Thank you very much for >> your time and consideration! >> >> Thanks, >> Lucy >> >> -----Original Message----- >>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >>> Sent: Monday, October 17, 2016 7:59 AM >>> To: Lu, Yingqi >>> Cc: nio-dev at openjdk.java.net; Kaczmarek, Eric >> >; >>> Kharbas, Kishor >>> Subject: Re: Proposal for adding O_DIRECT support into JDK 9 >>> >>> On 12/10/2016 17:41, Lu, Yingqi wrote: >>> >>> : >>>> >>>> You are correct about the "extra copy" with DirectIO. Will it be >>>> acceptable if we >>>> >>> add a function "Util.getAlignedTemporaryDirectBuffer" and use that for >>> the >>> DirectIO operation? In this case, I think we should be able to avoid the >>> additional >>> copy? >>> >>>> >>>> Yes, that should work but it still lacks a way for the user to get an >>> aligned buffer >>> and so you will always be copying in and out of an aligned buffer. The >>> other thing >>> is the sizing of the I/O operation where I think you will also need a >>> way to expose >>> the multiple (or block size) to the user. >>> >>> -Alan. >>> >> > -- > - DML > From paul.sandoz at oracle.com Fri Nov 4 16:58:21 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 4 Nov 2016 09:58:21 -0700 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AA516782E@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5134F66@ORSMSX113.amr.corp.intel.com> <062c589c-fa54-1652-683a-4e779816391d@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513500C@ORSMSX113.amr.corp.intel.com> <542288c7-b0b1-5b41-4c45-d07730e3cddf@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5139A26@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513CE96@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA51447D9@ORSMSX113.amr.corp.intel.com> <006c75c4-1404-d66b-737d-e07ea2b493fd@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> <4d4c5ae5-06f9-40a9-f29c-56d0a44e671d@! ! gmail.com> <9ACD5B67AAC5594CB6268234CF29CF9AA516782E@ORSMSX113.amr.corp.intel.com> Message-ID: <36CE90D5-B86C-4E0A-A2BD-AC812D4262D1@oracle.com> Hi Lucy, I am struggling to find an entirely satisfactory location to place a method such as getPageSize, but java.lang.Runtime seems less worse than other places :-) Paul. > On 3 Nov 2016, at 12:49, Lu, Yingqi wrote: > > Hi Paul and Peter, > > Thank you very much for pointing this out. We did not know about it J > > We will modify the patch accordingly and will send it here for review. > > Thanks, > Lucy > > From: Paul Sandoz [mailto:paul.sandoz at oracle.com] > Sent: Thursday, November 03, 2016 12:46 PM > To: Peter Levart > Cc: Lu, Yingqi ; Alan Bateman ; nio-dev at openjdk.java.net; Kaczmarek, Eric ; core-libs-dev at openjdk.java.net; Kharbas, Kishor > Subject: Re: Proposal for adding O_DIRECT support into JDK 9 > > Hi Peter, > > Thanks for pointing this out, you beat me to it :-) > > Note that the alignment for a unit size corresponding to page size will only be stable for direct byte buffers, since for heap byte buffers the GC can move the underlying byte array and the alignment properties may change. > > Paul. > > On 3 Nov 2016, at 12:38, Peter Levart wrote: > > Hi Lucy, > > Did you know that in JDK 9 the following two methods have been added to java.nio.ByteBuffer: > > /** @return The indexed byte's memory address modulus the unit size > */ > public final int alignmentOffset(int index, int unitSize); > > /** @return new byte buffer whose content is a shared and aligned subsequence of this buffer's content > */ > public final ByteBuffer alignedSlice(int unitSize); > > > So you could express your proposed methods ByteBuffer.allocateDirectAligned() and ByteBuffer.isAligned() with the above two methods in the following way: > > instead of: > > ByteBuffer bb = ByteBuffer.allocateDirectAligned(capacity) > > you could do: > > int pageSize = ... > ByteBuffer bb = ByteBuffer.allocateDirect(capacity + pageSize - 1).alignedSlice(pageSize); > > And instead of: > > bb.isAligned() > > you could do: > > bb.alignmentOffset(pageSize) == 0 > > > > The only thing that needs to be added is a public API to return the pageSize (i.e. Bits.pageSize()). > > > What do you think? > > Regards, Peter > > On 11/03/2016 12:34 AM, Lu, Yingqi wrote: > Hi All, > > Our most recent DirectIO patch is available at http://cr.openjdk.java.net/~igraves/8164900-3/ > > In this version, we made following changes: > > 1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to the FileChannelImpl class. > > 2. Provided a way for user to allocate a page aligned direct ByteBuffer. > 1) Added a constructor DirectByteBuffer(int cap, boolean direct) to allocate a direct ByteBuffer that is aligned to the page size. > 2) Added Util.getTemporaryAlignedDirectBuffer(int size) > 3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is aligned before doing native IO with it. > > 3. Moved all the alignment check from C code to Java code (mainly FileChannelImpl and IOUtil.java). > > 4. Made the DirectIO functionality consistent between read and write operations. With current version of the patch, user would be responsible for the alignment with file offset and IO size. > > 5. Made the API for DirectIO more extensible to all the supporting platforms. > 1) Unix OS specific code are done through UnixConstants.java.template and FileChannelImpl.c. > 2) Coded and tested for Linux and OS X (OS X testing is done through VirtualBox with OS X VM on top of Linux OS). > 3) Coded for Solaris. We do not have environment to test it so that we commented the changes out. > > 6. We added 4 test cases following the existing non-direct IO examples. > > 7. We did jtreg test for the entire nio package and no errors were found due to our changes. > > Please let us know your feedback and comment. Thank you very much for your time and consideration! > > Thanks, > Lucy > > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > Sent: Monday, October 17, 2016 7:59 AM > To: Lu, Yingqi > Cc: nio-dev at openjdk.java.net; Kaczmarek, Eric ; > Kharbas, Kishor > Subject: Re: Proposal for adding O_DIRECT support into JDK 9 > > On 12/10/2016 17:41, Lu, Yingqi wrote: > > : > > You are correct about the "extra copy" with DirectIO. Will it be acceptable if we > add a function "Util.getAlignedTemporaryDirectBuffer" and use that for the > DirectIO operation? In this case, I think we should be able to avoid the additional > copy? > Yes, that should work but it still lacks a way for the user to get an aligned buffer > and so you will always be copying in and out of an aligned buffer. The other thing > is the sizing of the I/O operation where I think you will also need a way to expose > the multiple (or block size) to the user. > > -Alan. From yingqi.lu at intel.com Fri Nov 4 17:08:59 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Fri, 4 Nov 2016 17:08:59 +0000 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <36CE90D5-B86C-4E0A-A2BD-AC812D4262D1@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5134F66@ORSMSX113.amr.corp.intel.com> <062c589c-fa54-1652-683a-4e779816391d@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513500C@ORSMSX113.amr.corp.intel.com> <542288c7-b0b1-5b41-4c45-d07730e3cddf@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5139A26@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513CE96@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA51447D9@ORSMSX113.amr.corp.intel.com> <006c75c4-1404-d66b-737d-e07ea2b493fd@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> <4d4c5ae5-06f9-40a9-f29c-56d0a44e671d@! ! gmail.com> <9ACD5B67AAC5594CB6268234CF29CF9AA516782E@ORSMSX113.amr.corp.intel.com> <36CE90D5-B86C-4E0A-A2BD-AC812D4262D1@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA516893D@ORSMSX113.amr.corp.intel.com> Hi Paul, Thank you very much for all your suggestions. Currently, we add getAlignment() function to FileChannel and override it in FileChannelImpl with details. Basically, it just calls sun.nio.ch.Util.pageSize(). However, if you think exposing pageSize() from java.lang.Runtime is a better approach, we can certainly do that. Please let us know! Thanks, Lucy >-----Original Message----- >From: Paul Sandoz [mailto:paul.sandoz at oracle.com] >Sent: Friday, November 04, 2016 9:58 AM >To: Lu, Yingqi >Cc: Peter Levart ; Alan Bateman >; nio-dev at openjdk.java.net; Kaczmarek, Eric >; core-libs-dev at openjdk.java.net; Kharbas, Kishor > >Subject: Re: Proposal for adding O_DIRECT support into JDK 9 > >Hi Lucy, > >I am struggling to find an entirely satisfactory location to place a method such as >getPageSize, but java.lang.Runtime seems less worse than other places :-) > >Paul. > >> On 3 Nov 2016, at 12:49, Lu, Yingqi wrote: >> >> Hi Paul and Peter, >> >> Thank you very much for pointing this out. We did not know about it J >> >> We will modify the patch accordingly and will send it here for review. >> >> Thanks, >> Lucy >> >> From: Paul Sandoz [mailto:paul.sandoz at oracle.com] >> Sent: Thursday, November 03, 2016 12:46 PM >> To: Peter Levart >> Cc: Lu, Yingqi ; Alan Bateman >> ; nio-dev at openjdk.java.net; Kaczmarek, Eric >> ; core-libs-dev at openjdk.java.net; Kharbas, >> Kishor >> Subject: Re: Proposal for adding O_DIRECT support into JDK 9 >> >> Hi Peter, >> >> Thanks for pointing this out, you beat me to it :-) >> >> Note that the alignment for a unit size corresponding to page size will only be >stable for direct byte buffers, since for heap byte buffers the GC can move the >underlying byte array and the alignment properties may change. >> >> Paul. >> >> On 3 Nov 2016, at 12:38, Peter Levart wrote: >> >> Hi Lucy, >> >> Did you know that in JDK 9 the following two methods have been added to >java.nio.ByteBuffer: >> >> /** @return The indexed byte's memory address modulus the unit size >> */ >> public final int alignmentOffset(int index, int unitSize); >> >> /** @return new byte buffer whose content is a shared and aligned >subsequence of this buffer's content >> */ >> public final ByteBuffer alignedSlice(int unitSize); >> >> >> So you could express your proposed methods ByteBuffer.allocateDirectAligned() >and ByteBuffer.isAligned() with the above two methods in the following way: >> >> instead of: >> >> ByteBuffer bb = ByteBuffer.allocateDirectAligned(capacity) >> >> you could do: >> >> int pageSize = ... >> ByteBuffer bb = ByteBuffer.allocateDirect(capacity + pageSize - >> 1).alignedSlice(pageSize); >> >> And instead of: >> >> bb.isAligned() >> >> you could do: >> >> bb.alignmentOffset(pageSize) == 0 >> >> >> >> The only thing that needs to be added is a public API to return the pageSize (i.e. >Bits.pageSize()). >> >> >> What do you think? >> >> Regards, Peter >> >> On 11/03/2016 12:34 AM, Lu, Yingqi wrote: >> Hi All, >> >> Our most recent DirectIO patch is available at >> http://cr.openjdk.java.net/~igraves/8164900-3/ >> >> In this version, we made following changes: >> >> 1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to the >FileChannelImpl class. >> >> 2. Provided a way for user to allocate a page aligned direct ByteBuffer. >> 1) Added a constructor DirectByteBuffer(int cap, boolean direct) to allocate a >direct ByteBuffer that is aligned to the page size. >> 2) Added Util.getTemporaryAlignedDirectBuffer(int size) >> 3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is aligned >before doing native IO with it. >> >> 3. Moved all the alignment check from C code to Java code (mainly >FileChannelImpl and IOUtil.java). >> >> 4. Made the DirectIO functionality consistent between read and write >operations. With current version of the patch, user would be responsible for the >alignment with file offset and IO size. >> >> 5. Made the API for DirectIO more extensible to all the supporting platforms. >> 1) Unix OS specific code are done through UnixConstants.java.template and >FileChannelImpl.c. >> 2) Coded and tested for Linux and OS X (OS X testing is done through >VirtualBox with OS X VM on top of Linux OS). >> 3) Coded for Solaris. We do not have environment to test it so that we >commented the changes out. >> >> 6. We added 4 test cases following the existing non-direct IO examples. >> >> 7. We did jtreg test for the entire nio package and no errors were found due to >our changes. >> >> Please let us know your feedback and comment. Thank you very much for your >time and consideration! >> >> Thanks, >> Lucy >> >> -----Original Message----- >> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >> Sent: Monday, October 17, 2016 7:59 AM >> To: Lu, Yingqi >> Cc: nio-dev at openjdk.java.net; Kaczmarek, Eric >> ; Kharbas, Kishor >> Subject: Re: Proposal for adding O_DIRECT support into JDK 9 >> >> On 12/10/2016 17:41, Lu, Yingqi wrote: >> >> : >> >> You are correct about the "extra copy" with DirectIO. Will it be >> acceptable if we add a function "Util.getAlignedTemporaryDirectBuffer" >> and use that for the DirectIO operation? In this case, I think we >> should be able to avoid the additional copy? >> Yes, that should work but it still lacks a way for the user to get an >> aligned buffer and so you will always be copying in and out of an >> aligned buffer. The other thing is the sizing of the I/O operation >> where I think you will also need a way to expose the multiple (or block size) to >the user. >> >> -Alan. From david.lloyd at redhat.com Fri Nov 4 18:32:01 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 4 Nov 2016 13:32:01 -0500 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <36CE90D5-B86C-4E0A-A2BD-AC812D4262D1@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513500C@ORSMSX113.amr.corp.intel.com> <542288c7-b0b1-5b41-4c45-d07730e3cddf@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5139A26@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513CE96@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA51447D9@ORSMSX113.amr.corp.intel.com> <006c75c4-1404-d66b-737d-e07ea2b493fd@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> <4d4c5ae5-06f9-40a9-f29c-56d0a44e671d@! ! gmail.com> <9ACD5B67AAC5594CB6268234CF29CF9AA516782E@ORSMSX113.amr.corp.intel.com> <36CE90D5-B86C-4E0A-A2BD-AC812D4262D1@oracle.com> Message-ID: <82b85038-36a9-bd93-7131-2d9a2607e60a@redhat.com> I still feel like it could be a problem to have just one simple getPageSize method, given how many CPU architectures and OSes support multiple page sizes. On 11/04/2016 11:58 AM, Paul Sandoz wrote: > Hi Lucy, > > I am struggling to find an entirely satisfactory location to place a method such as getPageSize, but java.lang.Runtime seems less worse than other places :-) > > Paul. > >> On 3 Nov 2016, at 12:49, Lu, Yingqi wrote: >> >> Hi Paul and Peter, >> >> Thank you very much for pointing this out. We did not know about it J >> >> We will modify the patch accordingly and will send it here for review. >> >> Thanks, >> Lucy >> >> From: Paul Sandoz [mailto:paul.sandoz at oracle.com] >> Sent: Thursday, November 03, 2016 12:46 PM >> To: Peter Levart >> Cc: Lu, Yingqi ; Alan Bateman ; nio-dev at openjdk.java.net; Kaczmarek, Eric ; core-libs-dev at openjdk.java.net; Kharbas, Kishor >> Subject: Re: Proposal for adding O_DIRECT support into JDK 9 >> >> Hi Peter, >> >> Thanks for pointing this out, you beat me to it :-) >> >> Note that the alignment for a unit size corresponding to page size will only be stable for direct byte buffers, since for heap byte buffers the GC can move the underlying byte array and the alignment properties may change. >> >> Paul. >> >> On 3 Nov 2016, at 12:38, Peter Levart wrote: >> >> Hi Lucy, >> >> Did you know that in JDK 9 the following two methods have been added to java.nio.ByteBuffer: >> >> /** @return The indexed byte's memory address modulus the unit size >> */ >> public final int alignmentOffset(int index, int unitSize); >> >> /** @return new byte buffer whose content is a shared and aligned subsequence of this buffer's content >> */ >> public final ByteBuffer alignedSlice(int unitSize); >> >> >> So you could express your proposed methods ByteBuffer.allocateDirectAligned() and ByteBuffer.isAligned() with the above two methods in the following way: >> >> instead of: >> >> ByteBuffer bb = ByteBuffer.allocateDirectAligned(capacity) >> >> you could do: >> >> int pageSize = ... >> ByteBuffer bb = ByteBuffer.allocateDirect(capacity + pageSize - 1).alignedSlice(pageSize); >> >> And instead of: >> >> bb.isAligned() >> >> you could do: >> >> bb.alignmentOffset(pageSize) == 0 >> >> >> >> The only thing that needs to be added is a public API to return the pageSize (i.e. Bits.pageSize()). >> >> >> What do you think? >> >> Regards, Peter >> >> On 11/03/2016 12:34 AM, Lu, Yingqi wrote: >> Hi All, >> >> Our most recent DirectIO patch is available at http://cr.openjdk.java.net/~igraves/8164900-3/ >> >> In this version, we made following changes: >> >> 1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to the FileChannelImpl class. >> >> 2. Provided a way for user to allocate a page aligned direct ByteBuffer. >> 1) Added a constructor DirectByteBuffer(int cap, boolean direct) to allocate a direct ByteBuffer that is aligned to the page size. >> 2) Added Util.getTemporaryAlignedDirectBuffer(int size) >> 3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is aligned before doing native IO with it. >> >> 3. Moved all the alignment check from C code to Java code (mainly FileChannelImpl and IOUtil.java). >> >> 4. Made the DirectIO functionality consistent between read and write operations. With current version of the patch, user would be responsible for the alignment with file offset and IO size. >> >> 5. Made the API for DirectIO more extensible to all the supporting platforms. >> 1) Unix OS specific code are done through UnixConstants.java.template and FileChannelImpl.c. >> 2) Coded and tested for Linux and OS X (OS X testing is done through VirtualBox with OS X VM on top of Linux OS). >> 3) Coded for Solaris. We do not have environment to test it so that we commented the changes out. >> >> 6. We added 4 test cases following the existing non-direct IO examples. >> >> 7. We did jtreg test for the entire nio package and no errors were found due to our changes. >> >> Please let us know your feedback and comment. Thank you very much for your time and consideration! >> >> Thanks, >> Lucy >> >> -----Original Message----- >> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >> Sent: Monday, October 17, 2016 7:59 AM >> To: Lu, Yingqi >> Cc: nio-dev at openjdk.java.net; Kaczmarek, Eric ; >> Kharbas, Kishor >> Subject: Re: Proposal for adding O_DIRECT support into JDK 9 >> >> On 12/10/2016 17:41, Lu, Yingqi wrote: >> >> : >> >> You are correct about the "extra copy" with DirectIO. Will it be acceptable if we >> add a function "Util.getAlignedTemporaryDirectBuffer" and use that for the >> DirectIO operation? In this case, I think we should be able to avoid the additional >> copy? >> Yes, that should work but it still lacks a way for the user to get an aligned buffer >> and so you will always be copying in and out of an aligned buffer. The other thing >> is the sizing of the I/O operation where I think you will also need a way to expose >> the multiple (or block size) to the user. >> >> -Alan. > -- - DML From Alan.Burlison at oracle.com Sat Nov 5 08:13:18 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Sat, 5 Nov 2016 08:13:18 +0000 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <82b85038-36a9-bd93-7131-2d9a2607e60a@redhat.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <542288c7-b0b1-5b41-4c45-d07730e3cddf@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5139A26@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513CE96@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA51447D9@ORSMSX113.amr.corp.intel.com> <006c75c4-1404-d66b-737d-e07ea2b493fd@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> <4d4c5ae5-06f9-40a9-f29c-56d0a44e671d@! ! gmail.com> <9ACD5B67AAC5594CB6268234CF29CF9AA516782E@ORSMSX113.amr.corp.intel.com> <36CE90D5-B86C-4E0A-A2BD-AC812D4262D1@oracle.com> <82b85038-36a9-bd93-7131-2d9a2607e60a@redhat.com> Message-ID: <706b2cc6-6fb1-a006-5549-bea484edb5fb@oracle.com> On 04/11/2016 18:32, David M. Lloyd wrote: > I still feel like it could be a problem to have just one simple > getPageSize method, given how many CPU architectures and OSes support > multiple page sizes. Yes. $ pagesize -a 8192 65536 4194304 268435456 2147483648 -- Alan Burlison -- From david.holmes at oracle.com Sat Nov 5 17:42:15 2016 From: david.holmes at oracle.com (David Holmes) Date: Sun, 6 Nov 2016 03:42:15 +1000 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <36CE90D5-B86C-4E0A-A2BD-AC812D4262D1@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513500C@ORSMSX113.amr.corp.intel.com> <542288c7-b0b1-5b41-4c45-d07730e3cddf@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5139A26@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513CE96@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA51447D9@ORSMSX113.amr.corp.intel.com> <006c75c4-1404-d66b-737d-e07ea2b493fd@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> <4d4c5ae5-06f9-40a9-f29c-56d0a44e671d@! ! gmail.com> <9ACD5B67AAC5594CB6268234CF29CF9AA516782E@ORSMSX113.amr.corp.intel.com> <36CE90D5-B86C-4E0A-A2BD-AC812D4262D1@oracle.com> Message-ID: <66b40d54-fcf7-4258-6499-082742727e66@oracle.com> Hi Paul, On 5/11/2016 2:58 AM, Paul Sandoz wrote: > Hi Lucy, > > I am struggling to find an entirely satisfactory location to place a method such as getPageSize, but java.lang.Runtime seems less worse than other places :-) This does not seem an appropriate method to expose in this form at the java.lang.Runtime level. If we want a public, platform agnostic API for exposing virtual memory page sizes (plural) then we should design such an API IMHO. David > Paul. > >> On 3 Nov 2016, at 12:49, Lu, Yingqi wrote: >> >> Hi Paul and Peter, >> >> Thank you very much for pointing this out. We did not know about it J >> >> We will modify the patch accordingly and will send it here for review. >> >> Thanks, >> Lucy >> >> From: Paul Sandoz [mailto:paul.sandoz at oracle.com] >> Sent: Thursday, November 03, 2016 12:46 PM >> To: Peter Levart >> Cc: Lu, Yingqi ; Alan Bateman ; nio-dev at openjdk.java.net; Kaczmarek, Eric ; core-libs-dev at openjdk.java.net; Kharbas, Kishor >> Subject: Re: Proposal for adding O_DIRECT support into JDK 9 >> >> Hi Peter, >> >> Thanks for pointing this out, you beat me to it :-) >> >> Note that the alignment for a unit size corresponding to page size will only be stable for direct byte buffers, since for heap byte buffers the GC can move the underlying byte array and the alignment properties may change. >> >> Paul. >> >> On 3 Nov 2016, at 12:38, Peter Levart wrote: >> >> Hi Lucy, >> >> Did you know that in JDK 9 the following two methods have been added to java.nio.ByteBuffer: >> >> /** @return The indexed byte's memory address modulus the unit size >> */ >> public final int alignmentOffset(int index, int unitSize); >> >> /** @return new byte buffer whose content is a shared and aligned subsequence of this buffer's content >> */ >> public final ByteBuffer alignedSlice(int unitSize); >> >> >> So you could express your proposed methods ByteBuffer.allocateDirectAligned() and ByteBuffer.isAligned() with the above two methods in the following way: >> >> instead of: >> >> ByteBuffer bb = ByteBuffer.allocateDirectAligned(capacity) >> >> you could do: >> >> int pageSize = ... >> ByteBuffer bb = ByteBuffer.allocateDirect(capacity + pageSize - 1).alignedSlice(pageSize); >> >> And instead of: >> >> bb.isAligned() >> >> you could do: >> >> bb.alignmentOffset(pageSize) == 0 >> >> >> >> The only thing that needs to be added is a public API to return the pageSize (i.e. Bits.pageSize()). >> >> >> What do you think? >> >> Regards, Peter >> >> On 11/03/2016 12:34 AM, Lu, Yingqi wrote: >> Hi All, >> >> Our most recent DirectIO patch is available at http://cr.openjdk.java.net/~igraves/8164900-3/ >> >> In this version, we made following changes: >> >> 1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to the FileChannelImpl class. >> >> 2. Provided a way for user to allocate a page aligned direct ByteBuffer. >> 1) Added a constructor DirectByteBuffer(int cap, boolean direct) to allocate a direct ByteBuffer that is aligned to the page size. >> 2) Added Util.getTemporaryAlignedDirectBuffer(int size) >> 3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is aligned before doing native IO with it. >> >> 3. Moved all the alignment check from C code to Java code (mainly FileChannelImpl and IOUtil.java). >> >> 4. Made the DirectIO functionality consistent between read and write operations. With current version of the patch, user would be responsible for the alignment with file offset and IO size. >> >> 5. Made the API for DirectIO more extensible to all the supporting platforms. >> 1) Unix OS specific code are done through UnixConstants.java.template and FileChannelImpl.c. >> 2) Coded and tested for Linux and OS X (OS X testing is done through VirtualBox with OS X VM on top of Linux OS). >> 3) Coded for Solaris. We do not have environment to test it so that we commented the changes out. >> >> 6. We added 4 test cases following the existing non-direct IO examples. >> >> 7. We did jtreg test for the entire nio package and no errors were found due to our changes. >> >> Please let us know your feedback and comment. Thank you very much for your time and consideration! >> >> Thanks, >> Lucy >> >> -----Original Message----- >> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >> Sent: Monday, October 17, 2016 7:59 AM >> To: Lu, Yingqi >> Cc: nio-dev at openjdk.java.net; Kaczmarek, Eric ; >> Kharbas, Kishor >> Subject: Re: Proposal for adding O_DIRECT support into JDK 9 >> >> On 12/10/2016 17:41, Lu, Yingqi wrote: >> >> : >> >> You are correct about the "extra copy" with DirectIO. Will it be acceptable if we >> add a function "Util.getAlignedTemporaryDirectBuffer" and use that for the >> DirectIO operation? In this case, I think we should be able to avoid the additional >> copy? >> Yes, that should work but it still lacks a way for the user to get an aligned buffer >> and so you will always be copying in and out of an aligned buffer. The other thing >> is the sizing of the I/O operation where I think you will also need a way to expose >> the multiple (or block size) to the user. >> >> -Alan. > From yingqi.lu at intel.com Sat Nov 5 18:33:12 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Sat, 5 Nov 2016 18:33:12 +0000 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <706b2cc6-6fb1-a006-5549-bea484edb5fb@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <542288c7-b0b1-5b41-4c45-d07730e3cddf@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5139A26@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513CE96@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA51447D9@ORSMSX113.amr.corp.intel.com> <006c75c4-1404-d66b-737d-e07ea2b493fd@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> <4d4c5ae5-06f9-40a9-f29c-56d0a44e671d@! ! gmail.com> <9ACD5B67AAC5594CB6268234CF29CF9AA516782E@ORSMSX113.amr.corp.intel.com> <36CE90D5-B86C-4E0A-A2BD-AC812D4262D1@oracle.com> <82b85038-36a9-bd93-7131-2d9a2607e60a@redhat.com> <706b2cc6-6fb1-a006-5549-bea484edb5fb@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA51697D2@ORSMSX113.amr.corp.intel.com> Hi Alan and David, Thank you for your email. I totally agree that OS kernel supports multiple page sizes. For example, my Linux box supports both 4K and 2M pages. Currently, our getAlignment() function inside FileChannel/FileChannelImpl calls an existing function sun.nio.ch.Util.pageSize() which eventually calls unsafe.pageSize(). I use a small Java program to test unsafe.pageSize() with and without the flag " -XX:+UseLargePages" on my Linux box, both testing return 4096. To make DirectIO work, IO size and file position need to be aligned to the disk block size. Native memory page size (in our case, 4096) is always a multiple or equal of disk block size. That is why we try to use this existing JDK function (sun.nio.ch.Util.pageSize()) for the alignment value. To make it simpler, we use getAlignment as the function name and put it inside the FileChannel/FileChannelImpl. Please let us know if you have any questions, comments and concerns. Thank you very much for your consideration! Thanks, Lucy >-----Original Message----- >From: Alan Burlison [mailto:Alan.Burlison at oracle.com] >Sent: Saturday, November 05, 2016 1:13 AM >To: David M. Lloyd ; Paul Sandoz >; Lu, Yingqi >Cc: nio-dev at openjdk.java.net; Kaczmarek, Eric ; >core-libs-dev at openjdk.java.net; Kharbas, Kishor >Subject: Re: Proposal for adding O_DIRECT support into JDK 9 > >On 04/11/2016 18:32, David M. Lloyd wrote: > >> I still feel like it could be a problem to have just one simple >> getPageSize method, given how many CPU architectures and OSes support >> multiple page sizes. > >Yes. > >$ pagesize -a >8192 >65536 >4194304 >268435456 >2147483648 > >-- >Alan Burlison >-- From thomas.stuefe at gmail.com Sun Nov 6 11:21:37 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sun, 6 Nov 2016 12:21:37 +0100 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <66b40d54-fcf7-4258-6499-082742727e66@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513500C@ORSMSX113.amr.corp.intel.com> <542288c7-b0b1-5b41-4c45-d07730e3cddf@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5139A26@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513CE96@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA51447D9@ORSMSX113.amr.corp.intel.com> <006c75c4-1404-d66b-737d-e07ea2b493fd@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA516782E@ORSMSX113.amr.corp.intel.com> <36CE90D5-B86C-4E0A-A2BD-AC812D4262D1@oracle.com> <66b40d54-fcf7-4258-6499-082742727e66@oracle.com> Message-ID: On Sat, Nov 5, 2016 at 6:42 PM, David Holmes wrote: > Hi Paul, > > On 5/11/2016 2:58 AM, Paul Sandoz wrote: > >> Hi Lucy, >> >> I am struggling to find an entirely satisfactory location to place a >> method such as getPageSize, but java.lang.Runtime seems less worse than >> other places :-) >> > > This does not seem an appropriate method to expose in this form at the > java.lang.Runtime level. If we want a public, platform agnostic API for > exposing virtual memory page sizes (plural) then we should design such an > API IMHO. > > I absolutely agree. Different memory regions can have different page sizes following different rules. The fact that in hotspot coding os::vm_page_size() is used in many places as "the pagesize" gave us lots of headaches in the AIX port, where we can have up to four different page sizes for heap, stack, text and different instances of shared memory. I consider the fact that unsafe.pageSize() exists sloppy API design. Even on Linux we can have two page sizes within one process, or? If we really need a generic "pageSize" API this should be designed to cover a reasonable large array of OS breeds. IMHO a good generic API should allow me to query, given a memory range, its page-size-composition, because within a region of memory one may have different page sizes. Thomas David > > > Paul. >> >> On 3 Nov 2016, at 12:49, Lu, Yingqi wrote: >>> >>> Hi Paul and Peter, >>> >>> Thank you very much for pointing this out. We did not know about it J >>> >>> We will modify the patch accordingly and will send it here for review. >>> >>> Thanks, >>> Lucy >>> >>> From: Paul Sandoz [mailto:paul.sandoz at oracle.com] >>> Sent: Thursday, November 03, 2016 12:46 PM >>> To: Peter Levart >>> Cc: Lu, Yingqi ; Alan Bateman < >>> Alan.Bateman at oracle.com>; nio-dev at openjdk.java.net; Kaczmarek, Eric < >>> eric.kaczmarek at intel.com>; core-libs-dev at openjdk.java.net; Kharbas, >>> Kishor >>> Subject: Re: Proposal for adding O_DIRECT support into JDK 9 >>> >>> Hi Peter, >>> >>> Thanks for pointing this out, you beat me to it :-) >>> >>> Note that the alignment for a unit size corresponding to page size will >>> only be stable for direct byte buffers, since for heap byte buffers the GC >>> can move the underlying byte array and the alignment properties may change. >>> >>> Paul. >>> >>> On 3 Nov 2016, at 12:38, Peter Levart wrote: >>> >>> Hi Lucy, >>> >>> Did you know that in JDK 9 the following two methods have been added to >>> java.nio.ByteBuffer: >>> >>> /** @return The indexed byte's memory address modulus the unit size >>> */ >>> public final int alignmentOffset(int index, int unitSize); >>> >>> /** @return new byte buffer whose content is a shared and aligned >>> subsequence of this buffer's content >>> */ >>> public final ByteBuffer alignedSlice(int unitSize); >>> >>> >>> So you could express your proposed methods ByteBuffer.allocateDirectAligned() >>> and ByteBuffer.isAligned() with the above two methods in the following way: >>> >>> instead of: >>> >>> ByteBuffer bb = ByteBuffer.allocateDirectAligned(capacity) >>> >>> you could do: >>> >>> int pageSize = ... >>> ByteBuffer bb = ByteBuffer.allocateDirect(capacity + pageSize - >>> 1).alignedSlice(pageSize); >>> >>> And instead of: >>> >>> bb.isAligned() >>> >>> you could do: >>> >>> bb.alignmentOffset(pageSize) == 0 >>> >>> >>> >>> The only thing that needs to be added is a public API to return the >>> pageSize (i.e. Bits.pageSize()). >>> >>> >>> What do you think? >>> >>> Regards, Peter >>> >>> On 11/03/2016 12:34 AM, Lu, Yingqi wrote: >>> Hi All, >>> >>> Our most recent DirectIO patch is available at >>> http://cr.openjdk.java.net/~igraves/8164900-3/ >>> >>> In this version, we made following changes: >>> >>> 1. Removed the flag "direct" from FileDescriptor class. Instead, moved >>> it to the FileChannelImpl class. >>> >>> 2. Provided a way for user to allocate a page aligned direct ByteBuffer. >>> 1) Added a constructor DirectByteBuffer(int cap, boolean direct) to >>> allocate a direct ByteBuffer that is aligned to the page size. >>> 2) Added Util.getTemporaryAlignedDirectBuffer(int size) >>> 3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer >>> is aligned before doing native IO with it. >>> >>> 3. Moved all the alignment check from C code to Java code (mainly >>> FileChannelImpl and IOUtil.java). >>> >>> 4. Made the DirectIO functionality consistent between read and write >>> operations. With current version of the patch, user would be responsible >>> for the alignment with file offset and IO size. >>> >>> 5. Made the API for DirectIO more extensible to all the supporting >>> platforms. >>> 1) Unix OS specific code are done through >>> UnixConstants.java.template and FileChannelImpl.c. >>> 2) Coded and tested for Linux and OS X (OS X testing is done through >>> VirtualBox with OS X VM on top of Linux OS). >>> 3) Coded for Solaris. We do not have environment to test it so that >>> we commented the changes out. >>> >>> 6. We added 4 test cases following the existing non-direct IO examples. >>> >>> 7. We did jtreg test for the entire nio package and no errors were found >>> due to our changes. >>> >>> Please let us know your feedback and comment. Thank you very much for >>> your time and consideration! >>> >>> Thanks, >>> Lucy >>> >>> -----Original Message----- >>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >>> Sent: Monday, October 17, 2016 7:59 AM >>> To: Lu, Yingqi >>> Cc: nio-dev at openjdk.java.net; Kaczmarek, Eric >> >; >>> Kharbas, Kishor >>> Subject: Re: Proposal for adding O_DIRECT support into JDK 9 >>> >>> On 12/10/2016 17:41, Lu, Yingqi wrote: >>> >>> : >>> >>> You are correct about the "extra copy" with DirectIO. Will it be >>> acceptable if we >>> add a function "Util.getAlignedTemporaryDirectBuffer" and use that for >>> the >>> DirectIO operation? In this case, I think we should be able to avoid the >>> additional >>> copy? >>> Yes, that should work but it still lacks a way for the user to get an >>> aligned buffer >>> and so you will always be copying in and out of an aligned buffer. The >>> other thing >>> is the sizing of the I/O operation where I think you will also need a >>> way to expose >>> the multiple (or block size) to the user. >>> >>> -Alan. >>> >> >> From yingqi.lu at intel.com Sun Nov 6 15:51:14 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Sun, 6 Nov 2016 15:51:14 +0000 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513500C@ORSMSX113.amr.corp.intel.com> <542288c7-b0b1-5b41-4c45-d07730e3cddf@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5139A26@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513CE96@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA51447D9@ORSMSX113.amr.corp.intel.com> <006c75c4-1404-d66b-737d-e07ea2b493fd@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA516782E@ORSMSX113.amr.corp.intel.com> <36CE90D5-B86C-4E0A-A2BD-AC812D4262D1@oracle.com> <66b40d54-fcf7-4258-6499-082742727e66@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA5169EFD@ORSMSX113.amr.corp.intel.com> Another approach might be use ioctl to get the block size and use that as the alignment value. I think ioctl is available on UNIX based OSes (please chime in if I miss any OS here) and has a similar call for Windows named DeviceIoControl. The request code of ioctl is different from OS to OS, but we could address that in the native code. What do you all think on this? Thanks, Lucy From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Sunday, November 06, 2016 3:22 AM To: David Holmes Cc: Paul Sandoz ; Lu, Yingqi ; nio-dev at openjdk.java.net; Kaczmarek, Eric ; core-libs-dev at openjdk.java.net; Kharbas, Kishor Subject: Re: Proposal for adding O_DIRECT support into JDK 9 On Sat, Nov 5, 2016 at 6:42 PM, David Holmes > wrote: Hi Paul, On 5/11/2016 2:58 AM, Paul Sandoz wrote: Hi Lucy, I am struggling to find an entirely satisfactory location to place a method such as getPageSize, but java.lang.Runtime seems less worse than other places :-) This does not seem an appropriate method to expose in this form at the java.lang.Runtime level. If we want a public, platform agnostic API for exposing virtual memory page sizes (plural) then we should design such an API IMHO. I absolutely agree. Different memory regions can have different page sizes following different rules. The fact that in hotspot coding os::vm_page_size() is used in many places as "the pagesize" gave us lots of headaches in the AIX port, where we can have up to four different page sizes for heap, stack, text and different instances of shared memory. I consider the fact that unsafe.pageSize() exists sloppy API design. Even on Linux we can have two page sizes within one process, or? If we really need a generic "pageSize" API this should be designed to cover a reasonable large array of OS breeds. IMHO a good generic API should allow me to query, given a memory range, its page-size-composition, because within a region of memory one may have different page sizes. Thomas David Paul. On 3 Nov 2016, at 12:49, Lu, Yingqi > wrote: Hi Paul and Peter, Thank you very much for pointing this out. We did not know about it J We will modify the patch accordingly and will send it here for review. Thanks, Lucy From: Paul Sandoz [mailto:paul.sandoz at oracle.com] Sent: Thursday, November 03, 2016 12:46 PM To: Peter Levart > Cc: Lu, Yingqi >; Alan Bateman >; nio-dev at openjdk.java.net; Kaczmarek, Eric >; core-libs-dev at openjdk.java.net; Kharbas, Kishor > Subject: Re: Proposal for adding O_DIRECT support into JDK 9 Hi Peter, Thanks for pointing this out, you beat me to it :-) Note that the alignment for a unit size corresponding to page size will only be stable for direct byte buffers, since for heap byte buffers the GC can move the underlying byte array and the alignment properties may change. Paul. On 3 Nov 2016, at 12:38, Peter Levart > wrote: Hi Lucy, Did you know that in JDK 9 the following two methods have been added to java.nio.ByteBuffer: /** @return The indexed byte's memory address modulus the unit size */ public final int alignmentOffset(int index, int unitSize); /** @return new byte buffer whose content is a shared and aligned subsequence of this buffer's content */ public final ByteBuffer alignedSlice(int unitSize); So you could express your proposed methods ByteBuffer.allocateDirectAligned() and ByteBuffer.isAligned() with the above two methods in the following way: instead of: ByteBuffer bb = ByteBuffer.allocateDirectAligned(capacity) you could do: int pageSize = ... ByteBuffer bb = ByteBuffer.allocateDirect(capacity + pageSize - 1).alignedSlice(pageSize); And instead of: bb.isAligned() you could do: bb.alignmentOffset(pageSize) == 0 The only thing that needs to be added is a public API to return the pageSize (i.e. Bits.pageSize()). What do you think? Regards, Peter On 11/03/2016 12:34 AM, Lu, Yingqi wrote: Hi All, Our most recent DirectIO patch is available at http://cr.openjdk.java.net/~igraves/8164900-3/ In this version, we made following changes: 1. Removed the flag "direct" from FileDescriptor class. Instead, moved it to the FileChannelImpl class. 2. Provided a way for user to allocate a page aligned direct ByteBuffer. 1) Added a constructor DirectByteBuffer(int cap, boolean direct) to allocate a direct ByteBuffer that is aligned to the page size. 2) Added Util.getTemporaryAlignedDirectBuffer(int size) 3) Added DirectByteBuffer.isAligned(int pos) to check if the buffer is aligned before doing native IO with it. 3. Moved all the alignment check from C code to Java code (mainly FileChannelImpl and IOUtil.java). 4. Made the DirectIO functionality consistent between read and write operations. With current version of the patch, user would be responsible for the alignment with file offset and IO size. 5. Made the API for DirectIO more extensible to all the supporting platforms. 1) Unix OS specific code are done through UnixConstants.java.template and FileChannelImpl.c. 2) Coded and tested for Linux and OS X (OS X testing is done through VirtualBox with OS X VM on top of Linux OS). 3) Coded for Solaris. We do not have environment to test it so that we commented the changes out. 6. We added 4 test cases following the existing non-direct IO examples. 7. We did jtreg test for the entire nio package and no errors were found due to our changes. Please let us know your feedback and comment. Thank you very much for your time and consideration! Thanks, Lucy -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Monday, October 17, 2016 7:59 AM To: Lu, Yingqi > Cc: nio-dev at openjdk.java.net; Kaczmarek, Eric >; Kharbas, Kishor > Subject: Re: Proposal for adding O_DIRECT support into JDK 9 On 12/10/2016 17:41, Lu, Yingqi wrote: : You are correct about the "extra copy" with DirectIO. Will it be acceptable if we add a function "Util.getAlignedTemporaryDirectBuffer" and use that for the DirectIO operation? In this case, I think we should be able to avoid the additional copy? Yes, that should work but it still lacks a way for the user to get an aligned buffer and so you will always be copying in and out of an aligned buffer. The other thing is the sizing of the I/O operation where I think you will also need a way to expose the multiple (or block size) to the user. -Alan. From Alan.Bateman at oracle.com Sun Nov 6 17:04:22 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 6 Nov 2016 17:04:22 +0000 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AA5169EFD@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5139A26@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513CE96@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA51447D9@ORSMSX113.amr.corp.intel.com> <006c75c4-1404-d66b-737d-e07ea2b493fd@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA516782E@ORSMSX113.amr.corp.intel.com> <36CE90D5-B86C-4E0A-A2BD-AC812D4262D1@oracle.com> <66b40d54-fcf7-4258-6499-082742727e66@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5169EFD@ORSMSX113.amr.corp.intel.com> Message-ID: <482dd41a-89c8-fe56-c9ab-e662a2f957e8@oracle.com> On 06/11/2016 15:51, Lu, Yingqi wrote: > Another approach might be use ioctl to get the block size and use that > as the alignment value. I think ioctl is available on UNIX based OSes > (please chime in if I miss any OS here) and has a similar call for > Windows named DeviceIoControl. The request code of ioctl is different > from OS to OS, but we could address that in the native code. > > A possible approach (I think I mentioned this in one of the early mails) is to have FileStore expose the block size that can be use to align and size the buffer. -Alan From yingqi.lu at intel.com Sun Nov 6 17:36:57 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Sun, 6 Nov 2016 17:36:57 +0000 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <482dd41a-89c8-fe56-c9ab-e662a2f957e8@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5139A26@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513CE96@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA51447D9@ORSMSX113.amr.corp.intel.com> <006c75c4-1404-d66b-737d-e07ea2b493fd@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA516782E@ORSMSX113.amr.corp.intel.com> <36CE90D5-B86C-4E0A-A2BD-AC812D4262D1@oracle.com> <66b40d54-fcf7-4258-6499-082742727e66@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5169EFD@ORSMSX113.amr.corp.intel.com>, <482dd41a-89c8-fe56-c9ab-e662a2f957e8@oracle.com> Message-ID: <77D7708E-07FE-4E39-BF7A-30799EB8CEA7@intel.com> Hi Alan, Thank you very much for your suggestion. FileStore is a better home for the alignment value. We will use It in our next version of the patch and update here for review soon. Thanks, Lucy Sent from my iPhone On Nov 6, 2016, at 9:04 AM, Alan Bateman > wrote: On 06/11/2016 15:51, Lu, Yingqi wrote: Another approach might be use ioctl to get the block size and use that as the alignment value. I think ioctl is available on UNIX based OSes (please chime in if I miss any OS here) and has a similar call for Windows named DeviceIoControl. The request code of ioctl is different from OS to OS, but we could address that in the native code. A possible approach (I think I mentioned this in one of the early mails) is to have FileStore expose the block size that can be use to align and size the buffer. -Alan From sha.jiang at oracle.com Mon Nov 7 02:37:34 2016 From: sha.jiang at oracle.com (John Jiang) Date: Mon, 7 Nov 2016 10:37:34 +0800 Subject: RFR[9] JDK-8158916: ProblemList.txt update for com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java Message-ID: <59dc7e57-3d05-6395-abdc-a0677b487fbb@oracle.com> Hi, com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java is associated to 8141370 in ProblemList, though issue JDK-8141370 has been resolved. In fact, the fix for JDK-8141370 extracted some codes from com/sun/jndi/ldap/LdapTimeoutTest.java to create com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java, and put the new test to ProblemList. It would be better to remove this item from ProblemList. If com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java still fails intermittently, we can put it back to ProblemList with the exact failure logs. Issue: https://bugs.openjdk.java.net/browse/JDK-8158916 Webrev: http://cr.openjdk.java.net/~jjiang/8158916/webrev.00/ Best regards, John Jiang From thomas.stuefe at gmail.com Mon Nov 7 08:36:54 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 7 Nov 2016 09:36:54 +0100 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <482dd41a-89c8-fe56-c9ab-e662a2f957e8@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5139A26@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513CE96@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA51447D9@ORSMSX113.amr.corp.intel.com> <006c75c4-1404-d66b-737d-e07ea2b493fd@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA516782E@ORSMSX113.amr.corp.intel.com> <36CE90D5-B86C-4E0A-A2BD-AC812D4262D1@oracle.com> <66b40d54-fcf7-4258-6499-082742727e66@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5169EFD@ORSMSX113.amr.corp.intel.com> <482dd41a-89c8-fe56-c9ab-e662a2f957e8@oracle.com> Message-ID: On Sun, Nov 6, 2016 at 6:04 PM, Alan Bateman wrote: > On 06/11/2016 15:51, Lu, Yingqi wrote: > > Another approach might be use ioctl to get the block size and use that as > the alignment value. I think ioctl is available on UNIX based OSes (please > chime in if I miss any OS here) and has a similar call for Windows named > DeviceIoControl. The request code of ioctl is different from OS to OS, but > we could address that in the native code. > > A possible approach (I think I mentioned this in one of the early mails) > is to have FileStore expose the block size that can be use to align and > size the buffer. > > -Alan > And if an OS or a file system driver does not provide information about block size, one still could poll. E.g. on Linux, attempt to read() at ever increasing alignments until one does not get EINVAL anymore. Thomas From ramanand.patil at oracle.com Mon Nov 7 10:43:11 2016 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Mon, 7 Nov 2016 02:43:11 -0800 (PST) Subject: RFR: 8169191: (tz) Support tzdata2016i Message-ID: Hi all, Please review the latest TZDATA integration (tzdata2016i) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8169191 Webrev: http://cr.openjdk.java.net/~rpatil/8169191/webrev.00/ All the TimeZone related tests are passed after integration. Regards, Ramanand. From rahul.v.raghavan at oracle.com Mon Nov 7 11:21:10 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Mon, 7 Nov 2016 03:21:10 -0800 (PST) Subject: RFR: 8159035: com/sun/crypto/provider/Cipher/CTS/CTSMode.java test crashed due to unhandled case of cipher length value as 0 Message-ID: <70b2c1c2-7d04-47e8-8330-5e65e13b8425@default> Hi, Request review for closed bug fix - JDK-8159035. - http://cr.openjdk.java.net/~rraghavan/8159035/webrev.03/ Notes: 1. - https://bugs.openjdk.java.net/browse/JDK-8159035 - (com/sun/crypto/provider/Cipher/CTS/CTSMode.java test crashed due to unhandled case of cipher length value as 0) Related issues - https://bugs.openjdk.java.net/browse/JDK-8076112 - 'Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics' https://bugs.openjdk.java.net/browse/JDK-8167595 - 'AArch64: SEGV in stub code cipherBlockChaining_decryptAESCrypt' 2. Found root cause of the reported jvm crash for sparc - Crash happens at 'generate_cipherBlockChaining_decryptAESCrypt_Parallel()' [stubGenerator_sparc.cpp] The implDecrypt can be called from CipherBlockChaining.decrypt, even with cipherLen as 0. But the same condition is not handled in the stub code and results in crash. (the same applicable for implEncrypt) 3. Though the reported case was for sparc, understood that same issue is present for x86, aarch64 (JDK-8167595). So in above fix proposed in Java wrapper method side [CipherBlockChaining.java]. 4. The same issue in aarch64 (JDK-8167595) was fixed earlier in stubGenerator_aarch64. So once above is approved, I will initiate new hotspot webrev to revert this earlier 8167595 change. 5. Checked for any other similar cases with HotSpotIntrinsicCandidate support and found two cases as proposed in - implCrypt() / CounterMode.java - implEncodeISOArray() / ISO_8859_1.java Confirmed no Issues for with jprt testing (-testset hotspot, core) Thanks, Rahul From daniel.fuchs at oracle.com Mon Nov 7 11:21:30 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 7 Nov 2016 11:21:30 +0000 Subject: RFR[9] JDK-8158916: ProblemList.txt update for com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java In-Reply-To: <59dc7e57-3d05-6395-abdc-a0677b487fbb@oracle.com> References: <59dc7e57-3d05-6395-abdc-a0677b487fbb@oracle.com> Message-ID: <0988590c-7530-8470-3b74-56a2a8c3e744@oracle.com> Hi John, Maybe you should reach out to Rob who fixed JDK-8141370 to make sure this is the right thing to do. It seems the exclusion on problematic platforms [1] was deliberate: > Basically I've separated the failing subtest out into its own file and > excluded it on the (intermittently) failing platforms. best regards, -- daniel [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037385.html On 07/11/16 02:37, John Jiang wrote: > Hi, > com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java is associated to 8141370 > in ProblemList, though issue JDK-8141370 has been resolved. > In fact, the fix for JDK-8141370 extracted some codes from > com/sun/jndi/ldap/LdapTimeoutTest.java to create > com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java, and put the new test to > ProblemList. > It would be better to remove this item from ProblemList. If > com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java still fails > intermittently, we can put it back to ProblemList with the exact failure > logs. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8158916 > Webrev: http://cr.openjdk.java.net/~jjiang/8158916/webrev.00/ > > Best regards, > John Jiang > From bhanu.prakash.gopularam at oracle.com Mon Nov 7 12:01:42 2016 From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam) Date: Mon, 7 Nov 2016 04:01:42 -0800 (PST) Subject: RFR 8160036: Java API doc for method minusMonths in LocalDateTime class needs correction Message-ID: Hi all, Could you please review fix for following issue? Bug id: https://bugs.openjdk.java.net/browse/JDK-8160036 Solution: Corrected documentation for couple of methods in LocalDateTime and OffsetDateTime classes Webrev: http://cr.openjdk.java.net/~bgopularam/8160036/webrev.00 Thanks, Bhanu From nadeesh.tv at oracle.com Mon Nov 7 12:07:48 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Mon, 07 Nov 2016 17:37:48 +0530 Subject: RFR 8160036: Java API doc for method minusMonths in LocalDateTime class needs correction In-Reply-To: References: Message-ID: <58206E94.3000504@oracle.com> Hi Bhanu, Same issues with OffsetDateTime minusWeeks and minusDays Thanks and Regards, Nadeesh On 11/7/2016 5:31 PM, Bhanu Gopularam wrote: > Hi all, > > Could you please review fix for following issue? > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8160036 > > Solution: Corrected documentation for couple of methods in LocalDateTime and OffsetDateTime classes > > Webrev: http://cr.openjdk.java.net/~bgopularam/8160036/webrev.00 > > Thanks, > Bhanu -- Thanks and Regards, Nadeesh TV From bhanu.prakash.gopularam at oracle.com Mon Nov 7 12:27:02 2016 From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam) Date: Mon, 7 Nov 2016 04:27:02 -0800 (PST) Subject: RFR 8160036: Java API doc for method minusMonths in LocalDateTime class needs correction In-Reply-To: <58206E94.3000504@oracle.com> References: <58206E94.3000504@oracle.com> Message-ID: Thanks Nadeesh. Here is the updated webrev: http://cr.openjdk.java.net/~bgopularam/8160036/webrev.01 Thanks, Bhanu -----Original Message----- From: nadeesh tv Sent: Monday, November 07, 2016 5:38 PM To: core-libs-dev at openjdk.java.net Subject: Re: RFR 8160036: Java API doc for method minusMonths in LocalDateTime class needs correction Hi Bhanu, Same issues with OffsetDateTime minusWeeks and minusDays Thanks and Regards, Nadeesh On 11/7/2016 5:31 PM, Bhanu Gopularam wrote: > Hi all, > > Could you please review fix for following issue? > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8160036 > > Solution: Corrected documentation for couple of methods in LocalDateTime and OffsetDateTime classes > > Webrev: http://cr.openjdk.java.net/~bgopularam/8160036/webrev.00 > > Thanks, > Bhanu -- Thanks and Regards, Nadeesh TV From anubhav.meena at oracle.com Mon Nov 7 12:35:38 2016 From: anubhav.meena at oracle.com (Anubhav Meena) Date: Mon, 7 Nov 2016 18:05:38 +0530 Subject: RFR: JDK-8167618: DateTimeFormatter.format() uses exceptions for flow control. In-Reply-To: References: <58137592.1000207@oracle.com> Message-ID: Thanks for the review! Here is the updated webrev http://cr.openjdk.java.net/~ntv/others/anubhav/webrev.01/ -Anubhav > On Nov 2, 2016, at 4:04 PM, Stephen Colebourne wrote: > > I agree with Nadeesh, the updated code can still throw > DateTimeException from the call to getLong(). Unlike before, this > DateTimeException is desired. > > Stephen > > > On 28 October 2016 at 16:58, nadeesh tv wrote: >> >> Hi Anubhav, >> >> >> - * @throws DateTimeException if the field is not available and the >> section is not optional >> >> >> I think you should not remove the DTException since still there is a chance >> of throwing DTE >> Regards, >> Nadeesh >> >> On 10/28/2016 12:18 AM, Anubhav Meena wrote: >>> >>> Hi all, >>> >>> Please review. Please ignore last mail as links not working properly >>> there. >>> >>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8167618 >>> >>> Issue: DateTimeFormatter.format() uses exceptions for flow control. >>> Webrev: http://cr.openjdk.java.net/~rchamyal/anmeena/8167618/webrev.00/ >>> >> >> >> -- >> Thanks and Regards, >> Nadeesh TV >> From scolebourne at joda.org Mon Nov 7 12:51:49 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 7 Nov 2016 12:51:49 +0000 Subject: RFR: JDK-8167618: DateTimeFormatter.format() uses exceptions for flow control. In-Reply-To: References: <58137592.1000207@oracle.com> Message-ID: Looks good, thanks. I'm sure it will make some cases faster, I just hope it doesn't make cases that don't throw an exception significantly slower. Stephen On 7 November 2016 at 12:35, Anubhav Meena wrote: > Thanks for the review! > > Here is the updated webrev > http://cr.openjdk.java.net/~ntv/others/anubhav/webrev.01/ > > -Anubhav > > > On Nov 2, 2016, at 4:04 PM, Stephen Colebourne wrote: > > I agree with Nadeesh, the updated code can still throw > DateTimeException from the call to getLong(). Unlike before, this > DateTimeException is desired. > > Stephen > > > On 28 October 2016 at 16:58, nadeesh tv wrote: > > > Hi Anubhav, > > > - * @throws DateTimeException if the field is not available and the > section is not optional > > > I think you should not remove the DTException since still there is a chance > of throwing DTE > Regards, > Nadeesh > > On 10/28/2016 12:18 AM, Anubhav Meena wrote: > > > Hi all, > > Please review. Please ignore last mail as links not working properly > there. > > Bug Id : https://bugs.openjdk.java.net/browse/JDK-8167618 > > Issue: DateTimeFormatter.format() uses exceptions for flow control. > Webrev: http://cr.openjdk.java.net/~rchamyal/anmeena/8167618/webrev.00/ > > > > > -- > Thanks and Regards, > Nadeesh TV > > From christoph.langer at sap.com Mon Nov 7 16:09:20 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 7 Nov 2016 16:09:20 +0000 Subject: XALAN: Text node of value 'null' - Is this illegal or does XSLTC have an issue here? Message-ID: <957da990d3b845d1aa055135ceed2861@DEROTE13DE07.global.corp.sap> Hi Xalan experts, I've recently handled a customer issue about Text Nodes of value 'null' inside a DOM, causing an exception during XALAN XSLT transformation. The repro case is quite simple. Consider the following small Java sample [1] which creates a DOM from a very basic XML, inserts a text node with value null into the DOM and then runs an identity transformation on it. Without inserting the null Text node, it would run without issues. However, the com.sun.org.apache.xml.internal.serializer.ToUnknownStream class stumbles over the null value and the transformation throws an NPE [2]. I believe this could be easily fixed by adding a null check in the serializer and handling null like "". However, would you agree that it is a real issue worth fixing or should one rather stress the point that Text Nodes of null are illegal? (Is that true, anyway? Didn't find any specification about that...) Please let me know your opinion - and if you agree I would work on a fix. Thanks in advance for comments Christoph [1] Sample code: import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; import javax.xml.parsers.DocumentBuilder; import javax.xml.parsers.DocumentBuilderFactory; import javax.xml.parsers.ParserConfigurationException; import javax.xml.transform.TransformerException; import javax.xml.transform.TransformerFactory; import javax.xml.transform.dom.DOMSource; import javax.xml.transform.stream.StreamResult; import org.w3c.dom.Document; import org.w3c.dom.Element; import org.xml.sax.SAXException; public class TestTransformWithNullText { public static void main(String[] args) throws ParserConfigurationException, SAXException, IOException, TransformerException { // create a small DOM DocumentBuilder db = DocumentBuilderFactory.newInstance().newDocumentBuilder(); Document doc = db.parse(new ByteArrayInputStream("".getBytes())); // insert a bad element Element e = doc.createElement("ERROR"); e.appendChild(doc.createTextNode(null)); doc.getDocumentElement().appendChild(e); // transform ByteArrayOutputStream bos = new ByteArrayOutputStream(); TransformerFactory.newInstance().newTransformer().transform( new DOMSource(doc.getDocumentElement()), new StreamResult(bos)); System.out.println(bos); } } [2] Exception encountered: Exception in thread "main" javax.xml.transform.TransformerException: java.lang.NullPointerException at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(java.xml at 9.0.0.1-internal/TransformerImpl.java:789) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(java.xml at 9.0.0.1-internal/TransformerImpl.java:376) at com.sap.cl.xml.test.transform.TestTransformWithNullText.main(TestTransformWithNullText.java:33) Caused by: java.lang.NullPointerException at com.sun.org.apache.xml.internal.serializer.ToUnknownStream.characters(java.xml at 9.0.0.1-internal/ToUnknownStream.java:342) at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:244) at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:230) at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:230) at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:94) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(java.xml at 9.0.0.1-internal/TransformerImpl.java:718) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(java.xml at 9.0.0.1-internal/TransformerImpl.java:780) ... 2 more --------- java.lang.NullPointerException at com.sun.org.apache.xml.internal.serializer.ToUnknownStream.characters(java.xml at 9.0.0.1-internal/ToUnknownStream.java:342) at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:244) at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:230) at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:230) at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:94) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(java.xml at 9.0.0.1-internal/TransformerImpl.java:718) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(java.xml at 9.0.0.1-internal/TransformerImpl.java:780) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(java.xml at 9.0.0.1-internal/TransformerImpl.java:376) at com.sap.cl.xml.test.transform.TestTransformWithNullText.main(TestTransformWithNullText.java:33) From martinrb at google.com Mon Nov 7 16:36:24 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 7 Nov 2016 08:36:24 -0800 Subject: RFR: 8169191: (tz) Support tzdata2016i In-Reply-To: References: Message-ID: Looks good to me! On Mon, Nov 7, 2016 at 2:43 AM, Ramanand Patil wrote: > Hi all, > Please review the latest TZDATA integration (tzdata2016i) to JDK9. > Bug: https://bugs.openjdk.java.net/browse/JDK-8169191 > Webrev: http://cr.openjdk.java.net/~rpatil/8169191/webrev.00/ > > All the TimeZone related tests are passed after integration. > > Regards, > Ramanand. > From vladimir.kozlov at oracle.com Mon Nov 7 18:04:51 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 7 Nov 2016 10:04:51 -0800 Subject: RFR: 8159035: com/sun/crypto/provider/Cipher/CTS/CTSMode.java test crashed due to unhandled case of cipher length value as 0 In-Reply-To: <70b2c1c2-7d04-47e8-8330-5e65e13b8425@default> References: <70b2c1c2-7d04-47e8-8330-5e65e13b8425@default> Message-ID: <99fb049d-b79e-1484-a8c8-dd46795bd041@oracle.com> Looks good. Thanks, Vladimir On 11/7/16 3:21 AM, Rahul Raghavan wrote: > Hi, > > Request review for closed bug fix - JDK-8159035. > > - http://cr.openjdk.java.net/~rraghavan/8159035/webrev.03/ > > Notes: > > 1. - https://bugs.openjdk.java.net/browse/JDK-8159035 - (com/sun/crypto/provider/Cipher/CTS/CTSMode.java test crashed due to unhandled case of cipher length value as 0) > Related issues - > https://bugs.openjdk.java.net/browse/JDK-8076112 - 'Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics' > https://bugs.openjdk.java.net/browse/JDK-8167595 - 'AArch64: SEGV in stub code cipherBlockChaining_decryptAESCrypt' > > 2. Found root cause of the reported jvm crash for sparc - > Crash happens at 'generate_cipherBlockChaining_decryptAESCrypt_Parallel()' [stubGenerator_sparc.cpp] > The implDecrypt can be called from CipherBlockChaining.decrypt, even with cipherLen as 0. > But the same condition is not handled in the stub code and results in crash. > (the same applicable for implEncrypt) > > 3. Though the reported case was for sparc, understood that same issue is present for x86, aarch64 (JDK-8167595). > So in above fix proposed in Java wrapper method side [CipherBlockChaining.java]. > > 4. The same issue in aarch64 (JDK-8167595) was fixed earlier in stubGenerator_aarch64. > So once above is approved, I will initiate new hotspot webrev to revert this earlier 8167595 change. > > 5. Checked for any other similar cases with HotSpotIntrinsicCandidate support and found two cases as proposed in > - implCrypt() / CounterMode.java > - implEncodeISOArray() / ISO_8859_1.java > > Confirmed no Issues for with jprt testing (-testset hotspot, core) > > > Thanks, > Rahul > From kumar.x.srinivasan at oracle.com Mon Nov 7 18:47:48 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 07 Nov 2016 10:47:48 -0800 Subject: 8169001: Remove launcher's built-in ergonomics Message-ID: <5820CC54.4010401@oracle.com> Hello, Please review the fix for: https://bugs.openjdk.java.net/browse/JDK-8169001 Webrev at: http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/ Background: > Launcher ergonomics was introduced last decade to help determine > if the execution system is "Server Class", this was necessary to > choose server VM on platforms that supported both client and server > VMs (primarily for Solaris and Linux 32-bit). > > The algorithm involves computing and detecting the number of CPUs > and the amount of memory on the target system. All modern computers > systems with hyper-threading cause the ergonomics to choose server. > > JDK9 Platforms that have only server vm. > > ./linux-x64/lib/amd64/server/libjvm.so > ./linux-arm64-vfp-hflt/lib/aarch64/server/libjvm.so > ./solaris-sparcv9/lib/sparcv9/server/libjvm.so > ./solaris-x64/lib/amd64/server/libjvm.so > ./windows-x86/bin/server/jvm.dll > ./windows-x64/bin/server/jvm.dll > > JDK9 Platforms that have more than one vm variant: > ./linux-arm32-vfp-hflt/lib/arm/client/libjvm.so (default) > ./linux-arm32-vfp-hflt/lib/arm/minimal/libjvm.so > > ./linux-x86/lib/i386/server/libjvm.so (default) > ./linux-x86/lib/i386/minimal/libjvm.so > > > In the cases where multiple VMs are supported the ergnomics > has no effect, and the default platforms are chosen by the > jvm.cfg. Thus the launcher ergonomics is obsolete and redundant. Thanks Kumar From xueming.shen at oracle.com Mon Nov 7 19:29:18 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 07 Nov 2016 11:29:18 -0800 Subject: RFR: 8159035: com/sun/crypto/provider/Cipher/CTS/CTSMode.java test crashed due to unhandled case of cipher length value as 0 In-Reply-To: <99fb049d-b79e-1484-a8c8-dd46795bd041@oracle.com> References: <70b2c1c2-7d04-47e8-8330-5e65e13b8425@default> <99fb049d-b79e-1484-a8c8-dd46795bd041@oracle.com> Message-ID: <5820D60E.1000301@oracle.com> change in 8859-1 looks good. sherman > On 11/7/16 3:21 AM, Rahul Raghavan wrote: >> Hi, >> >> Request review for closed bug fix - JDK-8159035. >> >> - http://cr.openjdk.java.net/~rraghavan/8159035/webrev.03/ >> >> Notes: >> >> 1. - https://bugs.openjdk.java.net/browse/JDK-8159035 - >> (com/sun/crypto/provider/Cipher/CTS/CTSMode.java test crashed due to >> unhandled case of cipher length value as 0) >> Related issues - >> https://bugs.openjdk.java.net/browse/JDK-8076112 - 'Add >> @HotSpotIntrinsicCandidate annotation to indicate methods for which >> Java Runtime has intrinsics' >> https://bugs.openjdk.java.net/browse/JDK-8167595 - 'AArch64: SEGV >> in stub code cipherBlockChaining_decryptAESCrypt' >> >> 2. Found root cause of the reported jvm crash for sparc - >> Crash happens at >> 'generate_cipherBlockChaining_decryptAESCrypt_Parallel()' >> [stubGenerator_sparc.cpp] >> The implDecrypt can be called from CipherBlockChaining.decrypt, even >> with cipherLen as 0. >> But the same condition is not handled in the stub code and results in >> crash. >> (the same applicable for implEncrypt) >> >> 3. Though the reported case was for sparc, understood that same issue >> is present for x86, aarch64 (JDK-8167595). >> So in above fix proposed in Java wrapper method side >> [CipherBlockChaining.java]. >> >> 4. The same issue in aarch64 (JDK-8167595) was fixed earlier in >> stubGenerator_aarch64. >> So once above is approved, I will initiate new hotspot >> webrev to revert this earlier 8167595 change. >> >> 5. Checked for any other similar cases with HotSpotIntrinsicCandidate >> support and found two cases as proposed in >> - implCrypt() / CounterMode.java >> - implEncodeISOArray() / ISO_8859_1.java >> >> Confirmed no Issues for with jprt testing (-testset >> hotspot, core) >> >> >> Thanks, >> Rahul >> From Roger.Riggs at Oracle.com Mon Nov 7 21:23:24 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 7 Nov 2016 16:23:24 -0500 Subject: RFR 8160036: Java API doc for method minusMonths in LocalDateTime class needs correction In-Reply-To: References: <58206E94.3000504@oracle.com> Message-ID: Looks good, Thanks, Roger On 11/7/2016 7:27 AM, Bhanu Gopularam wrote: > Thanks Nadeesh. Here is the updated webrev: > > http://cr.openjdk.java.net/~bgopularam/8160036/webrev.01 > > Thanks, > Bhanu > > -----Original Message----- > From: nadeesh tv > Sent: Monday, November 07, 2016 5:38 PM > To: core-libs-dev at openjdk.java.net > Subject: Re: RFR 8160036: Java API doc for method minusMonths in LocalDateTime class needs correction > > Hi Bhanu, > Same issues with OffsetDateTime minusWeeks and minusDays > > Thanks and Regards, > Nadeesh > > On 11/7/2016 5:31 PM, Bhanu Gopularam wrote: >> Hi all, >> >> Could you please review fix for following issue? >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8160036 >> >> Solution: Corrected documentation for couple of methods in LocalDateTime and OffsetDateTime classes >> >> Webrev: http://cr.openjdk.java.net/~bgopularam/8160036/webrev.00 >> >> Thanks, >> Bhanu From david.holmes at oracle.com Mon Nov 7 23:24:33 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Nov 2016 09:24:33 +1000 Subject: 8169001: Remove launcher's built-in ergonomics In-Reply-To: <5820CC54.4010401@oracle.com> References: <5820CC54.4010401@oracle.com> Message-ID: <6a3463cb-6e3f-a5cd-601a-2bb6f715eef1@oracle.com> Hi Kumar, On 8/11/2016 4:47 AM, Kumar Srinivasan wrote: > > Hello, > > Please review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8169001 > > Webrev at: > http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/ Overall this looks like a complete eradication of the launcher ergonomics. A few specific comments: src/java.base/share/native/launcher/main.c ! const_cpwildcard, const_javaw, 0); Can you clarify this change with ! const_cpwildcard, const_javaw, 0 /* unused */); Thanks. --- src/java.base/share/native/libjli/java.c 220 jint ergo /* unused */ I assume JLI_Launch is an exported API otherwise I'd expect this to be deleted. The fact it is unused should also be documented in src/java.base/share/native/libjli/java.h. But I'm also wondering where this API change is being documented for external users? - FreeKnownVMs(); /* after last possible PrintUsage() */ Not clear why you no longer need to free here. But if you don't then FreeKnownVMs() seems to be dead code now. --- src/java.base/unix/conf/i586/jvm.cfg I think you still need an entry for "-client KNOWN" as anyone can build the client VM if they choose. Ditto for src/java.base/unix/conf/sparc/jvm.cfg (though 32-bit Solaris builds are obsolete now). --- You have updated a number of copyright notices but not all of them. --- I see no changes to tests, but I'm pretty sure we have a test for server-class-machine somewhere (or we did - I recall it breaking at some point). Thanks, David > Background: >> Launcher ergonomics was introduced last decade to help determine >> if the execution system is "Server Class", this was necessary to >> choose server VM on platforms that supported both client and server >> VMs (primarily for Solaris and Linux 32-bit). >> >> The algorithm involves computing and detecting the number of CPUs >> and the amount of memory on the target system. All modern computers >> systems with hyper-threading cause the ergonomics to choose server. >> >> JDK9 Platforms that have only server vm. >> >> ./linux-x64/lib/amd64/server/libjvm.so >> ./linux-arm64-vfp-hflt/lib/aarch64/server/libjvm.so >> ./solaris-sparcv9/lib/sparcv9/server/libjvm.so >> ./solaris-x64/lib/amd64/server/libjvm.so >> ./windows-x86/bin/server/jvm.dll >> ./windows-x64/bin/server/jvm.dll >> >> JDK9 Platforms that have more than one vm variant: >> ./linux-arm32-vfp-hflt/lib/arm/client/libjvm.so (default) >> ./linux-arm32-vfp-hflt/lib/arm/minimal/libjvm.so >> >> ./linux-x86/lib/i386/server/libjvm.so (default) >> ./linux-x86/lib/i386/minimal/libjvm.so >> >> >> In the cases where multiple VMs are supported the ergnomics >> has no effect, and the default platforms are chosen by the >> jvm.cfg. Thus the launcher ergonomics is obsolete and redundant. > > Thanks > Kumar > From sha.jiang at oracle.com Tue Nov 8 01:30:58 2016 From: sha.jiang at oracle.com (John Jiang) Date: Tue, 8 Nov 2016 09:30:58 +0800 Subject: RFR[9] JDK-8158916: ProblemList.txt update for com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java In-Reply-To: <0988590c-7530-8470-3b74-56a2a8c3e744@oracle.com> References: <59dc7e57-3d05-6395-abdc-a0677b487fbb@oracle.com> <0988590c-7530-8470-3b74-56a2a8c3e744@oracle.com> Message-ID: Hi Daniel, Thanks for your comments. On 2016/11/7 19:21, Daniel Fuchs wrote: > Hi John, > > Maybe you should reach out to Rob who fixed JDK-8141370 to > make sure this is the right thing to do. just cc Rob Mckenna > > It seems the exclusion on problematic platforms [1] was deliberate: > >> Basically I've separated the failing subtest out into its own file and >> excluded it on the (intermittently) failing platforms. I see. But it should use an open issue. I would like to open a new issue to track this issue. But I don't get the exact failure log on DeadSSLLdapTimeoutTest.java, though the failure may still be related to SSLHandshakeException. When this test was born, it was in the ProblemList, so I suppose it has no chance to be executed by our automatic testing systems. Best regards, John Jiang > > best regards, > > -- daniel > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037385.html > > > On 07/11/16 02:37, John Jiang wrote: >> Hi, >> com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java is associated to 8141370 >> in ProblemList, though issue JDK-8141370 has been resolved. >> In fact, the fix for JDK-8141370 extracted some codes from >> com/sun/jndi/ldap/LdapTimeoutTest.java to create >> com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java, and put the new test to >> ProblemList. >> It would be better to remove this item from ProblemList. If >> com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java still fails >> intermittently, we can put it back to ProblemList with the exact failure >> logs. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8158916 >> Webrev: http://cr.openjdk.java.net/~jjiang/8158916/webrev.00/ >> >> Best regards, >> John Jiang >> > > From masayoshi.okutsu at oracle.com Tue Nov 8 04:26:42 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 8 Nov 2016 13:26:42 +0900 Subject: RFR: 8169191: (tz) Support tzdata2016i In-Reply-To: References: Message-ID: +1 On 11/8/2016 1:36 AM, Martin Buchholz wrote: > Looks good to me! > > On Mon, Nov 7, 2016 at 2:43 AM, Ramanand Patil > wrote: > >> Hi all, >> Please review the latest TZDATA integration (tzdata2016i) to JDK9. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8169191 >> Webrev: http://cr.openjdk.java.net/~rpatil/8169191/webrev.00/ >> >> All the TimeZone related tests are passed after integration. >> >> Regards, >> Ramanand. >> From huizhe.wang at oracle.com Tue Nov 8 05:01:14 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 7 Nov 2016 21:01:14 -0800 Subject: XALAN: Text node of value 'null' - Is this illegal or does XSLTC have an issue here? In-Reply-To: <957da990d3b845d1aa055135ceed2861@DEROTE13DE07.global.corp.sap> References: <957da990d3b845d1aa055135ceed2861@DEROTE13DE07.global.corp.sap> Message-ID: Looks like a null check-in is desirable. If the intention is to add a text node, which I assume was his intention, he wouldn't want a null node. If the intention is to create an empty element, then he didn't need the line that added the null text node. As far as DOM goes, it would have been better if it was clearer on how null be handled (a DOMException probably). But for a 10+ yr old API, the case is not enough to call for a change of the behavior. Thanks, Joe On 11/7/2016 8:09 AM, Langer, Christoph wrote: > > Hi Xalan experts, > > I?ve recently handled a customer issue about Text Nodes of value > ?null? inside a DOM, causing an exception during XALAN XSLT > transformation. The repro case is quite simple. Consider the following > small Java sample [1] which creates a DOM from a very basic XML, > inserts a text node with value null into the DOM and then runs an > identity transformation on it. Without inserting the null Text node, > it would run without issues. However, the > com.sun.org.apache.xml.internal.serializer.ToUnknownStream class > stumbles over the null value and the transformation throws an NPE [2]. > I believe this could be easily fixed by adding a null check in the > serializer and handling null like ??. However, would you agree that it > is a real issue worth fixing or should one rather stress the point > that Text Nodes of null are illegal? (Is that true, anyway? Didn?t > find any specification about that?) Please let me know your opinion ? > and if you agree I would work on a fix. > > Thanks in advance for comments > > Christoph > > [1] Sample code: > > import java.io.ByteArrayInputStream; > > import java.io.ByteArrayOutputStream; > > import java.io.IOException; > > import javax.xml.parsers.DocumentBuilder; > > import javax.xml.parsers.DocumentBuilderFactory; > > import javax.xml.parsers.ParserConfigurationException; > > import javax.xml.transform.TransformerException; > > import javax.xml.transform.TransformerFactory; > > import javax.xml.transform.dom.DOMSource; > > import javax.xml.transform.stream.StreamResult; > > import org.w3c.dom.Document; > > import org.w3c.dom.Element; > > import org.xml.sax.SAXException; > > public class TestTransformWithNullText { > > public static void main(String[] args) throws > ParserConfigurationException, SAXException, IOException, > TransformerException { > > // create a small DOM > > DocumentBuilder db = > DocumentBuilderFactory.newInstance().newDocumentBuilder(); > > Document doc = db.parse(new ByteArrayInputStream(" version=\"1.0\"?>".getBytes())); > > // insert a bad element > > Element e = doc.createElement("ERROR"); > > e.appendChild(doc.createTextNode(null)); > > doc.getDocumentElement().appendChild(e); > > // transform > > ByteArrayOutputStream bos = new ByteArrayOutputStream(); > > TransformerFactory.newInstance().newTransformer().transform( > > new DOMSource(doc.getDocumentElement()), new StreamResult(bos)); > > System.out.println(bos); > > } > > } > > [2] Exception encountered: > > Exception in thread "main" javax.xml.transform.TransformerException: > java.lang.NullPointerException > > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(java.xml at 9.0.0.1-internal/TransformerImpl.java:789) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(java.xml at 9.0.0.1-internal/TransformerImpl.java:376) > > at > com.sap.cl.xml.test.transform.TestTransformWithNullText.main(TestTransformWithNullText.java:33) > > Caused by: java.lang.NullPointerException > > at > com.sun.org.apache.xml.internal.serializer.ToUnknownStream.characters(java.xml at 9.0.0.1-internal/ToUnknownStream.java:342) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:244) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:230) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:230) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:94) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(java.xml at 9.0.0.1-internal/TransformerImpl.java:718) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(java.xml at 9.0.0.1-internal/TransformerImpl.java:780) > > ... 2 more > > --------- > > java.lang.NullPointerException > > at > com.sun.org.apache.xml.internal.serializer.ToUnknownStream.characters(java.xml at 9.0.0.1-internal/ToUnknownStream.java:342) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:244) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:230) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:230) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:94) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(java.xml at 9.0.0.1-internal/TransformerImpl.java:718) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(java.xml at 9.0.0.1-internal/TransformerImpl.java:780) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(java.xml at 9.0.0.1-internal/TransformerImpl.java:376) > > at > com.sap.cl.xml.test.transform.TestTransformWithNullText.main(TestTransformWithNullText.java:33) > From christoph.langer at sap.com Tue Nov 8 07:31:00 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 8 Nov 2016 07:31:00 +0000 Subject: XALAN: Text node of value 'null' - Is this illegal or does XSLTC have an issue here? In-Reply-To: References: <957da990d3b845d1aa055135ceed2861@DEROTE13DE07.global.corp.sap> Message-ID: <7ba8848d50b54d878ff63a17f7f8e2dd@DEROTE13DE07.global.corp.sap> Hi Joe, thanks for your comments. Yes the customer does not really want to insert a null value but create an empty text node. So they'll fix their code anyway. However, I thought it would be a good Idea to make the Serializer more robust with regards to such null data. Especially given that it's possible via the DOM API to construct such null nodes. So I take you support this endeavor? Thanks Christoph From: huizhe wang [mailto:huizhe.wang at oracle.com] Sent: Dienstag, 8. November 2016 06:01 To: Langer, Christoph ; Aleks Efimov ; Lance Andersen Cc: core-libs-dev at openjdk.java.net Subject: Re: XALAN: Text node of value 'null' - Is this illegal or does XSLTC have an issue here? Looks like a null check-in is desirable. If the intention is to add a text node, which I assume was his intention, he wouldn't want a null node. If the intention is to create an empty element, then he didn't need the line that added the null text node. As far as DOM goes, it would have been better if it was clearer on how null be handled (a DOMException probably). But for a 10+ yr old API, the case is not enough to call for a change of the behavior. Thanks, Joe On 11/7/2016 8:09 AM, Langer, Christoph wrote: Hi Xalan experts, I've recently handled a customer issue about Text Nodes of value 'null' inside a DOM, causing an exception during XALAN XSLT transformation. The repro case is quite simple. Consider the following small Java sample [1] which creates a DOM from a very basic XML, inserts a text node with value null into the DOM and then runs an identity transformation on it. Without inserting the null Text node, it would run without issues. However, the com.sun.org.apache.xml.internal.serializer.ToUnknownStream class stumbles over the null value and the transformation throws an NPE [2]. I believe this could be easily fixed by adding a null check in the serializer and handling null like "". However, would you agree that it is a real issue worth fixing or should one rather stress the point that Text Nodes of null are illegal? (Is that true, anyway? Didn't find any specification about that...) Please let me know your opinion - and if you agree I would work on a fix. Thanks in advance for comments Christoph [1] Sample code: import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; import javax.xml.parsers.DocumentBuilder; import javax.xml.parsers.DocumentBuilderFactory; import javax.xml.parsers.ParserConfigurationException; import javax.xml.transform.TransformerException; import javax.xml.transform.TransformerFactory; import javax.xml.transform.dom.DOMSource; import javax.xml.transform.stream.StreamResult; import org.w3c.dom.Document; import org.w3c.dom.Element; import org.xml.sax.SAXException; public class TestTransformWithNullText { public static void main(String[] args) throws ParserConfigurationException, SAXException, IOException, TransformerException { // create a small DOM DocumentBuilder db = DocumentBuilderFactory.newInstance().newDocumentBuilder(); Document doc = db.parse(new ByteArrayInputStream("".getBytes())); // insert a bad element Element e = doc.createElement("ERROR"); e.appendChild(doc.createTextNode(null)); doc.getDocumentElement().appendChild(e); // transform ByteArrayOutputStream bos = new ByteArrayOutputStream(); TransformerFactory.newInstance().newTransformer().transform( new DOMSource(doc.getDocumentElement()), new StreamResult(bos)); System.out.println(bos); } } [2] Exception encountered: Exception in thread "main" javax.xml.transform.TransformerException: java.lang.NullPointerException at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(java.xml at 9.0.0.1-internal/TransformerImpl.java:789) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(java.xml at 9.0.0.1-internal/TransformerImpl.java:376) at com.sap.cl.xml.test.transform.TestTransformWithNullText.main(TestTransformWithNullText.java:33) Caused by: java.lang.NullPointerException at com.sun.org.apache.xml.internal.serializer.ToUnknownStream.characters(java.xml at 9.0.0.1-internal/ToUnknownStream.java:342) at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:244) at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:230) at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:230) at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:94) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(java.xml at 9.0.0.1-internal/TransformerImpl.java:718) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(java.xml at 9.0.0.1-internal/TransformerImpl.java:780) ... 2 more --------- java.lang.NullPointerException at com.sun.org.apache.xml.internal.serializer.ToUnknownStream.characters(java.xml at 9.0.0.1-internal/ToUnknownStream.java:342) at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:244) at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:230) at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:230) at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:94) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(java.xml at 9.0.0.1-internal/TransformerImpl.java:718) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(java.xml at 9.0.0.1-internal/TransformerImpl.java:780) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(java.xml at 9.0.0.1-internal/TransformerImpl.java:376) at com.sap.cl.xml.test.transform.TestTransformWithNullText.main(TestTransformWithNullText.java:33) From tobias.hartmann at oracle.com Tue Nov 8 08:16:33 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 8 Nov 2016 09:16:33 +0100 Subject: RFR: 8159035: com/sun/crypto/provider/Cipher/CTS/CTSMode.java test crashed due to unhandled case of cipher length value as 0 In-Reply-To: <70b2c1c2-7d04-47e8-8330-5e65e13b8425@default> References: <70b2c1c2-7d04-47e8-8330-5e65e13b8425@default> Message-ID: <582189E1.6000308@oracle.com> Hi Rahul, On 07.11.2016 12:21, Rahul Raghavan wrote: > Hi, > > Request review for closed bug fix - JDK-8159035. > > - http://cr.openjdk.java.net/~rraghavan/8159035/webrev.03/ Looks good to me! > Notes: > > 1. - https://bugs.openjdk.java.net/browse/JDK-8159035 - (com/sun/crypto/provider/Cipher/CTS/CTSMode.java test crashed due to unhandled case of cipher length value as 0) > Related issues - > https://bugs.openjdk.java.net/browse/JDK-8076112 - 'Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics' > https://bugs.openjdk.java.net/browse/JDK-8167595 - 'AArch64: SEGV in stub code cipherBlockChaining_decryptAESCrypt' > > 2. Found root cause of the reported jvm crash for sparc - > Crash happens at 'generate_cipherBlockChaining_decryptAESCrypt_Parallel()' [stubGenerator_sparc.cpp] > The implDecrypt can be called from CipherBlockChaining.decrypt, even with cipherLen as 0. > But the same condition is not handled in the stub code and results in crash. > (the same applicable for implEncrypt) > > 3. Though the reported case was for sparc, understood that same issue is present for x86, aarch64 (JDK-8167595). > So in above fix proposed in Java wrapper method side [CipherBlockChaining.java]. > > 4. The same issue in aarch64 (JDK-8167595) was fixed earlier in stubGenerator_aarch64. > So once above is approved, I will initiate new hotspot webrev to revert this earlier 8167595 change. Please file another bug for this and link it to this bug. > 5. Checked for any other similar cases with HotSpotIntrinsicCandidate support and found two cases as proposed in > - implCrypt() / CounterMode.java > - implEncodeISOArray() / ISO_8859_1.java > > Confirmed no Issues for with jprt testing (-testset hotspot, core) Please also run our RBT testing before pushing. Thanks, Tobias > Thanks, > Rahul > From erik.joelsson at oracle.com Tue Nov 8 08:23:37 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 8 Nov 2016 09:23:37 +0100 Subject: 8169001: Remove launcher's built-in ergonomics In-Reply-To: <5820CC54.4010401@oracle.com> References: <5820CC54.4010401@oracle.com> Message-ID: <501f7c83-19a4-5927-2116-a8c9ed506d08@oracle.com> Build changes look ok. /Erik On 2016-11-07 19:47, Kumar Srinivasan wrote: > > Hello, > > Please review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8169001 > > Webrev at: > http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/ > > Background: >> Launcher ergonomics was introduced last decade to help determine >> if the execution system is "Server Class", this was necessary to >> choose server VM on platforms that supported both client and server >> VMs (primarily for Solaris and Linux 32-bit). >> >> The algorithm involves computing and detecting the number of CPUs >> and the amount of memory on the target system. All modern computers >> systems with hyper-threading cause the ergonomics to choose server. >> >> JDK9 Platforms that have only server vm. >> >> ./linux-x64/lib/amd64/server/libjvm.so >> ./linux-arm64-vfp-hflt/lib/aarch64/server/libjvm.so >> ./solaris-sparcv9/lib/sparcv9/server/libjvm.so >> ./solaris-x64/lib/amd64/server/libjvm.so >> ./windows-x86/bin/server/jvm.dll >> ./windows-x64/bin/server/jvm.dll >> >> JDK9 Platforms that have more than one vm variant: >> ./linux-arm32-vfp-hflt/lib/arm/client/libjvm.so (default) >> ./linux-arm32-vfp-hflt/lib/arm/minimal/libjvm.so >> >> ./linux-x86/lib/i386/server/libjvm.so (default) >> ./linux-x86/lib/i386/minimal/libjvm.so >> >> >> In the cases where multiple VMs are supported the ergnomics >> has no effect, and the default platforms are chosen by the >> jvm.cfg. Thus the launcher ergonomics is obsolete and redundant. > > Thanks > Kumar > From daniel.fuchs at oracle.com Tue Nov 8 10:53:44 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 8 Nov 2016 10:53:44 +0000 Subject: RFR[9] JDK-8158916: ProblemList.txt update for com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java In-Reply-To: References: <59dc7e57-3d05-6395-abdc-a0677b487fbb@oracle.com> <0988590c-7530-8470-3b74-56a2a8c3e744@oracle.com> Message-ID: Hi John, On 08/11/16 01:30, John Jiang wrote: > Hi Daniel, > Thanks for your comments. > > On 2016/11/7 19:21, Daniel Fuchs wrote: >> Hi John, >> >> Maybe you should reach out to Rob who fixed JDK-8141370 to >> make sure this is the right thing to do. > just cc Rob Mckenna > >> >> It seems the exclusion on problematic platforms [1] was deliberate: >> >>> Basically I've separated the failing subtest out into its own file and >>> excluded it on the (intermittently) failing platforms. > I see. But it should use an open issue. > I would like to open a new issue to track this issue. But I don't get > the exact failure log on DeadSSLLdapTimeoutTest.java, though the failure > may still be related to SSLHandshakeException. > When this test was born, it was in the ProblemList, so I suppose it has > no chance to be executed by our automatic testing systems. I see. I agree it's better to have an open bug in the ProblemList. But I am concerned if that bug is something that we never intend to fix because the test is not appropriate for those platforms. best regards, -- daniel > > Best regards, > John Jiang > >> >> best regards, >> >> -- daniel >> >> [1] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037385.html >> >> >> >> On 07/11/16 02:37, John Jiang wrote: >>> Hi, >>> com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java is associated to 8141370 >>> in ProblemList, though issue JDK-8141370 has been resolved. >>> In fact, the fix for JDK-8141370 extracted some codes from >>> com/sun/jndi/ldap/LdapTimeoutTest.java to create >>> com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java, and put the new test to >>> ProblemList. >>> It would be better to remove this item from ProblemList. If >>> com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java still fails >>> intermittently, we can put it back to ProblemList with the exact failure >>> logs. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8158916 >>> Webrev: http://cr.openjdk.java.net/~jjiang/8158916/webrev.00/ >>> >>> Best regards, >>> John Jiang >>> >> >> > From denis.kononenko at oracle.com Tue Nov 8 13:17:54 2016 From: denis.kononenko at oracle.com (Denis Kononenko) Date: Tue, 8 Nov 2016 05:17:54 -0800 (PST) Subject: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options Message-ID: <260cd370-a550-4403-89a3-6255b6106cbe@default> Hi, The new version of changes. - Switched back to jdk/test/testlibrary to avoid unwanted dependencies (JImageToolTest.java); - Verified tests on smallest possible JDK build. WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.02/ BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 Thank you, Denis. > Denis, > > I can see that you have switched to the top level test library with > this change. With that you are getting more module dependencies than > just java.base. First of all, it would probably make sense to build > only the classes you needed (which would be > jdk.test.lib.process.ProcessTools, I assume), but even if you only > build that, jdk.test.lib.process.ProcessTools has dependencies outside > java.base module. > > You either have to declare @modules in your test or go back to the > jdk/test/lib/testlibrary. Then, of course, unneeded module > dependencies are questionable. > > Shura > > > > On Nov 3, 2016, at 6:29 AM, Denis Kononenko > wrote: > > > > Hi, > > > > I've done some rework accordingly to Alan's and Shura's comments: > > > > 1) removed overlapped tests from JImageToolTest.java; > > > > 2) added new tests JImageVerifyTest.java for jimage verify; > > > > 3) reorganized jtreg's tags; > > > > The new WEBREV can be found here: > http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/ > > > > Thank you, > > Denis. > > > > On 06.10.2016 19:37, Denis Kononenko wrote: > >> Hi, > >> > >> Could someone please review these new tests for jimage utility. > >> > >> There're 5 new files containing tests to cover use cases for > 'info', 'list', 'extract' and other options. No new tests for > 'verify'. > >> > >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > >> WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/ > >> > >> > >> Thank you, > >> Denis. > > From roman.grigoriadi at oracle.com Tue Nov 8 13:18:20 2016 From: roman.grigoriadi at oracle.com (Roman Grigoriadi) Date: Tue, 8 Nov 2016 14:18:20 +0100 Subject: RFR: 8164479: Update JAX-WS RI integration to latest version In-Reply-To: <4E89C684-9EE0-468A-8068-412A8BBF991E@oracle.com> References: <1c63a0dc-d38d-0148-016c-30b15721d6a6@oracle.com> <3F91468F-78B2-4D3D-80D2-E429D8FAFC61@oracle.com> <57E5909E.3050702@oracle.com> <5754D4FE-0D20-4527-B163-E9224E3A4FDD@oracle.com> <5ac5eeec-fe39-0728-1ee4-2bc8684722d1@oracle.com> <435c44ae-51fc-c727-915c-6acb499d72a9@oracle.com> <4bbb97c4-4423-30b3-b906-95ff56dda779@oracle.com> <4ff0efee-19fe-8125-163c-5f2981941e39@oracle.com> <01423715-826e-8b53-0060-93a2e513138c@oracle.com> <4E89C684-9EE0-468A-8068-412A8BBF991E@oracle.com> Message-ID: <3dfa6703-de07-a13f-562d-e22ae50da77d@oracle.com> Thanks for suggestions Mandy. xjc -m option is used to pass module name if module-info generation is desired. Here is updated webrev with all suggestions included: http://cr.openjdk.java.net/~aefimov/8164479/04/ Roman On 11/03/2016 09:37 PM, Mandy Chung wrote: >> On Nov 3, 2016, at 4:53 AM, Roman Grigoriadi wrote: >> >> CCC for CommandInfo changes is now approved (http://ccc.us.oracle.com/8047773), you can find new webrev here: >> >> http://cr.openjdk.java.net/~aefimov/8164479/03/ >> > javax/activation/CommandInfo.java > > 92 * When java.beans.Beans is not visible (when java.desktop module is not > > Formatting nit: ?java.beans.Beans? and ?java.desktop? can be wrapped with {@code?} > > 218 Class beanClass = Class.forName(cn, true, loader); > > I suggest to not to initialize the class in the Class::forName call (i.e. s/true/false) > > 220 return beanClass.newInstance(); > Class::newInstance is deprecated in JDK 9. Can you replace it with Class::getDeclaredConstructor and Constructor::newInstance > > > What does wsimport and xjc -m option do? > > 67 private static final String JAXWS_PACKAGE = "java.xml.ws?; > > - Is it a module name, not package name? > > Does java.xml.ws module still require java.rmi? Should it be updated? > > Otherwise, looks okay to me. > > Mandy From andrey.x.nazarov at oracle.com Tue Nov 8 14:04:55 2016 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Tue, 8 Nov 2016 17:04:55 +0300 Subject: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options In-Reply-To: <260cd370-a550-4403-89a3-6255b6106cbe@default> References: <260cd370-a550-4403-89a3-6255b6106cbe@default> Message-ID: <56800DAF-B1AE-4E16-BE85-4566BB067F38@oracle.com> Hi, Looks OK to me. I can suggest two more cases. A directory and file symlink can be passed in options where tool requires a file path. ?Andrey > On 8 Nov 2016, at 16:17, Denis Kononenko wrote: > > > Hi, > > The new version of changes. > > - Switched back to jdk/test/testlibrary to avoid unwanted dependencies (JImageToolTest.java); > - Verified tests on smallest possible JDK build. > > WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.02/ > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > > Thank you, > Denis. > >> Denis, >> >> I can see that you have switched to the top level test library with >> this change. With that you are getting more module dependencies than >> just java.base. First of all, it would probably make sense to build >> only the classes you needed (which would be >> jdk.test.lib.process.ProcessTools, I assume), but even if you only >> build that, jdk.test.lib.process.ProcessTools has dependencies outside >> java.base module. >> >> You either have to declare @modules in your test or go back to the >> jdk/test/lib/testlibrary. Then, of course, unneeded module >> dependencies are questionable. >> >> Shura >> >> >>> On Nov 3, 2016, at 6:29 AM, Denis Kononenko >> wrote: >>> >>> Hi, >>> >>> I've done some rework accordingly to Alan's and Shura's comments: >>> >>> 1) removed overlapped tests from JImageToolTest.java; >>> >>> 2) added new tests JImageVerifyTest.java for jimage verify; >>> >>> 3) reorganized jtreg's tags; >>> >>> The new WEBREV can be found here: >> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/ >>> >>> Thank you, >>> Denis. >>> >>> On 06.10.2016 19:37, Denis Kononenko wrote: >>>> Hi, >>>> >>>> Could someone please review these new tests for jimage utility. >>>> >>>> There're 5 new files containing tests to cover use cases for >> 'info', 'list', 'extract' and other options. No new tests for >> 'verify'. >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 >>>> WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/ >>>> >>>> >>>> Thank you, >>>> Denis. >>> From mandy.chung at oracle.com Tue Nov 8 16:45:49 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 8 Nov 2016 08:45:49 -0800 Subject: RFR: 8164479: Update JAX-WS RI integration to latest version In-Reply-To: <3dfa6703-de07-a13f-562d-e22ae50da77d@oracle.com> References: <1c63a0dc-d38d-0148-016c-30b15721d6a6@oracle.com> <3F91468F-78B2-4D3D-80D2-E429D8FAFC61@oracle.com> <57E5909E.3050702@oracle.com> <5754D4FE-0D20-4527-B163-E9224E3A4FDD@oracle.com> <5ac5eeec-fe39-0728-1ee4-2bc8684722d1@oracle.com> <435c44ae-51fc-c727-915c-6acb499d72a9@oracle.com> <4bbb97c4-4423-30b3-b906-95ff56dda779@oracle.com> <4ff0efee-19fe-8125-163c-5f2981941e39@oracle.com> <01423715-826e-8b53-0060-93a2e513138c@oracle.com> <4E89C684-9EE0-468A-8068-412A8BBF991E@oracle.com> <3dfa6703-de07-a13f-562d-e22ae50da77d@oracle.com> Message-ID: > On Nov 8, 2016, at 5:18 AM, Roman Grigoriadi wrote: > > Thanks for suggestions Mandy. xjc -m option is used to pass module name if module-info generation is desired. Here is updated webrev with all suggestions included: > > http://cr.openjdk.java.net/~aefimov/8164479/04/ > +1. One javadoc comment: 90 * If {@code java.beans.Beans} is visible then it's {@link Beans#instantiate} I don?t see an import java.beans.Beans and so does javadoc issue warning for {@link Beans#instantiate}? You can run make docs to check for any javadoc warnings. No need to generate a new webrev. Mandy > Roman > > > On 11/03/2016 09:37 PM, Mandy Chung wrote: >>> On Nov 3, 2016, at 4:53 AM, Roman Grigoriadi wrote: >>> >>> CCC for CommandInfo changes is now approved (http://ccc.us.oracle.com/8047773), you can find new webrev here: >>> >>> http://cr.openjdk.java.net/~aefimov/8164479/03/ >>> >> javax/activation/CommandInfo.java >> >> 92 * When java.beans.Beans is not visible (when java.desktop module is not >> >> Formatting nit: ?java.beans.Beans? and ?java.desktop? can be wrapped with {@code?} >> >> 218 Class beanClass = Class.forName(cn, true, loader); >> >> I suggest to not to initialize the class in the Class::forName call (i.e. s/true/false) >> >> 220 return beanClass.newInstance(); >> Class::newInstance is deprecated in JDK 9. Can you replace it with Class::getDeclaredConstructor and Constructor::newInstance >> >> >> What does wsimport and xjc -m option do? >> >> 67 private static final String JAXWS_PACKAGE = "java.xml.ws?; >> >> - Is it a module name, not package name? >> >> Does java.xml.ws module still require java.rmi? Should it be updated? >> >> Otherwise, looks okay to me. >> >> Mandy > From kumar.x.srinivasan at oracle.com Tue Nov 8 17:28:06 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 08 Nov 2016 09:28:06 -0800 Subject: 8169001: Remove launcher's built-in ergonomics In-Reply-To: <6a3463cb-6e3f-a5cd-601a-2bb6f715eef1@oracle.com> References: <5820CC54.4010401@oracle.com> <6a3463cb-6e3f-a5cd-601a-2bb6f715eef1@oracle.com> Message-ID: <58220B26.9020907@oracle.com> Hi David, Thanks for the review please see embedded comments: > Hi Kumar, > > On 8/11/2016 4:47 AM, Kumar Srinivasan wrote: >> >> Hello, >> >> Please review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8169001 >> >> Webrev at: >> http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/ > > Overall this looks like a complete eradication of the launcher > ergonomics. A few specific comments: > > src/java.base/share/native/launcher/main.c > > ! const_cpwildcard, const_javaw, 0); > > Can you clarify this change with > > ! const_cpwildcard, const_javaw, 0 /* unused */); To clarify: -159 const_cpwildcard, const_javaw, const_ergo_class); +159 const_cpwildcard, const_javaw, 0); JLI_Launch is an *internal* entry point, this is primarily used in main.c, and this is called by JDK's tool launchers which sets "NEVER_ACT_AS_SERVER", also this entry point is used by the java packager and deployment, I have cc'ed Chris Bensen and David DeHaven, my take is not to change the signature now. Chris, David ? > > Thanks. > > --- > > src/java.base/share/native/libjli/java.c > > 220 jint ergo /* unused */ > > I assume JLI_Launch is an exported API otherwise I'd expect this to be > deleted. The fact it is unused should also be documented in > src/java.base/share/native/libjli/java.h. But I'm also wondering where > this API change is being documented for external users? This entry point is for internal users only. > > - FreeKnownVMs(); /* after last possible PrintUsage() */ > > Not clear why you no longer need to free here. But if you don't then > FreeKnownVMs() seems to be dead code now. Ugh (and thanks!), I was too aggressive, this should remain, I will put it back in the next revision. > > --- > > src/java.base/unix/conf/i586/jvm.cfg > > I think you still need an entry for "-client KNOWN" as anyone can > build the client VM if they choose. Ditto for > src/java.base/unix/conf/sparc/jvm.cfg (though 32-bit Solaris builds > are obsolete now). I had to mull on this, one hand jvm.cfg should reflect the VMs we support, but we could have someone build client vm. I will go with making the change you suggested. > > --- > > You have updated a number of copyright notices but not all of them. Yes, I vaguely recall, that the CR should be updated if there is any content that ought to be copyrighted, in this case several changes are typo fixups in the comments. So I don't think it is warranted. > > --- > > I see no changes to tests, but I'm pretty sure we have a test for > server-class-machine somewhere (or we did - I recall it breaking at > some point). I ran -testset pit, saw no failures, I will perform a -testset hotspot. Note though, several test changes had to be made, when Solaris 32-bit was yanked out. Thanks Kumar > > Thanks, > David > >> Background: >>> Launcher ergonomics was introduced last decade to help determine >>> if the execution system is "Server Class", this was necessary to >>> choose server VM on platforms that supported both client and server >>> VMs (primarily for Solaris and Linux 32-bit). >>> >>> The algorithm involves computing and detecting the number of CPUs >>> and the amount of memory on the target system. All modern computers >>> systems with hyper-threading cause the ergonomics to choose server. >>> >>> JDK9 Platforms that have only server vm. >>> >>> ./linux-x64/lib/amd64/server/libjvm.so >>> ./linux-arm64-vfp-hflt/lib/aarch64/server/libjvm.so >>> ./solaris-sparcv9/lib/sparcv9/server/libjvm.so >>> ./solaris-x64/lib/amd64/server/libjvm.so >>> ./windows-x86/bin/server/jvm.dll >>> ./windows-x64/bin/server/jvm.dll >>> >>> JDK9 Platforms that have more than one vm variant: >>> ./linux-arm32-vfp-hflt/lib/arm/client/libjvm.so (default) >>> ./linux-arm32-vfp-hflt/lib/arm/minimal/libjvm.so >>> >>> ./linux-x86/lib/i386/server/libjvm.so (default) >>> ./linux-x86/lib/i386/minimal/libjvm.so >>> >>> >>> In the cases where multiple VMs are supported the ergnomics >>> has no effect, and the default platforms are chosen by the >>> jvm.cfg. Thus the launcher ergonomics is obsolete and redundant. >> >> Thanks >> Kumar >> From huizhe.wang at oracle.com Tue Nov 8 17:58:18 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 8 Nov 2016 09:58:18 -0800 Subject: XALAN: Text node of value 'null' - Is this illegal or does XSLTC have an issue here? In-Reply-To: <7ba8848d50b54d878ff63a17f7f8e2dd@DEROTE13DE07.global.corp.sap> References: <957da990d3b845d1aa055135ceed2861@DEROTE13DE07.global.corp.sap> <7ba8848d50b54d878ff63a17f7f8e2dd@DEROTE13DE07.global.corp.sap> Message-ID: <74a0cccd-fec3-47e1-7d2b-2958af0205fe@oracle.com> On 11/7/2016 11:31 PM, Langer, Christoph wrote: > > Hi Joe, > > thanks for your comments. > > Yes the customer does not really want to insert a null value but > create an empty text node. So they?ll fix their code anyway. > > However, I thought it would be a good Idea to make the Serializer more > robust with regards to such null data. Especially given that it?s > possible via the DOM API to construct such null nodes. So I take you > support this endeavor? > Sure. Some null-checks are welcome. Thanks, Joe > Thanks > > Christoph > > *From:*huizhe wang [mailto:huizhe.wang at oracle.com] > *Sent:* Dienstag, 8. November 2016 06:01 > *To:* Langer, Christoph ; Aleks Efimov > ; Lance Andersen > *Cc:* core-libs-dev at openjdk.java.net > *Subject:* Re: XALAN: Text node of value 'null' - Is this illegal or > does XSLTC have an issue here? > > Looks like a null check-in is desirable. If the intention is to add a > text node, which I assume was his intention, he wouldn't want a null > node. If the intention is to create an empty element, then he didn't > need the line that added the null text node. > > As far as DOM goes, it would have been better if it was clearer on how > null be handled (a DOMException probably). But for a 10+ yr old API, > the case is not enough to call for a change of the behavior. > > Thanks, > Joe > > On 11/7/2016 8:09 AM, Langer, Christoph wrote: > > Hi Xalan experts, > > I?ve recently handled a customer issue about Text Nodes of value > ?null? inside a DOM, causing an exception during XALAN XSLT > transformation. The repro case is quite simple. Consider the > following small Java sample [1] which creates a DOM from a very > basic XML, inserts a text node with value null into the DOM and > then runs an identity transformation on it. Without inserting the > null Text node, it would run without issues. However, the > com.sun.org.apache.xml.internal.serializer.ToUnknownStream class > stumbles over the null value and the transformation throws an NPE > [2]. I believe this could be easily fixed by adding a null check > in the serializer and handling null like ??. However, would you > agree that it is a real issue worth fixing or should one rather > stress the point that Text Nodes of null are illegal? (Is that > true, anyway? Didn?t find any specification about that?) Please > let me know your opinion ? and if you agree I would work on a fix. > > Thanks in advance for comments > > Christoph > > [1] Sample code: > > import java.io.ByteArrayInputStream; > > import java.io.ByteArrayOutputStream; > > import java.io.IOException; > > import javax.xml.parsers.DocumentBuilder; > > import javax.xml.parsers.DocumentBuilderFactory; > > import javax.xml.parsers.ParserConfigurationException; > > import javax.xml.transform.TransformerException; > > import javax.xml.transform.TransformerFactory; > > import javax.xml.transform.dom.DOMSource; > > import javax.xml.transform.stream.StreamResult; > > import org.w3c.dom.Document; > > import org.w3c.dom.Element; > > import org.xml.sax.SAXException; > > public class TestTransformWithNullText { > > public static void main(String[] args) throws > ParserConfigurationException, SAXException, IOException, > TransformerException { > > // create a small DOM > > DocumentBuilder db = > DocumentBuilderFactory.newInstance().newDocumentBuilder(); > > Document doc = db.parse(new ByteArrayInputStream(" version=\"1.0\"?>".getBytes())); > > // insert a bad element > > Element e = doc.createElement("ERROR"); > > e.appendChild(doc.createTextNode(null)); > > doc.getDocumentElement().appendChild(e); > > // transform > > ByteArrayOutputStream bos = new ByteArrayOutputStream(); > > TransformerFactory.newInstance().newTransformer().transform( > > new DOMSource(doc.getDocumentElement()), new StreamResult(bos)); > > System.out.println(bos); > > } > > } > > [2] Exception encountered: > > Exception in thread "main" > javax.xml.transform.TransformerException: > java.lang.NullPointerException > > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(java.xml at 9.0.0.1-internal/TransformerImpl.java:789 > ) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(java.xml at 9.0.0.1-internal/TransformerImpl.java:376 > ) > > at > com.sap.cl.xml.test.transform.TestTransformWithNullText.main(TestTransformWithNullText.java:33) > > Caused by: java.lang.NullPointerException > > at > com.sun.org.apache.xml.internal.serializer.ToUnknownStream.characters(java.xml at 9.0.0.1-internal/ToUnknownStream.java:342 > ) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:244 > ) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:230 > ) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:230 > ) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:94 > ) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(java.xml at 9.0.0.1-internal/TransformerImpl.java:718 > ) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(java.xml at 9.0.0.1-internal/TransformerImpl.java:780 > ) > > ... 2 more > > --------- > > java.lang.NullPointerException > > at > com.sun.org.apache.xml.internal.serializer.ToUnknownStream.characters(java.xml at 9.0.0.1-internal/ToUnknownStream.java:342 > ) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:244 > ) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:230 > ) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:230 > ) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(java.xml at 9.0.0.1-internal/DOM2TO.java:94 > ) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(java.xml at 9.0.0.1-internal/TransformerImpl.java:718 > ) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(java.xml at 9.0.0.1-internal/TransformerImpl.java:780 > ) > > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(java.xml at 9.0.0.1-internal/TransformerImpl.java:376 > ) > > at > com.sap.cl.xml.test.transform.TestTransformWithNullText.main(TestTransformWithNullText.java:33) > From lance.andersen at oracle.com Tue Nov 8 19:04:18 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 8 Nov 2016 14:04:18 -0500 Subject: RFR: 8164479: Update JAX-WS RI integration to latest version In-Reply-To: References: <1c63a0dc-d38d-0148-016c-30b15721d6a6@oracle.com> <3F91468F-78B2-4D3D-80D2-E429D8FAFC61@oracle.com> <57E5909E.3050702@oracle.com> <5754D4FE-0D20-4527-B163-E9224E3A4FDD@oracle.com> <5ac5eeec-fe39-0728-1ee4-2bc8684722d1@oracle.com> <435c44ae-51fc-c727-915c-6acb499d72a9@oracle.com> <4bbb97c4-4423-30b3-b906-95ff56dda779@oracle.com> <4ff0efee-19fe-8125-163c-5f2981941e39@oracle.com> <01423715-826e-8b53-0060-93a2e513138c@oracle.com> <4E89C684-9EE0-468A-8068-412A8BBF991E@oracle.com> <3dfa6703-de07-a13f-562d-e22ae50da77d@oracle.com> Message-ID: <5AE09F2A-2975-48F2-8567-A3718AB8513A@oracle.com> Hi Roman, Not sure why there is an @since in package.html http://cr.openjdk.java.net/~aefimov/8164479/04/raw_files/new/jaxws/src/java.xml.bind/share/classes/javax/xml/bind/attachment/package.html it shows up as: ???? Related Standards [1]SOAP Message Transmission Optimization Mechanism [2]XML-binary Optimized Packaging [3]WS-I Attachments Profile Version 1.0. [4]Describing Media Content of Binary Data in XML @since JAXB 2.0 ?????? Best Lance > On Nov 8, 2016, at 11:45 AM, Mandy Chung wrote: > > >> On Nov 8, 2016, at 5:18 AM, Roman Grigoriadi wrote: >> >> Thanks for suggestions Mandy. xjc -m option is used to pass module name if module-info generation is desired. Here is updated webrev with all suggestions included: >> >> http://cr.openjdk.java.net/~aefimov/8164479/04/ >> > > > +1. > > > One javadoc comment: > > 90 * If {@code java.beans.Beans} is visible then it's {@link Beans#instantiate} > > I don?t see an import java.beans.Beans and so does javadoc issue warning for {@link Beans#instantiate}? > > You can run make docs to check for any javadoc warnings. > > No need to generate a new webrev. > > Mandy > >> Roman >> >> >> On 11/03/2016 09:37 PM, Mandy Chung wrote: >>>> On Nov 3, 2016, at 4:53 AM, Roman Grigoriadi wrote: >>>> >>>> CCC for CommandInfo changes is now approved (http://ccc.us.oracle.com/8047773), you can find new webrev here: >>>> >>>> http://cr.openjdk.java.net/~aefimov/8164479/03/ >>>> >>> javax/activation/CommandInfo.java >>> >>> 92 * When java.beans.Beans is not visible (when java.desktop module is not >>> >>> Formatting nit: ?java.beans.Beans? and ?java.desktop? can be wrapped with {@code?} >>> >>> 218 Class beanClass = Class.forName(cn, true, loader); >>> >>> I suggest to not to initialize the class in the Class::forName call (i.e. s/true/false) >>> >>> 220 return beanClass.newInstance(); >>> Class::newInstance is deprecated in JDK 9. Can you replace it with Class::getDeclaredConstructor and Constructor::newInstance >>> >>> >>> What does wsimport and xjc -m option do? >>> >>> 67 private static final String JAXWS_PACKAGE = "java.xml.ws?; >>> >>> - Is it a module name, not package name? >>> >>> Does java.xml.ws module still require java.rmi? Should it be updated? >>> >>> Otherwise, looks okay to me. >>> >>> Mandy >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From xueming.shen at oracle.com Tue Nov 8 21:30:28 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 08 Nov 2016 13:30:28 -0800 Subject: RFR 9: JDK-8168862:Tighten permissions granted to the jdk.zipfs module In-Reply-To: <5660258f-fb68-7458-b38e-b34e4cda447b@oracle.com> References: <5817A8E7.2070203@oracle.com> <5660258f-fb68-7458-b38e-b34e4cda447b@oracle.com> Message-ID: <582243F4.5030303@oracle.com> On 10/31/2016 01:56 PM, Sean Mullan wrote: > It would be good to add or modify existing test(s) to run with a Security Manager, if there is not one already. Hi Sean, All current zipfs tests are being run under "default" security manager as one of their testing scenario, for example * @summary Test Zip filesystem provider * @run main ZipFSTester * @run main/othervm/java.security.policy=test.policy ZipFSTester * @modules jdk.zipfs -sherman > > --Sean > > On 10/31/16 4:32 PM, Mandy Chung wrote: >> +1 >> Mandy >> >>> On Oct 31, 2016, at 1:26 PM, Xueming Shen wrote: >>> >>> Please help review the change for >>> >>> issue: https://bugs.openjdk.java.net/browse/JDK-8168862 >>> webre: http://cr.openjdk.java.net/~sherman/8168862 >>> >>> The change is to tighten the permission to read "os.name" only. >>> >>> Thanks, >>> Xueming >> From sean.mullan at oracle.com Tue Nov 8 21:46:51 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 8 Nov 2016 16:46:51 -0500 Subject: RFR 9: JDK-8168862:Tighten permissions granted to the jdk.zipfs module In-Reply-To: <582243F4.5030303@oracle.com> References: <5817A8E7.2070203@oracle.com> <5660258f-fb68-7458-b38e-b34e4cda447b@oracle.com> <582243F4.5030303@oracle.com> Message-ID: <6b411578-b393-0050-f7dd-70ef75ed35f6@oracle.com> On 11/8/16 4:30 PM, Xueming Shen wrote: > On 10/31/2016 01:56 PM, Sean Mullan wrote: >> It would be good to add or modify existing test(s) to run with a >> Security Manager, if there is not one already. > > Hi Sean, > > All current zipfs tests are being run under "default" security manager as > one of their testing scenario, for example > > * @summary Test Zip filesystem provider > * @run main ZipFSTester > * @run main/othervm/java.security.policy=test.policy ZipFSTester > * @modules jdk.zipfs Ok, sounds good, thanks for checking. --Sean > > > -sherman > > >> >> --Sean >> >> On 10/31/16 4:32 PM, Mandy Chung wrote: >>> +1 >>> Mandy >>> >>>> On Oct 31, 2016, at 1:26 PM, Xueming Shen >>>> wrote: >>>> >>>> Please help review the change for >>>> >>>> issue: https://bugs.openjdk.java.net/browse/JDK-8168862 >>>> webre: http://cr.openjdk.java.net/~sherman/8168862 >>>> >>>> The change is to tighten the permission to read "os.name" only. >>>> >>>> Thanks, >>>> Xueming >>> > From paul.sandoz at oracle.com Tue Nov 8 23:27:30 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 8 Nov 2016 15:27:30 -0800 Subject: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue Message-ID: <314D8B90-3D99-4666-A1B4-3152C0D103D3@oracle.com> Hi, Please review the addition of an api note to ClassValue.computeValue. There is some history behind this issue. Another issue was logged [1] related to Groovy using ClassValue and there being a memory leak with classes/loaders not being GC?ed, but it turned out the problem was with Groovy's explicit retention of computed values in a global set. So i closed that issue down. But, there is an edge case where it?s possible to induce out of memory errors with ClassValue, specifically if the computed value holds onto the corresponding ClassValue instance. I think this is an edge case and does not warrant a change to the ClassValue implementation to support weak refs to computed values which is likely to complicate an already intricate implementation and perturb its performance characteristics. So i have opted for an api note. I don?t want to normatively specify this, nor do i want to allude to various implementation details. (One can argue a similar note could be written for ThreadLocal.) Thanks, Paul. [1] https://bugs.openjdk.java.net/browse/JDK-8136353 --- a/src/java.base/share/classes/java/lang/ClassValue.java Tue Nov 08 12:36:21 2016 -0800 +++ b/src/java.base/share/classes/java/lang/ClassValue.java Tue Nov 08 15:25:04 2016 -0800 @@ -62,6 +62,13 @@ * If this method throws an exception, the corresponding call to {@code get} * will terminate abnormally with that exception, and no class value will be recorded. * + * @apiNote + * Care should be taken to ensure that this {@code ClassValue} is not + * strongly reachable + * from the computed value. Doing so may prevent classes and their loaders + * from being garbage collected which in turn may induce out of memory + * errors. + * * @param type the type whose class value must be computed * @return the newly computed value associated with this {@code ClassValue}, for the given class or interface * @see #get From paul.sandoz at oracle.com Tue Nov 8 23:52:38 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 8 Nov 2016 15:52:38 -0800 Subject: RFR 8164934: Optional.map() javadoc code example is incorrect Message-ID: <5CD8BCEC-39E5-4919-977C-F0B37E7EEDA5@oracle.com> Hi, Please review an update to the api note of Optional.map() which embarrassingly contained erroneous code (labouring under the misapprehension that exception transparency is supported!). I tweaked the example to refer to a Stream where a URI is transformed into a Path. Paul. diff -r df7e627c7224 src/java.base/share/classes/java/util/Optional.java --- a/src/java.base/share/classes/java/util/Optional.java Tue Nov 08 15:28:44 2016 -0800 +++ b/src/java.base/share/classes/java/util/Optional.java Tue Nov 08 15:37:23 2016 -0800 @@ -214,20 +214,20 @@ * @apiNote * This method supports post-processing on {@code Optional} values, without * the need to explicitly check for a return status. For example, the - * following code traverses a stream of file names, selects one that has not - * yet been processed, and then opens that file, returning an - * {@code Optional}: + * following code traverses a stream of URIs, selects one that has not + * yet been processed, and creates a path from that URI, returning + * an {@code Optional}: * * 

      {@code
-     *     Optional fis =
-     *         names.stream().filter(name -> !isProcessedYet(name))
+     *     Optional p =
+     *         uris.stream().filter(uri -> !isProcessedYet(uri))
      *                       .findFirst()
-     *                       .map(name -> new FileInputStream(name));
+     *                       .map(Paths::get);
      * }
      * - * Here, {@code findFirst} returns an {@code Optional}, and then - * {@code map} returns an {@code Optional} for the desired - * file if one exists. + * Here, {@code findFirst} returns an {@code Optional}, and then + * {@code map} returns an {@code Optional} for the desired + * URI if one exists. * * @param mapper the mapping function to apply to a value, if present * @param The type of the value returned from the mapping function From david.holmes at oracle.com Wed Nov 9 00:22:42 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Nov 2016 10:22:42 +1000 Subject: 8169001: Remove launcher's built-in ergonomics In-Reply-To: <58220B26.9020907@oracle.com> References: <5820CC54.4010401@oracle.com> <6a3463cb-6e3f-a5cd-601a-2bb6f715eef1@oracle.com> <58220B26.9020907@oracle.com> Message-ID: <9b86332d-be53-2fd4-f5bd-498b3c94fe05@oracle.com> Hi Kumar, FYI regarding the test, I was mis-remembering - it was actually an issue with the VM's notion of is_server_class_machine(), not the launcher. It's used for GC ergonomic selection. Cheers, David On 9/11/2016 3:28 AM, Kumar Srinivasan wrote: > > Hi David, > > Thanks for the review please see embedded comments: > >> Hi Kumar, >> >> On 8/11/2016 4:47 AM, Kumar Srinivasan wrote: >>> >>> Hello, >>> >>> Please review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8169001 >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/ >> >> Overall this looks like a complete eradication of the launcher >> ergonomics. A few specific comments: >> >> src/java.base/share/native/launcher/main.c >> >> ! const_cpwildcard, const_javaw, 0); >> >> Can you clarify this change with >> >> ! const_cpwildcard, const_javaw, 0 /* unused */); > > To clarify: > > -159 const_cpwildcard, const_javaw, const_ergo_class); > +159 const_cpwildcard, const_javaw, 0); > > > JLI_Launch is an *internal* entry point, this is primarily used in main.c, > and this is called by JDK's tool launchers which sets > "NEVER_ACT_AS_SERVER", > also this entry point is used by the java packager and deployment, I > have cc'ed > Chris Bensen and David DeHaven, my take is not to change the signature now. > Chris, David ? > >> >> Thanks. >> >> --- >> >> src/java.base/share/native/libjli/java.c >> >> 220 jint ergo /* unused */ >> >> I assume JLI_Launch is an exported API otherwise I'd expect this to be >> deleted. The fact it is unused should also be documented in >> src/java.base/share/native/libjli/java.h. But I'm also wondering where >> this API change is being documented for external users? > > This entry point is for internal users only. > >> >> - FreeKnownVMs(); /* after last possible PrintUsage() */ >> >> Not clear why you no longer need to free here. But if you don't then >> FreeKnownVMs() seems to be dead code now. > > Ugh (and thanks!), I was too aggressive, this should remain, I will put > it back in the next revision. > >> >> --- >> >> src/java.base/unix/conf/i586/jvm.cfg >> >> I think you still need an entry for "-client KNOWN" as anyone can >> build the client VM if they choose. Ditto for >> src/java.base/unix/conf/sparc/jvm.cfg (though 32-bit Solaris builds >> are obsolete now). > > I had to mull on this, one hand jvm.cfg should reflect the VMs we support, > but we could have someone build client vm. I will go with making the change > you suggested. > >> >> --- >> >> You have updated a number of copyright notices but not all of them. > > Yes, I vaguely recall, that the CR should be updated if there is any > content > that ought to be copyrighted, in this case several changes are typo > fixups in the > comments. So I don't think it is warranted. > >> >> --- >> >> I see no changes to tests, but I'm pretty sure we have a test for >> server-class-machine somewhere (or we did - I recall it breaking at >> some point). > > I ran -testset pit, saw no failures, I will perform a -testset hotspot. > Note though, several test changes had to be made, when Solaris 32-bit > was yanked out. > > Thanks > Kumar > >> >> Thanks, >> David >> >>> Background: >>>> Launcher ergonomics was introduced last decade to help determine >>>> if the execution system is "Server Class", this was necessary to >>>> choose server VM on platforms that supported both client and server >>>> VMs (primarily for Solaris and Linux 32-bit). >>>> >>>> The algorithm involves computing and detecting the number of CPUs >>>> and the amount of memory on the target system. All modern computers >>>> systems with hyper-threading cause the ergonomics to choose server. >>>> >>>> JDK9 Platforms that have only server vm. >>>> >>>> ./linux-x64/lib/amd64/server/libjvm.so >>>> ./linux-arm64-vfp-hflt/lib/aarch64/server/libjvm.so >>>> ./solaris-sparcv9/lib/sparcv9/server/libjvm.so >>>> ./solaris-x64/lib/amd64/server/libjvm.so >>>> ./windows-x86/bin/server/jvm.dll >>>> ./windows-x64/bin/server/jvm.dll >>>> >>>> JDK9 Platforms that have more than one vm variant: >>>> ./linux-arm32-vfp-hflt/lib/arm/client/libjvm.so (default) >>>> ./linux-arm32-vfp-hflt/lib/arm/minimal/libjvm.so >>>> >>>> ./linux-x86/lib/i386/server/libjvm.so (default) >>>> ./linux-x86/lib/i386/minimal/libjvm.so >>>> >>>> >>>> In the cases where multiple VMs are supported the ergnomics >>>> has no effect, and the default platforms are chosen by the >>>> jvm.cfg. Thus the launcher ergonomics is obsolete and redundant. >>> >>> Thanks >>> Kumar >>> > From paul.sandoz at oracle.com Wed Nov 9 00:43:52 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 8 Nov 2016 16:43:52 -0800 Subject: RFR 8132097: Stream.generate should use a covariant Supplier as parameter Message-ID: <253C6046-0340-4B06-8F58-3407DB0D7E28@oracle.com> Hi Please review this compatible fix to Stream.generate to accept a covariant Supplier. Paul. diff -r 3e3ca9800322 src/java.base/share/classes/java/util/stream/Stream.java --- a/src/java.base/share/classes/java/util/stream/Stream.java Tue Nov 08 15:37:20 2016 -0800 +++ b/src/java.base/share/classes/java/util/stream/Stream.java Tue Nov 08 16:36:51 2016 -0800 @@ -1327,7 +1327,7 @@ * @param s the {@code Supplier} of generated elements * @return a new infinite sequential unordered {@code Stream} */ - public static Stream generate(Supplier s) { + public static Stream generate(Supplier s) { Objects.requireNonNull(s); return StreamSupport.stream( new StreamSpliterators.InfiniteSupplyingSpliterator.OfRef<>(Long.MAX_VALUE, s), false); diff -r 3e3ca9800322 src/java.base/share/classes/java/util/stream/StreamSpliterators.java --- a/src/java.base/share/classes/java/util/stream/StreamSpliterators.java Tue Nov 08 15:37:20 2016 -0800 +++ b/src/java.base/share/classes/java/util/stream/StreamSpliterators.java Tue Nov 08 16:36:51 2016 -0800 @@ -1346,9 +1346,9 @@ } static final class OfRef extends InfiniteSupplyingSpliterator { - final Supplier s; + final Supplier s; - OfRef(long size, Supplier s) { + OfRef(long size, Supplier s) { super(size); this.s = s; } From forax at univ-mlv.fr Wed Nov 9 06:35:43 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 09 Nov 2016 06:35:43 +0000 Subject: RFR 8132097: Stream.generate should use a covariant Supplier as parameter In-Reply-To: <253C6046-0340-4B06-8F58-3407DB0D7E28@oracle.com> References: <253C6046-0340-4B06-8F58-3407DB0D7E28@oracle.com> Message-ID: Good for me ! Remi On November 9, 2016 1:43:52 AM GMT+01:00, Paul Sandoz wrote: >Hi > >Please review this compatible fix to Stream.generate to accept a >covariant Supplier. > >Paul. > >diff -r 3e3ca9800322 >src/java.base/share/classes/java/util/stream/Stream.java >--- a/src/java.base/share/classes/java/util/stream/Stream.java Tue Nov >08 15:37:20 2016 -0800 >+++ b/src/java.base/share/classes/java/util/stream/Stream.java Tue Nov >08 16:36:51 2016 -0800 >@@ -1327,7 +1327,7 @@ > * @param s the {@code Supplier} of generated elements > * @return a new infinite sequential unordered {@code Stream} > */ >- public static Stream generate(Supplier s) { >+ public static Stream generate(Supplier s) { > Objects.requireNonNull(s); > return StreamSupport.stream( >new >StreamSpliterators.InfiniteSupplyingSpliterator.OfRef<>(Long.MAX_VALUE, >s), false); >diff -r 3e3ca9800322 >src/java.base/share/classes/java/util/stream/StreamSpliterators.java >--- >a/src/java.base/share/classes/java/util/stream/StreamSpliterators.java Tue >Nov 08 15:37:20 2016 -0800 >+++ >b/src/java.base/share/classes/java/util/stream/StreamSpliterators.java Tue >Nov 08 16:36:51 2016 -0800 >@@ -1346,9 +1346,9 @@ > } > > static final class OfRef extends InfiniteSupplyingSpliterator { >- final Supplier s; >+ final Supplier s; > >- OfRef(long size, Supplier s) { >+ OfRef(long size, Supplier s) { > super(size); > this.s = s; > } -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From forax at univ-mlv.fr Wed Nov 9 07:18:51 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 09 Nov 2016 07:18:51 +0000 Subject: RFR 8164934: Optional.map() javadoc code example is incorrect In-Reply-To: <5CD8BCEC-39E5-4919-977C-F0B37E7EEDA5@oracle.com> References: <5CD8BCEC-39E5-4919-977C-F0B37E7EEDA5@oracle.com> Message-ID: <1EA02C5B-A9E8-41C9-8949-B52F16CCEA09@univ-mlv.fr> Looks good. At some point we should provide a way to de-activate checked exception in Java ! I vote for 10. I know it's a bold move but seriously checked exception are fine as feature until you try to compose it with another feature. This is a perfect example of why checked exceptions are a bad feature. If you take a look to the code, you do not see why it is wrong. From a language that make readability of the code one of its most important goals, I think we should stop pretending that checked exceptions are a feature. Automatic exception transparency (otherwise it's not backward compatible) works like @SafeVarags, you have to know the precise implementation to guarantee that an exception do not escape (stored in a Future by example), so it's not practical. The only benefit of checked exception is documentation, i think it was an important factor in the early days of Java. But now, we are used to document any exceptions checked or not. So we should recognise that checked was an idea of the past (like multiple inheritance) and move on. regards, R?mi On November 9, 2016 12:52:38 AM GMT+01:00, Paul Sandoz wrote: >Hi, > >Please review an update to the api note of Optional.map() which >embarrassingly contained erroneous code (labouring under the >misapprehension that exception transparency is supported!). > >I tweaked the example to refer to a Stream where a URI is >transformed into a Path. > >Paul. > >diff -r df7e627c7224 >src/java.base/share/classes/java/util/Optional.java >--- a/src/java.base/share/classes/java/util/Optional.java Tue Nov 08 >15:28:44 2016 -0800 >+++ b/src/java.base/share/classes/java/util/Optional.java Tue Nov 08 >15:37:23 2016 -0800 >@@ -214,20 +214,20 @@ > * @apiNote >* This method supports post-processing on {@code Optional} values, >without > * the need to explicitly check for a return status. For example, the >- * following code traverses a stream of file names, selects one >that has not >- * yet been processed, and then opens that file, returning an >- * {@code Optional}: >+ * following code traverses a stream of URIs, selects one that has >not >+ * yet been processed, and creates a path from that URI, returning >+ * an {@code Optional}: > * > * 
      {@code
>-     *     Optional fis =
>-     *         names.stream().filter(name -> !isProcessedYet(name))
>+     *     Optional p =
>+     *         uris.stream().filter(uri -> !isProcessedYet(uri))
>      *                       .findFirst()
>-     *                       .map(name -> new FileInputStream(name));
>+     *                       .map(Paths::get);
>      * }
      > * >- * Here, {@code findFirst} returns an {@code Optional}, >and then >- * {@code map} returns an {@code Optional} for >the desired >- * file if one exists. >+ * Here, {@code findFirst} returns an {@code Optional}, and >then >+ * {@code map} returns an {@code Optional} for the desired >+ * URI if one exists. > * > * @param mapper the mapping function to apply to a value, if present > * @param The type of the value returned from the mapping function -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From peter.levart at gmail.com Wed Nov 9 08:13:54 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 9 Nov 2016 09:13:54 +0100 Subject: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue In-Reply-To: <314D8B90-3D99-4666-A1B4-3152C0D103D3@oracle.com> References: <314D8B90-3D99-4666-A1B4-3152C0D103D3@oracle.com> Message-ID: <0308ce68-14b9-8297-1929-fef2b6c0c37f@gmail.com> Hi Paul, On 11/09/2016 12:27 AM, Paul Sandoz wrote: > Hi, > > Please review the addition of an api note to ClassValue.computeValue. > > There is some history behind this issue. Another issue was logged [1] related to Groovy using ClassValue and there being a memory leak with classes/loaders not being GC?ed, but it turned out the problem was with Groovy's explicit retention of computed values in a global set. So i closed that issue down. > > But, there is an edge case where it?s possible to induce out of memory errors with ClassValue, specifically if the computed value holds onto the corresponding ClassValue instance. I think this is an edge case and does not warrant a change to the ClassValue implementation to support weak refs to computed values which is likely to complicate an already intricate implementation and perturb its performance characteristics. Simply referencing the associated computed value through a WeakReference would break the ClassValue API. It is expected that the associated value is strongly reachable through the Class instance with which it is associated. Not being reachable strongly, would cause weakly reachable associated value to be GCed prematurely. To fix this problem, one would need to implement ClassValue using Ephemeron(s) but Java does not (yet;-) have them. > > So i have opted for an api note. I don?t want to normatively specify this, nor do i want to allude to various implementation details. (One can argue a similar note could be written for ThreadLocal.) > > Thanks, > Paul. > > [1] https://bugs.openjdk.java.net/browse/JDK-8136353 > > --- a/src/java.base/share/classes/java/lang/ClassValue.java Tue Nov 08 12:36:21 2016 -0800 > +++ b/src/java.base/share/classes/java/lang/ClassValue.java Tue Nov 08 15:25:04 2016 -0800 > @@ -62,6 +62,13 @@ > * If this method throws an exception, the corresponding call to {@code get} > * will terminate abnormally with that exception, and no class value will be recorded. > * > + * @apiNote > + * Care should be taken to ensure that this {@code ClassValue} is not > + * strongly reachable > + * from the computed value. Doing so may prevent classes and their loaders > + * from being garbage collected which in turn may induce out of memory > + * errors. > + * > * @param type the type whose class value must be computed > * @return the newly computed value associated with this {@code ClassValue}, for the given class or interface > * @see #get It is not always the case that when ClassValue instance is strongly reachable from the associated computed value, unloading of classes and class loaders is prevented. So using "may" is correct here. Would it make sense to describe the situations where ClassValue instance can still be strongly reachable from the associated value and not prevent classes and their loaders from being GCed? Regards, Peter From forax at univ-mlv.fr Wed Nov 9 08:32:33 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 9 Nov 2016 09:32:33 +0100 (CET) Subject: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue In-Reply-To: <0308ce68-14b9-8297-1929-fef2b6c0c37f@gmail.com> References: <314D8B90-3D99-4666-A1B4-3152C0D103D3@oracle.com> <0308ce68-14b9-8297-1929-fef2b6c0c37f@gmail.com> Message-ID: <1674952623.1171364.1478680353060.JavaMail.zimbra@u-pem.fr> We should really lock Doug Lea and a GC guy in a room and only release them when they have produce a java.util.EphemeronHashMap (or maybe something which doesn't implement the whole Map contract but only put and get), using a WeakHashMap with the value strongly referencing the key is way too common. see https://bugs.openjdk.java.net/browse/JDK-6389107 and BTW JavasScript WeakMap uses ephemerons. R?mi ----- Mail original ----- > De: "Peter Levart" > ?: "Paul Sandoz" , "Core-Libs-Dev" > Envoy?: Mercredi 9 Novembre 2016 09:13:54 > Objet: Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue > Hi Paul, > > On 11/09/2016 12:27 AM, Paul Sandoz wrote: >> Hi, >> >> Please review the addition of an api note to ClassValue.computeValue. >> >> There is some history behind this issue. Another issue was logged [1] related to >> Groovy using ClassValue and there being a memory leak with classes/loaders not >> being GC?ed, but it turned out the problem was with Groovy's explicit retention >> of computed values in a global set. So i closed that issue down. >> >> But, there is an edge case where it?s possible to induce out of memory errors >> with ClassValue, specifically if the computed value holds onto the >> corresponding ClassValue instance. I think this is an edge case and does not >> warrant a change to the ClassValue implementation to support weak refs to >> computed values which is likely to complicate an already intricate >> implementation and perturb its performance characteristics. > > Simply referencing the associated computed value through a WeakReference > would break the ClassValue API. It is expected that the associated value > is strongly reachable through the Class instance with which it is > associated. Not being reachable strongly, would cause weakly reachable > associated value to be GCed prematurely. To fix this problem, one would > need to implement ClassValue using Ephemeron(s) but Java does not > (yet;-) have them. > >> >> So i have opted for an api note. I don?t want to normatively specify this, nor >> do i want to allude to various implementation details. (One can argue a similar >> note could be written for ThreadLocal.) >> >> Thanks, >> Paul. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8136353 >> >> --- a/src/java.base/share/classes/java/lang/ClassValue.java Tue Nov 08 12:36:21 >> 2016 -0800 >> +++ b/src/java.base/share/classes/java/lang/ClassValue.java Tue Nov 08 15:25:04 >> 2016 -0800 >> @@ -62,6 +62,13 @@ >> * If this method throws an exception, the corresponding call to {@code get} >> * will terminate abnormally with that exception, and no class value will be >> recorded. >> * >> + * @apiNote >> + * Care should be taken to ensure that this {@code ClassValue} is not >> + * strongly >> reachable >> + * from the computed value. Doing so may prevent classes and their loaders >> + * from being garbage collected which in turn may induce out of memory >> + * errors. >> + * >> * @param type the type whose class value must be computed >> * @return the newly computed value associated with this {@code ClassValue}, for >> the given class or interface >> * @see #get > > It is not always the case that when ClassValue instance is strongly > reachable from the associated computed value, unloading of classes and > class loaders is prevented. So using "may" is correct here. Would it > make sense to describe the situations where ClassValue instance can > still be strongly reachable from the associated value and not prevent > classes and their loaders from being GCed? > > Regards, Peter From chris.hegarty at oracle.com Wed Nov 9 09:19:43 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 9 Nov 2016 09:19:43 +0000 Subject: RFR 8164934: Optional.map() javadoc code example is incorrect In-Reply-To: <5CD8BCEC-39E5-4919-977C-F0B37E7EEDA5@oracle.com> References: <5CD8BCEC-39E5-4919-977C-F0B37E7EEDA5@oracle.com> Message-ID: On 8 Nov 2016, at 23:52, Paul Sandoz wrote: > > Hi, > > Please review an update to the api note of Optional.map() which embarrassingly contained erroneous code (labouring under the misapprehension that exception transparency is supported!). > > I tweaked the example to refer to a Stream where a URI is transformed into a Path. > This looks fine Paul. -Chris. > Paul. > > diff -r df7e627c7224 src/java.base/share/classes/java/util/Optional.java > --- a/src/java.base/share/classes/java/util/Optional.java Tue Nov 08 15:28:44 2016 -0800 > +++ b/src/java.base/share/classes/java/util/Optional.java Tue Nov 08 15:37:23 2016 -0800 > @@ -214,20 +214,20 @@ > * @apiNote > * This method supports post-processing on {@code Optional} values, without > * the need to explicitly check for a return status. For example, the > - * following code traverses a stream of file names, selects one that has not > - * yet been processed, and then opens that file, returning an > - * {@code Optional}: > + * following code traverses a stream of URIs, selects one that has not > + * yet been processed, and creates a path from that URI, returning > + * an {@code Optional}: > * > * 
      {@code
> -     *     Optional fis =
> -     *         names.stream().filter(name -> !isProcessedYet(name))
> +     *     Optional p =
> +     *         uris.stream().filter(uri -> !isProcessedYet(uri))
>      *                       .findFirst()
> -     *                       .map(name -> new FileInputStream(name));
> +     *                       .map(Paths::get);
>      * }
      > * > - * Here, {@code findFirst} returns an {@code Optional}, and then > - * {@code map} returns an {@code Optional} for the desired > - * file if one exists. > + * Here, {@code findFirst} returns an {@code Optional}, and then > + * {@code map} returns an {@code Optional} for the desired > + * URI if one exists. > * > * @param mapper the mapping function to apply to a value, if present > * @param The type of the value returned from the mapping function From peter.levart at gmail.com Wed Nov 9 12:31:12 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 9 Nov 2016 13:31:12 +0100 Subject: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue In-Reply-To: <0308ce68-14b9-8297-1929-fef2b6c0c37f@gmail.com> References: <314D8B90-3D99-4666-A1B4-3152C0D103D3@oracle.com> <0308ce68-14b9-8297-1929-fef2b6c0c37f@gmail.com> Message-ID: <9c44bc90-a4b9-d758-ee61-c910afe4851d@gmail.com> Hi Paul, On 11/09/2016 09:13 AM, Peter Levart wrote: > > It is not always the case that when ClassValue instance is strongly > reachable from the associated computed value, unloading of classes and > class loaders is prevented. Take the following example (assume that the code is loaded by a special - say container - app class loader): public class MyApp { public static final ClassValue CV = new ClassValue() { @Override protected Object computeValue(Class type) { return CV; } }; public static void main(String[] args) { CV.get(MyApp.class); // this is OK, it only makes CV reachable from MyApp.class CV.get(Object.class); // WARNING!!! this will make CV reachable from Object.class, pinning it for the VM's lifetime } } So the advise could be: "Avoid referencing ClassValue instance from associated values, but if you really must, you can do that safely only if you limit associating values with classes that have been loaded by the same class loader as the ClassValue instance runtime class (a subclass of ClassValue) or any descendant class loader. We see that what causes the problem in above situation is the fact that the CV instance's runtime class is a subclass of ClassValue and that it is loaded by a non-system class loader. The above situation could be prevented by a special concrete ClassValue implementation, provided by the platform (loaded by bootstrap CL): public class WeakSupplierClassValue extends ClassValue { private final WeakReference> supplierRef; public WeakSupplierClassValue(Supplier supplier) { supplierRef = new WeakReference<>(supplier); } @Override protected T computeValue(Class type) { Supplier supplier = supplierRef.get(); if (supplier == null) { throw new IllegalStateException("Supplier has already been GCed"); } return supplier.get(); } } ...with such utility class, one could rewrite above example to: public class MyApp { // make CV_SUPPLIER stay at least until MyApp class is alive private static final Supplier CV_SUPPLIER = () -> MyApp.CV; public static final ClassValue CV = new WeakSupplierClassValue<>(CV_SUPPLIER); public static void main(String[] args) { // this is OK CV.get(MyApp.class); // even this is OK, it makes CV reachable from Object.class, // but CV_SUPPLIER is only weakly reachable CV.get(Object.class); } } Regards, Peter From peter.levart at gmail.com Wed Nov 9 12:49:11 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 9 Nov 2016 13:49:11 +0100 Subject: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue In-Reply-To: <9c44bc90-a4b9-d758-ee61-c910afe4851d@gmail.com> References: <314D8B90-3D99-4666-A1B4-3152C0D103D3@oracle.com> <0308ce68-14b9-8297-1929-fef2b6c0c37f@gmail.com> <9c44bc90-a4b9-d758-ee61-c910afe4851d@gmail.com> Message-ID: <21fe833e-724f-4905-3eda-255bc739bff0@gmail.com> Or, better yet, using value factory Function instead of Supplier: public class WeakFactoryClassValue extends ClassValue { private final WeakReference, ? extends T>> factoryRef; public WeakFactoryClassValue(Function, ? extends T> factory) { factoryRef = new WeakReference<>(factory); } @Override protected T computeValue(Class type) { Function, ? extends T> factory = factoryRef.get(); if (factory == null) { throw new IllegalStateException("Value factory function has already been GCed"); } return factory.apply(type); } } The example would then read: public class MyApp { // make VALUE_FACTORY stay at least until MyApp class is alive private static final Function, Object> VALUE_FACTORY = clazz -> MyApp.CV; public static final ClassValue CV = new WeakFactoryClassValue<>(VALUE_FACTORY); public static void main(String[] args) { // this is OK CV.get(MyApp.class); // even this is OK, it makes CV reachable from Object.class, // but VALUE_FACTORY is only weakly reachable CV.get(Object.class); } } Regards, Peter On 11/09/2016 01:31 PM, Peter Levart wrote: > The above situation could be prevented by a special concrete > ClassValue implementation, provided by the platform (loaded by > bootstrap CL): > > public class WeakSupplierClassValue extends ClassValue { > private final WeakReference> supplierRef; > > public WeakSupplierClassValue(Supplier supplier) { supplierRef = > new WeakReference<>(supplier); } > > @Override protected T computeValue(Class type) { Supplier > supplier = supplierRef.get(); if (supplier == null) { throw new > IllegalStateException("Supplier has already been GCed"); } return > supplier.get(); } } > > > ...with such utility class, one could rewrite above example to: > > public class MyApp { // make CV_SUPPLIER stay at least until MyApp > class is alive private static final Supplier CV_SUPPLIER = () > -> MyApp.CV; > > public static final ClassValue CV = new > WeakSupplierClassValue<>(CV_SUPPLIER); > > public static void main(String[] args) { // this is OK > CV.get(MyApp.class); > > // even this is OK, it makes CV reachable from Object.class, // but > CV_SUPPLIER is only weakly reachable CV.get(Object.class); } } > > > Regards, Peter From peter.levart at gmail.com Wed Nov 9 13:15:58 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 9 Nov 2016 14:15:58 +0100 Subject: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue In-Reply-To: <21fe833e-724f-4905-3eda-255bc739bff0@gmail.com> References: <314D8B90-3D99-4666-A1B4-3152C0D103D3@oracle.com> <0308ce68-14b9-8297-1929-fef2b6c0c37f@gmail.com> <9c44bc90-a4b9-d758-ee61-c910afe4851d@gmail.com> <21fe833e-724f-4905-3eda-255bc739bff0@gmail.com> Message-ID: Hi Paul, What do you think of introducing a static factory method in ClassValue in addition to your @implNotes. The method would go like this (similar to ThreadLocal.withInitial()): public abstract class ClassValue { /** * Creates a {@code ClassValue} instance which uses given {@code factory} * function for computing values associated with classes passed as arguments * to {@link #get} method. The given {@code factory} function will only be * weakly reachable * from the created ClassValue instance, so one must ensure that is is not Garbage * Collected at least until the returned ClassValue is not used any more. *

      * Attempts to use created ClassValue instance to lazily calculate another * associated value after the given factory function is GCed will result in * {@link IllegalStateException} being thrown from the {@link #get} method. * * @param factory the function to be used to produce values associated with * passed-in classes and created ClassValue instance * @param the type of values associated with created ClassValue instance * @return new instance of ClassValue, weakly referencing given factory function. * @since 9 */ public static ClassValue withWeakFactory( Function, T> factory) { WeakReference, T>> factoryRef = new WeakReference<>(factory); return new ClassValue() { @Override protected T computeValue(Class type) { Function, T> factory = factoryRef.get(); if (factory == null) { throw new IllegalStateException( "The value factory function has already been GC(ed)."); } return factory.apply(type); } }; } @implNotes could point to this method with an example... Regards, Peter On 11/09/2016 01:49 PM, Peter Levart wrote: > Or, better yet, using value factory Function instead of Supplier: > > > public class WeakFactoryClassValue extends ClassValue { > private final WeakReference, ? extends > T>> factoryRef; > > public WeakFactoryClassValue(Function, ? extends > T> factory) { > factoryRef = new WeakReference<>(factory); > } > > @Override > protected T computeValue(Class type) { > Function, ? extends T> factory = > factoryRef.get(); > if (factory == null) { > throw new IllegalStateException("Value factory function > has already been GCed"); > } > return factory.apply(type); > } > } > > > The example would then read: > > public class MyApp { > // make VALUE_FACTORY stay at least until MyApp class is alive > private static final Function, Object> VALUE_FACTORY = > clazz -> MyApp.CV; > > public static final ClassValue CV = > new WeakFactoryClassValue<>(VALUE_FACTORY); > > public static void main(String[] args) { > // this is OK > CV.get(MyApp.class); > > // even this is OK, it makes CV reachable from Object.class, > // but VALUE_FACTORY is only weakly reachable > CV.get(Object.class); > } > } > > > > Regards, Peter > > > > On 11/09/2016 01:31 PM, Peter Levart wrote: > > The above situation could be prevented by a special concrete > ClassValue implementation, provided by the platform (loaded by > > bootstrap CL): > > public class WeakSupplierClassValue extends > ClassValue { > private final WeakReference> > supplierRef; > > public WeakSupplierClassValue(Supplier supplier) { > supplierRef = > new WeakReference<>(supplier); } > > @Override > protected T computeValue(Class type) { Supplier > supplier = > supplierRef.get(); if (supplier == null) { throw new > > IllegalStateException("Supplier has already been GCed"); } return > > supplier.get(); } } > > > ...with such utility class, one could > rewrite above example to: > > public class MyApp { // make CV_SUPPLIER > stay at least until MyApp > class is alive private static final > Supplier CV_SUPPLIER = () > -> MyApp.CV; > > public static > final ClassValue CV = new > > WeakSupplierClassValue<>(CV_SUPPLIER); > > public static void > main(String[] args) { // this is OK > CV.get(MyApp.class); > > // even > this is OK, it makes CV reachable from Object.class, // but > > CV_SUPPLIER is only weakly reachable CV.get(Object.class); } } > > > > Regards, Peter > From paul.sandoz at oracle.com Wed Nov 9 16:47:34 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 9 Nov 2016 08:47:34 -0800 Subject: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue In-Reply-To: References: <314D8B90-3D99-4666-A1B4-3152C0D103D3@oracle.com> <0308ce68-14b9-8297-1929-fef2b6c0c37f@gmail.com> <9c44bc90-a4b9-d758-ee61-c910afe4851d@gmail.com> <21fe833e-724f-4905-3eda-255bc739bff0@gmail.com> Message-ID: Hi Peter, Good point about if such support was added it would break the API and also (with Remi) about Ephemerons. You are correct in stating the constraints in more detail regarding classes in the same loader. However, i think that is going into more detail than I would prefer for what i think is an edge case. So I want in general to warn developers away from strongly referencing this ClassValue in the computed value for any associated class. If we do get strong feedback that this is a real problem we could consider adding a clever little static method like you suggest, with caveats that the computing Function might go away. At the moment I would prefer to keep things simple and say as little as possible. Paul. > On 9 Nov 2016, at 05:15, Peter Levart wrote: > > Hi Paul, > > What do you think of introducing a static factory method in ClassValue in addition to your @implNotes. The method would go like this (similar to ThreadLocal.withInitial()): > > public abstract class ClassValue { > > /** > * Creates a {@code ClassValue} instance which uses given {@code factory} > * function for computing values associated with classes passed as arguments > * to {@link #get} method. The given {@code factory} function will only be > * weakly reachable > * from the created ClassValue instance, so one must ensure that is is not Garbage > * Collected at least until the returned ClassValue is not used any more. > *

      > * Attempts to use created ClassValue instance to lazily calculate another > * associated value after the given factory function is GCed will result in > * {@link IllegalStateException} being thrown from the {@link #get} method. > * > * @param factory the function to be used to produce values associated with > * passed-in classes and created ClassValue instance > * @param the type of values associated with created ClassValue instance > * @return new instance of ClassValue, weakly referencing given factory function. > * @since 9 > */ > public static ClassValue withWeakFactory( > Function, T> factory) > { > WeakReference, T>> factoryRef = > new WeakReference<>(factory); > > return new ClassValue() { > @Override > protected T computeValue(Class type) { > Function, T> factory = factoryRef.get(); > if (factory == null) { > throw new IllegalStateException( > "The value factory function has already been GC(ed)."); > } > return factory.apply(type); > } > }; > } > > @implNotes could point to this method with an example... > > > Regards, Peter > > > On 11/09/2016 01:49 PM, Peter Levart wrote: >> Or, better yet, using value factory Function instead of Supplier: >> >> >> public class WeakFactoryClassValue extends ClassValue { >> private final WeakReference, ? extends T>> factoryRef; >> >> public WeakFactoryClassValue(Function, ? extends T> factory) { >> factoryRef = new WeakReference<>(factory); >> } >> >> @Override >> protected T computeValue(Class type) { >> Function, ? extends T> factory = factoryRef.get(); >> if (factory == null) { >> throw new IllegalStateException("Value factory function has already been GCed"); >> } >> return factory.apply(type); >> } >> } >> >> >> The example would then read: >> >> public class MyApp { >> // make VALUE_FACTORY stay at least until MyApp class is alive >> private static final Function, Object> VALUE_FACTORY = clazz -> MyApp.CV; >> >> public static final ClassValue CV = >> new WeakFactoryClassValue<>(VALUE_FACTORY); >> >> public static void main(String[] args) { >> // this is OK >> CV.get(MyApp.class); >> >> // even this is OK, it makes CV reachable from Object.class, >> // but VALUE_FACTORY is only weakly reachable >> CV.get(Object.class); >> } >> } >> >> >> >> Regards, Peter >> >> >> >> On 11/09/2016 01:31 PM, Peter Levart wrote: >> > The above situation could be prevented by a special concrete >> > ClassValue implementation, provided by the platform (loaded by >> > bootstrap CL): >> > >> > public class WeakSupplierClassValue extends ClassValue { >> > private final WeakReference> supplierRef; >> > >> > public WeakSupplierClassValue(Supplier supplier) { supplierRef = >> > new WeakReference<>(supplier); } >> > >> > @Override protected T computeValue(Class type) { Supplier >> > supplier = supplierRef.get(); if (supplier == null) { throw new >> > IllegalStateException("Supplier has already been GCed"); } return >> > supplier.get(); } } >> > >> > >> > ...with such utility class, one could rewrite above example to: >> > >> > public class MyApp { // make CV_SUPPLIER stay at least until MyApp >> > class is alive private static final Supplier CV_SUPPLIER = () >> > -> MyApp.CV; >> > >> > public static final ClassValue CV = new >> > WeakSupplierClassValue<>(CV_SUPPLIER); >> > >> > public static void main(String[] args) { // this is OK >> > CV.get(MyApp.class); >> > >> > // even this is OK, it makes CV reachable from Object.class, // but >> > CV_SUPPLIER is only weakly reachable CV.get(Object.class); } } >> > >> > >> > Regards, Peter >> > From forax at univ-mlv.fr Wed Nov 9 17:29:35 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 9 Nov 2016 18:29:35 +0100 (CET) Subject: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue In-Reply-To: References: <314D8B90-3D99-4666-A1B4-3152C0D103D3@oracle.com> <0308ce68-14b9-8297-1929-fef2b6c0c37f@gmail.com> <9c44bc90-a4b9-d758-ee61-c910afe4851d@gmail.com> <21fe833e-724f-4905-3eda-255bc739bff0@gmail.com> Message-ID: <86984637.1554131.1478712575694.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Paul Sandoz" > Cc: "Core-Libs-Dev" > Envoy?: Mercredi 9 Novembre 2016 17:47:34 > Objet: Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue > Hi Peter, > > Good point about if such support was added it would break the API and also (with > Remi) about Ephemerons. > > You are correct in stating the constraints in more detail regarding classes in > the same loader. However, i think that is going into more detail than I would > prefer for what i think is an edge case. So I want in general to warn > developers away from strongly referencing this ClassValue in the computed value > for any associated class. > > If we do get strong feedback that this is a real problem we could consider > adding a clever little static method like you suggest, with caveats that the > computing Function might go away. > > At the moment I would prefer to keep things simple and say as little as > possible. I agree with Paul, given the number of people that use ClassValue, i think we should keep the thing simple and let people write their own class on top of ClassValue if they need it. > > Paul. R?mi > > >> On 9 Nov 2016, at 05:15, Peter Levart wrote: >> >> Hi Paul, >> >> What do you think of introducing a static factory method in ClassValue in >> addition to your @implNotes. The method would go like this (similar to >> ThreadLocal.withInitial()): >> >> public abstract class ClassValue { >> >> /** >> * Creates a {@code ClassValue} instance which uses given {@code factory} >> * function for computing values associated with classes passed as arguments >> * to {@link #get} method. The given {@code factory} function will only be >> * weakly >> reachable >> * from the created ClassValue instance, so one must ensure that is is not >> Garbage >> * Collected at least until the returned ClassValue is not used any more. >> *

      >> * Attempts to use created ClassValue instance to lazily calculate another >> * associated value after the given factory function is GCed will result in >> * {@link IllegalStateException} being thrown from the {@link #get} method. >> * >> * @param factory the function to be used to produce values associated with >> * passed-in classes and created ClassValue instance >> * @param the type of values associated with created ClassValue instance >> * @return new instance of ClassValue, weakly referencing given factory function. >> * @since 9 >> */ >> public static ClassValue withWeakFactory( >> Function, T> factory) >> { >> WeakReference, T>> factoryRef = >> new WeakReference<>(factory); >> >> return new ClassValue() { >> @Override >> protected T computeValue(Class type) { >> Function, T> factory = factoryRef.get(); >> if (factory == null) { >> throw new IllegalStateException( >> "The value factory function has already been GC(ed)."); >> } >> return factory.apply(type); >> } >> }; >> } >> >> @implNotes could point to this method with an example... >> >> >> Regards, Peter >> >> >> On 11/09/2016 01:49 PM, Peter Levart wrote: >>> Or, better yet, using value factory Function instead of Supplier: >>> >>> >>> public class WeakFactoryClassValue extends ClassValue { >>> private final WeakReference, ? extends T>> factoryRef; >>> >>> public WeakFactoryClassValue(Function, ? extends T> factory) { >>> factoryRef = new WeakReference<>(factory); >>> } >>> >>> @Override >>> protected T computeValue(Class type) { >>> Function, ? extends T> factory = factoryRef.get(); >>> if (factory == null) { >>> throw new IllegalStateException("Value factory function has already been GCed"); >>> } >>> return factory.apply(type); >>> } >>> } >>> >>> >>> The example would then read: >>> >>> public class MyApp { >>> // make VALUE_FACTORY stay at least until MyApp class is alive >>> private static final Function, Object> VALUE_FACTORY = clazz -> >>> MyApp.CV; >>> >>> public static final ClassValue CV = >>> new WeakFactoryClassValue<>(VALUE_FACTORY); >>> >>> public static void main(String[] args) { >>> // this is OK >>> CV.get(MyApp.class); >>> >>> // even this is OK, it makes CV reachable from Object.class, >>> // but VALUE_FACTORY is only weakly reachable >>> CV.get(Object.class); >>> } >>> } >>> >>> >>> >>> Regards, Peter >>> >>> >>> >>> On 11/09/2016 01:31 PM, Peter Levart wrote: >>> > The above situation could be prevented by a special concrete >>> > ClassValue implementation, provided by the platform (loaded by >>> > bootstrap CL): >>> > >>> > public class WeakSupplierClassValue extends ClassValue { >>> > private final WeakReference> supplierRef; >>> > >>> > public WeakSupplierClassValue(Supplier supplier) { supplierRef = >>> > new WeakReference<>(supplier); } >>> > >>> > @Override protected T computeValue(Class type) { Supplier >>> > supplier = supplierRef.get(); if (supplier == null) { throw new >>> > IllegalStateException("Supplier has already been GCed"); } return >>> > supplier.get(); } } >>> > >>> > >>> > ...with such utility class, one could rewrite above example to: >>> > >>> > public class MyApp { // make CV_SUPPLIER stay at least until MyApp >>> > class is alive private static final Supplier CV_SUPPLIER = () >>> > -> MyApp.CV; >>> > >>> > public static final ClassValue CV = new >>> > WeakSupplierClassValue<>(CV_SUPPLIER); >>> > >>> > public static void main(String[] args) { // this is OK >>> > CV.get(MyApp.class); >>> > >>> > // even this is OK, it makes CV reachable from Object.class, // but >>> > CV_SUPPLIER is only weakly reachable CV.get(Object.class); } } >>> > >>> > >>> > Regards, Peter >>> From denis.kononenko at oracle.com Wed Nov 9 17:36:28 2016 From: denis.kononenko at oracle.com (Denis Kononenko) Date: Wed, 9 Nov 2016 09:36:28 -0800 (PST) Subject: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options Message-ID: Hi, After discussion with Andrey we decided to add more tests for corner cases. The new changes are available by the link below. WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.03/ BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 Thank you, Denis. > Hi, > > Looks OK to me. > I can suggest two more cases. A directory and file symlink can be > passed in options where tool requires a file path. > > ?Andrey > > > On 8 Nov 2016, at 16:17, Denis Kononenko > wrote: > > > > > > Hi, > > > > The new version of changes. > > > > - Switched back to jdk/test/testlibrary to avoid unwanted > dependencies (JImageToolTest.java); > > - Verified tests on smallest possible JDK build. > > > > WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.02/ > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > > > > Thank you, > > Denis. > > > >> Denis, > >> > >> I can see that you have switched to the top level test library > with > >> this change. With that you are getting more module dependencies > than > >> just java.base. First of all, it would probably make sense to > build > >> only the classes you needed (which would be > >> jdk.test.lib.process.ProcessTools, I assume), but even if you only > >> build that, jdk.test.lib.process.ProcessTools has dependencies > outside > >> java.base module. > >> > >> You either have to declare @modules in your test or go back to the > >> jdk/test/lib/testlibrary. Then, of course, unneeded module > >> dependencies are questionable. > >> > >> Shura > >> > >> > >>> On Nov 3, 2016, at 6:29 AM, Denis Kononenko > >> wrote: > >>> > >>> Hi, > >>> > >>> I've done some rework accordingly to Alan's and Shura's comments: > >>> > >>> 1) removed overlapped tests from JImageToolTest.java; > >>> > >>> 2) added new tests JImageVerifyTest.java for jimage verify; > >>> > >>> 3) reorganized jtreg's tags; > >>> > >>> The new WEBREV can be found here: > >> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/ > >>> > >>> Thank you, > >>> Denis. > >>> > >>> On 06.10.2016 19:37, Denis Kononenko wrote: > >>>> Hi, > >>>> > >>>> Could someone please review these new tests for jimage utility. > >>>> > >>>> There're 5 new files containing tests to cover use cases for > >> 'info', 'list', 'extract' and other options. No new tests for > >> 'verify'. > >>>> > >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > >>>> WEBREV: > http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/ > >>>> > >>>> > >>>> Thank you, > >>>> Denis. > >>> From david.dehaven at oracle.com Wed Nov 9 18:13:05 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 9 Nov 2016 10:13:05 -0800 Subject: 8169001: Remove launcher's built-in ergonomics In-Reply-To: <9b86332d-be53-2fd4-f5bd-498b3c94fe05@oracle.com> References: <5820CC54.4010401@oracle.com> <6a3463cb-6e3f-a5cd-601a-2bb6f715eef1@oracle.com> <58220B26.9020907@oracle.com> <9b86332d-be53-2fd4-f5bd-498b3c94fe05@oracle.com> Message-ID: >>>> Please review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8169001 >>>> >>>> Webrev at: >>>> http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/ >>> >>> Overall this looks like a complete eradication of the launcher >>> ergonomics. A few specific comments: >>> >>> src/java.base/share/native/launcher/main.c >>> >>> ! const_cpwildcard, const_javaw, 0); >>> >>> Can you clarify this change with >>> >>> ! const_cpwildcard, const_javaw, 0 /* unused */); >> >> To clarify: >> >> -159 const_cpwildcard, const_javaw, const_ergo_class); >> +159 const_cpwildcard, const_javaw, 0); >> >> >> JLI_Launch is an *internal* entry point, this is primarily used in main.c, >> and this is called by JDK's tool launchers which sets >> "NEVER_ACT_AS_SERVER", >> also this entry point is used by the java packager and deployment, I >> have cc'ed >> Chris Bensen and David DeHaven, my take is not to change the signature now. >> Chris, David ? We (deploy) pass 0 for ergo policy, so we're fine as long as the signature doesn't change. I would appreciate if we could leave the signature alone as that would require us to support both forms at least until Java 12. It's easy to adapt to changing signatures in Java, but not native as we'll get the same function pointer regardless of what the function arguments are. Sending an improperly set up stack frame to a function can cause Very Bad Things(tm) to happen. While it may work on one system, purely by virtue of the fact that it's the last argument in the list, there's no guarantee it will behave properly for future compilers or even different optimization levels. And just so I don't appear entirely selfish here, you'll also impact anyone using JLI_Launch in third party software. Since jli.h is included in the JDK it really should be viewed as external API, or at least externally accessible. -DrD- From dl at cs.oswego.edu Wed Nov 9 18:18:48 2016 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 9 Nov 2016 13:18:48 -0500 Subject: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue In-Reply-To: <1674952623.1171364.1478680353060.JavaMail.zimbra@u-pem.fr> References: <314D8B90-3D99-4666-A1B4-3152C0D103D3@oracle.com> <0308ce68-14b9-8297-1929-fef2b6c0c37f@gmail.com> <1674952623.1171364.1478680353060.JavaMail.zimbra@u-pem.fr> Message-ID: On 11/09/2016 03:32 AM, Remi Forax wrote: > We should really lock Doug Lea and a GC guy in a room and only release them when they have produce a java.util.EphemeronHashMap (or maybe something which doesn't implement the whole Map contract but only put and get), using a WeakHashMap with the value strongly referencing the key is way too common. > Well, GC is an internal API for several collectors, not a specific mechanism, so you'd need a bunch of GC engineers. In the near term, it's more productive to identify specific problems and issues, as Peter has been doing. And: Similar cases can indeed occur with ThreadLocal, but users seem to mostly avoid them, sometimes after painful experience. -Doug > see https://bugs.openjdk.java.net/browse/JDK-6389107 > and BTW JavasScript WeakMap uses ephemerons. > > R?mi > > ----- Mail original ----- >> De: "Peter Levart" >> ?: "Paul Sandoz" , "Core-Libs-Dev" >> Envoy?: Mercredi 9 Novembre 2016 09:13:54 >> Objet: Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue > >> Hi Paul, >> >> On 11/09/2016 12:27 AM, Paul Sandoz wrote: >>> Hi, >>> >>> Please review the addition of an api note to ClassValue.computeValue. >>> >>> There is some history behind this issue. Another issue was logged [1] related to >>> Groovy using ClassValue and there being a memory leak with classes/loaders not >>> being GC?ed, but it turned out the problem was with Groovy's explicit retention >>> of computed values in a global set. So i closed that issue down. >>> >>> But, there is an edge case where it?s possible to induce out of memory errors >>> with ClassValue, specifically if the computed value holds onto the >>> corresponding ClassValue instance. I think this is an edge case and does not >>> warrant a change to the ClassValue implementation to support weak refs to >>> computed values which is likely to complicate an already intricate >>> implementation and perturb its performance characteristics. >> >> Simply referencing the associated computed value through a WeakReference >> would break the ClassValue API. It is expected that the associated value >> is strongly reachable through the Class instance with which it is >> associated. Not being reachable strongly, would cause weakly reachable >> associated value to be GCed prematurely. To fix this problem, one would >> need to implement ClassValue using Ephemeron(s) but Java does not >> (yet;-) have them. >> >>> >>> So i have opted for an api note. I don?t want to normatively specify this, nor >>> do i want to allude to various implementation details. (One can argue a similar >>> note could be written for ThreadLocal.) >>> >>> Thanks, >>> Paul. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8136353 >>> >>> --- a/src/java.base/share/classes/java/lang/ClassValue.java Tue Nov 08 12:36:21 >>> 2016 -0800 >>> +++ b/src/java.base/share/classes/java/lang/ClassValue.java Tue Nov 08 15:25:04 >>> 2016 -0800 >>> @@ -62,6 +62,13 @@ >>> * If this method throws an exception, the corresponding call to {@code get} >>> * will terminate abnormally with that exception, and no class value will be >>> recorded. >>> * >>> + * @apiNote >>> + * Care should be taken to ensure that this {@code ClassValue} is not >>> + * strongly >>> reachable >>> + * from the computed value. Doing so may prevent classes and their loaders >>> + * from being garbage collected which in turn may induce out of memory >>> + * errors. >>> + * >>> * @param type the type whose class value must be computed >>> * @return the newly computed value associated with this {@code ClassValue}, for >>> the given class or interface >>> * @see #get >> >> It is not always the case that when ClassValue instance is strongly >> reachable from the associated computed value, unloading of classes and >> class loaders is prevented. So using "may" is correct here. Would it >> make sense to describe the situations where ClassValue instance can >> still be strongly reachable from the associated value and not prevent >> classes and their loaders from being GCed? >> >> Regards, Peter > From chris.bensen at oracle.com Wed Nov 9 18:30:33 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Wed, 9 Nov 2016 10:30:33 -0800 Subject: 8169001: Remove launcher's built-in ergonomics In-Reply-To: References: <5820CC54.4010401@oracle.com> <6a3463cb-6e3f-a5cd-601a-2bb6f715eef1@oracle.com> <58220B26.9020907@oracle.com> <9b86332d-be53-2fd4-f5bd-498b3c94fe05@oracle.com> Message-ID: > On Nov 9, 2016, at 10:13 AM, David DeHaven wrote: > > >>>>> Please review the fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8169001 >>>>> >>>>> Webrev at: >>>>> http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/ >>>> >>>> Overall this looks like a complete eradication of the launcher >>>> ergonomics. A few specific comments: >>>> >>>> src/java.base/share/native/launcher/main.c >>>> >>>> ! const_cpwildcard, const_javaw, 0); >>>> >>>> Can you clarify this change with >>>> >>>> ! const_cpwildcard, const_javaw, 0 /* unused */); >>> >>> To clarify: >>> >>> -159 const_cpwildcard, const_javaw, const_ergo_class); >>> +159 const_cpwildcard, const_javaw, 0); >>> >>> >>> JLI_Launch is an *internal* entry point, this is primarily used in main.c, >>> and this is called by JDK's tool launchers which sets >>> "NEVER_ACT_AS_SERVER", >>> also this entry point is used by the java packager and deployment, I >>> have cc'ed >>> Chris Bensen and David DeHaven, my take is not to change the signature now. >>> Chris, David ? > > We (deploy) pass 0 for ergo policy, so we're fine as long as the signature doesn't change. > > I would appreciate if we could leave the signature alone as that would require us to support both forms at least until Java 12. It's easy to adapt to changing signatures in Java, but not native as we'll get the same function pointer regardless of what the function arguments are. Sending an improperly set up stack frame to a function can cause Very Bad Things(tm) to happen. While it may work on one system, purely by virtue of the fact that it's the last argument in the list, there's no guarantee it will behave properly for future compilers or even different optimization levels. > > And just so I don't appear entirely selfish here, you'll also impact anyone using JLI_Launch in third party software. Since jli.h is included in the JDK it really should be viewed as external API, or at least externally accessible. As long as the signature doesn?t change the Java Packager will be fine. If there is a signature change I?d suggest changing the name of the method especially if it happens during a minor release so there is some way the Java Packager?s launcher can determine what to call. Chris From andrey.x.nazarov at oracle.com Wed Nov 9 18:55:24 2016 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Wed, 9 Nov 2016 21:55:24 +0300 Subject: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options In-Reply-To: References: Message-ID: <4D19CF54-3CFA-41A3-A3AA-32DC7694F6E5@oracle.com> Hi, Looks OK. Is it 100% pass rate? ?Andrey > On 9 Nov 2016, at 20:36, Denis Kononenko wrote: > > > > Hi, > > After discussion with Andrey we decided to add more tests for corner cases. > The new changes are available by the link below. > > WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.03/ > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > > > Thank you, > Denis. > >> Hi, >> >> Looks OK to me. >> I can suggest two more cases. A directory and file symlink can be >> passed in options where tool requires a file path. >> >> ?Andrey >> >>> On 8 Nov 2016, at 16:17, Denis Kononenko >> wrote: >>> >>> >>> Hi, >>> >>> The new version of changes. >>> >>> - Switched back to jdk/test/testlibrary to avoid unwanted >> dependencies (JImageToolTest.java); >>> - Verified tests on smallest possible JDK build. >>> >>> WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.02/ >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 >>> >>> Thank you, >>> Denis. >>> >>>> Denis, >>>> >>>> I can see that you have switched to the top level test library >> with >>>> this change. With that you are getting more module dependencies >> than >>>> just java.base. First of all, it would probably make sense to >> build >>>> only the classes you needed (which would be >>>> jdk.test.lib.process.ProcessTools, I assume), but even if you only >>>> build that, jdk.test.lib.process.ProcessTools has dependencies >> outside >>>> java.base module. >>>> >>>> You either have to declare @modules in your test or go back to the >>>> jdk/test/lib/testlibrary. Then, of course, unneeded module >>>> dependencies are questionable. >>>> >>>> Shura >>>> >>>> >>>>> On Nov 3, 2016, at 6:29 AM, Denis Kononenko >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I've done some rework accordingly to Alan's and Shura's comments: >>>>> >>>>> 1) removed overlapped tests from JImageToolTest.java; >>>>> >>>>> 2) added new tests JImageVerifyTest.java for jimage verify; >>>>> >>>>> 3) reorganized jtreg's tags; >>>>> >>>>> The new WEBREV can be found here: >>>> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/ >>>>> >>>>> Thank you, >>>>> Denis. >>>>> >>>>> On 06.10.2016 19:37, Denis Kononenko wrote: >>>>>> Hi, >>>>>> >>>>>> Could someone please review these new tests for jimage utility. >>>>>> >>>>>> There're 5 new files containing tests to cover use cases for >>>> 'info', 'list', 'extract' and other options. No new tests for >>>> 'verify'. >>>>>> >>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 >>>>>> WEBREV: >> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/ >>>>>> >>>>>> >>>>>> Thank you, >>>>>> Denis. >>>>> From peter.levart at gmail.com Wed Nov 9 18:56:28 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 9 Nov 2016 19:56:28 +0100 Subject: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue In-Reply-To: <86984637.1554131.1478712575694.JavaMail.zimbra@u-pem.fr> References: <314D8B90-3D99-4666-A1B4-3152C0D103D3@oracle.com> <0308ce68-14b9-8297-1929-fef2b6c0c37f@gmail.com> <9c44bc90-a4b9-d758-ee61-c910afe4851d@gmail.com> <21fe833e-724f-4905-3eda-255bc739bff0@gmail.com> <86984637.1554131.1478712575694.JavaMail.zimbra@u-pem.fr> Message-ID: <3e7228fa-008a-39fb-5e2a-fa31b6b0dfc5@gmail.com> Hi Remi, On 11/09/2016 06:29 PM, Remi Forax wrote: > ----- Mail original ----- >> De: "Paul Sandoz" >> Cc: "Core-Libs-Dev" >> Envoy?: Mercredi 9 Novembre 2016 17:47:34 >> Objet: Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue >> Hi Peter, >> >> Good point about if such support was added it would break the API and also (with >> Remi) about Ephemerons. >> >> You are correct in stating the constraints in more detail regarding classes in >> the same loader. However, i think that is going into more detail than I would >> prefer for what i think is an edge case. So I want in general to warn >> developers away from strongly referencing this ClassValue in the computed value >> for any associated class. >> >> If we do get strong feedback that this is a real problem we could consider >> adding a clever little static method like you suggest, with caveats that the >> computing Function might go away. >> >> At the moment I would prefer to keep things simple and say as little as >> possible. > I agree with Paul, given the number of people that use ClassValue, i think we should keep the thing simple and let people write their own class on top of ClassValue if they need it. That's OK. I don't think such class or static method should be added if there is no demand for it. But the point I was trying to make is that while people can write such utility class themselves, in order to be effective, they would have to deploy it with a class loader that is otherwise permanent (that doesn't need to go away) and such that the class is visible to application. This means that they can't just bundle such class with the application. Regards, Peter >> Paul. > R?mi > >>> On 9 Nov 2016, at 05:15, Peter Levart wrote: >>> >>> Hi Paul, >>> >>> What do you think of introducing a static factory method in ClassValue in >>> addition to your @implNotes. The method would go like this (similar to >>> ThreadLocal.withInitial()): >>> >>> public abstract class ClassValue { >>> >>> /** >>> * Creates a {@code ClassValue} instance which uses given {@code factory} >>> * function for computing values associated with classes passed as arguments >>> * to {@link #get} method. The given {@code factory} function will only be >>> * weakly >>> reachable >>> * from the created ClassValue instance, so one must ensure that is is not >>> Garbage >>> * Collected at least until the returned ClassValue is not used any more. >>> *

      >>> * Attempts to use created ClassValue instance to lazily calculate another >>> * associated value after the given factory function is GCed will result in >>> * {@link IllegalStateException} being thrown from the {@link #get} method. >>> * >>> * @param factory the function to be used to produce values associated with >>> * passed-in classes and created ClassValue instance >>> * @param the type of values associated with created ClassValue instance >>> * @return new instance of ClassValue, weakly referencing given factory function. >>> * @since 9 >>> */ >>> public static ClassValue withWeakFactory( >>> Function, T> factory) >>> { >>> WeakReference, T>> factoryRef = >>> new WeakReference<>(factory); >>> >>> return new ClassValue() { >>> @Override >>> protected T computeValue(Class type) { >>> Function, T> factory = factoryRef.get(); >>> if (factory == null) { >>> throw new IllegalStateException( >>> "The value factory function has already been GC(ed)."); >>> } >>> return factory.apply(type); >>> } >>> }; >>> } >>> >>> @implNotes could point to this method with an example... >>> >>> >>> Regards, Peter >>> >>> >>> On 11/09/2016 01:49 PM, Peter Levart wrote: >>>> Or, better yet, using value factory Function instead of Supplier: >>>> >>>> >>>> public class WeakFactoryClassValue extends ClassValue { >>>> private final WeakReference, ? extends T>> factoryRef; >>>> >>>> public WeakFactoryClassValue(Function, ? extends T> factory) { >>>> factoryRef = new WeakReference<>(factory); >>>> } >>>> >>>> @Override >>>> protected T computeValue(Class type) { >>>> Function, ? extends T> factory = factoryRef.get(); >>>> if (factory == null) { >>>> throw new IllegalStateException("Value factory function has already been GCed"); >>>> } >>>> return factory.apply(type); >>>> } >>>> } >>>> >>>> >>>> The example would then read: >>>> >>>> public class MyApp { >>>> // make VALUE_FACTORY stay at least until MyApp class is alive >>>> private static final Function, Object> VALUE_FACTORY = clazz -> >>>> MyApp.CV; >>>> >>>> public static final ClassValue CV = >>>> new WeakFactoryClassValue<>(VALUE_FACTORY); >>>> >>>> public static void main(String[] args) { >>>> // this is OK >>>> CV.get(MyApp.class); >>>> >>>> // even this is OK, it makes CV reachable from Object.class, >>>> // but VALUE_FACTORY is only weakly reachable >>>> CV.get(Object.class); >>>> } >>>> } >>>> >>>> >>>> >>>> Regards, Peter >>>> >>>> >>>> >>>> On 11/09/2016 01:31 PM, Peter Levart wrote: >>>>> The above situation could be prevented by a special concrete >>>>> ClassValue implementation, provided by the platform (loaded by >>>>> bootstrap CL): >>>>> >>>>> public class WeakSupplierClassValue extends ClassValue { >>>>> private final WeakReference> supplierRef; >>>>> >>>>> public WeakSupplierClassValue(Supplier supplier) { supplierRef = >>>>> new WeakReference<>(supplier); } >>>>> >>>>> @Override protected T computeValue(Class type) { Supplier >>>>> supplier = supplierRef.get(); if (supplier == null) { throw new >>>>> IllegalStateException("Supplier has already been GCed"); } return >>>>> supplier.get(); } } >>>>> >>>>> >>>>> ...with such utility class, one could rewrite above example to: >>>>> >>>>> public class MyApp { // make CV_SUPPLIER stay at least until MyApp >>>>> class is alive private static final Supplier CV_SUPPLIER = () >>>>> -> MyApp.CV; >>>>> >>>>> public static final ClassValue CV = new >>>>> WeakSupplierClassValue<>(CV_SUPPLIER); >>>>> >>>>> public static void main(String[] args) { // this is OK >>>>> CV.get(MyApp.class); >>>>> >>>>> // even this is OK, it makes CV reachable from Object.class, // but >>>>> CV_SUPPLIER is only weakly reachable CV.get(Object.class); } } >>>>> >>>>> >>>>> Regards, Peter From brent.christian at oracle.com Wed Nov 9 22:53:32 2016 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 9 Nov 2016 14:53:32 -0800 Subject: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError Message-ID: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> Hi, It seems that the method name used in 8165793[1], "isParallelCapable", was a little *too* intuitive. An existing use of that method name has been uncovered (via NetBeans, in Eclipse Equinox). Because the newly added method was marked final, the pre-existing method results in a VerifyError under JDK 9 (for overriding a final method). Please review my fix, which makes ClassLoader.isParallelCapable() non-final. The semantics of such a boolean-returning isXXXX method are clear - it's unlikely that existing methods would use different semantics. I've included an @apiNote (ala ClassLoader.getName()) explaining that the non-final-ness here is strictly for compatibility. Bug: https://bugs.openjdk.java.net/browse/JDK-8169435 Webrev: http://cr.openjdk.java.net/~bchristi/8169435/webrev.0/ Thanks, -Brent 1. https://bugs.openjdk.java.net/browse/JDK-8165793 From claes.redestad at oracle.com Wed Nov 9 23:02:15 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 10 Nov 2016 00:02:15 +0100 Subject: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError In-Reply-To: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> References: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> Message-ID: <5823AAF7.6040900@oracle.com> Hi, On 2016-11-09 23:53, Brent Christian wrote: > Hi, > > It seems that the method name used in 8165793[1], "isParallelCapable", > was a little *too* intuitive. An existing use of that method name has > been uncovered (via NetBeans, in Eclipse Equinox). > > Because the newly added method was marked final, the pre-existing method > results in a VerifyError under JDK 9 (for overriding a final method). > > Please review my fix, which makes ClassLoader.isParallelCapable() > non-final. The semantics of such a boolean-returning isXXXX method are > clear - it's unlikely that existing methods would use different semantics. > > I've included an @apiNote (ala ClassLoader.getName()) explaining that > the non-final-ness here is strictly for compatibility. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8169435 > Webrev: > http://cr.openjdk.java.net/~bchristi/8169435/webrev.0/ looks good to me. Thanks! /Claes From mandy.chung at oracle.com Wed Nov 9 23:30:07 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 9 Nov 2016 15:30:07 -0800 Subject: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError In-Reply-To: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> References: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> Message-ID: <36AD984C-1B0B-4018-A9DE-A20FAF7F055D@oracle.com> > On Nov 9, 2016, at 2:53 PM, Brent Christian wrote: > > Hi, > > It seems that the method name used in 8165793[1], "isParallelCapable", was a little *too* intuitive. An existing use of that method name has been uncovered (via NetBeans, in Eclipse Equinox). > > Because the newly added method was marked final, the pre-existing method results in a VerifyError under JDK 9 (for overriding a final method). > > Please review my fix, which makes ClassLoader.isParallelCapable() non-final. The semantics of such a boolean-returning isXXXX method are clear - it's unlikely that existing methods would use different semantics. > > I've included an @apiNote (ala ClassLoader.getName()) explaining that the non-final-ness here is strictly for compatibility. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8169435 > Webrev: > http://cr.openjdk.java.net/~bchristi/8169435/webrev.0/ +1 Mandy From mandy.chung at oracle.com Thu Nov 10 03:01:59 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 9 Nov 2016 19:01:59 -0800 Subject: Review request: JDK-8168386: Fix jdeps verbose options Message-ID: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8168386/webrev.00 This patch tightens the option validation to jdeps and the new test shows some example of conflicting options. Mandy From Sunny.Chan at gs.com Thu Nov 10 03:02:58 2016 From: Sunny.Chan at gs.com (Chan, Sunny) Date: Thu, 10 Nov 2016 03:02:58 +0000 Subject: Proposed patch: further wrapping of FileInputStream's native method Message-ID: Hello all, I proposed a patch to provide wrapping for some native methods in FileInputStream a while ago in May, and the patch has been reviewed but it has not been integrated. I have checked the patch again with the latest JDK9 dev builds and it still works correctly passing java.io regression tests so could I have someone to sponsor this and integrate this patch? Here is the previous threads from email archive: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040901.html I have attached the patch again in this email for reference. Sunny Chan Executive Director Technology Goldman Sachs (Asia) L.L.C. | 39th Floor | The Center | 99 Queens Road Central | Hong Kong Email: sunny.chan at gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633 Learn more about Goldman Sachs GS.com | Blog | LinkedIn | YouTube | Twitter 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. From amy.lu at oracle.com Thu Nov 10 03:31:32 2016 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 10 Nov 2016 11:31:32 +0800 Subject: JDK 9 RFR of JDK-8169041: com/sun/corba/cachedSocket should be added to exclusiveAccess.dirs Message-ID: Please review the patch to add com/sun/corba/cachedSocket to exclusiveAccess.dirs so as tests won't run concurrently. This is to address one potential issue that corba tests (start and use orbd service) may run into port conflict issue if run in concurrency. Most of such tests are under javax/rmi and already in exclusiveAccess.dirs. Test com/sun/corba/cachedSocket/7056731.sh also runs orbd and should not be run concurrently. bug: https://bugs.openjdk.java.net/browse/JDK-8169041 webrev: http://cr.openjdk.java.net/~amlu/8169041/webrev.00 Thanks, Amy --- old/test/TEST.ROOT 2016-11-10 11:05:37.000000000 +0800 +++ new/test/TEST.ROOT 2016-11-10 11:05:36.000000000 +0800 @@ -18,7 +18,7 @@ othervm.dirs=java/awt java/beans javax/accessibility javax/imageio javax/sound javax/print javax/management com/sun/awt sun/awt sun/java2d sun/pisces javax/xml/jaxp/testng/validation java/lang/ProcessHandle # Tests that cannot run concurrently -exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote sun/tools/jstatd sun/security/mscapi java/util/stream javax/rmi +exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote sun/tools/jstatd sun/security/mscapi java/util/stream javax/rmi com/sun/corba/cachedSocket # Group definitions groups=TEST.groups [closed/TEST.groups] From blackdrag at gmx.org Thu Nov 10 08:51:49 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Thu, 10 Nov 2016 09:51:49 +0100 Subject: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue In-Reply-To: References: <314D8B90-3D99-4666-A1B4-3152C0D103D3@oracle.com> <0308ce68-14b9-8297-1929-fef2b6c0c37f@gmail.com> <9c44bc90-a4b9-d758-ee61-c910afe4851d@gmail.com> <21fe833e-724f-4905-3eda-255bc739bff0@gmail.com> Message-ID: <71bc9aef-e7bc-6946-fe16-63a0c14fdffc@gmx.org> On 09.11.2016 17:47, Paul Sandoz wrote: > Hi Peter, > > Good point about if such support was added it would break the API and also (with Remi) about Ephemerons. > > You are correct in stating the constraints in more detail regarding classes in the same loader. However, i think that is going into more detail than I would prefer for what i think is an edge case. I would not regard that an edge case. For a dynamic language using ClassValue to store information, it is very easy to produce a memory leak with ClassValue. > So I want in general to warn developers away from strongly referencing this ClassValue in the computed value for any associated class. > > If we do get strong feedback that this is a real problem we could consider adding a clever little static method like you suggest, with caveats that the computing Function might go away. for us it is such a strong problem, that we are unable to transfer the old structure to use ClassValue without a major rewrite of large parts. Just imagine a runtime that uses ClassValue and that your application, let it be a web application, will spawn many runtimes over time. You do want the runtimes and all computed values be able to be garbage collected. But if you will need at the same time a ClassValue to not to prevent a class we computed the value for from unloading and have the computed value alive for min(lifespan class, lifespan runtime), then you get a real big problem in realizing this. As it stands for me ClassValue is only usable as a class associated cache with values you can recreate at any moment. That is not good enough for us in the general case. If that is an edge case I still miss a major part in the documentation... and that is what a ClassValue should be used for instead of a cryptic and incomplete description of what a ClassValue is. And then we could talk about if the intended use and the actual usability fit together bye Jcohen From blackdrag at gmx.org Thu Nov 10 08:54:52 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Thu, 10 Nov 2016 09:54:52 +0100 Subject: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue In-Reply-To: References: <314D8B90-3D99-4666-A1B4-3152C0D103D3@oracle.com> <0308ce68-14b9-8297-1929-fef2b6c0c37f@gmail.com> <1674952623.1171364.1478680353060.JavaMail.zimbra@u-pem.fr> Message-ID: <1a0d22a1-88bc-bcfa-28cd-72715d5eb1ab@gmx.org> On 09.11.2016 19:18, Doug Lea wrote: [...] > And: Similar cases can indeed occur with ThreadLocal, but users seem > to mostly avoid them, sometimes after painful experience. ThreadLocal is already a bad choice once you subclass it. bye Jochen From ramanand.patil at oracle.com Thu Nov 10 09:48:00 2016 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Thu, 10 Nov 2016 01:48:00 -0800 (PST) Subject: RFR: jdk8u-dev Backport of 8169191: (tz) Support tzdata2016i Message-ID: Hi all, Please review the latest TZDATA integration (tzdata2016i) to JDK8U. Since tzdata is cumulative, this bug fix backports both the tzdata versions(tzdata2016h+tzdata2016i) into jdk8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8169191 Webrev: http://cr.openjdk.java.net/~rpatil/8169537/webrev.00/ Jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7f7091c1dd33 For reference: Jdk9 changeset for tzdata2016h integration(JDK-8168512): http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3192d7aa428d All the TimeZone related tests are passed after integration. Regards, Ramanand. From denis.kononenko at oracle.com Thu Nov 10 10:40:57 2016 From: denis.kononenko at oracle.com (Denis Kononenko) Date: Thu, 10 Nov 2016 02:40:57 -0800 (PST) Subject: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options Message-ID: <4c733bd0-ecb3-4cb9-9521-df943becd146@default> Hi Andrey, No, it isn't. I submitted a new CR: https://bugs.openjdk.java.net/browse/JDK-8167384. Thank you, Denis. > Hi, > > Looks OK. Is it 100% pass rate? > > ?Andrey > > On 9 Nov 2016, at 20:36, Denis Kononenko > wrote: > > > > > > > > Hi, > > > > After discussion with Andrey we decided to add more tests for corner > cases. > > The new changes are available by the link below. > > > > WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.03/ > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > > > > > > Thank you, > > Denis. > > > >> Hi, > >> > >> Looks OK to me. > >> I can suggest two more cases. A directory and file symlink can be > >> passed in options where tool requires a file path. > >> > >> ?Andrey > >> > >>> On 8 Nov 2016, at 16:17, Denis Kononenko > >> wrote: > >>> > >>> > >>> Hi, > >>> > >>> The new version of changes. > >>> > >>> - Switched back to jdk/test/testlibrary to avoid unwanted > >> dependencies (JImageToolTest.java); > >>> - Verified tests on smallest possible JDK build. > >>> > >>> WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.02/ > >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > >>> > >>> Thank you, > >>> Denis. > >>> > >>>> Denis, > >>>> > >>>> I can see that you have switched to the top level test library > >> with > >>>> this change. With that you are getting more module dependencies > >> than > >>>> just java.base. First of all, it would probably make sense to > >> build > >>>> only the classes you needed (which would be > >>>> jdk.test.lib.process.ProcessTools, I assume), but even if you > only > >>>> build that, jdk.test.lib.process.ProcessTools has dependencies > >> outside > >>>> java.base module. > >>>> > >>>> You either have to declare @modules in your test or go back to > the > >>>> jdk/test/lib/testlibrary. Then, of course, unneeded module > >>>> dependencies are questionable. > >>>> > >>>> Shura > >>>> > >>>> > >>>>> On Nov 3, 2016, at 6:29 AM, Denis Kononenko > >>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> I've done some rework accordingly to Alan's and Shura's > comments: > >>>>> > >>>>> 1) removed overlapped tests from JImageToolTest.java; > >>>>> > >>>>> 2) added new tests JImageVerifyTest.java for jimage verify; > >>>>> > >>>>> 3) reorganized jtreg's tags; > >>>>> > >>>>> The new WEBREV can be found here: > >>>> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/ > >>>>> > >>>>> Thank you, > >>>>> Denis. > >>>>> > >>>>> On 06.10.2016 19:37, Denis Kononenko wrote: > >>>>>> Hi, > >>>>>> > >>>>>> Could someone please review these new tests for jimage > utility. > >>>>>> > >>>>>> There're 5 new files containing tests to cover use cases for > >>>> 'info', 'list', 'extract' and other options. No new tests for > >>>> 'verify'. > >>>>>> > >>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > >>>>>> WEBREV: > >> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/ > >>>>>> > >>>>>> > >>>>>> Thank you, > >>>>>> Denis. > >>>>> From chris.hegarty at oracle.com Thu Nov 10 13:44:03 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Nov 2016 13:44:03 +0000 Subject: JDK 9 RFR of JDK-8169041: com/sun/corba/cachedSocket should be added to exclusiveAccess.dirs In-Reply-To: References: Message-ID: <71E2BCE0-F7AF-477A-8C81-10998F1BE50B@oracle.com> Looks ok Amy. -Chris. > On 10 Nov 2016, at 03:31, Amy Lu wrote: > > Please review the patch to add com/sun/corba/cachedSocket to exclusiveAccess.dirs so as tests won't run concurrently. > > This is to address one potential issue that corba tests (start and use orbd service) may run into port conflict issue if run in concurrency. Most of such tests are under javax/rmi and already in exclusiveAccess.dirs. Test com/sun/corba/cachedSocket/7056731.sh also runs orbd and should not be run concurrently. > > bug: https://bugs.openjdk.java.net/browse/JDK-8169041 > webrev: http://cr.openjdk.java.net/~amlu/8169041/webrev.00 > > Thanks, > Amy > > --- old/test/TEST.ROOT 2016-11-10 11:05:37.000000000 +0800 > +++ new/test/TEST.ROOT 2016-11-10 11:05:36.000000000 +0800 > @@ -18,7 +18,7 @@ > othervm.dirs=java/awt java/beans javax/accessibility javax/imageio javax/sound javax/print javax/management com/sun/awt sun/awt sun/java2d sun/pisces javax/xml/jaxp/testng/validation java/lang/ProcessHandle > # Tests that cannot run concurrently > -exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote sun/tools/jstatd sun/security/mscapi java/util/stream javax/rmi > +exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote sun/tools/jstatd sun/security/mscapi java/util/stream javax/rmi com/sun/corba/cachedSocket > # Group definitions > groups=TEST.groups [closed/TEST.groups] > > From Ronald_Servant at ca.ibm.com Thu Nov 10 15:01:48 2016 From: Ronald_Servant at ca.ibm.com (Ronald Servant) Date: Thu, 10 Nov 2016 10:01:48 -0500 Subject: Race Condition in initializeEncoding() function in jni_util.c Message-ID: Hi, While building the J9 JVM for the IBM SDK for Java(*), we've run across what we believe is a race condition in initializeEncoding(JNIEnv*) in jni_util.c. ? ? ? (*) ?The IBM SDK for Java is comprised of the J9 JVM and OpenJDK class library. We've encountered a situation where (*env)->CallObjectMethod() in JNU_GetStringPlatformChars() is invoked with an uninitialized method ID (the static variable "String_getBytes_ID"). The function initializeEnconding() initializes 4 static variables, but only one of them ("fastEncoding") is checked to see if initializeEnconding() should be called in?JNU_NewStringPlatform() and?JNU_GetStringPlatformChars (). ?Further, "fastEncoding" is the first of the 4 static variables set by initializeEncoding() leaving a race condition where another thread sees "fastEncoding" set but?"String_getBytes_ID" is not yet initialized. I believe that moving the initialization of "String_getBytes_ID" and "String_init_ID" to the top of the function would eliminate the impact of the race condition. I'd also recommend moving the initialization of "jnuEncoding" up one line, but this may lead to leaking a global ref. We are able to reproduce the failure in JNU_GetStringPlatformChars() due to using an null String_getBytes_ID variable for a method id?race condition in our environment 1 in 20. ?With the following patch applied, the race condition can no longer be reproduced. Do you agree there is a race condition? ?If so, would the patch be an appropriate fix? ?We could introduce locking, but that feels like overkill. Ron. diff -r efa71dc820eb src/java.base/share/native/libjava/jni_util.c --- a/src/java.base/share/native/libjava/jni_util.c?? ?Mon Nov 07 13:10:42 2016 -0400 +++ b/src/java.base/share/native/libjava/jni_util.c?? ?Wed Nov 09 17:19:16 2016 -0500 @@ -688,6 +688,15 @@ ?? ? strClazz = JNU_ClassString(env); ?? ? CHECK_NULL(strClazz); + +? ? /* Initialize method-id cache */ +? ? String_getBytes_ID = (*env)->GetMethodID(env, strClazz, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "getBytes", "(Ljava/lang/String;)[B"); +? ? CHECK_NULL(String_getBytes_ID); +? ? String_init_ID = (*env)->GetMethodID(env, strClazz, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "", "([BLjava/lang/String;)V"); +? ? CHECK_NULL(String_init_ID); + ?? ? propname = (*env)->NewStringUTF(env, "sun.jnu.encoding"); ?? ? if (propname) { @@ -727,8 +736,8 @@ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? strcmp(encname, "utf-16le") == 0) ?? ? ? ? ? ? ? ? ? ? ? ? fastEncoding = FAST_CP1252; ?? ? ? ? ? ? ? ? ? ? else { +? ? ? ? ? ? ? ? ? ? ? ? jnuEncoding = (jstring)(*env)->NewGlobalRef(env, enc); ?? ? ? ? ? ? ? ? ? ? ? ? fastEncoding = NO_FAST_ENCODING; -? ? ? ? ? ? ? ? ? ? ? ? jnuEncoding = (jstring)(*env)->NewGlobalRef(env, enc); ?? ? ? ? ? ? ? ? ? ? } ?? ? ? ? ? ? ? ? ? ? (*env)->ReleaseStringUTFChars(env, enc, encname); ?? ? ? ? ? ? ? ? } @@ -741,13 +750,6 @@ ?? ? } ?? ? (*env)->DeleteLocalRef(env, propname); ?? ? (*env)->DeleteLocalRef(env, enc); - -? ? /* Initialize method-id cache */ -? ? String_getBytes_ID = (*env)->GetMethodID(env, strClazz, - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "getBytes", "(Ljava/lang/String;)[B"); -? ? CHECK_NULL(String_getBytes_ID); -? ? String_init_ID = (*env)->GetMethodID(env, strClazz, - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "", "([BLjava/lang/String;)V"); ?} From daniel.fuchs at oracle.com Thu Nov 10 15:12:38 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 10 Nov 2016 15:12:38 +0000 Subject: RFR: 8169495: Add a method to set an Authenticator on a HttpURLConnection. Message-ID: <014ecda5-f37c-7a5a-8dfc-36f924f47bd3@oracle.com> Hi, Please find below a patch for: https://bugs.openjdk.java.net/browse/JDK-8169495 8169495: Add a method to set an Authenticator on a HttpURLConnection. webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8169495/webrev.00 The public API changes are in java.net.HttpURLConnection and java.net.Authenticator. For backward compatibility reason the new HttpURLConnection::setAuthenticator method is not abstract, but is instead implemented to throw UOE unless overridden. Again for compatibility reasons, if no authenticator is explicitly supplied to the connection then the behavior is unchanged: the default authenticator will be invoked, if needed, at the time credentials are requested through the HTTP protocol. Here is the description of the new HttpURLConnection::setAuthenticator method: /** + * Supplies an {@link java.net.Authenticator Authenticator} to be used + * when authentication is requested through the HTTP protocol for + * this {@code HttpURLConnection}. + * If no authenticator is supplied, the + * {@linkplain Authenticator#setDefault(java.net.Authenticator) default + * authenticator} will be used. + * + * @implNote The default behavior of this method is to throw + * {@link UnsupportedOperationException}. Concrete + * implementations of {@code HttpURLConnection} + * which support supplying an {@code Authenticator} for a + * specific {@code HttpURLConnection} instance should + * override this method to implement a different behavior. + * + * @implSpec Depending on authentication schemes, an implementation + * may or may not need to use the provided authenticator + * to obtain a password. For instance, an implementation that + * relies on third-party security libraries may still invoke the + * default authenticator if these libraries are configured + * to do so. + * Likewise, an implementation that supports transparent + * NTLM authentication may let the system attempt + * to connect using the system user credentials first, + * before invoking the provided authenticator. + *
      + * However, if an authenticator is specifically provided, + * then the underlying connection may only be reused for + * {@code HttpURLConnection} instances which share the same + * {@code Authenticator} instance, and authentication information, + * if cached, may only be reused for an {@code HttpURLConnection} + * sharing that same {@code Authenticator}. + * + * @param auth The {@code Authenticator} that should be used by this + * {@code HttpURLConnection}. + * + * @throws UnsupportedOperationException if setting an Authenticator is + * not supported by the underlying implementation. + * @throws IllegalStateException if URLConnection is already connected. + * @throws NullPointerException if the supplied {@code auth} is {@code null}. + * @since 9 + */ + public void setAuthenticator(Authenticator auth) { + throw new UnsupportedOperationException("Supplying an authenticator" + + " is not supported by " + this.getClass()); + } best regards, -- daniel From david.lloyd at redhat.com Thu Nov 10 16:42:41 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 10 Nov 2016 10:42:41 -0600 Subject: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError In-Reply-To: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> References: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> Message-ID: My original suggestion for the method was to make it static, and possibly even caller-sensitive, for just this reason. On 11/09/2016 04:53 PM, Brent Christian wrote: > Hi, > > It seems that the method name used in 8165793[1], "isParallelCapable", > was a little *too* intuitive. An existing use of that method name has > been uncovered (via NetBeans, in Eclipse Equinox). > > Because the newly added method was marked final, the pre-existing method > results in a VerifyError under JDK 9 (for overriding a final method). > > Please review my fix, which makes ClassLoader.isParallelCapable() > non-final. The semantics of such a boolean-returning isXXXX method are > clear - it's unlikely that existing methods would use different semantics. > > I've included an @apiNote (ala ClassLoader.getName()) explaining that > the non-final-ness here is strictly for compatibility. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8169435 > Webrev: > http://cr.openjdk.java.net/~bchristi/8169435/webrev.0/ > > Thanks, > -Brent > > 1. https://bugs.openjdk.java.net/browse/JDK-8165793 > -- - DML From martinrb at google.com Thu Nov 10 16:48:32 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 10 Nov 2016 08:48:32 -0800 Subject: RFR: jdk8u-dev Backport of 8169191: (tz) Support tzdata2016i In-Reply-To: References: Message-ID: Looks good! On Thu, Nov 10, 2016 at 1:48 AM, Ramanand Patil wrote: > Hi all, > Please review the latest TZDATA integration (tzdata2016i) to JDK8U. > Since tzdata is cumulative, this bug fix backports both the tzdata > versions(tzdata2016h+tzdata2016i) into jdk8u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169191 > Webrev: http://cr.openjdk.java.net/~rpatil/8169537/webrev.00/ > > Jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7f7091c1dd33 > > For reference: > Jdk9 changeset for tzdata2016h integration(JDK-8168512): > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3192d7aa428d > > All the TimeZone related tests are passed after integration. > > > Regards, > Ramanand. > From Alan.Bateman at oracle.com Thu Nov 10 16:59:02 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Nov 2016 17:59:02 +0100 Subject: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError In-Reply-To: References: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> Message-ID: On 10/11/2016 17:42, David M. Lloyd wrote: > My original suggestion for the method was to make it static, and > possibly even caller-sensitive, for just this reason. Changing it to be non-final looks reasonable here, the main reason being that it's a no-arg isXXXX method and so unlikely that there are custom class loaders that have a method with this name that returns something other than boolean. However the modifier might be a concern and so time will tell if there are custom class loaders that defining a non-public no-arg method with this name. -Alan From david.dehaven at oracle.com Thu Nov 10 17:38:03 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 10 Nov 2016 09:38:03 -0800 Subject: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method Message-ID: <3160154D-73F2-430C-A943-E75CC9FF4C08@oracle.com> Please review the (fairly straightforward) JDK changes needed to support launching JavaFX applications in a named module. JBS: https://bugs.openjdk.java.net/browse/JDK-8169289 Webrev: http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/ For reference, here are the openjfx changes needed: http://cr.openjdk.java.net/~ddehaven/8169289/openjfx-rt.0/ The changes can be pushed independently, so no fancy juggling will be needed. Only the LM_MODULE mode fails in any mixed combination, which fails as things stand now. I will file a followup issue to add unit tests, but those tests will go into openjfx and will wait until openjfx and openjdk promoted builds are in sync. I don't think the non-FX modes are affected substantially enough to warrant any test changes on the openjdk side. -DrD- From lance.andersen at oracle.com Thu Nov 10 17:48:32 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 10 Nov 2016 12:48:32 -0500 Subject: Review request: JDK-8168386: Fix jdeps verbose options In-Reply-To: References: Message-ID: Hi Mandy, This looks OK. Best Lance > On Nov 9, 2016, at 10:01 PM, Mandy Chung wrote: > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8168386/webrev.00 > > This patch tightens the option validation to jdeps and the new test shows some example of conflicting options. > > Mandy Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Roger.Riggs at Oracle.com Thu Nov 10 19:09:28 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 10 Nov 2016 14:09:28 -0500 Subject: RFR 9: 8169556 : Wrap FileInputStream's native skip and available methods In-Reply-To: References: Message-ID: <499d6671-2629-0832-9d2d-2c8d307d7bb3@Oracle.com> Hi, Please review this request to enable instrumentation on the FileInputStream skip and available methods by wrapping native methods with java methods as proposed and contributed by Sunny Chan. webrev: http://cr.openjdk.java.net/~rriggs/webrev-fis-native-wrap-8169556/ Issue: https://bugs.openjdk.java.net/browse/JDK-8169556 Regards, Roger p.s. Sorry for the long lapse Sonny On 11/9/2016 10:02 PM, Chan, Sunny wrote: > Hello all, > > I proposed a patch to provide wrapping for some native methods in FileInputStream a while ago in May, and the patch has been reviewed but it has not been integrated. I have checked the patch again with the latest JDK9 dev builds and it still works correctly passing java.io regression tests so could I have someone to sponsor this and integrate this patch? > > Here is the previous threads from email archive: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040901.html I have attached the patch again in this email for reference. > > Sunny Chan > Executive Director > Technology > > Goldman Sachs (Asia) L.L.C. | 39th Floor | The Center | 99 Queens Road Central | Hong Kong > Email: sunny.chan at gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633 > > Learn more about Goldman Sachs > GS.com | Blog | LinkedIn | YouTube | Twitter > > 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. > From chris.hegarty at oracle.com Thu Nov 10 19:17:04 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Nov 2016 19:17:04 +0000 Subject: RFR 9: 8169556 : Wrap FileInputStream's native skip and available methods In-Reply-To: <499d6671-2629-0832-9d2d-2c8d307d7bb3@Oracle.com> References: <499d6671-2629-0832-9d2d-2c8d307d7bb3@Oracle.com> Message-ID: <41338080-088E-4638-9E7B-9DDD0F35EC99@oracle.com> On 10 Nov 2016, at 19:09, Roger Riggs wrote: > > Hi, > > Please review this request to enable instrumentation on the FileInputStream skip and available methods > by wrapping native methods with java methods as proposed and contributed by Sunny Chan. > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-fis-native-wrap-8169556/ Reviewed. Thanks Roger. -Chris. > Issue: > https://bugs.openjdk.java.net/browse/JDK-8169556 > > Regards, Roger > > p.s. Sorry for the long lapse Sonny > > > On 11/9/2016 10:02 PM, Chan, Sunny wrote: >> Hello all, >> >> I proposed a patch to provide wrapping for some native methods in FileInputStream a while ago in May, and the patch has been reviewed but it has not been integrated. I have checked the patch again with the latest JDK9 dev builds and it still works correctly passing java.io regression tests so could I have someone to sponsor this and integrate this patch? >> >> Here is the previous threads from email archive: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040901.html I have attached the patch again in this email for reference. >> >> Sunny Chan >> Executive Director >> Technology >> >> Goldman Sachs (Asia) L.L.C. | 39th Floor | The Center | 99 Queens Road Central | Hong Kong >> Email: sunny.chan at gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633 >> >> Learn more about Goldman Sachs >> GS.com | Blog | LinkedIn | YouTube | Twitter >> >> 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. >> > From brian.burkhalter at oracle.com Thu Nov 10 19:18:47 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 Nov 2016 11:18:47 -0800 Subject: RFR 9: 8169556 : Wrap FileInputStream's native skip and available methods In-Reply-To: <41338080-088E-4638-9E7B-9DDD0F35EC99@oracle.com> References: <499d6671-2629-0832-9d2d-2c8d307d7bb3@Oracle.com> <41338080-088E-4638-9E7B-9DDD0F35EC99@oracle.com> Message-ID: +1 Thanks, Brian On Nov 10, 2016, at 11:17 AM, Chris Hegarty wrote: > On 10 Nov 2016, at 19:09, Roger Riggs wrote: >> >> Hi, >> >> Please review this request to enable instrumentation on the FileInputStream skip and available methods >> by wrapping native methods with java methods as proposed and contributed by Sunny Chan. >> >> webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-fis-native-wrap-8169556/ > > Reviewed. Thanks Roger. From paul.sandoz at oracle.com Thu Nov 10 20:24:04 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 10 Nov 2016 12:24:04 -0800 Subject: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue In-Reply-To: <71bc9aef-e7bc-6946-fe16-63a0c14fdffc@gmx.org> References: <314D8B90-3D99-4666-A1B4-3152C0D103D3@oracle.com> <0308ce68-14b9-8297-1929-fef2b6c0c37f@gmail.com> <9c44bc90-a4b9-d758-ee61-c910afe4851d@gmail.com> <21fe833e-724f-4905-3eda-255bc739bff0@gmail.com> <71bc9aef-e7bc-6946-fe16-63a0c14fdffc@gmx.org> Message-ID: <394D2FBD-4828-43AD-9640-0661F8379241@oracle.com> Hi Jochen, Can you confirm if my analysis of Groovy using ClassValue was correct: https://bugs.openjdk.java.net/browse/JDK-8136353 AFAICT in this case the issue was not with ClassValue itself but the storing of computed values in a global set. If i understand correctly you are you raising a wider issue with the function of ClassValue itself, it may be insufficient for your use-case, and not specifically with computed values strongly referring the associated ClassValue? Specifically, I am struggling to unpack this bit: > But if you will need at the same time a ClassValue to not to prevent a class we computed the value for from unloading and have the computed value alive for min(lifespan class, lifespan runtime), then you get a real big problem in realizing this. Computed values can strongly refer to the associated class, it becomes problematic when computed values strongly refer to the associated ClassValue. Is that something you require? Paul. > On 10 Nov 2016, at 00:51, Jochen Theodorou wrote: > > > > On 09.11.2016 17:47, Paul Sandoz wrote: >> Hi Peter, >> >> Good point about if such support was added it would break the API and also (with Remi) about Ephemerons. >> >> You are correct in stating the constraints in more detail regarding classes in the same loader. However, i think that is going into more detail than I would prefer for what i think is an edge case. > > I would not regard that an edge case. For a dynamic language using ClassValue to store information, it is very easy to produce a memory leak with ClassValue. > >> So I want in general to warn developers away from strongly referencing this ClassValue in the computed value for any associated class. >> >> If we do get strong feedback that this is a real problem we could consider adding a clever little static method like you suggest, with caveats that the computing Function might go away. > > for us it is such a strong problem, that we are unable to transfer the old structure to use ClassValue without a major rewrite of large parts. > Just imagine a runtime that uses ClassValue and that your application, let it be a web application, will spawn many runtimes over time. You do want the runtimes and all computed values be able to be garbage collected. But if you will need at the same time a ClassValue to not to prevent a class we computed the value for from unloading and have the computed value alive for min(lifespan class, lifespan runtime), then you get a real big problem in realizing this. > > As it stands for me ClassValue is only usable as a class associated cache with values you can recreate at any moment. That is not good enough for us in the general case. > > If that is an edge case I still miss a major part in the documentation... and that is what a ClassValue should be used for instead of a cryptic and incomplete description of what a ClassValue is. And then we could talk about if the intended use and the actual usability fit together > > bye Jcohen From kumar.x.srinivasan at oracle.com Thu Nov 10 21:10:51 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 10 Nov 2016 13:10:51 -0800 Subject: 8169001: Remove launcher's built-in ergonomics In-Reply-To: <6a3463cb-6e3f-a5cd-601a-2bb6f715eef1@oracle.com> References: <5820CC54.4010401@oracle.com> <6a3463cb-6e3f-a5cd-601a-2bb6f715eef1@oracle.com> Message-ID: <5824E25B.2040008@oracle.com> Hi David, Here is the updated revision * added back in FreeUnknowVMS * add -client KNOWN as you suggested delta webrev http://cr.openjdk.java.net/~ksrini/8169001/webrev.01/webrev.delta/ full webrev (for reference): http://cr.openjdk.java.net/~ksrini/8169001/webrev.01/ Thanks Kumar On 11/7/2016 3:24 PM, David Holmes wrote: > Hi Kumar, > > On 8/11/2016 4:47 AM, Kumar Srinivasan wrote: >> >> Hello, >> >> Please review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8169001 >> >> Webrev at: >> http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/ > > Overall this looks like a complete eradication of the launcher > ergonomics. A few specific comments: > > src/java.base/share/native/launcher/main.c > > ! const_cpwildcard, const_javaw, 0); > > Can you clarify this change with > > ! const_cpwildcard, const_javaw, 0 /* unused */); > > Thanks. > > --- > > src/java.base/share/native/libjli/java.c > > 220 jint ergo /* unused */ > > I assume JLI_Launch is an exported API otherwise I'd expect this to be > deleted. The fact it is unused should also be documented in > src/java.base/share/native/libjli/java.h. But I'm also wondering where > this API change is being documented for external users? > > - FreeKnownVMs(); /* after last possible PrintUsage() */ > > Not clear why you no longer need to free here. But if you don't then > FreeKnownVMs() seems to be dead code now. > > --- > > src/java.base/unix/conf/i586/jvm.cfg > > I think you still need an entry for "-client KNOWN" as anyone can > build the client VM if they choose. Ditto for > src/java.base/unix/conf/sparc/jvm.cfg (though 32-bit Solaris builds > are obsolete now). > > --- > > You have updated a number of copyright notices but not all of them. > > --- > > I see no changes to tests, but I'm pretty sure we have a test for > server-class-machine somewhere (or we did - I recall it breaking at > some point). > > Thanks, > David > >> Background: >>> Launcher ergonomics was introduced last decade to help determine >>> if the execution system is "Server Class", this was necessary to >>> choose server VM on platforms that supported both client and server >>> VMs (primarily for Solaris and Linux 32-bit). >>> >>> The algorithm involves computing and detecting the number of CPUs >>> and the amount of memory on the target system. All modern computers >>> systems with hyper-threading cause the ergonomics to choose server. >>> >>> JDK9 Platforms that have only server vm. >>> >>> ./linux-x64/lib/amd64/server/libjvm.so >>> ./linux-arm64-vfp-hflt/lib/aarch64/server/libjvm.so >>> ./solaris-sparcv9/lib/sparcv9/server/libjvm.so >>> ./solaris-x64/lib/amd64/server/libjvm.so >>> ./windows-x86/bin/server/jvm.dll >>> ./windows-x64/bin/server/jvm.dll >>> >>> JDK9 Platforms that have more than one vm variant: >>> ./linux-arm32-vfp-hflt/lib/arm/client/libjvm.so (default) >>> ./linux-arm32-vfp-hflt/lib/arm/minimal/libjvm.so >>> >>> ./linux-x86/lib/i386/server/libjvm.so (default) >>> ./linux-x86/lib/i386/minimal/libjvm.so >>> >>> >>> In the cases where multiple VMs are supported the ergnomics >>> has no effect, and the default platforms are chosen by the >>> jvm.cfg. Thus the launcher ergonomics is obsolete and redundant. >> >> Thanks >> Kumar >> From david.holmes at oracle.com Thu Nov 10 21:47:31 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Nov 2016 07:47:31 +1000 Subject: 8169001: Remove launcher's built-in ergonomics In-Reply-To: <5824E25B.2040008@oracle.com> References: <5820CC54.4010401@oracle.com> <6a3463cb-6e3f-a5cd-601a-2bb6f715eef1@oracle.com> <5824E25B.2040008@oracle.com> Message-ID: <64688e3b-41dd-224a-b990-fdc2c4c6cee6@oracle.com> Looks good! Thanks, David On 11/11/2016 7:10 AM, Kumar Srinivasan wrote: > Hi David, > > Here is the updated revision > * added back in FreeUnknowVMS > * add -client KNOWN as you suggested > > delta webrev > http://cr.openjdk.java.net/~ksrini/8169001/webrev.01/webrev.delta/ > > full webrev (for reference): > http://cr.openjdk.java.net/~ksrini/8169001/webrev.01/ > > Thanks > Kumar > > > > > On 11/7/2016 3:24 PM, David Holmes wrote: >> Hi Kumar, >> >> On 8/11/2016 4:47 AM, Kumar Srinivasan wrote: >>> >>> Hello, >>> >>> Please review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8169001 >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/ >> >> Overall this looks like a complete eradication of the launcher >> ergonomics. A few specific comments: >> >> src/java.base/share/native/launcher/main.c >> >> ! const_cpwildcard, const_javaw, 0); >> >> Can you clarify this change with >> >> ! const_cpwildcard, const_javaw, 0 /* unused */); >> >> Thanks. >> >> --- >> >> src/java.base/share/native/libjli/java.c >> >> 220 jint ergo /* unused */ >> >> I assume JLI_Launch is an exported API otherwise I'd expect this to be >> deleted. The fact it is unused should also be documented in >> src/java.base/share/native/libjli/java.h. But I'm also wondering where >> this API change is being documented for external users? >> >> - FreeKnownVMs(); /* after last possible PrintUsage() */ >> >> Not clear why you no longer need to free here. But if you don't then >> FreeKnownVMs() seems to be dead code now. >> >> --- >> >> src/java.base/unix/conf/i586/jvm.cfg >> >> I think you still need an entry for "-client KNOWN" as anyone can >> build the client VM if they choose. Ditto for >> src/java.base/unix/conf/sparc/jvm.cfg (though 32-bit Solaris builds >> are obsolete now). >> >> --- >> >> You have updated a number of copyright notices but not all of them. >> >> --- >> >> I see no changes to tests, but I'm pretty sure we have a test for >> server-class-machine somewhere (or we did - I recall it breaking at >> some point). >> >> Thanks, >> David >> >>> Background: >>>> Launcher ergonomics was introduced last decade to help determine >>>> if the execution system is "Server Class", this was necessary to >>>> choose server VM on platforms that supported both client and server >>>> VMs (primarily for Solaris and Linux 32-bit). >>>> >>>> The algorithm involves computing and detecting the number of CPUs >>>> and the amount of memory on the target system. All modern computers >>>> systems with hyper-threading cause the ergonomics to choose server. >>>> >>>> JDK9 Platforms that have only server vm. >>>> >>>> ./linux-x64/lib/amd64/server/libjvm.so >>>> ./linux-arm64-vfp-hflt/lib/aarch64/server/libjvm.so >>>> ./solaris-sparcv9/lib/sparcv9/server/libjvm.so >>>> ./solaris-x64/lib/amd64/server/libjvm.so >>>> ./windows-x86/bin/server/jvm.dll >>>> ./windows-x64/bin/server/jvm.dll >>>> >>>> JDK9 Platforms that have more than one vm variant: >>>> ./linux-arm32-vfp-hflt/lib/arm/client/libjvm.so (default) >>>> ./linux-arm32-vfp-hflt/lib/arm/minimal/libjvm.so >>>> >>>> ./linux-x86/lib/i386/server/libjvm.so (default) >>>> ./linux-x86/lib/i386/minimal/libjvm.so >>>> >>>> >>>> In the cases where multiple VMs are supported the ergnomics >>>> has no effect, and the default platforms are chosen by the >>>> jvm.cfg. Thus the launcher ergonomics is obsolete and redundant. >>> >>> Thanks >>> Kumar >>> > From peter.levart at gmail.com Thu Nov 10 22:28:35 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 10 Nov 2016 23:28:35 +0100 Subject: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError In-Reply-To: References: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> Message-ID: <3c4ec322-bbc6-f0a1-14aa-6fbea37da699@gmail.com> On 11/10/2016 05:59 PM, Alan Bateman wrote: > > > On 10/11/2016 17:42, David M. Lloyd wrote: >> My original suggestion for the method was to make it static, and >> possibly even caller-sensitive, for just this reason. > Changing it to be non-final looks reasonable here, the main reason > being that it's a no-arg isXXXX method and so unlikely that there are > custom class loaders that have a method with this name that returns > something other than boolean. However the modifier might be a concern > and so time will tell if there are custom class loaders that defining > a non-public no-arg method with this name. > > -Alan It would be nice for this method to be final. This way it could be relied on to return the "correct" answer regardless of the implementation subclass. Who knows, maybe some internal logic might need this method in the future and at that time another package-protected method would have to be added and exposed via SharedSecrets or similar. If "isParallelCapable" is already taken, then what about choosing another name? Since there is already a @CallerSensitive protected static method called "registerAsParallelCapable" for subclasses to call from their blocks, the query could be called: isRegisteredAsParallelCapable() ? I doubt this name is already taken by any subclass out there... Regards, Peter From mandy.chung at oracle.com Thu Nov 10 22:46:40 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 10 Nov 2016 14:46:40 -0800 Subject: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError In-Reply-To: <3c4ec322-bbc6-f0a1-14aa-6fbea37da699@gmail.com> References: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> <3c4ec322-bbc6-f0a1-14aa-6fbea37da699@gmail.com> Message-ID: <0AA344AE-79D2-4DF6-A24B-E01463519147@oracle.com> > On Nov 10, 2016, at 2:28 PM, Peter Levart wrote: > > On 11/10/2016 05:59 PM, Alan Bateman wrote: >> >> >> On 10/11/2016 17:42, David M. Lloyd wrote: >>> My original suggestion for the method was to make it static, and possibly even caller-sensitive, for just this reason. >> Changing it to be non-final looks reasonable here, the main reason being that it's a no-arg isXXXX method and so unlikely that there are custom class loaders that have a method with this name that returns something other than boolean. However the modifier might be a concern and so time will tell if there are custom class loaders that defining a non-public no-arg method with this name. >> >> -Alan > > It would be nice for this method to be final. That?d be the ideal case. > This way it could be relied on to return the "correct" answer regardless of the implementation subclass. Who knows, maybe some internal logic might need this method in the future and at that time another package-protected method would have to be added and exposed via SharedSecrets or similar. If "isParallelCapable" is already taken, then what about choosing another name? This is alternative but it?s hard to predict the probability of a name clash with existing subclass implementation. > Since there is already a @CallerSensitive protected static method called "registerAsParallelCapable" for subclasses to call from their blocks, the query could be called: > > isRegisteredAsParallelCapable() ? > > I doubt this name is already taken by any subclass out there? isRegisteredAsParallelCapable may be okay. Mandy From david.holmes at oracle.com Thu Nov 10 22:56:48 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Nov 2016 08:56:48 +1000 Subject: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError In-Reply-To: <0AA344AE-79D2-4DF6-A24B-E01463519147@oracle.com> References: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> <3c4ec322-bbc6-f0a1-14aa-6fbea37da699@gmail.com> <0AA344AE-79D2-4DF6-A24B-E01463519147@oracle.com> Message-ID: <58552d39-458c-b721-ae36-9bdeba3b1ff0@oracle.com> On 11/11/2016 8:46 AM, Mandy Chung wrote: > >> On Nov 10, 2016, at 2:28 PM, Peter Levart wrote: >> >> On 11/10/2016 05:59 PM, Alan Bateman wrote: >>> >>> >>> On 10/11/2016 17:42, David M. Lloyd wrote: >>>> My original suggestion for the method was to make it static, and possibly even caller-sensitive, for just this reason. >>> Changing it to be non-final looks reasonable here, the main reason being that it's a no-arg isXXXX method and so unlikely that there are custom class loaders that have a method with this name that returns something other than boolean. However the modifier might be a concern and so time will tell if there are custom class loaders that defining a non-public no-arg method with this name. >>> >>> -Alan >> >> It would be nice for this method to be final. > > That?d be the ideal case. > >> This way it could be relied on to return the "correct" answer regardless of the implementation subclass. Who knows, maybe some internal logic might need this method in the future and at that time another package-protected method would have to be added and exposed via SharedSecrets or similar. If "isParallelCapable" is already taken, then what about choosing another name? > > This is alternative but it?s hard to predict the probability of a name clash with existing subclass implementation. > >> Since there is already a @CallerSensitive protected static method called "registerAsParallelCapable" for subclasses to call from their blocks, the query could be called: >> >> isRegisteredAsParallelCapable() ? >> >> I doubt this name is already taken by any subclass out there? > > isRegisteredAsParallelCapable may be okay. I'd vote for that and keeping it final. Thanks, David > Mandy > From masayoshi.okutsu at oracle.com Thu Nov 10 23:15:19 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 11 Nov 2016 08:15:19 +0900 Subject: RFR: jdk8u-dev Backport of 8169191: (tz) Support tzdata2016i In-Reply-To: References: Message-ID: <32d01d3a-decf-9750-32be-ad532612e4a7@oracle.com> +1 On 11/11/2016 1:48 AM, Martin Buchholz wrote: > Looks good! > > On Thu, Nov 10, 2016 at 1:48 AM, Ramanand Patil > wrote: > >> Hi all, >> Please review the latest TZDATA integration (tzdata2016i) to JDK8U. >> Since tzdata is cumulative, this bug fix backports both the tzdata >> versions(tzdata2016h+tzdata2016i) into jdk8u. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8169191 >> Webrev: http://cr.openjdk.java.net/~rpatil/8169537/webrev.00/ >> >> Jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7f7091c1dd33 >> >> For reference: >> Jdk9 changeset for tzdata2016h integration(JDK-8168512): >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3192d7aa428d >> >> All the TimeZone related tests are passed after integration. >> >> >> Regards, >> Ramanand. >> From bhanu.prakash.gopularam at oracle.com Fri Nov 11 05:27:20 2016 From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam) Date: Thu, 10 Nov 2016 21:27:20 -0800 (PST) Subject: RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale In-Reply-To: <574b23f4-e9cc-cc95-0b7b-6dd5a4bdea68@Oracle.com> References: <574b23f4-e9cc-cc95-0b7b-6dd5a4bdea68@Oracle.com> Message-ID: <50825aee-4268-451c-a470-4433fb8c437b@default> Hi Roger, Thanks for the review. I have updated the test to set default locale (and restore it) in only those methods which were causing problem in non English locales. Please review the updated webrev below: Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.01/ Thanks, Bhanu From: Roger Riggs Sent: Tuesday, June 21, 2016 8:36 PM To: Bhanu Gopularam; core-libs-dev at openjdk.java.net Cc: Stephen Colebourne Subject: Re: RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale Hi Bhanu, It can be problematic to change the default Locale for the entire process, especially since many tests are run in the same process. It would be preferable to set the locale in the DateTimeFormatter builder instead of changing the process wide Locale. Please identify the specific test case to apply the fix only where needed. Is it only tck.java.time.format.TCKDateTimeFormatterBuilder.test_appendZoneText_parseGenericTimeZonePatterns where the failure is seen? This would be an issue testing any pattern letter with locale dependent behavior. The locale should be set explicitly in the test. BTW, There is a predefined Locale.US that can be used, no need to construct a new Locale. Roger On 6/21/2016 6:31 AM, Bhanu Gopularam wrote: 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 From david.holmes at oracle.com Fri Nov 11 06:11:15 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Nov 2016 16:11:15 +1000 Subject: Race Condition in initializeEncoding() function in jni_util.c In-Reply-To: References: Message-ID: <12fca821-6427-9cf7-4d67-141a306aa2eb@oracle.com> Hi Ron, On 11/11/2016 1:01 AM, Ronald Servant wrote: > > > Hi, > > While building the J9 JVM for the IBM SDK for Java(*), we've run across > what we believe is a race condition in initializeEncoding(JNIEnv*) in > jni_util.c. I suspect there is an assumption of single-threaded initialization of the system classes, which would hit this code and so safely initialize the statics. There may be many such assumptions. Reordering the statements may address your failure but does not make the code thread-safe, and you may encounter additional, more obscure race conditions. David ----- > > (*) The IBM SDK for Java is comprised of the J9 JVM and OpenJDK > class library. > We've encountered a situation where (*env)->CallObjectMethod() in > JNU_GetStringPlatformChars() is invoked with an uninitialized method ID > (the static variable "String_getBytes_ID"). > > The function initializeEnconding() initializes 4 static variables, but only > one of them ("fastEncoding") is checked to see if initializeEnconding() > should be called in JNU_NewStringPlatform() and JNU_GetStringPlatformChars > (). Further, "fastEncoding" is the first of the 4 static variables set by > initializeEncoding() leaving a race condition where another thread sees > "fastEncoding" set but "String_getBytes_ID" is not yet initialized. > > I believe that moving the initialization of "String_getBytes_ID" and > "String_init_ID" to the top of the function would eliminate the impact of > the race condition. > > I'd also recommend moving the initialization of "jnuEncoding" up one line, > but this may lead to leaking a global ref. > > We are able to reproduce the failure in JNU_GetStringPlatformChars() due to > using an null String_getBytes_ID variable for a method id race condition in > our environment 1 in 20. With the following patch applied, the race > condition can no longer be reproduced. > > Do you agree there is a race condition? If so, would the patch be an > appropriate fix? We could introduce locking, but that feels like > overkill. > > Ron. > > diff -r efa71dc820eb src/java.base/share/native/libjava/jni_util.c > --- a/src/java.base/share/native/libjava/jni_util.c Mon Nov 07 13:10:42 > 2016 -0400 > +++ b/src/java.base/share/native/libjava/jni_util.c Wed Nov 09 17:19:16 > 2016 -0500 > @@ -688,6 +688,15 @@ > > strClazz = JNU_ClassString(env); > CHECK_NULL(strClazz); > + > + /* Initialize method-id cache */ > + String_getBytes_ID = (*env)->GetMethodID(env, strClazz, > + "getBytes", > "(Ljava/lang/String;)[B"); > + CHECK_NULL(String_getBytes_ID); > + String_init_ID = (*env)->GetMethodID(env, strClazz, > + "", > "([BLjava/lang/String;)V"); > + CHECK_NULL(String_init_ID); > + > > propname = (*env)->NewStringUTF(env, "sun.jnu.encoding"); > if (propname) { > @@ -727,8 +736,8 @@ > strcmp(encname, "utf-16le") == 0) > fastEncoding = FAST_CP1252; > else { > + jnuEncoding = (jstring)(*env)->NewGlobalRef(env, > enc); > fastEncoding = NO_FAST_ENCODING; > - jnuEncoding = (jstring)(*env)->NewGlobalRef(env, > enc); > } > (*env)->ReleaseStringUTFChars(env, enc, encname); > } > @@ -741,13 +750,6 @@ > } > (*env)->DeleteLocalRef(env, propname); > (*env)->DeleteLocalRef(env, enc); > - > - /* Initialize method-id cache */ > - String_getBytes_ID = (*env)->GetMethodID(env, strClazz, > - "getBytes", > "(Ljava/lang/String;)[B"); > - CHECK_NULL(String_getBytes_ID); > - String_init_ID = (*env)->GetMethodID(env, strClazz, > - "", > "([BLjava/lang/String;)V"); > } > > > From nadeesh.tv at oracle.com Fri Nov 11 08:39:07 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Fri, 11 Nov 2016 14:09:07 +0530 Subject: RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale In-Reply-To: <50825aee-4268-451c-a470-4433fb8c437b@default> References: <574b23f4-e9cc-cc95-0b7b-6dd5a4bdea68@Oracle.com> <50825aee-4268-451c-a470-4433fb8c437b@default> Message-ID: <582583AB.3060308@oracle.com> Hi Bhanu, I think adding Locale to the formatter will be better For eg: DateTimeFormatter f = builder.parseLenient().appendValue(HOUR_OF_DAY).appendValue(MINUTE_OF_HOUR, 2).appendLiteral('9').toFormatter(Locale.UK); Since other test cases use Locale.UK may be here also you can use UK instead of locale.US. Thanks and Regards, Nadeesh On 11/11/2016 10:57 AM, Bhanu Gopularam wrote: > Hi Roger, > > > > Thanks for the review. I have updated the test to set default locale (and restore it) in only those methods which were causing problem in non English locales. > > > > Please review the updated webrev below: > > Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.01/ > > > > Thanks, > > Bhanu > > > > From: Roger Riggs > Sent: Tuesday, June 21, 2016 8:36 PM > To: Bhanu Gopularam; core-libs-dev at openjdk.java.net > Cc: Stephen Colebourne > Subject: Re: RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale > > > > Hi Bhanu, > > It can be problematic to change the default Locale for the entire process, especially > since many tests are run in the same process. It would be preferable to set the locale > in the DateTimeFormatter builder instead of changing the process wide Locale. > > Please identify the specific test case to apply the fix only where needed. > > Is it only tck.java.time.format.TCKDateTimeFormatterBuilder.test_appendZoneText_parseGenericTimeZonePatterns > where the failure is seen? > > This would be an issue testing any pattern letter with locale dependent behavior. > The locale should be set explicitly in the test. > > BTW, There is a predefined Locale.US that can be used, no need to construct a new Locale. > > Roger > > > > > > On 6/21/2016 6:31 AM, Bhanu Gopularam wrote: > > 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 > > -- Thanks and Regards, Nadeesh TV From zoltan.majo at oracle.com Fri Nov 11 09:25:13 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 11 Nov 2016 10:25:13 +0100 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package Message-ID: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> Hi, please review the fix for 8169000: https://bugs.openjdk.java.net/browse/JDK-8169000 http://cr.openjdk.java.net/~zmajo/8169000/webrev.00/ The bug was filed because different behavior of interpreted and compiled code in HotSpot was observed (different behavior with respect to phantom references). After discussions with Maurizio C, Alex B, and David H, the best way to address this problem seems to be to update update the documentation of the java.lang.ref to avoid confusion in the future. David's comment in the bug report [1] accurately and concisely summarizes the reasons for the suggested patch. For more details please feel free to look at the comments in the bug report. Thank you! Best regards, Zoltan [1] https://bugs.openjdk.java.net/browse/JDK-8169000?focusedCommentId=14021250&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14021250 From Alan.Bateman at oracle.com Fri Nov 11 10:16:21 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Nov 2016 10:16:21 +0000 Subject: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError In-Reply-To: <0AA344AE-79D2-4DF6-A24B-E01463519147@oracle.com> References: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> <3c4ec322-bbc6-f0a1-14aa-6fbea37da699@gmail.com> <0AA344AE-79D2-4DF6-A24B-E01463519147@oracle.com> Message-ID: <4c9dc49f-c67e-4a0c-634e-f91d44cc0c6a@oracle.com> On 10/11/2016 22:46, Mandy Chung wrote: > : >> Since there is already a @CallerSensitive protected static method called "registerAsParallelCapable" for subclasses to call from their blocks, the query could be called: >> >> isRegisteredAsParallelCapable() ? >> >> I doubt this name is already taken by any subclass out there? > isRegisteredAsParallelCapable may be okay. > It's always a potential compatibility issue to add a final method to a non-final class but if we can get away with the rename suggested by Peter then it would be good. I hope there will be enough usages of the EA builds to shake out any other conflicts. -Alan. From vladimir.x.ivanov at oracle.com Fri Nov 11 10:46:38 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 11 Nov 2016 13:46:38 +0300 Subject: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError In-Reply-To: References: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> Message-ID: Alan, I've looked through the current thread and also review thread [1] for original change (8165793), but haven't found any discussion why making it static (instead of instance final) is undesirable. Can you shed some light on it? Is it mainly usability concern (loader.isParallelCapable() vs ClassLoader.isParallelCapable(loader))? Best regards, Vladimir Ivanov [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-October/044060.html On 11/10/16 7:59 PM, Alan Bateman wrote: > > > On 10/11/2016 17:42, David M. Lloyd wrote: >> My original suggestion for the method was to make it static, and >> possibly even caller-sensitive, for just this reason. > Changing it to be non-final looks reasonable here, the main reason being > that it's a no-arg isXXXX method and so unlikely that there are custom > class loaders that have a method with this name that returns something > other than boolean. However the modifier might be a concern and so time > will tell if there are custom class loaders that defining a non-public > no-arg method with this name. > > -Alan From Alan.Bateman at oracle.com Fri Nov 11 11:07:00 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Nov 2016 11:07:00 +0000 Subject: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError In-Reply-To: References: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> Message-ID: <8ebb0fac-2be6-8163-7742-21dc53c72de0@oracle.com> On 11/11/2016 10:46, Vladimir Ivanov wrote: > Alan, > > I've looked through the current thread and also review thread [1] for > original change (8165793), but haven't found any discussion why making > it static (instead of instance final) is undesirable. > > Can you shed some light on it? Is it mainly usability concern > (loader.isParallelCapable() vs ClassLoader.isParallelCapable(loader))? I assume you mean to address this to Brent rather than me, but yes, an instance method would be nicer (if we can get away with it). -Alan. From daniel.fuchs at oracle.com Fri Nov 11 12:21:33 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 11 Nov 2016 12:21:33 +0000 Subject: Review request: JDK-8168386: Fix jdeps verbose options In-Reply-To: References: Message-ID: <1745def2-6f2d-e51a-d70f-406588433e7c@oracle.com> Hi Mandy, This looks good to me. However, if I'm not mistaken, jdeps will now no longer list java.base as a dependency, unless the dependency is on a jdk internal API. This might be worthy of some mention in release notes - if any tools are relying on jdeps output. best regards, -- daniel On 10/11/16 03:01, Mandy Chung wrote: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8168386/webrev.00 > > This patch tightens the option validation to jdeps and the new test shows some example of conflicting options. > > Mandy > From david.lloyd at redhat.com Fri Nov 11 15:03:44 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 11 Nov 2016 09:03:44 -0600 Subject: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError In-Reply-To: <8ebb0fac-2be6-8163-7742-21dc53c72de0@oracle.com> References: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> <8ebb0fac-2be6-8163-7742-21dc53c72de0@oracle.com> Message-ID: On 11/11/2016 05:07 AM, Alan Bateman wrote: > > > On 11/11/2016 10:46, Vladimir Ivanov wrote: >> Alan, >> >> I've looked through the current thread and also review thread [1] for >> original change (8165793), but haven't found any discussion why making >> it static (instead of instance final) is undesirable. >> >> Can you shed some light on it? Is it mainly usability concern >> (loader.isParallelCapable() vs ClassLoader.isParallelCapable(loader))? > I assume you mean to address this to Brent rather than me, but yes, an > instance method would be nicer (if we can get away with it). I think the question was "why not?". A static method can never conflict, and doesn't have a usability impact. A final method can always conflict, and a non-final method is always potentially problematic for the multiple reasons already stated on this thread. By score, static wins. So, why not? -- - DML From peter.levart at gmail.com Fri Nov 11 15:33:21 2016 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 11 Nov 2016 16:33:21 +0100 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> Message-ID: <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> Hi Zoltan, On 11/11/2016 10:25 AM, Zolt?n Maj? wrote: > Hi, > > > please review the fix for 8169000: > > https://bugs.openjdk.java.net/browse/JDK-8169000 > http://cr.openjdk.java.net/~zmajo/8169000/webrev.00/ > > The bug was filed because different behavior of interpreted and > compiled code in HotSpot was observed (different behavior with respect > to phantom references). After discussions with Maurizio C, Alex B, > and David H, the best way to address this problem seems to be to > update update the documentation of the java.lang.ref to avoid > confusion in the future. David's comment in the bug report [1] > accurately and concisely summarizes the reasons for the suggested > patch. For more details please feel free to look at the comments in > the bug report. > > Thank you! > > Best regards, > > > Zoltan > > [1] > https://bugs.openjdk.java.net/browse/JDK-8169000?focusedCommentId=14021250&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14021250 > I think the wording could be even less specific about "detecting" the reachability of the reference object. For example: ... If a registered reference becomes unreachable itself, then it *may* never be enqueued. In addition, the situations that describe when the reference *may* not be enqueued could be expanded. For example: ... If a registered reference ceases to be strongly reachable itself, then it *may* never be enqueued. The following modified test shows this situation: public class WeaklyReachablePhantomReference { static ReferenceQueue rq = new ReferenceQueue<>(); static WeakReference> weakRefRef; public static void main(final String[] args) throws Exception { weakRefRef = new WeakReference<>( new PhantomReference<>( new Object(), rq ) ); // <- here System.gc(); Reference rmRef = rq.remove(1000); if (rmRef == null) { System.out.println("PhantomReference NOT enqueued"); } else { System.out.println("PhantomReference enqueued"); } } } At "<-- here" the PhantomReference object becomes weakly reachable while its referent becomes phantom reachable and this is enough for PhantomReference to not be enqueued. Regards, Peter From karen.kinnear at oracle.com Fri Nov 11 15:59:56 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 11 Nov 2016 10:59:56 -0500 Subject: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError In-Reply-To: <58552d39-458c-b721-ae36-9bdeba3b1ff0@oracle.com> References: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> <3c4ec322-bbc6-f0a1-14aa-6fbea37da699@gmail.com> <0AA344AE-79D2-4DF6-A24B-E01463519147@oracle.com> <58552d39-458c-b721-ae36-9bdeba3b1ff0@oracle.com> Message-ID: <5FB1D57C-8E0F-4A58-B543-D629B2E8BA6F@oracle.com> +1 Karen > On Nov 10, 2016, at 5:56 PM, David Holmes wrote: > > > > On 11/11/2016 8:46 AM, Mandy Chung wrote: >> >>> On Nov 10, 2016, at 2:28 PM, Peter Levart wrote: >>> >>> On 11/10/2016 05:59 PM, Alan Bateman wrote: >>>> >>>> >>>> On 10/11/2016 17:42, David M. Lloyd wrote: >>>>> My original suggestion for the method was to make it static, and possibly even caller-sensitive, for just this reason. >>>> Changing it to be non-final looks reasonable here, the main reason being that it's a no-arg isXXXX method and so unlikely that there are custom class loaders that have a method with this name that returns something other than boolean. However the modifier might be a concern and so time will tell if there are custom class loaders that defining a non-public no-arg method with this name. >>>> >>>> -Alan >>> >>> It would be nice for this method to be final. >> >> That?d be the ideal case. >> >>> This way it could be relied on to return the "correct" answer regardless of the implementation subclass. Who knows, maybe some internal logic might need this method in the future and at that time another package-protected method would have to be added and exposed via SharedSecrets or similar. If "isParallelCapable" is already taken, then what about choosing another name? >> >> This is alternative but it?s hard to predict the probability of a name clash with existing subclass implementation. >> >>> Since there is already a @CallerSensitive protected static method called "registerAsParallelCapable" for subclasses to call from their blocks, the query could be called: >>> >>> isRegisteredAsParallelCapable() ? >>> >>> I doubt this name is already taken by any subclass out there? >> >> isRegisteredAsParallelCapable may be okay. > > I'd vote for that and keeping it final. > > Thanks, > David > >> Mandy >> From forax at univ-mlv.fr Fri Nov 11 17:13:41 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 11 Nov 2016 18:13:41 +0100 (CET) Subject: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError In-Reply-To: References: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> <8ebb0fac-2be6-8163-7742-21dc53c72de0@oracle.com> Message-ID: <1677706373.2320667.1478884421420.JavaMail.zimbra@u-pem.fr> Hi David, you can not override a static method :) but there is still a corner case, you can have a conflict when you have a method reference over an instance method and you introduce a static method that have the same functional signature. Given that i prefer to have a compile time error than a strange behavior at runtime (if there is an accidental overriding), I vote for the static method too. cheers, R?mi ----- Mail original ----- > De: "David M. Lloyd" > ?: core-libs-dev at openjdk.java.net > Envoy?: Vendredi 11 Novembre 2016 16:03:44 > Objet: Re: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError > On 11/11/2016 05:07 AM, Alan Bateman wrote: >> >> >> On 11/11/2016 10:46, Vladimir Ivanov wrote: >>> Alan, >>> >>> I've looked through the current thread and also review thread [1] for >>> original change (8165793), but haven't found any discussion why making >>> it static (instead of instance final) is undesirable. >>> >>> Can you shed some light on it? Is it mainly usability concern >>> (loader.isParallelCapable() vs ClassLoader.isParallelCapable(loader))? >> I assume you mean to address this to Brent rather than me, but yes, an >> instance method would be nicer (if we can get away with it). > > I think the question was "why not?". A static method can never > conflict, and doesn't have a usability impact. A final method can > always conflict, and a non-final method is always potentially > problematic for the multiple reasons already stated on this thread. > > By score, static wins. So, why not? > -- > - DML From naoto.sato at oracle.com Fri Nov 11 18:52:23 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 11 Nov 2016 10:52:23 -0800 Subject: RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale In-Reply-To: <582583AB.3060308@oracle.com> References: <574b23f4-e9cc-cc95-0b7b-6dd5a4bdea68@Oracle.com> <50825aee-4268-451c-a470-4433fb8c437b@default> <582583AB.3060308@oracle.com> Message-ID: <4c8d8e3e-9f3e-59b4-cd7b-ff3b089c1a86@oracle.com> Hi Bhanu, Nadeesh, As to which locale to use, I suggest using US English (Locale.US), since that is the one in java.base module. Using Locale.UK could cause unexpected fallback to Locale.US if jdk.localedata module is not available. Naoto On 11/11/16 12:39 AM, nadeesh tv wrote: > Hi Bhanu, > > > I think adding Locale to the formatter will be better > > For eg: > > DateTimeFormatter f = > builder.parseLenient().appendValue(HOUR_OF_DAY).appendValue(MINUTE_OF_HOUR, > 2).appendLiteral('9').toFormatter(Locale.UK); > > Since other test cases use Locale.UK may be here also you can use UK > instead of locale.US. > > Thanks and Regards, > Nadeesh > > > On 11/11/2016 10:57 AM, Bhanu Gopularam wrote: >> Hi Roger, >> >> >> Thanks for the review. I have updated the test to set default locale >> (and restore it) in only those methods which were causing problem in >> non English locales. >> >> >> Please review the updated webrev below: >> >> Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.01/ >> >> >> Thanks, >> >> Bhanu >> >> >> From: Roger Riggs >> Sent: Tuesday, June 21, 2016 8:36 PM >> To: Bhanu Gopularam; core-libs-dev at openjdk.java.net >> Cc: Stephen Colebourne >> Subject: Re: RFR 8158880: >> java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail >> with zh_CN locale >> >> >> Hi Bhanu, >> >> It can be problematic to change the default Locale for the entire >> process, especially >> since many tests are run in the same process. It would be preferable >> to set the locale >> in the DateTimeFormatter builder instead of changing the process wide >> Locale. >> >> Please identify the specific test case to apply the fix only where >> needed. >> >> Is it only >> tck.java.time.format.TCKDateTimeFormatterBuilder.test_appendZoneText_parseGenericTimeZonePatterns >> >> where the failure is seen? >> >> This would be an issue testing any pattern letter with locale >> dependent behavior. >> The locale should be set explicitly in the test. >> >> BTW, There is a predefined Locale.US that can be used, no need to >> construct a new Locale. >> >> Roger >> >> >> >> On 6/21/2016 6:31 AM, Bhanu Gopularam wrote: >> >> 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 >> >> > From mandy.chung at oracle.com Fri Nov 11 22:58:59 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 11 Nov 2016 14:58:59 -0800 Subject: Review request: JDK-8168386: Fix jdeps verbose options In-Reply-To: <1745def2-6f2d-e51a-d70f-406588433e7c@oracle.com> References: <1745def2-6f2d-e51a-d70f-406588433e7c@oracle.com> Message-ID: > On Nov 11, 2016, at 4:21 AM, Daniel Fuchs wrote: > > Hi Mandy, > > This looks good to me. Thanks. > However, if I'm not mistaken, jdeps will now no longer > list java.base as a dependency, unless the dependency > is on a jdk internal API. > That is only when using ?-list-deps option. That is a separate issue. I will take it out from this webrev. Mandy > This might be worthy of some mention in release notes - if > any tools are relying on jdeps output. > > best regards, > > -- daniel > > On 10/11/16 03:01, Mandy Chung wrote: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8168386/webrev.00 >> >> This patch tightens the option validation to jdeps and the new test shows some example of conflicting options. >> >> Mandy >> > From mandy.chung at oracle.com Fri Nov 11 23:10:13 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 11 Nov 2016 15:10:13 -0800 Subject: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError In-Reply-To: <1677706373.2320667.1478884421420.JavaMail.zimbra@u-pem.fr> References: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> <8ebb0fac-2be6-8163-7742-21dc53c72de0@oracle.com> <1677706373.2320667.1478884421420.JavaMail.zimbra@u-pem.fr> Message-ID: <9B46CB8C-0746-4191-AD9D-4DB44100AF83@oracle.com> While this could be made as a static method, there are cases that an instance method would be preferred and same compatibility would arise. For example, ClassLoader::getName is non-final instance method as it stands and I?d be reluctant to make it a static method taking a ClassLoader instance. It would be nice to support @PromoteToFinalMethod to allow a new method be non-final when it?s added and promote to a final method in a future release allowing existing code to transition. My preference is to go with ClassLoader::isRegisteredAsParallelCapable final instance method and the chance of the name clash may be low (Brent did some search from grepcode and at least not finding that name yet. Of course this is not bullet-proof). Mandy > On Nov 11, 2016, at 9:13 AM, Remi Forax wrote: > > Hi David, > you can not override a static method :) > but there is still a corner case, you can have a conflict when you have a method reference over an instance method and you introduce a static method that have the same functional signature. > > Given that i prefer to have a compile time error than a strange behavior at runtime (if there is an accidental overriding), > I vote for the static method too. > > cheers, > R?mi > > ----- Mail original ----- >> De: "David M. Lloyd" >> ?: core-libs-dev at openjdk.java.net >> Envoy?: Vendredi 11 Novembre 2016 16:03:44 >> Objet: Re: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError > >> On 11/11/2016 05:07 AM, Alan Bateman wrote: >>> >>> >>> On 11/11/2016 10:46, Vladimir Ivanov wrote: >>>> Alan, >>>> >>>> I've looked through the current thread and also review thread [1] for >>>> original change (8165793), but haven't found any discussion why making >>>> it static (instead of instance final) is undesirable. >>>> >>>> Can you shed some light on it? Is it mainly usability concern >>>> (loader.isParallelCapable() vs ClassLoader.isParallelCapable(loader))? >>> I assume you mean to address this to Brent rather than me, but yes, an >>> instance method would be nicer (if we can get away with it). >> >> I think the question was "why not?". A static method can never >> conflict, and doesn't have a usability impact. A final method can >> always conflict, and a non-final method is always potentially >> problematic for the multiple reasons already stated on this thread. >> >> By score, static wins. So, why not? >> -- >> - DML From mandy.chung at oracle.com Sat Nov 12 06:46:13 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 11 Nov 2016 22:46:13 -0800 Subject: JDK-Review Request: JDK-8169606 jdeps --list-reduced-deps should not show java.base as all modules require it Message-ID: Daniel, This is an improved version of what you reviewed earlier. jdeps --list-reduced-deps will show java.base only when it?s the only module it depends on. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169606/webrev.00 thanks Mandy From forax at univ-mlv.fr Sat Nov 12 11:04:40 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 12 Nov 2016 12:04:40 +0100 (CET) Subject: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError In-Reply-To: <9B46CB8C-0746-4191-AD9D-4DB44100AF83@oracle.com> References: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> <8ebb0fac-2be6-8163-7742-21dc53c72de0@oracle.com> <1677706373.2320667.1478884421420.JavaMail.zimbra@u-pem.fr> <9B46CB8C-0746-4191-AD9D-4DB44100AF83@oracle.com> Message-ID: <577218967.2379337.1478948680504.JavaMail.zimbra@u-pem.fr> Hi Mandy, getName() is used for debugging so if it's the wrong name which is picked, is not a big deal, the stacktrace will be just a little weird, that's why i think it's fine to make getName non static and non final, because accidental overriding is not harmful. Accidental overriding of isParallelCapable is harmful. In term of design the main issue with a static method is the discoverability issue, if a user hit ctrl + space, a static method will not be among the proposed methods. so i'm fine with a final isRegisteredAsParallelCapable if you think that users should be aware that this method exist. regards, R?mi ----- Mail original ----- > De: "Mandy Chung" > ?: "Remi Forax" > Cc: "David M. Lloyd" , "core-libs-dev" > Envoy?: Samedi 12 Novembre 2016 00:10:13 > Objet: Re: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError > While this could be made as a static method, there are cases that an instance > method would be preferred and same compatibility would arise. For example, > ClassLoader::getName is non-final instance method as it stands and I?d be > reluctant to make it a static method taking a ClassLoader instance. > > It would be nice to support @PromoteToFinalMethod to allow a new method be > non-final when it?s added and promote to a final method in a future release > allowing existing code to transition. > > My preference is to go with ClassLoader::isRegisteredAsParallelCapable final > instance method and the chance of the name clash may be low (Brent did some > search from grepcode and at least not finding that name yet. Of course this is > not bullet-proof). > > Mandy > >> On Nov 11, 2016, at 9:13 AM, Remi Forax wrote: >> >> Hi David, >> you can not override a static method :) >> but there is still a corner case, you can have a conflict when you have a method >> reference over an instance method and you introduce a static method that have >> the same functional signature. >> >> Given that i prefer to have a compile time error than a strange behavior at >> runtime (if there is an accidental overriding), >> I vote for the static method too. >> >> cheers, >> R?mi >> >> ----- Mail original ----- >>> De: "David M. Lloyd" >>> ?: core-libs-dev at openjdk.java.net >>> Envoy?: Vendredi 11 Novembre 2016 16:03:44 >>> Objet: Re: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting >>> method may get VerifyError >> >>> On 11/11/2016 05:07 AM, Alan Bateman wrote: >>>> >>>> >>>> On 11/11/2016 10:46, Vladimir Ivanov wrote: >>>>> Alan, >>>>> >>>>> I've looked through the current thread and also review thread [1] for >>>>> original change (8165793), but haven't found any discussion why making >>>>> it static (instead of instance final) is undesirable. >>>>> >>>>> Can you shed some light on it? Is it mainly usability concern >>>>> (loader.isParallelCapable() vs ClassLoader.isParallelCapable(loader))? >>>> I assume you mean to address this to Brent rather than me, but yes, an >>>> instance method would be nicer (if we can get away with it). >>> >>> I think the question was "why not?". A static method can never >>> conflict, and doesn't have a usability impact. A final method can >>> always conflict, and a non-final method is always potentially >>> problematic for the multiple reasons already stated on this thread. >>> >>> By score, static wins. So, why not? >>> -- > >> - DML From daniel.fuchs at oracle.com Sat Nov 12 11:06:30 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Sat, 12 Nov 2016 11:06:30 +0000 Subject: JDK-Review Request: JDK-8169606 jdeps --list-reduced-deps should not show java.base as all modules require it In-Reply-To: References: Message-ID: <9cbda6df-e901-191a-3dda-5326613eb0f9@oracle.com> Hi Mandy, Looks good to me. cheers, -- daniel On 12/11/16 06:46, Mandy Chung wrote: > Daniel, > > This is an improved version of what you reviewed earlier. jdeps --list-reduced-deps will show java.base only when it?s the only module it depends on. > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169606/webrev.00 > > thanks > Mandy > From brunoaiss at gmail.com Sun Nov 13 10:35:07 2016 From: brunoaiss at gmail.com (Brunoais) Date: Sun, 13 Nov 2016 10:35:07 +0000 Subject: Java is too limited when dealing with the Console Message-ID: <3cab5cfd-1bdb-1922-627f-0424ad32f0d8@gmail.com> Since java 6, a class named Console was created. This class allows reading and writing directly to the console, including getting input without echoing for password purposes. Unfortunately, that class does not include useful functionality for java programs to work on the console and output formatted text. The feature I miss the most is knowing how many columns I have to type into in order to deliver an easier to read formatted output while avoiding line wraps that are not coded in. There are other things I miss like having multi-line progress bars (so far I can do single line if it is the last line by using "\r" and re-writing the line). Other times, it is more user friendly to wait for any key press instead of specifically waiting for "Enter" which will also add more lines to the console. I did some search and found nothing about this. Why hasn't this been implemented for java code? From rachna.goel at oracle.com Mon Nov 14 07:12:14 2016 From: rachna.goel at oracle.com (Rachna Goel) Date: Mon, 14 Nov 2016 12:42:14 +0530 Subject: RFR:JDK-8168906-Tighten permissions granted to the jdk.localedata module Message-ID: <1d18d1ad-cf80-8131-afcd-c8654f3c191c@oracle.com> Hi, Kindly review fix for JDK-8168906. https://bugs.openjdk.java.net/browse/JDK-8168906 Patch :http://cr.openjdk.java.net/~rgoel/JDK-8168906/webrev/ fix: As jdk.localedata module does read any system properties, tightened permissions for same. Thanks, Rachna From Alan.Bateman at oracle.com Mon Nov 14 07:16:56 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Nov 2016 07:16:56 +0000 Subject: RFR:JDK-8168906-Tighten permissions granted to the jdk.localedata module In-Reply-To: <1d18d1ad-cf80-8131-afcd-c8654f3c191c@oracle.com> References: <1d18d1ad-cf80-8131-afcd-c8654f3c191c@oracle.com> Message-ID: On 14/11/2016 07:12, Rachna Goel wrote: > Hi, > > Kindly review fix for JDK-8168906. > https://bugs.openjdk.java.net/browse/JDK-8168906 > > Patch :http://cr.openjdk.java.net/~rgoel/JDK-8168906/webrev/ > > fix: As jdk.localedata module does read any system properties, > tightened permissions for same. If you are sure it doesn't read any properties (or call anything that read properties without wrapping it in a privileged block) then it looks good. -Alan From rachna.goel at oracle.com Mon Nov 14 07:27:35 2016 From: rachna.goel at oracle.com (Rachna Goel) Date: Mon, 14 Nov 2016 12:57:35 +0530 Subject: RFR:JDK-8168906-Tighten permissions granted to the jdk.localedata module In-Reply-To: <1d18d1ad-cf80-8131-afcd-c8654f3c191c@oracle.com> References: <1d18d1ad-cf80-8131-afcd-c8654f3c191c@oracle.com> Message-ID: <7da1a463-a876-8385-af18-8c5f41cd1f7c@oracle.com> sorry, correction to typo As jdk.localedata module does *not* read any system properties, tightened permissions for same. On 14/11/16 12:42 PM, Rachna Goel wrote: > Hi, > > Kindly review fix for JDK-8168906. > https://bugs.openjdk.java.net/browse/JDK-8168906 > > Patch :http://cr.openjdk.java.net/~rgoel/JDK-8168906/webrev/ > > fix: As jdk.localedata module does read any system properties, > tightened permissions for same. > > Thanks, > Rachna From rahul.v.raghavan at oracle.com Mon Nov 14 11:03:58 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Mon, 14 Nov 2016 03:03:58 -0800 (PST) Subject: RFR: 8159035: com/sun/crypto/provider/Cipher/CTS/CTSMode.java test crashed due to unhandled case of cipher length value as 0 In-Reply-To: <582189E1.6000308@oracle.com> References: <70b2c1c2-7d04-47e8-8330-5e65e13b8425@default> <582189E1.6000308@oracle.com> Message-ID: <54d4b7db-1cda-46b4-8e98-2256428f11f3@default> Thank you all for the review comments for 8159035. - understood .java code uses 4 space indent and I will fix the same before any push - Created and linked task for reverting old aarch64 specific changes as required https://bugs.openjdk.java.net/browse/JDK-8169529 - At present analyzing RBT test results and also will confirm no performance issues before push Thanks, Rahul > -----Original Message----- > From: Tobias Hartmann > Sent: Tuesday, November 08, 2016 1:47 PM > To: Rahul Raghavan; core-libs-dev at openjdk.java.net > Cc: Shrinivas Joshi; Vladimir Kozlov; hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR: 8159035: com/sun/crypto/provider/Cipher/CTS/CTSMode.java test crashed due to unhandled case of cipher length > value as 0 > > Hi Rahul, > > On 07.11.2016 12:21, Rahul Raghavan wrote: > > Hi, > > > > Request review for closed bug fix - JDK-8159035. > > > > - http://cr.openjdk.java.net/~rraghavan/8159035/webrev.03/ > > Looks good to me! > > > Notes: > > > > 1. - https://bugs.openjdk.java.net/browse/JDK-8159035 - (com/sun/crypto/provider/Cipher/CTS/CTSMode.java test crashed > due to unhandled case of cipher length value as 0) > > Related issues - > > https://bugs.openjdk.java.net/browse/JDK-8076112 - 'Add @HotSpotIntrinsicCandidate annotation to indicate methods for which > Java Runtime has intrinsics' > > https://bugs.openjdk.java.net/browse/JDK-8167595 - 'AArch64: SEGV in stub code cipherBlockChaining_decryptAESCrypt' > > > > 2. Found root cause of the reported jvm crash for sparc - > > Crash happens at 'generate_cipherBlockChaining_decryptAESCrypt_Parallel()' [stubGenerator_sparc.cpp] > > The implDecrypt can be called from CipherBlockChaining.decrypt, even with cipherLen as 0. > > But the same condition is not handled in the stub code and results in crash. > > (the same applicable for implEncrypt) > > > > 3. Though the reported case was for sparc, understood that same issue is present for x86, aarch64 (JDK-8167595). > > So in above fix proposed in Java wrapper method side [CipherBlockChaining.java]. > > > > 4. The same issue in aarch64 (JDK-8167595) was fixed earlier in stubGenerator_aarch64. > > So once above is approved, I will initiate new hotspot webrev to revert this earlier 8167595 change. > > Please file another bug for this and link it to this bug. > > > 5. Checked for any other similar cases with HotSpotIntrinsicCandidate support and found two cases as proposed in > > - implCrypt() / CounterMode.java > > - implEncodeISOArray() / ISO_8859_1.java > > > > Confirmed no Issues for with jprt testing (-testset hotspot, core) > > Please also run our RBT testing before pushing. > > Thanks, > Tobias > > > Thanks, > > Rahul > > From patrick at reini.net Mon Nov 14 13:30:21 2016 From: patrick at reini.net (Patrick Reinhart) Date: Mon, 14 Nov 2016 14:30:21 +0100 Subject: Question about jdeps internalization Message-ID: <9fe0967b42b37fa3d79f0d77bf9cbc11@reini.net> Hi there, I have taken a look into the jdeps utility in order to may extend it to supply an additional parameter to scan an entire directory for all existing JAR files. In doing that, I stumbled over some output that has no direct resource bundle externalization. My question is now if this is intentional or just missed? I did externalize those in this patch as an proposal: http://cr.openjdk.java.net/~reinhapa/reviews/jdeps/langtools_resourcebundle.patch .Patrick From christoph.langer at sap.com Mon Nov 14 14:10:51 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 14 Nov 2016 14:10:51 +0000 Subject: RFR: 8169631: [JAXP] XALAN: transformation of XML via namespace-unaware SAX input yields a different result than namespace-unaware DOM input Message-ID: <313759790392479fa80a10542ab664ec@dewdfe13de07.global.corp.sap> Hi, please review this fix for bug 8169631. Bug: https://bugs.openjdk.java.net/browse/JDK-8169631 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169631.0/ When XALAN is handling namespace unaware input, it behaves differently while using SAX input compared to DOM input. With both input source types, the class com.sun.org.apache.xml.internal.dtm.ref.sax2dtm.SAX2DTM2 converts SAX input into a DTM representation for processing by the XALAN transformer. Its method startElement takes URI, localname and qName as attribute. In case of missing feature namespaces, startElement and localname can be empty. However, the function uses the localname value for the call to m_expandedNameTable.getExpandedTypeID() and further processing. In the case where only qName has data, this leads to issues. When using DOM input, the class com.sun.org.apache.xalan.internal.xsltc.trax.DOM2SAX converts the DOM input into SAX input. In the case of empty localname, it fills localname with qname data. See method getLocalName() [1], called by parse() [2]. When directly using SAX input, the SAX parser calls the startElement() function on XALAN's handler with empty uri and localname - which seems correct, as per the spec. Both paths end up in SAX2DTM2's startElement(). So I suggest to change this method to handle the case when uri and localname are empty and then set qname as localname. Maybe one should even change DOM2SAX's getLocalName handling to not fill localname with qname in case it is empty after SAX2DTM was changed.. Generally, JavaDoc for SAXSource says that "Attempting to transform an input source that is not generated with a namespace-aware parser may result in errors." But why not fix some of these :) Furthermore I did some cleanups in the code. Thanks and best regards Christoph [1] http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l139 [2] http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l279 [3] https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/sax/SAXSource.html From zoltan.majo at oracle.com Mon Nov 14 14:28:46 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 14 Nov 2016 15:28:46 +0100 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> Message-ID: <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> Hi Peter, On 11/11/2016 04:33 PM, Peter Levart wrote: > [...] > I think the wording could be even less specific about "detecting" the > reachability of the reference object. For example: > > ... If a registered reference becomes unreachable itself, then it > *may* never be enqueued. > > > In addition, the situations that describe when the reference *may* not > be enqueued could be expanded. For example: > > ... If a registered reference ceases to be strongly reachable itself, > then it *may* never be enqueued. > thank you for the suggestion and for the example program! Here is the updated webrev with the updated text: http://cr.openjdk.java.net/~zmajo/8169000/webrev.01/ Does that look reasonable to you? Thank you! Best regards, Zoltan > > The following modified test shows this situation: > > > public class WeaklyReachablePhantomReference { > > static ReferenceQueue rq = new ReferenceQueue<>(); > static WeakReference> weakRefRef; > > public static void main(final String[] args) throws Exception { > weakRefRef = new WeakReference<>( > new PhantomReference<>( > new Object(), > rq > ) > ); > // <- here > System.gc(); > Reference rmRef = rq.remove(1000); > if (rmRef == null) { > System.out.println("PhantomReference NOT enqueued"); > } else { > System.out.println("PhantomReference enqueued"); > } > } > } > > > At "<-- here" the PhantomReference object becomes weakly reachable > while its referent becomes phantom reachable and this is enough for > PhantomReference to not be enqueued. > > > Regards, Peter > From david.lloyd at redhat.com Mon Nov 14 14:47:37 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 14 Nov 2016 08:47:37 -0600 Subject: NPE on "return" bytecode of java.net.NetworkInterface Message-ID: I'm trying to work out something a colleague has observed during testing on an OpenJDK based on 1.8.0_111 (build 1.8.0_111-b16). The business end of the stack trace looks like this: Caused by: java.lang.NullPointerException at java.net.NetworkInterface.(NetworkInterface.java:80) at java.net.NetworkInterface.getAll(Native Method) at java.net.NetworkInterface.getNetworkInterfaces(NetworkInterface.java:343) According to javap, line 80 corresponds exclusively to the "return" instruction of the constructor: java.net.NetworkInterface(); Code: 0: aload_0 1: invokespecial #3 // Method java/lang/Object."":()V 4: aload_0 5: aconst_null 6: putfield #4 // Field parent:Ljava/net/NetworkInterface; 9: aload_0 10: iconst_0 11: putfield #5 // Field virtual:Z 14: return LineNumberTable: line 79: 0 line 50: 4 line 51: 9 line 80: 14 Since this method is called from a native method, is it possible that somehow the native method is generating an NPE, but the Java method is still in the stack context? I assume that what is happening here is some kind of class init order snafu, but it's pretty tricky to diagnose exactly with this non-intuitive stack. -- - DML From sean.mullan at oracle.com Mon Nov 14 14:59:22 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 14 Nov 2016 09:59:22 -0500 Subject: RFR:JDK-8168906-Tighten permissions granted to the jdk.localedata module In-Reply-To: <7da1a463-a876-8385-af18-8c5f41cd1f7c@oracle.com> References: <1d18d1ad-cf80-8131-afcd-c8654f3c191c@oracle.com> <7da1a463-a876-8385-af18-8c5f41cd1f7c@oracle.com> Message-ID: Looks good. Are there any regression tests for this component that run with a SecurityManager? If not, it would be useful to add some to ensure that the proper permissions are being granted to this module. --Sean On 11/14/16 2:27 AM, Rachna Goel wrote: > sorry, correction to typo > > As jdk.localedata module does *not* read any system properties, > tightened permissions for same. > > > On 14/11/16 12:42 PM, Rachna Goel wrote: >> Hi, >> >> Kindly review fix for JDK-8168906. >> https://bugs.openjdk.java.net/browse/JDK-8168906 >> >> Patch :http://cr.openjdk.java.net/~rgoel/JDK-8168906/webrev/ >> >> fix: As jdk.localedata module does read any system properties, >> tightened permissions for same. >> >> Thanks, >> Rachna > From Roger.Riggs at Oracle.com Mon Nov 14 15:17:16 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 14 Nov 2016 10:17:16 -0500 Subject: RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale In-Reply-To: <582583AB.3060308@oracle.com> References: <574b23f4-e9cc-cc95-0b7b-6dd5a4bdea68@Oracle.com> <50825aee-4268-451c-a470-4433fb8c437b@default> <582583AB.3060308@oracle.com> Message-ID: <16c283b6-3550-11bb-599b-519f9835e08e@Oracle.com> Hi, I agree, using toFormatter(Locale.US) is best. It avoids even transient changes to the default locale. (BTW, An exception in the test would fail to restore the locale unless it was in a try{} finally{} and someday multiple tests might be run concurrently in the same vm.) Roger On 11/11/2016 3:39 AM, nadeesh tv wrote: > Hi Bhanu, > > > I think adding Locale to the formatter will be better > > For eg: > > DateTimeFormatter f = > builder.parseLenient().appendValue(HOUR_OF_DAY).appendValue(MINUTE_OF_HOUR, > 2).appendLiteral('9').toFormatter(Locale.UK); > > Since other test cases use Locale.UK may be here also you can use UK > instead of locale.US. > > Thanks and Regards, > Nadeesh > > > On 11/11/2016 10:57 AM, Bhanu Gopularam wrote: >> Hi Roger, >> >> >> Thanks for the review. I have updated the test to set default locale >> (and restore it) in only those methods which were causing problem in >> non English locales. >> >> >> Please review the updated webrev below: >> >> Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.01/ >> >> >> Thanks, >> >> Bhanu >> >> >> From: Roger Riggs >> Sent: Tuesday, June 21, 2016 8:36 PM >> To: Bhanu Gopularam; core-libs-dev at openjdk.java.net >> Cc: Stephen Colebourne >> Subject: Re: RFR 8158880: >> java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail >> with zh_CN locale >> >> >> Hi Bhanu, >> >> It can be problematic to change the default Locale for the entire >> process, especially >> since many tests are run in the same process. It would be preferable >> to set the locale >> in the DateTimeFormatter builder instead of changing the process wide >> Locale. >> >> Please identify the specific test case to apply the fix only where >> needed. >> >> Is it only >> tck.java.time.format.TCKDateTimeFormatterBuilder.test_appendZoneText_parseGenericTimeZonePatterns >> where the failure is seen? >> >> This would be an issue testing any pattern letter with locale >> dependent behavior. >> The locale should be set explicitly in the test. >> >> BTW, There is a predefined Locale.US that can be used, no need to >> construct a new Locale. >> >> Roger >> >> >> >> On 6/21/2016 6:31 AM, Bhanu Gopularam wrote: >> >> 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 >> > From christoph.langer at sap.com Mon Nov 14 15:29:00 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 14 Nov 2016 15:29:00 +0000 Subject: NPE on "return" bytecode of java.net.NetworkInterface In-Reply-To: References: Message-ID: <96946d71bf28463baf954f7b70706060@dewdfe13de07.global.corp.sap> Hi David, can this be reproduced? What platform is it about? There have been fixes for some Windows native coding lately: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/ef9b2921bfa5 It really looks like some issues in the native code with a misleading callstack. Best regards Christoph > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf > Of David M. Lloyd > Sent: Montag, 14. November 2016 15:48 > To: core-libs-dev > Subject: NPE on "return" bytecode of java.net.NetworkInterface > > I'm trying to work out something a colleague has observed during testing > on an OpenJDK based on 1.8.0_111 (build 1.8.0_111-b16). > > The business end of the stack trace looks like this: > > Caused by: java.lang.NullPointerException > at java.net.NetworkInterface.(NetworkInterface.java:80) > at java.net.NetworkInterface.getAll(Native Method) > at > java.net.NetworkInterface.getNetworkInterfaces(NetworkInterface.java:343) > > According to javap, line 80 corresponds exclusively to the "return" > instruction of the constructor: > > java.net.NetworkInterface(); > Code: > 0: aload_0 > 1: invokespecial #3 // Method > java/lang/Object."":()V > 4: aload_0 > 5: aconst_null > 6: putfield #4 // Field > parent:Ljava/net/NetworkInterface; > 9: aload_0 > 10: iconst_0 > 11: putfield #5 // Field virtual:Z > 14: return > LineNumberTable: > line 79: 0 > line 50: 4 > line 51: 9 > line 80: 14 > > Since this method is called from a native method, is it possible that > somehow the native method is generating an NPE, but the Java method is > still in the stack context? I assume that what is happening here is > some kind of class init order snafu, but it's pretty tricky to diagnose > exactly with this non-intuitive stack. > > -- > - DML From aph at redhat.com Mon Nov 14 15:29:42 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 14 Nov 2016 15:29:42 +0000 Subject: NPE on "return" bytecode of java.net.NetworkInterface In-Reply-To: References: Message-ID: <12a0858a-5786-df65-07c7-6c6ca79d444f@redhat.com> On 14/11/16 14:47, David M. Lloyd wrote: > Since this method is called from a native method, is it possible > that somehow the native method is generating an NPE, but the Java > method is still in the stack context? I assume that what is > happening here is some kind of class init order snafu, but it's > pretty tricky to diagnose exactly with this non-intuitive stack. java.net.NetworkInterface.getAll() will return null if it fails to create an instance of NetworkInterface. It's quite possible that inlining will make it appear that a NPE at getAll's caller is reported at the return. Try either TieredStopAtLevel=1 or disable compilation for getAll(). Andrew. From chris.hegarty at oracle.com Mon Nov 14 15:39:09 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 14 Nov 2016 15:39:09 +0000 Subject: NPE on "return" bytecode of java.net.NetworkInterface In-Reply-To: <12a0858a-5786-df65-07c7-6c6ca79d444f@redhat.com> References: <12a0858a-5786-df65-07c7-6c6ca79d444f@redhat.com> Message-ID: On 14/11/16 15:29, Andrew Haley wrote: > On 14/11/16 14:47, David M. Lloyd wrote: > >> Since this method is called from a native method, is it possible >> that somehow the native method is generating an NPE, but the Java >> method is still in the stack context? I assume that what is >> happening here is some kind of class init order snafu, but it's >> pretty tricky to diagnose exactly with this non-intuitive stack. > > java.net.NetworkInterface.getAll() will return null if it fails to > create an instance of NetworkInterface. It's quite possible that > inlining will make it appear that a NPE at getAll's caller is reported > at the return. > > Try either TieredStopAtLevel=1 or disable compilation for getAll(). Additionally, is it possible to run with '-Xcheck:jni' ? -Chris. From david.lloyd at redhat.com Mon Nov 14 15:53:18 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 14 Nov 2016 09:53:18 -0600 Subject: NPE on "return" bytecode of java.net.NetworkInterface In-Reply-To: <12a0858a-5786-df65-07c7-6c6ca79d444f@redhat.com> References: <12a0858a-5786-df65-07c7-6c6ca79d444f@redhat.com> Message-ID: <4e817619-2fc6-b7ac-7c6d-82ac8fcbf8a8@redhat.com> On 11/14/2016 09:29 AM, Andrew Haley wrote: > On 14/11/16 14:47, David M. Lloyd wrote: > >> Since this method is called from a native method, is it possible >> that somehow the native method is generating an NPE, but the Java >> method is still in the stack context? I assume that what is >> happening here is some kind of class init order snafu, but it's >> pretty tricky to diagnose exactly with this non-intuitive stack. > > java.net.NetworkInterface.getAll() will return null if it fails to > create an instance of NetworkInterface. It's quite possible that > inlining will make it appear that a NPE at getAll's caller is reported > at the return. > > Try either TieredStopAtLevel=1 or disable compilation for getAll(). I thought inlining was not supposed to affect stack traces... if this is the case, is it a bug? -- - DML From david.lloyd at redhat.com Mon Nov 14 15:54:15 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 14 Nov 2016 09:54:15 -0600 Subject: NPE on "return" bytecode of java.net.NetworkInterface In-Reply-To: <96946d71bf28463baf954f7b70706060@dewdfe13de07.global.corp.sap> References: <96946d71bf28463baf954f7b70706060@dewdfe13de07.global.corp.sap> Message-ID: <5c3a80ec-6766-b9c6-f750-6a1939cdda25@redhat.com> On 11/14/2016 09:29 AM, Langer, Christoph wrote: > Hi David, > > can this be reproduced? It's part of the test suite of our application server, so, probably, but probably not easily. > What platform is it about? There have been fixes for some Windows native coding lately: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/ef9b2921bfa5 This case is 64-bit Linux. > It really looks like some issues in the native code with a misleading callstack. That's what I was thinking... -- - DML From david.lloyd at redhat.com Mon Nov 14 15:54:37 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 14 Nov 2016 09:54:37 -0600 Subject: NPE on "return" bytecode of java.net.NetworkInterface In-Reply-To: References: <12a0858a-5786-df65-07c7-6c6ca79d444f@redhat.com> Message-ID: On 11/14/2016 09:39 AM, Chris Hegarty wrote: > > On 14/11/16 15:29, Andrew Haley wrote: >> On 14/11/16 14:47, David M. Lloyd wrote: >> >>> Since this method is called from a native method, is it possible >>> that somehow the native method is generating an NPE, but the Java >>> method is still in the stack context? I assume that what is >>> happening here is some kind of class init order snafu, but it's >>> pretty tricky to diagnose exactly with this non-intuitive stack. >> >> java.net.NetworkInterface.getAll() will return null if it fails to >> create an instance of NetworkInterface. It's quite possible that >> inlining will make it appear that a NPE at getAll's caller is reported >> at the return. >> >> Try either TieredStopAtLevel=1 or disable compilation for getAll(). > > Additionally, is it possible to run with '-Xcheck:jni' ? We'll give it a shot. -- - DML From naoto.sato at oracle.com Mon Nov 14 16:07:32 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 14 Nov 2016 08:07:32 -0800 Subject: RFR:JDK-8168906-Tighten permissions granted to the jdk.localedata module In-Reply-To: <1d18d1ad-cf80-8131-afcd-c8654f3c191c@oracle.com> References: <1d18d1ad-cf80-8131-afcd-c8654f3c191c@oracle.com> Message-ID: <5f378665-d589-08d7-59fa-c8ed9638e4a9@oracle.com> +1 Naoto On 11/13/16 11:12 PM, Rachna Goel wrote: > Hi, > > Kindly review fix for JDK-8168906. > https://bugs.openjdk.java.net/browse/JDK-8168906 > > Patch :http://cr.openjdk.java.net/~rgoel/JDK-8168906/webrev/ > > fix: As jdk.localedata module does read any system properties, tightened > permissions for same. > > Thanks, > Rachna From mandy.chung at oracle.com Mon Nov 14 16:32:53 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Nov 2016 08:32:53 -0800 Subject: Question about jdeps internalization In-Reply-To: <9fe0967b42b37fa3d79f0d77bf9cbc11@reini.net> References: <9fe0967b42b37fa3d79f0d77bf9cbc11@reini.net> Message-ID: > On Nov 14, 2016, at 5:30 AM, Patrick Reinhart wrote: > > Hi there, > > I have taken a look into the jdeps utility in order to may extend it to supply an additional parameter to scan an entire directory for all existing JAR files. > > In doing that, I stumbled over some output that has no direct resource bundle externalization. My question is now if this is intentional or just missed? > > I did externalize those in this patch as an proposal: > > http://cr.openjdk.java.net/~reinhapa/reviews/jdeps/langtools_resourcebundle.patch Looks like we did miss these ones fixed in your patch. I will file JBS issue for it. Mandy From david.lloyd at redhat.com Mon Nov 14 17:02:05 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 14 Nov 2016 11:02:05 -0600 Subject: NPE on "return" bytecode of java.net.NetworkInterface In-Reply-To: References: <12a0858a-5786-df65-07c7-6c6ca79d444f@redhat.com> Message-ID: On 11/14/2016 09:54 AM, David M. Lloyd wrote: > On 11/14/2016 09:39 AM, Chris Hegarty wrote: >> >> On 14/11/16 15:29, Andrew Haley wrote: >>> On 14/11/16 14:47, David M. Lloyd wrote: >>> >>>> Since this method is called from a native method, is it possible >>>> that somehow the native method is generating an NPE, but the Java >>>> method is still in the stack context? I assume that what is >>>> happening here is some kind of class init order snafu, but it's >>>> pretty tricky to diagnose exactly with this non-intuitive stack. >>> >>> java.net.NetworkInterface.getAll() will return null if it fails to >>> create an instance of NetworkInterface. It's quite possible that >>> inlining will make it appear that a NPE at getAll's caller is reported >>> at the return. >>> >>> Try either TieredStopAtLevel=1 or disable compilation for getAll(). >> >> Additionally, is it possible to run with '-Xcheck:jni' ? > > We'll give it a shot. We're having a hard time getting JVM arguments set in all the processes of the test suite; we're working on that, but in the mean time, some more possibly related problems came up (and maybe this is starting to move into a hotspot-dev category?)... Now we're seeing NPEs originating at odd places, like one of these three instructions: 0: aload_0 1: invokestatic #10 // Method doInject:(Lorg/jboss/msc/service/ValueInjection;)V 4: return None of which should possibly be able to trigger an NPE... right? Unless it's some kind of unexpected SIGSEGV that looks sufficiently like a null dereference...? So maybe JNI isn't actually a factor. Or maybe Andrew's inline idea has some runway to it. -- - DML From david.lloyd at redhat.com Mon Nov 14 17:07:09 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 14 Nov 2016 11:07:09 -0600 Subject: NPE on "return" bytecode of java.net.NetworkInterface In-Reply-To: References: <12a0858a-5786-df65-07c7-6c6ca79d444f@redhat.com> Message-ID: On 11/14/2016 11:02 AM, David M. Lloyd wrote: > On 11/14/2016 09:54 AM, David M. Lloyd wrote: >> On 11/14/2016 09:39 AM, Chris Hegarty wrote: >>> >>> On 14/11/16 15:29, Andrew Haley wrote: >>>> On 14/11/16 14:47, David M. Lloyd wrote: >>>> >>>>> Since this method is called from a native method, is it possible >>>>> that somehow the native method is generating an NPE, but the Java >>>>> method is still in the stack context? I assume that what is >>>>> happening here is some kind of class init order snafu, but it's >>>>> pretty tricky to diagnose exactly with this non-intuitive stack. >>>> >>>> java.net.NetworkInterface.getAll() will return null if it fails to >>>> create an instance of NetworkInterface. It's quite possible that >>>> inlining will make it appear that a NPE at getAll's caller is reported >>>> at the return. >>>> >>>> Try either TieredStopAtLevel=1 or disable compilation for getAll(). >>> >>> Additionally, is it possible to run with '-Xcheck:jni' ? >> >> We'll give it a shot. > > We're having a hard time getting JVM arguments set in all the processes > of the test suite; we're working on that, but in the mean time, some > more possibly related problems came up (and maybe this is starting to > move into a hotspot-dev category?)... > > Now we're seeing NPEs originating at odd places, like one of these three > instructions: > > 0: aload_0 > 1: invokestatic #10 // Method > doInject:(Lorg/jboss/msc/service/ValueInjection;)V > 4: return > > None of which should possibly be able to trigger an NPE... right? Unless > it's some kind of unexpected SIGSEGV that looks sufficiently like a null > dereference...? > > So maybe JNI isn't actually a factor. Or maybe Andrew's inline idea has > some runway to it. Here's another: 87: aload_0 88: aload 7 90: putfield #17 // Field extensionModuleName:Ljava/lang/String; ... LocalVariableTable: Start Length Slot Name Signature 0 94 0 this Lorg/jboss/as/controller/extension/ExtensionRegistry$SubsystemRegistrationImpl; If "this" is null, then something bad is happening, right? -- - DML From sergei.kovalev at oracle.com Mon Nov 14 17:26:09 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Mon, 14 Nov 2016 20:26:09 +0300 Subject: RFR(s): 8169658: javax/rmi tests have undeclared dependencies Message-ID: Hello team, Please review a very small fix for tests. BugID: https://bugs.openjdk.java.net/browse/JDK-8169658 WebRev: http://cr.openjdk.java.net/~skovalev/8169658/webrev.00/ Issue: Two tests from RMI test group have undeclared dependency on java.rmi and java.naming modules. -- With best regards, Sergei From david.lloyd at redhat.com Mon Nov 14 18:02:35 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 14 Nov 2016 12:02:35 -0600 Subject: NPE on "return" bytecode of java.net.NetworkInterface In-Reply-To: References: <12a0858a-5786-df65-07c7-6c6ca79d444f@redhat.com> Message-ID: <5c5a15cb-f158-ab3a-b11b-f40460665524@redhat.com> On 11/14/2016 11:07 AM, David M. Lloyd wrote: > On 11/14/2016 11:02 AM, David M. Lloyd wrote: >> On 11/14/2016 09:54 AM, David M. Lloyd wrote: >>> On 11/14/2016 09:39 AM, Chris Hegarty wrote: >>>> >>>> On 14/11/16 15:29, Andrew Haley wrote: >>>>> On 14/11/16 14:47, David M. Lloyd wrote: >>>>> >>>>>> Since this method is called from a native method, is it possible >>>>>> that somehow the native method is generating an NPE, but the Java >>>>>> method is still in the stack context? I assume that what is >>>>>> happening here is some kind of class init order snafu, but it's >>>>>> pretty tricky to diagnose exactly with this non-intuitive stack. >>>>> >>>>> java.net.NetworkInterface.getAll() will return null if it fails to >>>>> create an instance of NetworkInterface. It's quite possible that >>>>> inlining will make it appear that a NPE at getAll's caller is reported >>>>> at the return. >>>>> >>>>> Try either TieredStopAtLevel=1 or disable compilation for getAll(). >>>> >>>> Additionally, is it possible to run with '-Xcheck:jni' ? >>> >>> We'll give it a shot. >> >> We're having a hard time getting JVM arguments set in all the processes >> of the test suite; we're working on that, but in the mean time, some >> more possibly related problems came up (and maybe this is starting to >> move into a hotspot-dev category?)... >> >> Now we're seeing NPEs originating at odd places, like one of these three >> instructions: >> >> 0: aload_0 >> 1: invokestatic #10 // Method >> doInject:(Lorg/jboss/msc/service/ValueInjection;)V >> 4: return >> >> None of which should possibly be able to trigger an NPE... right? Unless >> it's some kind of unexpected SIGSEGV that looks sufficiently like a null >> dereference...? >> >> So maybe JNI isn't actually a factor. Or maybe Andrew's inline idea has >> some runway to it. > > Here's another: > > 87: aload_0 > 88: aload 7 > 90: putfield #17 // Field > extensionModuleName:Ljava/lang/String; > ... > LocalVariableTable: > Start Length Slot Name Signature > 0 94 0 this > Lorg/jboss/as/controller/extension/ExtensionRegistry$SubsystemRegistrationImpl; > > > If "this" is null, then something bad is happening, right? Adding -XX:TieredStopAtLevel=1 appears to fix the problem. I'll move this over to hotspot-dev I guess... with any luck, it's something that was already fixed. -- - DML From patrick at reini.net Mon Nov 14 21:19:01 2016 From: patrick at reini.net (Patrick Reinhart) Date: Mon, 14 Nov 2016 22:19:01 +0100 Subject: RFR: JDK-8168836 Minor clean up on warning/error messages In-Reply-To: References: <9fe0967b42b37fa3d79f0d77bf9cbc11@reini.net> Message-ID: Webrev containing the changes: http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00 -Patrick > Am 14.11.2016 um 17:32 schrieb Mandy Chung : > > >> On Nov 14, 2016, at 5:30 AM, Patrick Reinhart wrote: >> >> Hi there, >> >> I have taken a look into the jdeps utility in order to may extend it to supply an additional parameter to scan an entire directory for all existing JAR files. >> >> In doing that, I stumbled over some output that has no direct resource bundle externalization. My question is now if this is intentional or just missed? >> >> I did externalize those in this patch as an proposal: >> >> http://cr.openjdk.java.net/~reinhapa/reviews/jdeps/langtools_resourcebundle.patch > > Looks like we did miss these ones fixed in your patch. I will file JBS issue for it. > > Mandy From patrick at reini.net Mon Nov 14 21:22:30 2016 From: patrick at reini.net (Patrick Reinhart) Date: Mon, 14 Nov 2016 22:22:30 +0100 Subject: RFR: JDK-8168836 Minor clean up on warning/error messages In-Reply-To: References: <9fe0967b42b37fa3d79f0d77bf9cbc11@reini.net> Message-ID: <591746A1-6EF0-4FBD-B099-DF8B5996432D@reini.net> Ups, previous mail contained wrong URL. Here?s the correct one: http://cr.openjdk.java.net/~reinhapa/reviews/8168836/webrev.00 -Patrick > Am 14.11.2016 um 22:19 schrieb Patrick Reinhart : > > Webrev containing the changes: > > http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00 > > -Patrick > >> Am 14.11.2016 um 17:32 schrieb Mandy Chung : >> >> >>> On Nov 14, 2016, at 5:30 AM, Patrick Reinhart wrote: >>> >>> Hi there, >>> >>> I have taken a look into the jdeps utility in order to may extend it to supply an additional parameter to scan an entire directory for all existing JAR files. >>> >>> In doing that, I stumbled over some output that has no direct resource bundle externalization. My question is now if this is intentional or just missed? >>> >>> I did externalize those in this patch as an proposal: >>> >>> http://cr.openjdk.java.net/~reinhapa/reviews/jdeps/langtools_resourcebundle.patch >> >> Looks like we did miss these ones fixed in your patch. I will file JBS issue for it. >> >> Mandy > From mandy.chung at oracle.com Mon Nov 14 21:23:53 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Nov 2016 13:23:53 -0800 Subject: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError In-Reply-To: <577218967.2379337.1478948680504.JavaMail.zimbra@u-pem.fr> References: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> <8ebb0fac-2be6-8163-7742-21dc53c72de0@oracle.com> <1677706373.2320667.1478884421420.JavaMail.zimbra@u-pem.fr> <9B46CB8C-0746-4191-AD9D-4DB44100AF83@oracle.com> <577218967.2379337.1478948680504.JavaMail.zimbra@u-pem.fr> Message-ID: > On Nov 12, 2016, at 3:04 AM, forax at univ-mlv.fr wrote: > > Hi Mandy, > getName() is used for debugging so if it's the wrong name which is picked, is not a big deal, the stacktrace will be just a little weird, > that's why i think it's fine to make getName non static and non final, because accidental overriding is not harmful. > > Accidental overriding of isParallelCapable is harmful. > That?s a good point. > In term of design the main issue with a static method is the discoverability issue, if a user hit ctrl + space, a static method will not be among the proposed methods. > so i'm fine with a final isRegisteredAsParallelCapable if you think that users should be aware that this method exist. > I am doing a scan on the corpus I have (an old snapshot of maven artifacts outdated but hope to represent a good set of samples). So far, I only found one ClassLoader subclass defining isParallelCapable method [1]. I haven?t found any use of isRegisteredAsParallelCapable method. Mandy [1] org.eclipse.osgi:org.eclipse.osgi:3.7.1 (and other versions) > regards, > R?mi > > ----- Mail original ----- >> De: "Mandy Chung" >> ?: "Remi Forax" >> Cc: "David M. Lloyd" , "core-libs-dev" >> Envoy?: Samedi 12 Novembre 2016 00:10:13 >> Objet: Re: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError > >> While this could be made as a static method, there are cases that an instance >> method would be preferred and same compatibility would arise. For example, >> ClassLoader::getName is non-final instance method as it stands and I?d be >> reluctant to make it a static method taking a ClassLoader instance. >> >> It would be nice to support @PromoteToFinalMethod to allow a new method be >> non-final when it?s added and promote to a final method in a future release >> allowing existing code to transition. >> >> My preference is to go with ClassLoader::isRegisteredAsParallelCapable final >> instance method and the chance of the name clash may be low (Brent did some >> search from grepcode and at least not finding that name yet. Of course this is >> not bullet-proof). >> >> Mandy >> >>> On Nov 11, 2016, at 9:13 AM, Remi Forax wrote: >>> >>> Hi David, >>> you can not override a static method :) >>> but there is still a corner case, you can have a conflict when you have a method >>> reference over an instance method and you introduce a static method that have >>> the same functional signature. >>> >>> Given that i prefer to have a compile time error than a strange behavior at >>> runtime (if there is an accidental overriding), >>> I vote for the static method too. >>> >>> cheers, >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "David M. Lloyd" >>>> ?: core-libs-dev at openjdk.java.net >>>> Envoy?: Vendredi 11 Novembre 2016 16:03:44 >>>> Objet: Re: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting >>>> method may get VerifyError >>> >>>> On 11/11/2016 05:07 AM, Alan Bateman wrote: >>>>> >>>>> >>>>> On 11/11/2016 10:46, Vladimir Ivanov wrote: >>>>>> Alan, >>>>>> >>>>>> I've looked through the current thread and also review thread [1] for >>>>>> original change (8165793), but haven't found any discussion why making >>>>>> it static (instead of instance final) is undesirable. >>>>>> >>>>>> Can you shed some light on it? Is it mainly usability concern >>>>>> (loader.isParallelCapable() vs ClassLoader.isParallelCapable(loader))? >>>>> I assume you mean to address this to Brent rather than me, but yes, an >>>>> instance method would be nicer (if we can get away with it). >>>> >>>> I think the question was "why not?". A static method can never >>>> conflict, and doesn't have a usability impact. A final method can >>>> always conflict, and a non-final method is always potentially >>>> problematic for the multiple reasons already stated on this thread. >>>> >>>> By score, static wins. So, why not? >>>> -- >>>> - DML From peter.levart at gmail.com Mon Nov 14 21:59:04 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 14 Nov 2016 22:59:04 +0100 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> Message-ID: Hi Zoltan, On 11/14/2016 03:28 PM, Zolt?n Maj? wrote: > Hi Peter, > > > On 11/11/2016 04:33 PM, Peter Levart wrote: >> [...] >> I think the wording could be even less specific about "detecting" the >> reachability of the reference object. For example: >> >> ... If a registered reference becomes unreachable itself, then it >> *may* never be enqueued. >> >> >> In addition, the situations that describe when the reference *may* >> not be enqueued could be expanded. For example: >> >> ... If a registered reference ceases to be strongly reachable itself, >> then it *may* never be enqueued. >> > > thank you for the suggestion and for the example program! > > Here is the updated webrev with the updated text: > > http://cr.openjdk.java.net/~zmajo/8169000/webrev.01/ > > Does that look reasonable to you? Yes, I think this is good. Maybe just a nit. This last statement: "It is the responsibility of the program using reference objects to ensure that the objects remain strongly reachable for as long as the program is interested in their referents." ...could be written more nicely like: "It is the responsibility of the program to ensure that reference objects remain strongly reachable for as long as it is interested in their referents." ...or even: "It is the responsibility of the program to ensure that reference objects remain strongly reachable for as long as it is interested in tracking the reachability of their referents." What do you think? Regards, Peter > > Thank you! > > Best regards, > > > Zoltan > >> >> The following modified test shows this situation: >> >> >> public class WeaklyReachablePhantomReference { >> >> static ReferenceQueue rq = new ReferenceQueue<>(); >> static WeakReference> weakRefRef; >> >> public static void main(final String[] args) throws Exception { >> weakRefRef = new WeakReference<>( >> new PhantomReference<>( >> new Object(), >> rq >> ) >> ); >> // <- here >> System.gc(); >> Reference rmRef = rq.remove(1000); >> if (rmRef == null) { >> System.out.println("PhantomReference NOT enqueued"); >> } else { >> System.out.println("PhantomReference enqueued"); >> } >> } >> } >> >> >> At "<-- here" the PhantomReference object becomes weakly reachable >> while its referent becomes phantom reachable and this is enough for >> PhantomReference to not be enqueued. >> >> >> Regards, Peter >> > From david.holmes at oracle.com Mon Nov 14 22:52:59 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Nov 2016 08:52:59 +1000 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> Message-ID: <124a7382-8380-d0f8-4d5d-e306813c00bf@oracle.com> Hi Zoltan, On 15/11/2016 12:28 AM, Zolt?n Maj? wrote: > Hi Peter, > > > On 11/11/2016 04:33 PM, Peter Levart wrote: >> [...] >> I think the wording could be even less specific about "detecting" the >> reachability of the reference object. For example: >> >> ... If a registered reference becomes unreachable itself, then it >> *may* never be enqueued. >> >> >> In addition, the situations that describe when the reference *may* not >> be enqueued could be expanded. For example: >> >> ... If a registered reference ceases to be strongly reachable itself, >> then it *may* never be enqueued. >> > > thank you for the suggestion and for the example program! > > Here is the updated webrev with the updated text: > > http://cr.openjdk.java.net/~zmajo/8169000/webrev.01/ I don't think you need the "(i.e ...)". You are cross referencing to the Reachability section where "strongly reachable" is defined. The fewer the changes the better - the key part is to make it clearer that it "may" never be enqueued, without getting bogged down with why, or why not. Of course this will need to go through CCC. Thanks, David > Does that look reasonable to you? > > Thank you! > > Best regards, > > > Zoltan > >> >> The following modified test shows this situation: >> >> >> public class WeaklyReachablePhantomReference { >> >> static ReferenceQueue rq = new ReferenceQueue<>(); >> static WeakReference> weakRefRef; >> >> public static void main(final String[] args) throws Exception { >> weakRefRef = new WeakReference<>( >> new PhantomReference<>( >> new Object(), >> rq >> ) >> ); >> // <- here >> System.gc(); >> Reference rmRef = rq.remove(1000); >> if (rmRef == null) { >> System.out.println("PhantomReference NOT enqueued"); >> } else { >> System.out.println("PhantomReference enqueued"); >> } >> } >> } >> >> >> At "<-- here" the PhantomReference object becomes weakly reachable >> while its referent becomes phantom reachable and this is enough for >> PhantomReference to not be enqueued. >> >> >> Regards, Peter >> > From mandy.chung at oracle.com Mon Nov 14 23:20:33 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Nov 2016 15:20:33 -0800 Subject: RFR: JDK-8168836 Minor clean up on warning/error messages In-Reply-To: <591746A1-6EF0-4FBD-B099-DF8B5996432D@reini.net> References: <9fe0967b42b37fa3d79f0d77bf9cbc11@reini.net> <591746A1-6EF0-4FBD-B099-DF8B5996432D@reini.net> Message-ID: <6B83B1C5-7DD6-4E7F-8294-9EF86F911564@oracle.com> > On Nov 14, 2016, at 1:22 PM, Patrick Reinhart wrote: > > Ups, previous mail contained wrong URL. Here?s the correct one: > > http://cr.openjdk.java.net/~reinhapa/reviews/8168836/webrev.00 879 log.println(getMessage("err.missing.dependences")); This should call reportError method that will prepend with ?error.prefix?. So no need to have ?ERROR:? in ?err.missing.dependences? message. Formatting Nit: line 541-542 and line 753-754 align to the first parameter of the method. Otherwise looks good. I can sponsor it. Mandy From blackdrag at gmx.org Mon Nov 14 23:23:51 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 15 Nov 2016 00:23:51 +0100 Subject: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue In-Reply-To: <394D2FBD-4828-43AD-9640-0661F8379241@oracle.com> References: <314D8B90-3D99-4666-A1B4-3152C0D103D3@oracle.com> <0308ce68-14b9-8297-1929-fef2b6c0c37f@gmail.com> <9c44bc90-a4b9-d758-ee61-c910afe4851d@gmail.com> <21fe833e-724f-4905-3eda-255bc739bff0@gmail.com> <71bc9aef-e7bc-6946-fe16-63a0c14fdffc@gmx.org> <394D2FBD-4828-43AD-9640-0661F8379241@oracle.com> Message-ID: <582A4787.4060502@gmx.org> resend after I did accidentally send it to Paul directly instead of the list On 10.11.2016 21:24, Paul Sandoz wrote: > Hi Jochen, > > Can you confirm if my analysis of Groovy using ClassValue was correct: > > https://bugs.openjdk.java.net/browse/JDK-8136353 > AFAICT in this case the issue was not with ClassValue itself but the > storing of computed values in a global set. Our last "solution" was not to use ClassValue at all and restore the faulty pre-ClassValue logic. Because not even making those weak references solved the problem. > If i understand correctly you are you raising a wider issue with the > function of ClassValue itself, it may be insufficient for your use-case, > and not specifically with computed values strongly referring the > associated ClassValue? > > Specifically, I am struggling to unpack this bit: > >> But if you will need at the same time a ClassValue to not to prevent a >> class we computed the value for from unloading and have the computed >> value alive for min(lifespan class, lifespan runtime), then you get a >> real big problem in realizing this. > Computed values can strongly refer to the associated class, it becomes > problematic when computed values strongly refer to the associated > ClassValue. Is that something you require? The problem is more how to avoid that, but still get the semantics I need. Example... have the computed value be the meta class of a class and let there be a class X with a static field representing the ClassValue. Now create the meta class of X and let say each meta class references also the meta class of the super class. And of course I do want to be able to init and destroy the runtime thousands of times without leaving garbage in memory. By doing this I have a computed value strongly referencing the ClassValue and I do have ClassValue pinned for VM lifetime because I made a metaclass of Object. A weak reference for the computed value is no solution, since we then would loose modifications done to the metaclasses. And this is the reason why we wanted ClassValue in the first place. I can also not just reference the ClassValue or the class containing the field, because that would still keep the strong reference alive. What is for example totally unclear to me is, what happens if the ClassValue itself is weakly referenced and a computed value references the ClassValue through that weak reference. Does ClassValue then possibly get collected before the computed values? If "yes" it is no solution again, as we would again loose meta class information. And a "no" most likely means another memory leak. Even if I lift the constraint of a meta class referencing its super class meta class - I will have meta classes of classes from java.lang.* and then a memory leak So how to solve the problem? bye Jochen From mandy.chung at oracle.com Tue Nov 15 00:34:53 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Nov 2016 16:34:53 -0800 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: <124a7382-8380-d0f8-4d5d-e306813c00bf@oracle.com> References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> <124a7382-8380-d0f8-4d5d-e306813c00bf@oracle.com> Message-ID: > On Nov 14, 2016, at 2:52 PM, David Holmes wrote: > >> >> Here is the updated webrev with the updated text: >> >> http://cr.openjdk.java.net/~zmajo/8169000/webrev.01/ > > I don't think you need the "(i.e ...)". You are cross referencing to the Reachability section where "strongly reachable" is defined. > > The fewer the changes the better - the key part is to make it clearer that it "may" never be enqueued, without getting bogged down with why, or why not. > I?m catching up on this thread (last Friday was Oracle US holiday). The word ?will? -> ?may? should be adequate for this spec clarification. I?d like to read through the package summary and send you feedback. > Of course this will need to go through CCC. Yes Mandy From mandy.chung at oracle.com Tue Nov 15 01:51:11 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Nov 2016 17:51:11 -0800 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> Message-ID: <1695A59F-98AB-4821-9E20-AD3FE155EFAE@oracle.com> > On Nov 14, 2016, at 6:28 AM, Zolt?n Maj? wrote: > > Here is the updated webrev with the updated text: > > http://cr.openjdk.java.net/~zmajo/8169000/webrev.01/ > This spec uses ?unreachable? to refer to when GC detects as unreachable. I think the current spec is correct. What about this suggested clarification? diff --git a/src/java.base/share/classes/java/lang/ref/package-info.java b/src/java.base/share/classes/java/lang/ref/package-info.java --- a/src/java.base/share/classes/java/lang/ref/package-info.java +++ b/src/java.base/share/classes/java/lang/ref/package-info.java @@ -77,8 +77,12 @@ * references that are registered with it. If a registered reference * becomes unreachable itself, then it will never be enqueued. It is * the responsibility of the program using reference objects to ensure - * that the objects remain reachable for as long as the program is - * interested in their referents. + * that the objects remain strongly reachable for as long as the program + * is interested in their referents. + * + *

      + * A Java virtual machine may implement optimization that could + * affects when objects become unreachable. * *

      While some programs will choose to dedicate a thread to * removing reference objects from one or more queues and processing Peter, > On Nov 14, 2016, at 1:59 PM, Peter Levart wrote: > > "It is the responsibility of the program using reference objects to ensure that the objects remain strongly reachable for as long as the program is interested in their referents." > > ...could be written more nicely like: > > "It is the responsibility of the program to ensure that reference objects remain strongly reachable for as long as it is interested in their referents." > > ...or even: > > "It is the responsibility of the program to ensure that reference objects remain strongly reachable for as long as it is interested in tracking the reachability of their referents." > Making it clear ?strongly reachable? is a good suggestion. I don?t see word-smithing is needed in the original sentence; hence my above suggested change only adds the word ?strongly? in this sentence. Mandy From paul.sandoz at oracle.com Tue Nov 15 01:56:13 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 14 Nov 2016 17:56:13 -0800 Subject: 8072784: Better spliterator implementation for BitSet.stream() Message-ID: Hi, Please review this patch implementing a spliterator for BitSet: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8072784-bitset-stream-spliterator/webrev/ The spliterator is SIZED but not SUBSIZED, the bit set?s cardinality is used (same for the iterator) as the size of the root spliterator, and estimates from that are derived thereafter for splits. Splitting attempts to balance the small vs. large, dense vs. sparse cases. Most of the complexity is dealing with the edge case of there being a bit set at Integer.MAX_VALUE. Testing-wise i have leveraged the existing tests. It would be nice to consider placing the spliterator testing functionality into a separate library for reuse as SpliteratorTraversingAndSplittingTest is getting large. Likewise for more formally for streams, which is possible to reuse but a little clunky. I can log issues for those. Paul. From huizhe.wang at oracle.com Tue Nov 15 02:22:40 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 14 Nov 2016 18:22:40 -0800 Subject: RFR: 8169631: [JAXP] XALAN: transformation of XML via namespace-unaware SAX input yields a different result than namespace-unaware DOM input In-Reply-To: <313759790392479fa80a10542ab664ec@dewdfe13de07.global.corp.sap> References: <313759790392479fa80a10542ab664ec@dewdfe13de07.global.corp.sap> Message-ID: <582A7170.7030100@oracle.com> Hi Christoph, Not all tests have finished yet, but there's at least one failure in the smoke test. I'll get to the details when I have time. Any reason why m_prefixMappings can not be replaced with ArrayList? Thanks, Joe On 11/14/16, 6:10 AM, Langer, Christoph wrote: > Hi, > > please review this fix for bug 8169631. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169631 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169631.0/ > > When XALAN is handling namespace unaware input, it behaves differently while using SAX input compared to DOM input. > > With both input source types, the class com.sun.org.apache.xml.internal.dtm.ref.sax2dtm.SAX2DTM2 converts SAX input into a DTM representation for processing by the XALAN transformer. Its method startElement takes URI, localname and qName as attribute. In case of missing feature namespaces, startElement and localname can be empty. However, the function uses the localname value for the call to m_expandedNameTable.getExpandedTypeID() and further processing. In the case where only qName has data, this leads to issues. > > When using DOM input, the class com.sun.org.apache.xalan.internal.xsltc.trax.DOM2SAX converts the DOM input into SAX input. In the case of empty localname, it fills localname with qname data. See method getLocalName() [1], called by parse() [2]. > When directly using SAX input, the SAX parser calls the startElement() function on XALAN's handler with empty uri and localname - which seems correct, as per the spec. > > Both paths end up in SAX2DTM2's startElement(). So I suggest to change this method to handle the case when uri and localname are empty and then set qname as localname. Maybe one should even change DOM2SAX's getLocalName handling to not fill localname with qname in case it is empty after SAX2DTM was changed.. > > Generally, JavaDoc for SAXSource says that "Attempting to transform an input source that is not generated with a namespace-aware parser may result in errors." But why not fix some of these :) > > Furthermore I did some cleanups in the code. > > Thanks and best regards > Christoph > > [1] http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l139 > [2] http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l279 > [3] https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/sax/SAXSource.html > > From patrick at reini.net Tue Nov 15 06:40:16 2016 From: patrick at reini.net (Patrick Reinhart) Date: Tue, 15 Nov 2016 07:40:16 +0100 Subject: RFR: JDK-8168836 Minor clean up on warning/error messages In-Reply-To: <6B83B1C5-7DD6-4E7F-8294-9EF86F911564@oracle.com> References: <9fe0967b42b37fa3d79f0d77bf9cbc11@reini.net> <591746A1-6EF0-4FBD-B099-DF8B5996432D@reini.net> <6B83B1C5-7DD6-4E7F-8294-9EF86F911564@oracle.com> Message-ID: Applied changes to http://cr.openjdk.java.net/~reinhapa/reviews/8168836/webrev.00 -Patrick On 15.11.2016 00:20, Mandy Chung wrote: >> On Nov 14, 2016, at 1:22 PM, Patrick Reinhart wrote: >> >> Ups, previous mail contained wrong URL. Here?s the correct one: >> >> http://cr.openjdk.java.net/~reinhapa/reviews/8168836/webrev.00 > 879 log.println(getMessage("err.missing.dependences")); > > This should call reportError method that will prepend with ?error.prefix?. So no need to have ?ERROR:? in ?err.missing.dependences? message. > > Formatting Nit: line 541-542 and line 753-754 align to the first parameter of the method. > > Otherwise looks good. I can sponsor it. > > Mandy > > > > From christoph.langer at sap.com Tue Nov 15 07:43:26 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 15 Nov 2016 07:43:26 +0000 Subject: RFR: 8169631: [JAXP] XALAN: transformation of XML via namespace-unaware SAX input yields a different result than namespace-unaware DOM input In-Reply-To: <582A7170.7030100@oracle.com> References: <313759790392479fa80a10542ab664ec@dewdfe13de07.global.corp.sap> <582A7170.7030100@oracle.com> Message-ID: <4be5158237814eeb9352fe8fe344e47c@dewdfe13de07.global.corp.sap> Hi Joe, thanks for looking. Can you let me know which smoke test is failing? I didn't see issues so far - I was merely running the jtreg unittests for transformer. I stepped back from replacing Vector with ArrayList for m_prefixMappings because the code is using methods indexOf() with a start index and setSize() for which ArrayList has no direct matchings. One could, for sure, add some other coding, e.g. use ArrayList's subList() method for the index based search - but I wouldn't want to run the risk of adding a regression here just because I modified the code and did not well test it. But if you insist, I could have another look. Best regards Christoph > -----Original Message----- > From: Joe Wang [mailto:huizhe.wang at oracle.com] > Sent: Dienstag, 15. November 2016 03:23 > To: Langer, Christoph > Cc: core-libs-dev at openjdk.java.net > Subject: Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via > namespace-unaware SAX input yields a different result than namespace- > unaware DOM input > > Hi Christoph, > > Not all tests have finished yet, but there's at least one failure in the > smoke test. I'll get to the details when I have time. > > Any reason why m_prefixMappings can not be replaced with ArrayList? > > Thanks, > Joe > > On 11/14/16, 6:10 AM, Langer, Christoph wrote: > > Hi, > > > > please review this fix for bug 8169631. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169631 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169631.0/ > > > > When XALAN is handling namespace unaware input, it behaves differently > while using SAX input compared to DOM input. > > > > With both input source types, the class > com.sun.org.apache.xml.internal.dtm.ref.sax2dtm.SAX2DTM2 converts SAX > input into a DTM representation for processing by the XALAN transformer. Its > method startElement takes URI, localname and qName as attribute. In case of > missing feature namespaces, startElement and localname can be empty. > However, the function uses the localname value for the call to > m_expandedNameTable.getExpandedTypeID() and further processing. In the > case where only qName has data, this leads to issues. > > > > When using DOM input, the class > com.sun.org.apache.xalan.internal.xsltc.trax.DOM2SAX converts the DOM input > into SAX input. In the case of empty localname, it fills localname with qname > data. See method getLocalName() [1], called by parse() [2]. > > When directly using SAX input, the SAX parser calls the startElement() > function on XALAN's handler with empty uri and localname - which seems > correct, as per the spec. > > > > Both paths end up in SAX2DTM2's startElement(). So I suggest to change this > method to handle the case when uri and localname are empty and then set > qname as localname. Maybe one should even change DOM2SAX's > getLocalName handling to not fill localname with qname in case it is empty > after SAX2DTM was changed.. > > > > Generally, JavaDoc for SAXSource says that "Attempting to transform an input > source that is not generated with a namespace-aware parser may result in > errors." But why not fix some of these :) > > > > Furthermore I did some cleanups in the code. > > > > Thanks and best regards > > Christoph > > > > [1] > http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/shar > e/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l139 > > [2] > http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/shar > e/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l279 > > [3] > https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/sax/SAXSource > .html > > > > From zoltan.majo at oracle.com Tue Nov 15 12:04:41 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 15 Nov 2016 13:04:41 +0100 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> Message-ID: <4b4bfce6-2a81-dfb6-6ad6-646a02b4fc6c@oracle.com> Hi Peter, On 11/14/2016 10:59 PM, Peter Levart wrote: > Hi Zoltan, > > On 11/14/2016 03:28 PM, Zolt?n Maj? wrote: >> [...] >> >> thank you for the suggestion and for the example program! >> >> Here is the updated webrev with the updated text: >> >> http://cr.openjdk.java.net/~zmajo/8169000/webrev.01/ >> >> Does that look reasonable to you? > > Yes, I think this is good. Maybe just a nit. This last statement: > > "It is the responsibility of the program using reference objects to > ensure that the objects remain strongly reachable for as long as the > program is interested in their referents." > > ...could be written more nicely like: > > "It is the responsibility of the program to ensure that reference > objects remain strongly reachable for as long as it is interested in > their referents." > > ...or even: > > "It is the responsibility of the program to ensure that reference > objects remain strongly reachable for as long as it is interested in > tracking the reachability of their referents." > > > What do you think? yes, it sounds better, but probably it's best if we keep this change to a minimum. So I'd add only the word "strongly" to that sentence. Please see the updated webrev in my reply to Mandy. Thank you! Best regards, Zoltan > > > Regards, Peter > >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >>> >>> The following modified test shows this situation: >>> >>> >>> public class WeaklyReachablePhantomReference { >>> >>> static ReferenceQueue rq = new ReferenceQueue<>(); >>> static WeakReference> weakRefRef; >>> >>> public static void main(final String[] args) throws Exception { >>> weakRefRef = new WeakReference<>( >>> new PhantomReference<>( >>> new Object(), >>> rq >>> ) >>> ); >>> // <- here >>> System.gc(); >>> Reference rmRef = rq.remove(1000); >>> if (rmRef == null) { >>> System.out.println("PhantomReference NOT enqueued"); >>> } else { >>> System.out.println("PhantomReference enqueued"); >>> } >>> } >>> } >>> >>> >>> At "<-- here" the PhantomReference object becomes weakly reachable >>> while its referent becomes phantom reachable and this is enough for >>> PhantomReference to not be enqueued. >>> >>> >>> Regards, Peter >>> >> > From zoltan.majo at oracle.com Tue Nov 15 12:06:15 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 15 Nov 2016 13:06:15 +0100 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: <124a7382-8380-d0f8-4d5d-e306813c00bf@oracle.com> References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> <124a7382-8380-d0f8-4d5d-e306813c00bf@oracle.com> Message-ID: <936b96c5-619e-1f11-d7b9-ff10183eec3c@oracle.com> Hi David, On 11/14/2016 11:52 PM, David Holmes wrote: > [...] > > I don't think you need the "(i.e ...)". You are cross referencing to > the Reachability section where "strongly reachable" is defined. I see. OK, I've removed the "i.e.,". > > The fewer the changes the better - the key part is to make it clearer > that it "may" never be enqueued, without getting bogged down with why, > or why not. I agree. > > Of course this will need to go through CCC. Thank you for letting me know. I'll take care of the CCC approval once we have a changeset that we all agree upon. Please see the updated webrev in my reply to Mandy. Best regards, Zoltan > > Thanks, > David > > >> Does that look reasonable to you? >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >>> >>> The following modified test shows this situation: >>> >>> >>> public class WeaklyReachablePhantomReference { >>> >>> static ReferenceQueue rq = new ReferenceQueue<>(); >>> static WeakReference> weakRefRef; >>> >>> public static void main(final String[] args) throws Exception { >>> weakRefRef = new WeakReference<>( >>> new PhantomReference<>( >>> new Object(), >>> rq >>> ) >>> ); >>> // <- here >>> System.gc(); >>> Reference rmRef = rq.remove(1000); >>> if (rmRef == null) { >>> System.out.println("PhantomReference NOT enqueued"); >>> } else { >>> System.out.println("PhantomReference enqueued"); >>> } >>> } >>> } >>> >>> >>> At "<-- here" the PhantomReference object becomes weakly reachable >>> while its referent becomes phantom reachable and this is enough for >>> PhantomReference to not be enqueued. >>> >>> >>> Regards, Peter >>> >> From zoltan.majo at oracle.com Tue Nov 15 12:41:31 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 15 Nov 2016 13:41:31 +0100 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: <1695A59F-98AB-4821-9E20-AD3FE155EFAE@oracle.com> References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> <1695A59F-98AB-4821-9E20-AD3FE155EFAE@oracle.com> Message-ID: Hi Mandy, thank you for looking at this! Please find more details below. On 11/15/2016 02:51 AM, Mandy Chung wrote: >> On Nov 14, 2016, at 6:28 AM, Zolt?n Maj? wrote: >> >> Here is the updated webrev with the updated text: >> >> http://cr.openjdk.java.net/~zmajo/8169000/webrev.01/ >> > This spec uses ?unreachable? to refer to when GC detects as unreachable. I think the current spec is correct. > > What about this suggested clarification? > > diff --git a/src/java.base/share/classes/java/lang/ref/package-info.java b/src/java.base/share/classes/java/lang/ref/package-info.java > --- a/src/java.base/share/classes/java/lang/ref/package-info.java > +++ b/src/java.base/share/classes/java/lang/ref/package-info.java > @@ -77,8 +77,12 @@ > * references that are registered with it. If a registered reference > * becomes unreachable itself, then it will never be enqueued. It is > * the responsibility of the program using reference objects to ensure > - * that the objects remain reachable for as long as the program is > - * interested in their referents. > + * that the objects remain strongly reachable for as long as the program > + * is interested in their referents. > + * > + *

      > + * A Java virtual machine may implement optimization that could > + * affects when objects become unreachable. > * > *

      While some programs will choose to dedicate a thread to > * removing reference objects from one or more queues and processing I think the sentence in webrev.01 (1) "If a registered referenceceases to be strongly reachable itself, then it may never be enqueued." is sufficient. I think we want to make a statement only about what happens when a reference ceases to be strongly reachable (i.e., that in that case we can't make a statement about that reference being enqueued or not). The sentence you suggested (2) "A Java virtual machine may implement optimization that could affects when objects become unreachable." adds too much ambiguity as it leaves room for speculation about what "optimization" might be. For example, statement (2) can be possibly (mis-)read as the JVM making references unreachable *earlier* than what a programmer may think -- based on the source code.(That is clearly not the case: References are available at least until the latest program point where they are used, otherwise the program would encounter an error.) It's indeed a JVM "optimization" keep references alive *longer* than it seems to be from the source code. But (1) already encapsulates that without referring to JVM optimizations explicitly. > [...] > > > Making it clear ?strongly reachable? is a good suggestion. I don?t see word-smithing is needed in the original sentence; hence my above suggested change only adds the word ?strongly? in this sentence. I agree. Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8169000/webrev.02/ Thank you! Best regards, Zoltan > > Mandy From sergei.kovalev at oracle.com Tue Nov 15 14:34:57 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Tue, 15 Nov 2016 17:34:57 +0300 Subject: RFR(s): 8169721: [TESTBUG] com/sun/jndi tests have undeclared dependency on java.naming module Message-ID: Hi Team, Please review a small fix for tests. BugID: https://bugs.openjdk.java.net/browse/JDK-8169721 Web review: http://cr.openjdk.java.net/~skovalev/8169721/webrev.00/ Issue: most tests has missed dependency om java.naming module. Solution: add missed module declaration for tests. If this possible, add module declaration to TEST.properties file to avoid modification of each individual test. -- With best regards, Sergei From Roger.Riggs at Oracle.com Tue Nov 15 15:12:50 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 15 Nov 2016 10:12:50 -0500 Subject: Java is too limited when dealing with the Console In-Reply-To: <3cab5cfd-1bdb-1922-627f-0424ad32f0d8@gmail.com> References: <3cab5cfd-1bdb-1922-627f-0424ad32f0d8@gmail.com> Message-ID: Hi, You might find an open source package like JLine would have the full featured terminal support you are looking for. http://jline.sourceforge.net/ Roger On 11/13/2016 5:35 AM, Brunoais wrote: > Since java 6, a class named Console was created. This class allows > reading and writing directly to the console, including getting input > without echoing for password purposes. > > Unfortunately, that class does not include useful functionality for > java programs to work on the console and output formatted text. The > feature I miss the most is knowing how many columns I have to type > into in order to deliver an easier to read formatted output while > avoiding line wraps that are not coded in. > > There are other things I miss like having multi-line progress bars (so > far I can do single line if it is the last line by using "\r" and > re-writing the line). > > Other times, it is more user friendly to wait for any key press > instead of specifically waiting for "Enter" which will also add more > lines to the console. > > I did some search and found nothing about this. Why hasn't this been > implemented for java code? > From denis.kononenko at oracle.com Tue Nov 15 15:16:23 2016 From: denis.kononenko at oracle.com (Denis Kononenko) Date: Tue, 15 Nov 2016 07:16:23 -0800 (PST) Subject: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options Message-ID: Hi, Please do re-review for these changes. 1) tests for list --include were rewritten accordingly to https://bugs.openjdk.java.net/browse/JDK-8167384; 2) removed tests for '@filename', see https://bugs.openjdk.java.net/browse/JDK-8169720; 3) two new CRs were submitted: https://bugs.openjdk.java.net/browse/JDK-8169715, https://bugs.openjdk.java.net/browse/JDK-8169713; WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.04/ BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 Thank you, Denis. > Hi Andrey, > > No, it isn't. I submitted a new CR: > https://bugs.openjdk.java.net/browse/JDK-8167384. > > Thank you, > Denis. > > > Hi, > > > > Looks OK. Is it 100% pass rate? > > > > ?Andrey > > > On 9 Nov 2016, at 20:36, Denis Kononenko > > wrote: > > > > > > > > > > > > Hi, > > > > > > After discussion with Andrey we decided to add more tests for > corner > > cases. > > > The new changes are available by the link below. > > > > > > WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.03/ > > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > > > > > > > > > Thank you, > > > Denis. > > > > > >> Hi, > > >> > > >> Looks OK to me. > > >> I can suggest two more cases. A directory and file symlink can > be > > >> passed in options where tool requires a file path. > > >> > > >> ?Andrey > > >> > > >>> On 8 Nov 2016, at 16:17, Denis Kononenko > > >> wrote: > > >>> > > >>> > > >>> Hi, > > >>> > > >>> The new version of changes. > > >>> > > >>> - Switched back to jdk/test/testlibrary to avoid unwanted > > >> dependencies (JImageToolTest.java); > > >>> - Verified tests on smallest possible JDK build. > > >>> > > >>> WEBREV: > http://cr.openjdk.java.net/~dkononenko/8167240/webrev.02/ > > >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > > >>> > > >>> Thank you, > > >>> Denis. > > >>> > > >>>> Denis, > > >>>> > > >>>> I can see that you have switched to the top level test library > > >> with > > >>>> this change. With that you are getting more module > dependencies > > >> than > > >>>> just java.base. First of all, it would probably make sense to > > >> build > > >>>> only the classes you needed (which would be > > >>>> jdk.test.lib.process.ProcessTools, I assume), but even if you > > only > > >>>> build that, jdk.test.lib.process.ProcessTools has dependencies > > >> outside > > >>>> java.base module. > > >>>> > > >>>> You either have to declare @modules in your test or go back to > > the > > >>>> jdk/test/lib/testlibrary. Then, of course, unneeded module > > >>>> dependencies are questionable. > > >>>> > > >>>> Shura > > >>>> > > >>>> > > >>>>> On Nov 3, 2016, at 6:29 AM, Denis Kononenko > > >>>> wrote: > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>> I've done some rework accordingly to Alan's and Shura's > > comments: > > >>>>> > > >>>>> 1) removed overlapped tests from JImageToolTest.java; > > >>>>> > > >>>>> 2) added new tests JImageVerifyTest.java for jimage verify; > > >>>>> > > >>>>> 3) reorganized jtreg's tags; > > >>>>> > > >>>>> The new WEBREV can be found here: > > >>>> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/ > > >>>>> > > >>>>> Thank you, > > >>>>> Denis. > > >>>>> > > >>>>> On 06.10.2016 19:37, Denis Kononenko wrote: > > >>>>>> Hi, > > >>>>>> > > >>>>>> Could someone please review these new tests for jimage > > utility. > > >>>>>> > > >>>>>> There're 5 new files containing tests to cover use cases for > > >>>> 'info', 'list', 'extract' and other options. No new tests for > > >>>> 'verify'. > > >>>>>> > > >>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > > >>>>>> WEBREV: > > >> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/ > > >>>>>> > > >>>>>> > > >>>>>> Thank you, > > >>>>>> Denis. > > >>>>> From james.laskey at oracle.com Tue Nov 15 15:29:10 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 15 Nov 2016 11:29:10 -0400 Subject: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options In-Reply-To: References: Message-ID: <57088D50-8B9C-417C-90A8-996AAA6EF44D@oracle.com> +1 Really nice, thank you. > On Nov 15, 2016, at 11:16 AM, Denis Kononenko wrote: > > > Hi, > > Please do re-review for these changes. > > 1) tests for list --include were rewritten accordingly to https://bugs.openjdk.java.net/browse/JDK-8167384; > 2) removed tests for '@filename', see https://bugs.openjdk.java.net/browse/JDK-8169720; > 3) two new CRs were submitted: https://bugs.openjdk.java.net/browse/JDK-8169715, https://bugs.openjdk.java.net/browse/JDK-8169713; > > WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.04/ > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 > > Thank you, > Denis. > > >> Hi Andrey, >> >> No, it isn't. I submitted a new CR: >> https://bugs.openjdk.java.net/browse/JDK-8167384. >> >> Thank you, >> Denis. >> >>> Hi, >>> >>> Looks OK. Is it 100% pass rate? >>> >>> ?Andrey >>>> On 9 Nov 2016, at 20:36, Denis Kononenko >>> wrote: >>>> >>>> >>>> >>>> Hi, >>>> >>>> After discussion with Andrey we decided to add more tests for >> corner >>> cases. >>>> The new changes are available by the link below. >>>> >>>> WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.03/ >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 >>>> >>>> >>>> Thank you, >>>> Denis. >>>> >>>>> Hi, >>>>> >>>>> Looks OK to me. >>>>> I can suggest two more cases. A directory and file symlink can >> be >>>>> passed in options where tool requires a file path. >>>>> >>>>> ?Andrey >>>>> >>>>>> On 8 Nov 2016, at 16:17, Denis Kononenko >>>>> wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> The new version of changes. >>>>>> >>>>>> - Switched back to jdk/test/testlibrary to avoid unwanted >>>>> dependencies (JImageToolTest.java); >>>>>> - Verified tests on smallest possible JDK build. >>>>>> >>>>>> WEBREV: >> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.02/ >>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 >>>>>> >>>>>> Thank you, >>>>>> Denis. >>>>>> >>>>>>> Denis, >>>>>>> >>>>>>> I can see that you have switched to the top level test library >>>>> with >>>>>>> this change. With that you are getting more module >> dependencies >>>>> than >>>>>>> just java.base. First of all, it would probably make sense to >>>>> build >>>>>>> only the classes you needed (which would be >>>>>>> jdk.test.lib.process.ProcessTools, I assume), but even if you >>> only >>>>>>> build that, jdk.test.lib.process.ProcessTools has dependencies >>>>> outside >>>>>>> java.base module. >>>>>>> >>>>>>> You either have to declare @modules in your test or go back to >>> the >>>>>>> jdk/test/lib/testlibrary. Then, of course, unneeded module >>>>>>> dependencies are questionable. >>>>>>> >>>>>>> Shura >>>>>>> >>>>>>> >>>>>>>> On Nov 3, 2016, at 6:29 AM, Denis Kononenko >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I've done some rework accordingly to Alan's and Shura's >>> comments: >>>>>>>> >>>>>>>> 1) removed overlapped tests from JImageToolTest.java; >>>>>>>> >>>>>>>> 2) added new tests JImageVerifyTest.java for jimage verify; >>>>>>>> >>>>>>>> 3) reorganized jtreg's tags; >>>>>>>> >>>>>>>> The new WEBREV can be found here: >>>>>>> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.01/ >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Denis. >>>>>>>> >>>>>>>> On 06.10.2016 19:37, Denis Kononenko wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Could someone please review these new tests for jimage >>> utility. >>>>>>>>> >>>>>>>>> There're 5 new files containing tests to cover use cases for >>>>>>> 'info', 'list', 'extract' and other options. No new tests for >>>>>>> 'verify'. >>>>>>>>> >>>>>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240 >>>>>>>>> WEBREV: >>>>> http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Denis. >>>>>>>> From peter.levart at gmail.com Tue Nov 15 16:08:48 2016 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 15 Nov 2016 17:08:48 +0100 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> <1695A59F-98AB-4821-9E20-AD3FE155EFAE@oracle.com> Message-ID: <5d75b7e6-183a-a17c-934e-5fd6980a9a5e@gmail.com> On 11/15/2016 01:41 PM, Zolt?n Maj? wrote: > Here is the updated webrev: > > http://cr.openjdk.java.net/~zmajo/8169000/webrev.02/ +1 Regards, Peter From paul.sandoz at oracle.com Tue Nov 15 16:23:19 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 15 Nov 2016 08:23:19 -0800 Subject: 8072784: Better spliterator implementation for BitSet.stream() In-Reply-To: References: Message-ID: <5A8FDC39-5B4C-4A77-AE67-51013284942A@oracle.com> > On 14 Nov 2016, at 17:56, Paul Sandoz wrote: > > Hi, > > Please review this patch implementing a spliterator for BitSet: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8072784-bitset-stream-spliterator/webrev/ > > The spliterator is SIZED but not SUBSIZED, the bit set?s cardinality is used (same for the iterator) as the size of the root spliterator, and estimates from that are derived thereafter for splits. Splitting attempts to balance the small vs. large, dense vs. sparse cases. > > Most of the complexity is dealing with the edge case of there being a bit set at Integer.MAX_VALUE. > I was right about that aspect, i found a bug in the lowering of the fence when splitting: diff -r 984df674e145 src/java.base/share/classes/java/util/BitSet.java --- a/src/java.base/share/classes/java/util/BitSet.java Mon Nov 14 17:35:00 2016 -0800 +++ b/src/java.base/share/classes/java/util/BitSet.java Tue Nov 15 07:05:38 2016 -0800 @@ -1300,9 +1300,9 @@ // The index is the first bit set, thus this spliterator // covers one bit and cannot be split, or two or more // bits - hi = fence = hi < Integer.MAX_VALUE + hi = fence = (hi < Integer.MAX_VALUE || !get(Integer.MAX_VALUE)) ? previousSetBit(hi - 1) + 1 - : previousSetBit(Integer.MAX_VALUE); + : Integer.MAX_VALUE; // Find the mid point int mid = (lo + hi) >>> 1; and i modified the test cases: diff -r d62ebbfd3e0d test/java/util/BitSet/BitSetStreamTest.java --- a/test/java/util/BitSet/BitSetStreamTest.java Tue Nov 15 07:11:07 2016 -0800 +++ b/test/java/util/BitSet/BitSetStreamTest.java Tue Nov 15 08:19:17 2016 -0800 @@ -83,6 +83,7 @@ { "index 255", IntStream.of(255) }, { "index 0 and 255", IntStream.of(0, 255) }, { "index Integer.MAX_VALUE", IntStream.of(Integer.MAX_VALUE) }, + { "index Integer.MAX_VALUE - 1", IntStream.of(Integer.MAX_VALUE - 1) }, { "index 0 and Integer.MAX_VALUE", IntStream.of(0, Integer.MAX_VALUE) }, { "every bit", IntStream.range(0, 255) }, { "step 2", IntStream.range(0, 255).map(f -> f * 2) }, diff -r d62ebbfd3e0d test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java --- a/test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java Tue Nov 15 07:11:07 2016 -0800 +++ b/test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java Tue Nov 15 08:19:17 2016 -0800 @@ -892,6 +892,9 @@ { "index 0", IntStream.of(0).toArray() }, { "index 255", IntStream.of(255).toArray() }, { "index 0 and 255", IntStream.of(0, 255).toArray() }, + { "index Integer.MAX_VALUE", IntStream.of(Integer.MAX_VALUE).toArray() }, + { "index Integer.MAX_VALUE - 1", IntStream.of(Integer.MAX_VALUE - 1).toArray() }, + { "index 0 and Integer.MAX_VALUE", IntStream.of(0, Integer.MAX_VALUE).toArray() }, { "every bit", IntStream.range(0, 255).toArray() }, { "step 2", IntStream.range(0, 255).map(f -> f * 2).toArray() }, { "step 3", IntStream.range(0, 255).map(f -> f * 3).toArray() }, Webrev is updated in place. Paul. > > Testing-wise i have leveraged the existing tests. It would be nice to consider placing the spliterator testing functionality into a separate library for reuse as SpliteratorTraversingAndSplittingTest is getting large. Likewise for more formally for streams, which is possible to reuse but a little clunky. I can log issues for those. > > Paul. > From daniel.fuchs at oracle.com Tue Nov 15 16:31:21 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 15 Nov 2016 16:31:21 +0000 Subject: [JAXP] RFR 8169723: remove jaxp/src/java.xml/share/classes/org/w3c/dom/xpath/COPYRIGHT.html Message-ID: Hi, Please find below a trivial patch for JBS: https://bugs.openjdk.java.net/browse/JDK-8169723 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8169723/webrev.00/ The org.w3c.dom.xpath package is now exported by the jdk.xml.dom package. Somehow this copyright file was copied instead of being moved, so now java.xml sources have an empty org.w3c.dom.xpath package that only contains the COPYRIGHT.html file: this file should be removed. Note: $ diff jaxp/src/java.xml/share/classes/org/w3c/dom/xpath/COPYRIGHT.html jaxp/src/jdk.xml.dom/share/classes/org/w3c/dom/xpath/COPYRIGHT.html shows that the two files are identical. best regards, -- daniel From Roger.Riggs at Oracle.com Tue Nov 15 16:49:14 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 15 Nov 2016 11:49:14 -0500 Subject: [JAXP] RFR 8169723: remove jaxp/src/java.xml/share/classes/org/w3c/dom/xpath/COPYRIGHT.html In-Reply-To: References: Message-ID: Looks fine. Roger On 11/15/2016 11:31 AM, Daniel Fuchs wrote: > Hi, > > Please find below a trivial patch for > > JBS: https://bugs.openjdk.java.net/browse/JDK-8169723 > webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8169723/webrev.00/ > > The org.w3c.dom.xpath package is now exported by the jdk.xml.dom package. > Somehow this copyright file was copied instead of being moved, so now > java.xml sources have an empty org.w3c.dom.xpath package that only > contains the COPYRIGHT.html file: this file should be removed. > > Note: > $ diff > jaxp/src/java.xml/share/classes/org/w3c/dom/xpath/COPYRIGHT.html > jaxp/src/jdk.xml.dom/share/classes/org/w3c/dom/xpath/COPYRIGHT.html > shows that the two files are identical. > > best regards, > > -- daniel > From david.dehaven at oracle.com Tue Nov 15 17:10:42 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 15 Nov 2016 09:10:42 -0800 Subject: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method In-Reply-To: <3160154D-73F2-430C-A943-E75CC9FF4C08@oracle.com> References: <3160154D-73F2-430C-A943-E75CC9FF4C08@oracle.com> Message-ID: Ping? Kumar? -DrD- > On Nov 10, 2016, at 9:38 AM, David DeHaven wrote: > > > Please review the (fairly straightforward) JDK changes needed to support launching JavaFX applications in a named module. > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8169289 > > Webrev: > http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/ > > > > For reference, here are the openjfx changes needed: > http://cr.openjdk.java.net/~ddehaven/8169289/openjfx-rt.0/ > > The changes can be pushed independently, so no fancy juggling will be needed. Only the LM_MODULE mode fails in any mixed combination, which fails as things stand now. I will file a followup issue to add unit tests, but those tests will go into openjfx and will wait until openjfx and openjdk promoted builds are in sync. I don't think the non-FX modes are affected substantially enough to warrant any test changes on the openjdk side. > > -DrD- > From james.laskey at oracle.com Tue Nov 15 17:57:08 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 15 Nov 2016 13:57:08 -0400 Subject: RFR: JDK-8169505 - Update changes by JDK-8159393 to reflect CCC review Message-ID: http://cr.openjdk.java.net/~jlaskey/8169505/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8169505 From brunoaiss at gmail.com Tue Nov 15 18:09:08 2016 From: brunoaiss at gmail.com (Brunoais) Date: Tue, 15 Nov 2016 18:09:08 +0000 Subject: Java is too limited when dealing with the Console In-Reply-To: References: <3cab5cfd-1bdb-1922-627f-0424ad32f0d8@gmail.com> Message-ID: jLine requires a .dll on windows making it not OS agnostic. If this existed in java itself, this problem would not be a problem because java internal dll are signed by java and can be included without issues. But then, why doesn't java have this? On 15/11/2016 15:12, Roger Riggs wrote: > Hi, > > You might find an open source package like JLine would have the full > featured terminal support you are looking for. > http://jline.sourceforge.net/ > > Roger > > > On 11/13/2016 5:35 AM, Brunoais wrote: >> Since java 6, a class named Console was created. This class allows >> reading and writing directly to the console, including getting input >> without echoing for password purposes. >> >> Unfortunately, that class does not include useful functionality for >> java programs to work on the console and output formatted text. The >> feature I miss the most is knowing how many columns I have to type >> into in order to deliver an easier to read formatted output while >> avoiding line wraps that are not coded in. >> >> There are other things I miss like having multi-line progress bars >> (so far I can do single line if it is the last line by using "\r" and >> re-writing the line). >> >> Other times, it is more user friendly to wait for any key press >> instead of specifically waiting for "Enter" which will also add more >> lines to the console. >> >> I did some search and found nothing about this. Why hasn't this been >> implemented for java code? >> > > From brunoaiss at gmail.com Tue Nov 15 18:14:41 2016 From: brunoaiss at gmail.com (Brunoais) Date: Tue, 15 Nov 2016 18:14:41 +0000 Subject: Java is too limited when dealing with the Console In-Reply-To: References: <3cab5cfd-1bdb-1922-627f-0424ad32f0d8@gmail.com> Message-ID: <79b94c12-07bc-e76b-47d7-47531158ea52@gmail.com> I also noticed now that this does not allow placing the cursor in arbitrary places. With the same restrictions as jline, I could use javacurses. https://sourceforge.net/projects/javacurses/ Unfortunately, it also requires using extra native libraries to work because java does not include such API natively. On 15/11/2016 18:09, Brunoais wrote: > jLine requires a .dll on windows making it not OS agnostic. If this > existed in java itself, this problem would not be a problem because > java internal dll are signed by java and can be included without issues. > > But then, why doesn't java have this? > > > On 15/11/2016 15:12, Roger Riggs wrote: >> Hi, >> >> You might find an open source package like JLine would have the full >> featured terminal support you are looking for. >> http://jline.sourceforge.net/ >> >> Roger >> >> >> On 11/13/2016 5:35 AM, Brunoais wrote: >>> Since java 6, a class named Console was created. This class allows >>> reading and writing directly to the console, including getting input >>> without echoing for password purposes. >>> >>> Unfortunately, that class does not include useful functionality for >>> java programs to work on the console and output formatted text. The >>> feature I miss the most is knowing how many columns I have to type >>> into in order to deliver an easier to read formatted output while >>> avoiding line wraps that are not coded in. >>> >>> There are other things I miss like having multi-line progress bars >>> (so far I can do single line if it is the last line by using "\r" >>> and re-writing the line). >>> >>> Other times, it is more user friendly to wait for any key press >>> instead of specifically waiting for "Enter" which will also add more >>> lines to the console. >>> >>> I did some search and found nothing about this. Why hasn't this been >>> implemented for java code? >>> >> >> > From Roger.Riggs at Oracle.com Tue Nov 15 18:17:34 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 15 Nov 2016 13:17:34 -0500 Subject: Java is too limited when dealing with the Console In-Reply-To: References: <3cab5cfd-1bdb-1922-627f-0424ad32f0d8@gmail.com> Message-ID: <6ca70418-8fd8-b71e-2a93-e7106acbd1a1@Oracle.com> Hi Brunoais, Largely, because most people don't interact with java from a terminal and the simple stream oriented access has been sufficient. Take a look for layered libraries that can handle fancier terminals that have color and various positioning (ANSI) escape sequences that might meet your needs. Roger On 11/15/2016 1:09 PM, Brunoais wrote: > jLine requires a .dll on windows making it not OS agnostic. If this > existed in java itself, this problem would not be a problem because > java internal dll are signed by java and can be included without issues. > > But then, why doesn't java have this? > > > On 15/11/2016 15:12, Roger Riggs wrote: >> Hi, >> >> You might find an open source package like JLine would have the full >> featured terminal support you are looking for. >> http://jline.sourceforge.net/ >> >> Roger >> >> >> On 11/13/2016 5:35 AM, Brunoais wrote: >>> Since java 6, a class named Console was created. This class allows >>> reading and writing directly to the console, including getting input >>> without echoing for password purposes. >>> >>> Unfortunately, that class does not include useful functionality for >>> java programs to work on the console and output formatted text. The >>> feature I miss the most is knowing how many columns I have to type >>> into in order to deliver an easier to read formatted output while >>> avoiding line wraps that are not coded in. >>> >>> There are other things I miss like having multi-line progress bars >>> (so far I can do single line if it is the last line by using "\r" >>> and re-writing the line). >>> >>> Other times, it is more user friendly to wait for any key press >>> instead of specifically waiting for "Enter" which will also add more >>> lines to the console. >>> >>> I did some search and found nothing about this. Why hasn't this been >>> implemented for java code? >>> >> >> > From mandy.chung at oracle.com Tue Nov 15 20:48:45 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 15 Nov 2016 12:48:45 -0800 Subject: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method In-Reply-To: <3160154D-73F2-430C-A943-E75CC9FF4C08@oracle.com> References: <3160154D-73F2-430C-A943-E75CC9FF4C08@oracle.com> Message-ID: <254E040E-2D2D-4325-A1EA-59FA12995EFE@oracle.com> > On Nov 10, 2016, at 9:38 AM, David DeHaven wrote: > > > Please review the (fairly straightforward) JDK changes needed to support launching JavaFX applications in a named module. > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8169289 > > Webrev: > http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/ > > Would it be better to refactor line 557-563 and 612-624 and be called in the checkAndLoadMain method after the main class is loaded? Mandy From jimmy.praet at telenet.be Sat Nov 12 11:26:21 2016 From: jimmy.praet at telenet.be (jimmy.praet at telenet.be) Date: Sat, 12 Nov 2016 12:26:21 +0100 (CET) Subject: default methods for java.lang.Comparable: isGreaterThan, ... Message-ID: <93742659.33709239.1478949981332.JavaMail.root@telenet.be> Hi, What are your thoughts on adding these default convenience methods to the java.lang.Comparable interface? public interface Comparable { int compareTo(T o); default boolean isGreaterThan(T o) { return compareTo(o) > 0; } default boolean isGreaterThanOrEqualTo(T o) { return compareTo(o) >= 0; } default boolean isLessThan(T o) { return compareTo(o) < 0; } default boolean isLessThanOrEqualTo(T o) { return compareTo(o) <= 0; } } code like "if (x.isGreaterThan(y))" is a lot more readable and expressive than "if (x.compareTo(y) > 0)". Kind regards, Jimmy From david.dehaven at oracle.com Tue Nov 15 21:13:30 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 15 Nov 2016 13:13:30 -0800 Subject: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method In-Reply-To: <254E040E-2D2D-4325-A1EA-59FA12995EFE@oracle.com> References: <3160154D-73F2-430C-A943-E75CC9FF4C08@oracle.com> <254E040E-2D2D-4325-A1EA-59FA12995EFE@oracle.com> Message-ID: <3B9F04BD-CF03-4FF2-9BD7-E35F6CB4AB1E@oracle.com> >> Please review the (fairly straightforward) JDK changes needed to support launching JavaFX applications in a named module. >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8169289 >> >> Webrev: >> http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/ >> >> > > Would it be better to refactor line 557-563 and 612-624 and be called in the checkAndLoadMain method after the main class is loaded? Yeah, we probably could do that. I'll look into it. -DrD- From joe.darcy at oracle.com Tue Nov 15 21:26:52 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 15 Nov 2016 13:26:52 -0800 Subject: JDK 9 RFR of JDK-8169736: Mark RmiIiopReturnValueTest.java as intermittently failing Message-ID: Hello, The test javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java has been seen in intermittently fail in various test systems and should be marked accordingly. Please review the patch below to do this. Thanks, -Joe diff -r 99b7853cfbd8 test/javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java --- a/test/javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java Tue Nov 15 08:40:36 2016 -0800 +++ b/test/javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java Tue Nov 15 13:26:29 2016 -0800 @@ -24,6 +24,7 @@ /* * @test * @bug 8146975 + * @key intermittent * @summary test RMI-IIOP with value object return * @modules java.corba * @library /lib/testlibrary From lance.andersen at oracle.com Tue Nov 15 21:30:26 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 15 Nov 2016 16:30:26 -0500 Subject: JDK 9 RFR of JDK-8169736: Mark RmiIiopReturnValueTest.java as intermittently failing In-Reply-To: References: Message-ID: +1 > On Nov 15, 2016, at 4:26 PM, joe darcy wrote: > > Hello, > > The test > > javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java > > has been seen in intermittently fail in various test systems and should be marked accordingly. > > Please review the patch below to do this. > > Thanks, > > -Joe > > diff -r 99b7853cfbd8 test/javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java > --- a/test/javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java Tue Nov 15 08:40:36 2016 -0800 > +++ b/test/javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java Tue Nov 15 13:26:29 2016 -0800 > @@ -24,6 +24,7 @@ > /* > * @test > * @bug 8146975 > + * @key intermittent > * @summary test RMI-IIOP with value object return > * @modules java.corba > * @library /lib/testlibrary > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From forax at univ-mlv.fr Tue Nov 15 21:35:27 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 15 Nov 2016 22:35:27 +0100 (CET) Subject: Java is too limited when dealing with the Console In-Reply-To: <6ca70418-8fd8-b71e-2a93-e7106acbd1a1@Oracle.com> References: <3cab5cfd-1bdb-1922-627f-0424ad32f0d8@gmail.com> <6ca70418-8fd8-b71e-2a93-e7106acbd1a1@Oracle.com> Message-ID: <1945209882.1409978.1479245727019.JavaMail.zimbra@u-pem.fr> Hi Brunoais, Java is not and will never be only what comes with the OpenJDK, it's a big (really big) community full of libraries for whatever you wish and even sometimes what you don't wish. So beside readline, you can also take a look at Jansi https://github.com/fusesource/jansi it's the package used by maven for its colored outputs. Btw you can put a dll inside a jmod. regards, R?mi ----- Mail original ----- > De: "Roger Riggs" > ?: core-libs-dev at openjdk.java.net > Envoy?: Mardi 15 Novembre 2016 19:17:34 > Objet: Re: Java is too limited when dealing with the Console > Hi Brunoais, > > Largely, because most people don't interact with java from a terminal > and the simple stream > oriented access has been sufficient. Take a look for layered libraries > that can handle > fancier terminals that have color and various positioning (ANSI) escape > sequences > that might meet your needs. > > Roger > > > On 11/15/2016 1:09 PM, Brunoais wrote: >> jLine requires a .dll on windows making it not OS agnostic. If this >> existed in java itself, this problem would not be a problem because >> java internal dll are signed by java and can be included without issues. >> >> But then, why doesn't java have this? >> >> >> On 15/11/2016 15:12, Roger Riggs wrote: >>> Hi, >>> >>> You might find an open source package like JLine would have the full >>> featured terminal support you are looking for. >>> http://jline.sourceforge.net/ >>> >>> Roger >>> >>> >>> On 11/13/2016 5:35 AM, Brunoais wrote: >>>> Since java 6, a class named Console was created. This class allows >>>> reading and writing directly to the console, including getting input >>>> without echoing for password purposes. >>>> >>>> Unfortunately, that class does not include useful functionality for >>>> java programs to work on the console and output formatted text. The >>>> feature I miss the most is knowing how many columns I have to type >>>> into in order to deliver an easier to read formatted output while >>>> avoiding line wraps that are not coded in. >>>> >>>> There are other things I miss like having multi-line progress bars >>>> (so far I can do single line if it is the last line by using "\r" >>>> and re-writing the line). >>>> >>>> Other times, it is more user friendly to wait for any key press >>>> instead of specifically waiting for "Enter" which will also add more >>>> lines to the console. >>>> >>>> I did some search and found nothing about this. Why hasn't this been >>>> implemented for java code? >>>> >>> >>> From aleksej.efimov at oracle.com Tue Nov 15 21:48:13 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Wed, 16 Nov 2016 00:48:13 +0300 Subject: [9] RFR(XXXXS): 8160999: GPL header missing comma in year Message-ID: <3ded054b-6564-fa4f-d682-2f8279a624fb@oracle.com> Hi, jaxws/src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java file contains incorrect GPL header which fails make/scripts/lic_check.sh script check. Failure is caused by missing comma after modification years. Please, help to review its addition: diff -r 26c9b9c51052 src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java --- a/src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java Tue Nov 15 23:43:38 2016 +0300 +++ b/src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java Wed Nov 16 00:38:23 2016 +0300 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013, 2014 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2013, 2014, 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 lic_check.sh passes after this modification: ### Checking copyright notice in the file: jaxws/src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java ### SUCCESS: The license header for jaxws/src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java has been verified. ### With Best Regards, Aleksej From mandy.chung at oracle.com Tue Nov 15 21:51:14 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 15 Nov 2016 13:51:14 -0800 Subject: [9] RFR(XXXXS): 8160999: GPL header missing comma in year In-Reply-To: <3ded054b-6564-fa4f-d682-2f8279a624fb@oracle.com> References: <3ded054b-6564-fa4f-d682-2f8279a624fb@oracle.com> Message-ID: +1 Mandy > On Nov 15, 2016, at 1:48 PM, Aleks Efimov wrote: > > Hi, > > jaxws/src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java file contains incorrect GPL header which fails make/scripts/lic_check.sh script check. > > Failure is caused by missing comma after modification years. Please, help to review its addition: > diff -r 26c9b9c51052 src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java > --- a/src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java Tue Nov 15 23:43:38 2016 +0300 > +++ b/src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java Wed Nov 16 00:38:23 2016 +0300 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2013, 2014 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2013, 2014, 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 > > > lic_check.sh passes after this modification: > ### Checking copyright notice in the file: jaxws/src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java > ### > SUCCESS: The license header for jaxws/src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java has been verified. > ### > > > With Best Regards, > Aleksej > From iris.clark at oracle.com Tue Nov 15 22:04:23 2016 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 15 Nov 2016 14:04:23 -0800 (PST) Subject: [9] RFR(XXXXS): 8160999: GPL header missing comma in year In-Reply-To: <3ded054b-6564-fa4f-d682-2f8279a624fb@oracle.com> References: <3ded054b-6564-fa4f-d682-2f8279a624fb@oracle.com> Message-ID: <956ccd28-6be7-470a-849b-2adac2d509a3@default> Hi. Your change looks fine to me. Thanks, iris -----Original Message----- From: Aleks Efimov Sent: Tuesday, November 15, 2016 1:48 PM To: core-libs-dev Subject: [9] RFR(XXXXS): 8160999: GPL header missing comma in year Hi, jaxws/src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java file contains incorrect GPL header which fails make/scripts/lic_check.sh script check. Failure is caused by missing comma after modification years. Please, help to review its addition: diff -r 26c9b9c51052 src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java --- a/src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java Tue Nov 15 23:43:38 2016 +0300 +++ b/src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java Wed Nov 16 00:38:23 2016 +0300 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013, 2014 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2013, 2014, 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 lic_check.sh passes after this modification: ### Checking copyright notice in the file: jaxws/src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java ### SUCCESS: The license header for jaxws/src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java has been verified. ### With Best Regards, Aleksej From david.dehaven at oracle.com Wed Nov 16 00:04:05 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 15 Nov 2016 16:04:05 -0800 Subject: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method In-Reply-To: <3B9F04BD-CF03-4FF2-9BD7-E35F6CB4AB1E@oracle.com> References: <3160154D-73F2-430C-A943-E75CC9FF4C08@oracle.com> <254E040E-2D2D-4325-A1EA-59FA12995EFE@oracle.com> <3B9F04BD-CF03-4FF2-9BD7-E35F6CB4AB1E@oracle.com> Message-ID: <2AD15EB5-255D-455C-A8CC-BD9B11D9D2D8@oracle.com> >>> Please review the (fairly straightforward) JDK changes needed to support launching JavaFX applications in a named module. >>> >>> JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8169289 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/ >>> >>> >> >> Would it be better to refactor line 557-563 and 612-624 and be called in the checkAndLoadMain method after the main class is loaded? > > Yeah, we probably could do that. I'll look into it. Updated with your suggested change: http://cr.openjdk.java.net/~ddehaven/8169289/jdk.1 -DrD- From mandy.chung at oracle.com Wed Nov 16 00:21:14 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 15 Nov 2016 16:21:14 -0800 Subject: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method In-Reply-To: <2AD15EB5-255D-455C-A8CC-BD9B11D9D2D8@oracle.com> References: <3160154D-73F2-430C-A943-E75CC9FF4C08@oracle.com> <254E040E-2D2D-4325-A1EA-59FA12995EFE@oracle.com> <3B9F04BD-CF03-4FF2-9BD7-E35F6CB4AB1E@oracle.com> <2AD15EB5-255D-455C-A8CC-BD9B11D9D2D8@oracle.com> Message-ID: <1D40C5B1-712A-4CA1-9B19-0C1E407876EB@oracle.com> > On Nov 15, 2016, at 4:04 PM, David DeHaven wrote: > > >>>> Please review the (fairly straightforward) JDK changes needed to support launching JavaFX applications in a named module. >>>> >>>> JBS: >>>> https://bugs.openjdk.java.net/browse/JDK-8169289 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/ >>>> >>>> >>> >>> Would it be better to refactor line 557-563 and 612-624 and be called in the checkAndLoadMain method after the main class is loaded? >> >> Yeah, we probably could do that. I'll look into it. > > Updated with your suggested change: > http://cr.openjdk.java.net/~ddehaven/8169289/jdk.1 Looks fine. I wonder what appClass is intended for and whether it should be set in line 483 instead. 554 appClass = c; 600 // record the main class 601 appClass = mainClass; Kumar would know the history. Mandy From david.dehaven at oracle.com Wed Nov 16 00:25:21 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 15 Nov 2016 16:25:21 -0800 Subject: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method In-Reply-To: <1D40C5B1-712A-4CA1-9B19-0C1E407876EB@oracle.com> References: <3160154D-73F2-430C-A943-E75CC9FF4C08@oracle.com> <254E040E-2D2D-4325-A1EA-59FA12995EFE@oracle.com> <3B9F04BD-CF03-4FF2-9BD7-E35F6CB4AB1E@oracle.com> <2AD15EB5-255D-455C-A8CC-BD9B11D9D2D8@oracle.com> <1D40C5B1-712A-4CA1-9B19-0C1E407876EB@oracle.com> Message-ID: <278A54B1-D254-4DC3-A8BE-4F0FF296E23F@oracle.com> > On Nov 15, 2016, at 4:21 PM, Mandy Chung wrote: > > >> On Nov 15, 2016, at 4:04 PM, David DeHaven wrote: >> >> >>>>> Please review the (fairly straightforward) JDK changes needed to support launching JavaFX applications in a named module. >>>>> >>>>> JBS: >>>>> https://bugs.openjdk.java.net/browse/JDK-8169289 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/ >>>>> >>>>> >>>> >>>> Would it be better to refactor line 557-563 and 612-624 and be called in the checkAndLoadMain method after the main class is loaded? >>> >>> Yeah, we probably could do that. I'll look into it. >> >> Updated with your suggested change: >> http://cr.openjdk.java.net/~ddehaven/8169289/jdk.1 > > Looks fine. I wonder what appClass is intended for and whether it should be set in line 483 instead. > > 554 appClass = c; > > 600 // record the main class > 601 appClass = mainClass; > > Kumar would know the history. It was added as part of the original work to support launching FX applications in JDK 8, it's primarily for error reporting so it reports the correct main class instead of FXHelper. You are correct in that it should have been moved too.. I'll update that when I get back. -DrD- From david.holmes at oracle.com Wed Nov 16 02:21:15 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Nov 2016 12:21:15 +1000 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> <1695A59F-98AB-4821-9E20-AD3FE155EFAE@oracle.com> Message-ID: <3e44c6db-ba97-3096-9210-56f9c15a2bd9@oracle.com> Hi Zoltan, First, I'm okay with latest webrev. Second, I don't want to confuse things but need to correct one thing ... On 15/11/2016 10:41 PM, Zolt?n Maj? wrote: > Hi Mandy, > > > thank you for looking at this! Please find more details below. > > On 11/15/2016 02:51 AM, Mandy Chung wrote: >>> On Nov 14, 2016, at 6:28 AM, Zolt?n Maj? wrote: >>> >>> Here is the updated webrev with the updated text: >>> >>> http://cr.openjdk.java.net/~zmajo/8169000/webrev.01/ >>> >> This spec uses ?unreachable? to refer to when GC detects as >> unreachable. I think the current spec is correct. >> >> What about this suggested clarification? >> >> diff --git >> a/src/java.base/share/classes/java/lang/ref/package-info.java >> b/src/java.base/share/classes/java/lang/ref/package-info.java >> --- a/src/java.base/share/classes/java/lang/ref/package-info.java >> +++ b/src/java.base/share/classes/java/lang/ref/package-info.java >> @@ -77,8 +77,12 @@ >> * references that are registered with it. If a registered reference >> * becomes unreachable itself, then it will never be enqueued. It is >> * the responsibility of the program using reference objects to ensure >> - * that the objects remain reachable for as long as the program is >> - * interested in their referents. >> + * that the objects remain strongly reachable for as long as the program >> + * is interested in their referents. >> + * >> + *

      >> + * A Java virtual machine may implement optimization that could >> + * affects when objects become unreachable. >> * >> *

      While some programs will choose to dedicate a thread to >> * removing reference objects from one or more queues and processing > > I think the sentence in webrev.01 > > (1) "If a registered referenceceases to be strongly reachable itself, > then it may never be enqueued." > > is sufficient. I think we want to make a statement only about what > happens when a reference ceases to be strongly reachable (i.e., that in > that case we can't make a statement about that reference being enqueued > or not). > > The sentence you suggested > > (2) "A Java virtual machine may implement optimization that could > affects when objects become unreachable." > > adds too much ambiguity as it leaves room for speculation about what > "optimization" might be. > > For example, statement (2) can be possibly (mis-)read as the JVM making > references unreachable *earlier* than what a programmer may think -- > based on the source code.(That is clearly not the case: References are > available at least until the latest program point where they are used, > otherwise the program would encounter an error.) Actually it can make references unreachable earlier than may be expected. The wording Mandy suggested comes from the JLS itself - see 12.6.1. (Though I agree it isn't the right disclaimer for the current situation - where the interpreter keeps the reference reachable longer than naively expected). David ----- > It's indeed a JVM "optimization" keep references alive *longer* than it > seems to be from the source code. But (1) already encapsulates that > without referring to JVM optimizations explicitly. > >> [...] >> >> >> Making it clear ?strongly reachable? is a good suggestion. I don?t >> see word-smithing is needed in the original sentence; hence my above >> suggested change only adds the word ?strongly? in this sentence. > > I agree. > > Here is the updated webrev: > > http://cr.openjdk.java.net/~zmajo/8169000/webrev.02/ > > Thank you! > > Best regards, > > > Zoltan > >> >> Mandy > From mandy.chung at oracle.com Wed Nov 16 06:11:26 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 15 Nov 2016 22:11:26 -0800 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> <1695A59F-98AB-4821-9E20-AD3FE155EFAE@oracle.com> Message-ID: <0D45991D-20E0-4835-9EFA-C3DCCBA24059@oracle.com> > On Nov 15, 2016, at 4:41 AM, Zolt?n Maj? wrote: > > > I think the sentence in webrev.01 > > (1) "If a registered referenceceases to be strongly reachable itself, then it may never be enqueued." > > is sufficient. I think we want to make a statement only about what happens when a reference ceases to be strongly reachable (i.e., that in that case we can't make a statement about that reference being enqueued or not). > When a reference becomes unreachable (not by examining the source code but the actual state of the VM at runtime), it will never be enqueued. > The sentence you suggested > > (2) "A Java virtual machine may implement optimization that could affects when objects become unreachable." > > adds too much ambiguity as it leaves room for speculation about what "optimization" might be. > > For example, statement (2) can be possibly (mis-)read as the JVM making references unreachable *earlier* than what a programmer may think -- based on the source code.(That is clearly not the case: References are available at least until the latest program point where they are used, otherwise the program would encounter an error.) > > It's indeed a JVM "optimization" keep references alive *longer* than it seems to be from the source code. But (1) already encapsulates that without referring to JVM optimizations explicitly. That?s fair. What I?m looking for is something like this [1]: Reachability is not determined by the statements in your source code but by the actual state of the virtual machine at runtime. Mandy [1] The Java Programming Language, Fourth Edition, section 17.5.4 From huaming.li at oracle.com Wed Nov 16 07:36:45 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 16 Nov 2016 15:36:45 +0800 Subject: RFR of JDK-8168975: java/rmi/activation/Activatable tests fail due to "Port already in use" in RMID.restart() Message-ID: <68995a74-8e19-9462-1ff3-cd32a3a40441@oracle.com> Would you please review below fix? bug: https://bugs.openjdk.java.net/browse/JDK-8168975 webrev: http://cr.openjdk.java.net/~mli/8168975/webrev.00/ Root Cause: There is a time window between RMID.start() and RMID.restart(), interloper can step in and bind to the port used by RMID in RMID.start(). Solution: Modify RMID.java to use inherited channel when calling RMID.restart. And extend RMIDSelectorProvider.java to try to bind to specific port, no matter 0 or none-zero(for RMID.restart) in a while loop, if timeout just call System.exit to exit rmid and let test fail. Thank you -Hamlin From zoltan.majo at oracle.com Wed Nov 16 08:21:40 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 16 Nov 2016 09:21:40 +0100 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: <3e44c6db-ba97-3096-9210-56f9c15a2bd9@oracle.com> References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> <1695A59F-98AB-4821-9E20-AD3FE155EFAE@oracle.com> <3e44c6db-ba97-3096-9210-56f9c15a2bd9@oracle.com> Message-ID: <0828637b-8bc9-3520-1879-0eb13c72dc17@oracle.com> Hi David, On 11/16/2016 03:21 AM, David Holmes wrote: > Hi Zoltan, > > First, I'm okay with latest webrev. thank you. > > Second, I don't want to confuse things but need to correct one thing ... I think you rather clarified things. > > On 15/11/2016 10:41 PM, Zolt?n Maj? wrote: >> [...] >> >> For example, statement (2) can be possibly (mis-)read as the JVM making >> references unreachable *earlier* than what a programmer may think -- >> based on the source code.(That is clearly not the case: References are >> available at least until the latest program point where they are used, >> otherwise the program would encounter an error.) > > Actually it can make references unreachable earlier than may be > expected. The wording Mandy suggested comes from the JLS itself - see > 12.6.1. That is right -- thank you for pointing to the relevant section of the JLS. > (Though I agree it isn't the right disclaimer for the current > situation - where the interpreter keeps the reference reachable longer > than naively expected). Please see my reply to Mandy's email. Thank you! Best regards, Zoltan > > David > ----- > >> It's indeed a JVM "optimization" keep references alive *longer* than it >> seems to be from the source code. But (1) already encapsulates that >> without referring to JVM optimizations explicitly. >> >>> [...] >>> >>> >>> Making it clear ?strongly reachable? is a good suggestion. I don?t >>> see word-smithing is needed in the original sentence; hence my above >>> suggested change only adds the word ?strongly? in this sentence. >> >> I agree. >> >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~zmajo/8169000/webrev.02/ >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >>> >>> Mandy >> From sundararajan.athijegannathan at oracle.com Wed Nov 16 08:25:04 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 16 Nov 2016 13:55:04 +0530 Subject: RFR: JDK-8169505 - Update changes by JDK-8159393 to reflect CCC review In-Reply-To: References: Message-ID: +1 -Sundar On 11/15/2016 11:27 PM, Jim Laskey (Oracle) wrote: > http://cr.openjdk.java.net/~jlaskey/8169505/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8169505 > > From zoltan.majo at oracle.com Wed Nov 16 08:41:26 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 16 Nov 2016 09:41:26 +0100 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: <0D45991D-20E0-4835-9EFA-C3DCCBA24059@oracle.com> References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> <1695A59F-98AB-4821-9E20-AD3FE155EFAE@oracle.com> <0D45991D-20E0-4835-9EFA-C3DCCBA24059@oracle.com> Message-ID: Hi Mandy, On 11/16/2016 07:11 AM, Mandy Chung wrote: >> On Nov 15, 2016, at 4:41 AM, Zolt?n Maj? wrote: >> >> >> I think the sentence in webrev.01 >> >> (1) "If a registered referenceceases to be strongly reachable itself, then it may never be enqueued." >> >> is sufficient. I think we want to make a statement only about what happens when a reference ceases to be strongly reachable (i.e., that in that case we can't make a statement about that reference being enqueued or not). >> > When a reference becomes unreachable (not by examining the source code but the actual state of the VM at runtime), it will never be enqueued. I also like that wording, thank you! > >> The sentence you suggested >> >> (2) "A Java virtual machine may implement optimization that could affects when objects become unreachable." >> >> adds too much ambiguity as it leaves room for speculation about what "optimization" might be. >> >> For example, statement (2) can be possibly (mis-)read as the JVM making references unreachable *earlier* than what a programmer may think -- based on the source code.(That is clearly not the case: References are available at least until the latest program point where they are used, otherwise the program would encounter an error.) >> >> It's indeed a JVM "optimization" keep references alive *longer* than it seems to be from the source code. But (1) already encapsulates that without referring to JVM optimizations explicitly. > > That?s fair. > > What I?m looking for is something like this [1]: > > Reachability is not determined by the statements in your source code but by the actual state of the virtual machine at runtime. OK, I see now -- thank you for explaining. Here is a new webrev (webrev.03) that includes what you suggested: http://cr.openjdk.java.net/~zmajo/8169000/webrev.03/ We could go either with this webrev or with the previous one (webrev.02) that changes "will never be enqueued" to "may never be enqueued". http://cr.openjdk.java.net/~zmajo/8169000/webrev.02/ I'm not sure which webrev is the better option. Thank you! Best regards, Zoltan > Mandy > [1] The Java Programming Language, Fourth Edition, section 17.5.4 > From nadeesh.tv at oracle.com Wed Nov 16 09:08:10 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Wed, 16 Nov 2016 14:38:10 +0530 Subject: RFR: JDK-8167618: DateTimeFormatter.format() uses exceptions for flow control. In-Reply-To: References: <58137592.1000207@oracle.com> Message-ID: <582C21FA.5010004@oracle.com> Hi Roger &Stephen, Could I push the webrev? http://cr.openjdk.java.net/~ntv/others/anubhav/webrev.01/ Thanks and regards, Nadeesh On 11/7/2016 6:05 PM, Anubhav Meena wrote: > Thanks for the review! > > Here is the updated webrev > http://cr.openjdk.java.net/~ntv/others/anubhav/webrev.01/ > > > -Anubhav > > >> On Nov 2, 2016, at 4:04 PM, Stephen Colebourne > > wrote: >> >> I agree with Nadeesh, the updated code can still throw >> DateTimeException from the call to getLong(). Unlike before, this >> DateTimeException is desired. >> >> Stephen >> >> >> On 28 October 2016 at 16:58, nadeesh tv > > wrote: >>> >>> Hi Anubhav, >>> >>> >>> - * @throws DateTimeException if the field is not available and the >>> section is not optional >>> >>> >>> I think you should not remove the DTException since still there is a >>> chance >>> of throwing DTE >>> Regards, >>> Nadeesh >>> >>> On 10/28/2016 12:18 AM, Anubhav Meena wrote: >>>> >>>> Hi all, >>>> >>>> Please review. Please ignore last mail as links not working properly >>>> there. >>>> >>>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8167618 >>>> >>>> Issue: DateTimeFormatter.format() uses exceptions for flow control. >>>> Webrev: >>>> http://cr.openjdk.java.net/~rchamyal/anmeena/8167618/webrev.00/ >>>> >>>> >>> > >>> >>> >>> -- >>> Thanks and Regards, >>> Nadeesh TV >>> > -- Thanks and Regards, Nadeesh TV From forax at univ-mlv.fr Wed Nov 16 09:23:39 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 16 Nov 2016 10:23:39 +0100 (CET) Subject: JShell doesn't provide a ToolProvider Message-ID: <1273273610.1599970.1479288219573.JavaMail.zimbra@u-pem.fr> Hi all, hi Robert, currently, unlike javac or javadoc, there is no way to directly invoke jshell (JShellTool) because it lies in an internal package (which is a good idea). I think the module jdk.jshell should provide a java.util.spi.ToolProvider so i can embed jshell, like i can embed any dynmic langage runtimes, in my program instead of having to invoke it using the command line (without being able to control the exact version of jshell or even if jshell is present in case of a custom jdk image). regards, R?mi From patrick at reini.net Wed Nov 16 10:29:55 2016 From: patrick at reini.net (Patrick Reinhart) Date: Wed, 16 Nov 2016 11:29:55 +0100 Subject: JShell doesn't provide a ToolProvider In-Reply-To: <1273273610.1599970.1479288219573.JavaMail.zimbra@u-pem.fr> References: <1273273610.1599970.1479288219573.JavaMail.zimbra@u-pem.fr> Message-ID: <37214b2063c909eb4ebf4d79d2daf637@reini.net> Hi Remi, At the moment there is only the both outputs and the arguments. So there seems to be no way to actually interact with a ToolProvider using the "run" method. Since there is no way to interact, the benefit is not given this way or am I wrong here? -Patrick On 2016-11-16 10:23, Remi Forax wrote: > Hi all, hi Robert, > currently, unlike javac or javadoc, there is no way to directly invoke > jshell (JShellTool) because it lies in an internal package (which is a > good idea). > > I think the module jdk.jshell should provide a > java.util.spi.ToolProvider so i can embed jshell, like i can embed any > dynmic langage runtimes, in my program instead of having to invoke it > using the command line (without being able to control the exact > version of jshell or even if jshell is present in case of a custom jdk > image). > > regards, > R?mi From patrick at reini.net Wed Nov 16 10:37:05 2016 From: patrick at reini.net (Patrick Reinhart) Date: Wed, 16 Nov 2016 11:37:05 +0100 Subject: Request to review: JDK-8169659 (JDK-8168836 seems the wrong id) In-Reply-To: <6B83B1C5-7DD6-4E7F-8294-9EF86F911564@oracle.com> References: <9fe0967b42b37fa3d79f0d77bf9cbc11@reini.net> <591746A1-6EF0-4FBD-B099-DF8B5996432D@reini.net> <6B83B1C5-7DD6-4E7F-8294-9EF86F911564@oracle.com> Message-ID: <7f23b5f28ab43a2c93fcd6037deaf7af@reini.net> Hi Mandy, It seem so me I made the webrev using the wrong issue, here is the correct URL including the changes that you have suggested http://cr.openjdk.java.net/~reinhapa/reviews/8169659/webrev.00 Sorry, for the confusion... -Patrick On 2016-11-15 00:20, Mandy Chung wrote: >> On Nov 14, 2016, at 1:22 PM, Patrick Reinhart >> wrote: >> >> Ups, previous mail contained wrong URL. Here?s the correct one: >> >> http://cr.openjdk.java.net/~reinhapa/reviews/8168836/webrev.00 > > 879 > log.println(getMessage("err.missing.dependences")); > > This should call reportError method that will prepend with > ?error.prefix?. So no need to have ?ERROR:? in > ?err.missing.dependences? message. > > Formatting Nit: line 541-542 and line 753-754 align to the first > parameter of the method. > > Otherwise looks good. I can sponsor it. > > Mandy From forax at univ-mlv.fr Wed Nov 16 11:06:36 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 16 Nov 2016 12:06:36 +0100 (CET) Subject: JShell doesn't provide a ToolProvider In-Reply-To: <37214b2063c909eb4ebf4d79d2daf637@reini.net> References: <1273273610.1599970.1479288219573.JavaMail.zimbra@u-pem.fr> <37214b2063c909eb4ebf4d79d2daf637@reini.net> Message-ID: <1890986526.1745459.1479294396979.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Patrick Reinhart" > ?: "Remi Forax" > Cc: "core-libs-dev" > Envoy?: Mercredi 16 Novembre 2016 11:29:55 > Objet: Re: JShell doesn't provide a ToolProvider > Hi Remi, > > At the moment there is only the both outputs and the arguments. So there > seems to be no way to actually interact with a ToolProvider using the > "run" method. Since there is no way to interact, the benefit is not > given this way or am I wrong here? > > -Patrick Hi Patrick, good question ! The Tool provider interface provide a non-interactive interface, so it's equivalent to calling jshell with some scripts as arguments and not with interacting with jshell on the console. So the input scripts are provided in the argument. R?mi > > > On 2016-11-16 10:23, Remi Forax wrote: >> Hi all, hi Robert, >> currently, unlike javac or javadoc, there is no way to directly invoke >> jshell (JShellTool) because it lies in an internal package (which is a >> good idea). >> >> I think the module jdk.jshell should provide a >> java.util.spi.ToolProvider so i can embed jshell, like i can embed any >> dynmic langage runtimes, in my program instead of having to invoke it >> using the command line (without being able to control the exact >> version of jshell or even if jshell is present in case of a custom jdk >> image). >> >> regards, > > R?mi From Alan.Bateman at oracle.com Wed Nov 16 11:29:42 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Nov 2016 11:29:42 +0000 Subject: JShell doesn't provide a ToolProvider In-Reply-To: <1273273610.1599970.1479288219573.JavaMail.zimbra@u-pem.fr> References: <1273273610.1599970.1479288219573.JavaMail.zimbra@u-pem.fr> Message-ID: On 16/11/2016 09:23, Remi Forax wrote: > Hi all, hi Robert, > currently, unlike javac or javadoc, there is no way to directly invoke jshell (JShellTool) because it lies in an internal package (which is a good idea). > > I think the module jdk.jshell should provide a java.util.spi.ToolProvider so i can embed jshell, like i can embed any dynmic langage runtimes, in my program instead of having to invoke it using the command line (without being able to control the exact version of jshell or even if jshell is present in case of a custom jdk image). > This was discussed as part of introducing the SPI [1], you'll see the mails from Robert where he points out that this doesn't fit. -Alan [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2016-October/010379.html From scolebourne at joda.org Wed Nov 16 12:29:46 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 16 Nov 2016 12:29:46 +0000 Subject: RFR: JDK-8167618: DateTimeFormatter.format() uses exceptions for flow control. In-Reply-To: <582C21FA.5010004@oracle.com> References: <58137592.1000207@oracle.com> <582C21FA.5010004@oracle.com> Message-ID: Yes. Stephen On 16 November 2016 at 09:08, nadeesh tv wrote: > Hi Roger &Stephen, > > Could I push the webrev? > > http://cr.openjdk.java.net/~ntv/others/anubhav/webrev.01/ > > Thanks and regards, > Nadeesh > > > On 11/7/2016 6:05 PM, Anubhav Meena wrote: > > Thanks for the review! > > Here is the updated webrev > http://cr.openjdk.java.net/~ntv/others/anubhav/webrev.01/ > > -Anubhav > > > On Nov 2, 2016, at 4:04 PM, Stephen Colebourne wrote: > > I agree with Nadeesh, the updated code can still throw > DateTimeException from the call to getLong(). Unlike before, this > DateTimeException is desired. > > Stephen > > > On 28 October 2016 at 16:58, nadeesh tv wrote: > > > Hi Anubhav, > > > - * @throws DateTimeException if the field is not available and the > section is not optional > > > I think you should not remove the DTException since still there is a chance > of throwing DTE > Regards, > Nadeesh > > On 10/28/2016 12:18 AM, Anubhav Meena wrote: > > > Hi all, > > Please review. Please ignore last mail as links not working properly > there. > > Bug Id : https://bugs.openjdk.java.net/browse/JDK-8167618 > > Issue: DateTimeFormatter.format() uses exceptions for flow control. > Webrev: http://cr.openjdk.java.net/~rchamyal/anmeena/8167618/webrev.00/ > > > > > -- > Thanks and Regards, > Nadeesh TV > > > > -- > Thanks and Regards, > Nadeesh TV > From christoph.langer at sap.com Wed Nov 16 13:41:02 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 16 Nov 2016 13:41:02 +0000 Subject: RFR: 8023653: xalan inconsistently parses DOMSource and StreamSource Message-ID: Hi, to address the long standing bug 8023653 I propose the following change: webrev: http://cr.openjdk.java.net/~clanger/webrevs/8023653.0/ bug: https://bugs.openjdk.java.net/browse/JDK-8023653 I think the bug report in general complains that the default for DOMSource input is to parse the input "namespace-unaware" whereas, if XALAN gets a StreamSource as input, it is parsed "namespace-aware". Generally I'm against changing either of these defaults (at this time at least) - XALAN StreamSource should be handled namespace aware and changing the default for DocumentBuilderFactory is maybe an option for the Java 10 timeframe, I'd say. However, at the moment it is not possible at all to configure XALAN's handling of StreamSource input to be namespace unaware. That's what I'd like to address with my change. With my modifications it's possible to set the namespace feature on the TransformerFactory (to false). It bases on my other open fix 8169631 which is discussed here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044662.html Only with the corrections for that fix, the SAX parsing that is used for stream sources will be handled correctly. The proposed change from the bugreport (change options for the parser of the XSL input before compilation) would not help with the reported issue and also is not a good idea anyway as xsl input needs to be handled with namespaces obviously. I did other cleanups in my change as well, the real functional changes are in TransformerFactoryImpl.java, XSLTCDTMManager.java and XMLReaderManager.java. Thanks in advance for reviewing. Best regards Christoph From christoph.langer at sap.com Wed Nov 16 14:22:39 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 16 Nov 2016 14:22:39 +0000 Subject: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE Message-ID: Hi, please review another XALAN fix. The Serializer should be able to handle text nodes with null input. There has already been some discussion here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044567.html Bug: https://bugs.openjdk.java.net/browse/JDK-8169772 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169772.0/ The actual fix is in ToUnknownStream.java, method "public void characters(String chars) throws SAXException". I don't know if one should even directly return after chars being null or of size() 0. The rest of this change is cleanups and a test case. Thanks for reviewing. Best regards Christoph From james.laskey at oracle.com Wed Nov 16 15:00:52 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 16 Nov 2016 11:00:52 -0400 Subject: RFR: JDK-8168256 - Plugin alias options in jlink --help output seems to be in an arbitrary order Message-ID: Sorts options by full name http://cr.openjdk.java.net/~jlaskey/8168256/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8168256 From martinrb at google.com Wed Nov 16 15:13:43 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 16 Nov 2016 07:13:43 -0800 Subject: 8072784: Better spliterator implementation for BitSet.stream() In-Reply-To: <5A8FDC39-5B4C-4A77-AE67-51013284942A@oracle.com> References: <5A8FDC39-5B4C-4A77-AE67-51013284942A@oracle.com> Message-ID: I've been looking, but all I got is: s/passed/past/ From martinrb at google.com Wed Nov 16 15:21:57 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 16 Nov 2016 07:21:57 -0800 Subject: 8072784: Better spliterator implementation for BitSet.stream() In-Reply-To: References: <5A8FDC39-5B4C-4A77-AE67-51013284942A@oracle.com> Message-ID: should the spec say that the spliterator is late binding? On Wed, Nov 16, 2016 at 7:13 AM, Martin Buchholz wrote: > I've been looking, but all I got is: > s/passed/past/ > From daniel.fuchs at oracle.com Wed Nov 16 15:24:53 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 16 Nov 2016 15:24:53 +0000 Subject: [JAXP] RFR: 8169778: Add new public methods to get new instances of the JAXP factories builtin system-default implementations Message-ID: <33d048b8-9aea-bc92-8478-0bebc7c2d8b6@oracle.com> Hi, Please find below a patch for: 8169778: Add new public methods to get new instances of the JAXP factories builtin system-default implementations bug: https://bugs.openjdk.java.net/browse/JDK-8169778 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8169778/webrev.00/ best regards, -- daniel From Roger.Riggs at Oracle.com Wed Nov 16 16:03:55 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 16 Nov 2016 11:03:55 -0500 Subject: [JAXP] RFR: 8169778: Add new public methods to get new instances of the JAXP factories builtin system-default implementations In-Reply-To: <33d048b8-9aea-bc92-8478-0bebc7c2d8b6@oracle.com> References: <33d048b8-9aea-bc92-8478-0bebc7c2d8b6@oracle.com> Message-ID: Hi Daniel, DocumentBuilderFactory and classes: - The new methods uses "Creates" instead of "Obtain"; perhaps it should be consistent with existing newInstance methods? - "Otherwise," and "Otherwise" (with and without ",") are not consistent in the webrev. XMLInputFactory.java: -line 212: the "system-default" should be inside the braces with the @link. SchemaFactory.java: - line 201: (pre-existing typo) "in a implementation" -> "in an implementation" XPathFactory.java - line 177: The {@linkplain platform...} doesn't look like a properly formed link. XMLOutputFactoryNewInstanceTest - line 2, has a 1999 date but is a new file. Many of the files have long lines (some new) that make side-by-side compares not fit on the screen. Regards, Roger On 11/16/2016 10:24 AM, Daniel Fuchs wrote: > Hi, > > Please find below a patch for: > 8169778: Add new public methods to get new instances of the > JAXP factories builtin system-default implementations > > bug: https://bugs.openjdk.java.net/browse/JDK-8169778 > webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8169778/webrev.00/ > > best regards, > > -- daniel From peter.levart at gmail.com Wed Nov 16 16:09:39 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 16 Nov 2016 17:09:39 +0100 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> <1695A59F-98AB-4821-9E20-AD3FE155EFAE@oracle.com> <0D45991D-20E0-4835-9EFA-C3DCCBA24059@oracle.com> Message-ID: <9a81608c-0973-a421-7bc6-830df99fd960@gmail.com> Hi Zoltan, Mandy, On 11/16/2016 09:41 AM, Zolt?n Maj? wrote: > Hi Mandy, > > > On 11/16/2016 07:11 AM, Mandy Chung wrote: >>> On Nov 15, 2016, at 4:41 AM, Zolt?n Maj? >>> wrote: >>> >>> >>> I think the sentence in webrev.01 >>> >>> (1) "If a registered referenceceases to be strongly reachable >>> itself, then it may never be enqueued." >>> >>> is sufficient. I think we want to make a statement only about what >>> happens when a reference ceases to be strongly reachable (i.e., that >>> in that case we can't make a statement about that reference being >>> enqueued or not). >>> >> When a reference becomes unreachable (not by examining the source >> code but the actual state of the VM at runtime), it will never be >> enqueued. > > I also like that wording, thank you! > >> >>> The sentence you suggested >>> >>> (2) "A Java virtual machine may implement optimization that could >>> affects when objects become unreachable." >>> >>> adds too much ambiguity as it leaves room for speculation about what >>> "optimization" might be. >>> >>> For example, statement (2) can be possibly (mis-)read as the JVM >>> making references unreachable *earlier* than what a programmer may >>> think -- based on the source code.(That is clearly not the case: >>> References are available at least until the latest program point >>> where they are used, otherwise the program would encounter an error.) >>> >>> It's indeed a JVM "optimization" keep references alive *longer* than >>> it seems to be from the source code. But (1) already encapsulates >>> that without referring to JVM optimizations explicitly. >> >> That?s fair. >> >> What I?m looking for is something like this [1]: >> >> Reachability is not determined by the statements in your source code >> but by the actual state of the virtual machine at runtime. > > OK, I see now -- thank you for explaining. > > Here is a new webrev (webrev.03) that includes what you suggested: > > http://cr.openjdk.java.net/~zmajo/8169000/webrev.03/ "If a registered reference ceases to be strongly reachable itself (not by examining the source code but by looking at the actual state of the VM at runtime), it will never be enqueued." I think this is wrong wording. A Reference object may cease to be strongly reachable for some time (even by looking at the actual state of the VM at runtime) and then regain strong reachability and then be enqueued. If during the period that a Reference object is not strongly reachable (even by looking at the actual state of the VM at runtime), GC is not run, the Reference object will not be discovered as not being strongly reachable and VM will not clear any Soft or Weak references having the Reference object as a referent and consequently the program will be able to regain strong reachability to it. > > We could go either with this webrev or with the previous one > (webrev.02) that changes "will never be enqueued" to "may never be > enqueued". > > http://cr.openjdk.java.net/~zmajo/8169000/webrev.02/ > > I'm not sure which webrev is the better option. "If a registered reference ceases to be strongly reachable itself, then it may never be enqueued." I think this is a better wording. We can even (but not need to) say the following: "If a registered reference ceases to be strongly reachable itself by examining the source code, then it may never be enqueued." ...and the statement will still be correct. By: "an object ceases to be strongly reachable by examining the source code", I mean: "the earliest point possible in program where no reference variable through which the object can be reached directly or indirectly (not traversing any Reference's referent) can be dereferenced any more". For example: void m() { ... Object o = new Object(); // <- this is the earliest point in program where the sole variable 'o' through which the Object could be reached, can't be dereferenced any more. ... ... ... // ... (there's no mentioning of 'o' in the rest of the method) } Regards, Peter > > Thank you! > > Best regards, > > > Zoltan > >> Mandy >> [1] The Java Programming Language, Fourth Edition, section 17.5.4 >> > From peter.levart at gmail.com Wed Nov 16 16:37:33 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 16 Nov 2016 17:37:33 +0100 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: <9a81608c-0973-a421-7bc6-830df99fd960@gmail.com> References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> <1695A59F-98AB-4821-9E20-AD3FE155EFAE@oracle.com> <0D45991D-20E0-4835-9EFA-C3DCCBA24059@oracle.com> <9a81608c-0973-a421-7bc6-830df99fd960@gmail.com> Message-ID: Hi, On 11/16/2016 05:09 PM, Peter Levart wrote: >> >> http://cr.openjdk.java.net/~zmajo/8169000/webrev.03/ > > "If a registered reference ceases to be strongly reachable itself (not > by examining the source code but by looking at the actual state of the > VM at runtime), it will never be enqueued." > > I think this is wrong wording. A Reference object may cease to be > strongly reachable for some time (even by looking at the actual state > of the VM at runtime) and then regain strong reachability and then be > enqueued. If during the period that a Reference object is not strongly > reachable (even by looking at the actual state of the VM at runtime), > GC is not run, the Reference object will not be discovered as not > being strongly reachable and VM will not clear any Soft or Weak > references having the Reference object as a referent and consequently > the program will be able to regain strong reachability to it. A counter example: A Reference object may cease to be strongly reachable by becoming softly reachable. The JVM may even discover it to be softly reachable (looking at the actual state of the VM at runtime), but by policy, VM may also see that is has not been softly reachable long enough and so it will not clear the SoftReference but instead rather enqueue the SoftReference's referent (our PhantomReference object): public class SoftlyReachablePhantomReference { static ReferenceQueue rq = new ReferenceQueue<>(); static Reference> refRef; public static void main(final String[] args) throws Exception { refRef = new SoftReference<>( new PhantomReference<>( new Object(), rq ) ); // <- here System.gc(); Reference rmRef = rq.remove(1000); if (rmRef == null) { System.out.println("PhantomReference NOT enqueued"); } else { System.out.println("PhantomReference enqueued"); } } } Running with -Xcomp, the above program will print: "PhantomReference enqueued". By just swapping SoftRererence with WeakReference: public class WeaklyReachablePhantomReference { static ReferenceQueue rq = new ReferenceQueue<>(); static Reference> refRef; public static void main(final String[] args) throws Exception { refRef = new WeakReference<>( new PhantomReference<>( new Object(), rq ) ); // <- here System.gc(); Reference rmRef = rq.remove(1000); if (rmRef == null) { System.out.println("PhantomReference NOT enqueued"); } else { System.out.println("PhantomReference enqueued"); } } } ...the program will print: "PhantomReference NOT enqueued". This is all expected and by the spec. Peter From chris.hegarty at oracle.com Wed Nov 16 17:01:12 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 16 Nov 2016 17:01:12 +0000 Subject: RFR of JDK-8168975: java/rmi/activation/Activatable tests fail due to "Port already in use" in RMID.restart() In-Reply-To: <68995a74-8e19-9462-1ff3-cd32a3a40441@oracle.com> References: <68995a74-8e19-9462-1ff3-cd32a3a40441@oracle.com> Message-ID: <5E268B7B-5C74-456F-BCCC-4CB0670C5E30@oracle.com> > On 16 Nov 2016, at 07:36, Hamlin Li wrote: > > Would you please review below fix? > > bug: https://bugs.openjdk.java.net/browse/JDK-8168975 > webrev: http://cr.openjdk.java.net/~mli/8168975/webrev.00/ The approach builds on the mechanism put in for 8168975, and seems reasonable. The system property being used to ?pass? the port number is specific to the test, and not JDK related so should not be named java.nio.channels.spi.SelectorProviderPort. Maybe something like openjdk.test.RMIDSelectorProvider.port ? -Chris. > Root Cause: There is a time window between RMID.start() and RMID.restart(), interloper can step in and bind to the port used by RMID in RMID.start(). > > Solution: Modify RMID.java to use inherited channel when calling RMID.restart. And extend RMIDSelectorProvider.java to try to bind to specific port, no matter 0 or none-zero(for RMID.restart) in a while loop, if timeout just call System.exit to exit rmid and let test fail. > > > Thank you > -Hamlin From huizhe.wang at oracle.com Wed Nov 16 17:18:49 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 16 Nov 2016 09:18:49 -0800 Subject: [JAXP] RFR: 8169778: Add new public methods to get new instances of the JAXP factories builtin system-default implementations In-Reply-To: References: <33d048b8-9aea-bc92-8478-0bebc7c2d8b6@oracle.com> Message-ID: <582C94F9.9000801@oracle.com> On 11/16/16, 8:03 AM, Roger Riggs wrote: > Hi Daniel, > > DocumentBuilderFactory and classes: > - The new methods uses "Creates" instead of "Obtain"; > perhaps it should be consistent with existing newInstance methods? "Obtain" was used in the early version of JAXP, and "Creates" in newer StAX factories. I used "Creates" as an example to explain the norm of writing Javadoc (the description is in 3rd person). If we want the consistency, we could do "Obtains" in the JAXP factories and "Creates" in StAX, alternatively, we could change all of them. Regards, Joe > > - "Otherwise," and "Otherwise" (with and without ",") are not > consistent in the webrev. > > > XMLInputFactory.java: > -line 212: the "system-default" should be inside the braces with the > @link. > > SchemaFactory.java: > - line 201: (pre-existing typo) "in a implementation" -> "in an > implementation" > > XPathFactory.java > - line 177: The {@linkplain platform...} doesn't look like a properly > formed link. > > > XMLOutputFactoryNewInstanceTest > - line 2, has a 1999 date but is a new file. > > Many of the files have long lines (some new) that make side-by-side > compares not fit on the screen. > > Regards, Roger > > > > > On 11/16/2016 10:24 AM, Daniel Fuchs wrote: >> Hi, >> >> Please find below a patch for: >> 8169778: Add new public methods to get new instances of the >> JAXP factories builtin system-default implementations >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8169778 >> webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8169778/webrev.00/ >> >> best regards, >> >> -- daniel > From lance.andersen at oracle.com Wed Nov 16 17:23:58 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 16 Nov 2016 12:23:58 -0500 Subject: [JAXP] RFR: 8169778: Add new public methods to get new instances of the JAXP factories builtin system-default implementations In-Reply-To: <582C94F9.9000801@oracle.com> References: <33d048b8-9aea-bc92-8478-0bebc7c2d8b6@oracle.com> <582C94F9.9000801@oracle.com> Message-ID: <980FD604-CCDC-484C-BFCA-A8268AFDC2FA@oracle.com> > On Nov 16, 2016, at 12:18 PM, Joe Wang wrote: > > > > On 11/16/16, 8:03 AM, Roger Riggs wrote: >> Hi Daniel, >> >> DocumentBuilderFactory and classes: >> - The new methods uses "Creates" instead of "Obtain"; >> perhaps it should be consistent with existing newInstance methods? > > "Obtain" was used in the early version of JAXP, and "Creates" in newer StAX factories. I used "Creates" as an example to explain the norm of writing Javadoc (the description is in 3rd person). If we want the consistency, we could do "Obtains" in the JAXP factories and "Creates" in StAX, alternatively, we could change all of them. I would work towards consistency throughout. Personally I prefer ?Creates? over ?Obtains? > > Regards, > Joe > >> >> - "Otherwise," and "Otherwise" (with and without ",") are not consistent in the webrev. >> >> >> XMLInputFactory.java: >> -line 212: the "system-default" should be inside the braces with the @link. >> >> SchemaFactory.java: >> - line 201: (pre-existing typo) "in a implementation" -> "in an implementation" >> >> XPathFactory.java >> - line 177: The {@linkplain platform...} doesn't look like a properly formed link. >> >> >> XMLOutputFactoryNewInstanceTest >> - line 2, has a 1999 date but is a new file. >> >> Many of the files have long lines (some new) that make side-by-side compares not fit on the screen. >> >> Regards, Roger >> >> >> >> >> On 11/16/2016 10:24 AM, Daniel Fuchs wrote: >>> Hi, >>> >>> Please find below a patch for: >>> 8169778: Add new public methods to get new instances of the >>> JAXP factories builtin system-default implementations >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8169778 >>> webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8169778/webrev.00/ >>> >>> best regards, >>> >>> -- daniel >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Wed Nov 16 17:26:41 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Nov 2016 09:26:41 -0800 Subject: Request to review: JDK-8169659 (JDK-8168836 seems the wrong id) In-Reply-To: <7f23b5f28ab43a2c93fcd6037deaf7af@reini.net> References: <9fe0967b42b37fa3d79f0d77bf9cbc11@reini.net> <591746A1-6EF0-4FBD-B099-DF8B5996432D@reini.net> <6B83B1C5-7DD6-4E7F-8294-9EF86F911564@oracle.com> <7f23b5f28ab43a2c93fcd6037deaf7af@reini.net> Message-ID: <6D68E55C-B83A-4678-965B-11459BDC927F@oracle.com> +1 I will sponsor it. Mandy > On Nov 16, 2016, at 2:37 AM, Patrick Reinhart wrote: > > Hi Mandy, > > It seem so me I made the webrev using the wrong issue, here is the correct URL including the changes that you have suggested > > http://cr.openjdk.java.net/~reinhapa/reviews/8169659/webrev.00 > > Sorry, for the confusion... > > -Patrick > > > On 2016-11-15 00:20, Mandy Chung wrote: >>> On Nov 14, 2016, at 1:22 PM, Patrick Reinhart wrote: >>> Ups, previous mail contained wrong URL. Here?s the correct one: >>> http://cr.openjdk.java.net/~reinhapa/reviews/8168836/webrev.00 >> 879 log.println(getMessage("err.missing.dependences")); >> This should call reportError method that will prepend with >> ?error.prefix?. So no need to have ?ERROR:? in >> ?err.missing.dependences? message. >> Formatting Nit: line 541-542 and line 753-754 align to the first >> parameter of the method. >> Otherwise looks good. I can sponsor it. >> Mandy From daniel.fuchs at oracle.com Wed Nov 16 17:35:29 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 16 Nov 2016 17:35:29 +0000 Subject: [JAXP] RFR: 8169778: Add new public methods to get new instances of the JAXP factories builtin system-default implementations In-Reply-To: References: <33d048b8-9aea-bc92-8478-0bebc7c2d8b6@oracle.com> Message-ID: Thanks Roger, On 16/11/16 16:03, Roger Riggs wrote: > Hi Daniel, > > DocumentBuilderFactory and classes: > - The new methods uses "Creates" instead of "Obtain"; > perhaps it should be consistent with existing newInstance methods? I had some pre-review advice from Joe (Wang) about who suggested using the 3rd person (Obtains) rather than the imperative (Obtain). Also I noticed that some factories use Get, some Obtain, some Create... Because this is a new method - that doesn't use any lookup mechanism, and I wanted that there be no ambiguity that a new instance will be returned with each invocation - I thought it might be better to use "Creates" in all new methods - regardless of what other verb the other method use - so for this feature, stay consistent across factories instead of being consistent within the factory. I can revert that if there's a general feeling that staying consistent with the other methods in the same file is preferable. > - "Otherwise," and "Otherwise" (with and without ",") are not > consistent in the webrev. Right - I will add the coma where it's missing. "Otherwise, " seems to be more widely used. > XMLInputFactory.java: > -line 212: the "system-default" should be inside the braces with the > @link. Good catch! > SchemaFactory.java: > - line 201: (pre-existing typo) "in a implementation" -> "in an > implementation" OK. > > XPathFactory.java > - line 177: The {@linkplain platform...} doesn't look like a properly > formed link. Good catch again. How did I miss that? > XMLOutputFactoryNewInstanceTest > - line 2, has a 1999 date but is a new file. Right. It's surprising that this file did not exits. I copied XMLInputFactoryNewInstanceTest and subtituted Input for Output... > Many of the files have long lines (some new) that make side-by-side > compares not fit on the screen. I will crop the new and changed lines - but I don't want to fix more as it would dilute the meaningful changes in noise. Here is a new webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8169778/webrev.01/index.html -- daniel > > Regards, Roger > > > > > On 11/16/2016 10:24 AM, Daniel Fuchs wrote: >> Hi, >> >> Please find below a patch for: >> 8169778: Add new public methods to get new instances of the >> JAXP factories builtin system-default implementations >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8169778 >> webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8169778/webrev.00/ >> >> best regards, >> >> -- daniel > From joe.darcy at oracle.com Wed Nov 16 18:30:14 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 16 Nov 2016 10:30:14 -0800 Subject: RFR of JDK-8168975: java/rmi/activation/Activatable tests fail due to "Port already in use" in RMID.restart() In-Reply-To: <5E268B7B-5C74-456F-BCCC-4CB0670C5E30@oracle.com> References: <68995a74-8e19-9462-1ff3-cd32a3a40441@oracle.com> <5E268B7B-5C74-456F-BCCC-4CB0670C5E30@oracle.com> Message-ID: <12b34d35-d7de-6268-771f-1c0ac6f883fa@oracle.com> In terms of timeout, please use much shorter timeout, seconds not minutes. Most JDK regression tests complete in well under 10 seconds and few tests should run for as long as a minute. Also, please scale any timeout if a timeout factor retrieved from the jtreg environment. This allows the test to behave better on heavily loaded or slow machines where the test invoker has requested more time. Thanks, -Joe On 11/16/2016 9:01 AM, Chris Hegarty wrote: >> On 16 Nov 2016, at 07:36, Hamlin Li wrote: >> >> Would you please review below fix? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8168975 >> webrev: http://cr.openjdk.java.net/~mli/8168975/webrev.00/ > The approach builds on the mechanism put in for 8168975, and seems > reasonable. > > The system property being used to ?pass? the port number is specific to > the test, and not JDK related so should not be named > java.nio.channels.spi.SelectorProviderPort. Maybe something like > openjdk.test.RMIDSelectorProvider.port ? > > -Chris. > >> Root Cause: There is a time window between RMID.start() and RMID.restart(), interloper can step in and bind to the port used by RMID in RMID.start(). >> >> Solution: Modify RMID.java to use inherited channel when calling RMID.restart. And extend RMIDSelectorProvider.java to try to bind to specific port, no matter 0 or none-zero(for RMID.restart) in a while loop, if timeout just call System.exit to exit rmid and let test fail. >> >> >> Thank you >> -Hamlin From paul.sandoz at oracle.com Wed Nov 16 19:28:35 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Nov 2016 11:28:35 -0800 Subject: 8072784: Better spliterator implementation for BitSet.stream() In-Reply-To: References: <5A8FDC39-5B4C-4A77-AE67-51013284942A@oracle.com> Message-ID: <4D5852D8-4C66-46DA-A0F0-AFB723C7A14C@oracle.com> > On 16 Nov 2016, at 07:21, Martin Buchholz wrote: > > should the spec say that the spliterator is late binding? > I logged this issue: https://bugs.openjdk.java.net/browse/JDK-8169808 We sold also consider CharSequence as well (and there might be other cases). > On Wed, Nov 16, 2016 at 7:13 AM, Martin Buchholz > wrote: > I've been looking, but all I got is: > s/passed/past/ > Thanks, updated. Paul. From martinrb at google.com Wed Nov 16 20:14:41 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 16 Nov 2016 12:14:41 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: References: <8cc0d5a9-9245-e6b1-0ff2-616127dbc583@oracle.com> Message-ID: Thanks to Vitaly and Doug for being more concerned about offer/poll performance than I was initially. ArrayDeque is now back to using the head + tail + spare slot strategy, which keeps optimal performance for non-bulk operations, while everything else gets faster. We have new tests and new benchmarks, as a result of which new bugs were found and fixed, and this integration wave has grown rather larger than originally intended. The JIT-friendly nested loop strategy was successful for making bulk operations on circular arrays faster, and this is used for both ArrayDeque and ArrayBlockingQueue. + /* + * VMs excel at optimizing simple array loops where indices are + * incrementing or decrementing over a valid slice, e.g. + * + * for (int i = start; i < end; i++) ... elements[i] + * + * Because in a circular array, elements are in general stored in + * two disjoint such slices, we help the VM by writing unusual + * nested loops for all traversals over the elements. + */ Bulk removal operations on array-based collections retreat to a two-pass algorithm, which is slightly slower (but still O(n)), but continues to support (questionable) predicates that reentrantly access the collection in read mode. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ On Fri, Oct 21, 2016 at 12:32 PM, Martin Buchholz wrote: > > > On Tue, Oct 18, 2016 at 4:18 PM, Martin Buchholz > wrote: > >> >> >> On Tue, Oct 18, 2016 at 4:00 PM, Vitaly Davidovich >> wrote: >> >>> >>>> > * Change in allocation/capacity policy. >>>> > >>>> > The removal of the power-of-two restriction, and applying a 1.5x >>>> growth >>>> > factor (same as ArrayList) seems sensible. Does this mean that the >>>> ability >>>> > to compute the proper array index by using x & (length-1) wasn't >>>> worth it? >>>> > Or at least not worth the extra tail wastage? >>>> > >>>> >>>> There's no integer division to optimize, as with hash tables. >>> >>> But it does add some new branches, doesn't it? Potentially branches that >>> aren't taken prior to JIT compilation, but taken later = deopt. >>> >> >> If it's a smidgeon slower, I don't care that much; improvement in >> flexibility and scalability are more important. >> >> Of course, I do care about algorithmic improvements to e.g. removeIf >> >> >>> Curious if you ran some benchmarks on ArrayDeque. >>> >> >> Not yet. Who would like to show how slow the code is? >> > > I revived my ancient IteratorMicroBenchmark for the latest webrev, made it > a proper jtreg test, added ArrayDeque Jobs, and verified that the new code > is measurably faster than the old code, at least for the mundane job of > iterating. > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ > jsr166-jdk9-integration/ArrayList/ > > From martinrb at google.com Wed Nov 16 20:22:12 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 16 Nov 2016 12:22:12 -0800 Subject: RFR 8132097: Stream.generate should use a covariant Supplier as parameter In-Reply-To: <253C6046-0340-4B06-8F58-3407DB0D7E28@oracle.com> References: <253C6046-0340-4B06-8F58-3407DB0D7E28@oracle.com> Message-ID: Looks good to me! On Tue, Nov 8, 2016 at 4:43 PM, Paul Sandoz wrote: > Hi > > Please review this compatible fix to Stream.generate to accept a covariant > Supplier. > > Paul. > > diff -r 3e3ca9800322 src/java.base/share/classes/ > java/util/stream/Stream.java > --- a/src/java.base/share/classes/java/util/stream/Stream.java Tue Nov > 08 15:37:20 2016 -0800 > +++ b/src/java.base/share/classes/java/util/stream/Stream.java Tue Nov > 08 16:36:51 2016 -0800 > @@ -1327,7 +1327,7 @@ > * @param s the {@code Supplier} of generated elements > * @return a new infinite sequential unordered {@code Stream} > */ > - public static Stream generate(Supplier s) { > + public static Stream generate(Supplier s) { > Objects.requireNonNull(s); > return StreamSupport.stream( > new StreamSpliterators.InfiniteSupplyingSpliterator.OfRef<>(Long.MAX_VALUE, > s), false); > diff -r 3e3ca9800322 src/java.base/share/classes/java/util/stream/ > StreamSpliterators.java > --- a/src/java.base/share/classes/java/util/stream/StreamSpliterators.java > Tue Nov 08 15:37:20 2016 -0800 > +++ b/src/java.base/share/classes/java/util/stream/StreamSpliterators.java > Tue Nov 08 16:36:51 2016 -0800 > @@ -1346,9 +1346,9 @@ > } > > static final class OfRef extends InfiniteSupplyingSpliterator > { > - final Supplier s; > + final Supplier s; > > - OfRef(long size, Supplier s) { > + OfRef(long size, Supplier s) { > super(size); > this.s = s; > } > From david.dehaven at oracle.com Wed Nov 16 20:30:24 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 16 Nov 2016 12:30:24 -0800 Subject: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method In-Reply-To: <278A54B1-D254-4DC3-A8BE-4F0FF296E23F@oracle.com> References: <3160154D-73F2-430C-A943-E75CC9FF4C08@oracle.com> <254E040E-2D2D-4325-A1EA-59FA12995EFE@oracle.com> <3B9F04BD-CF03-4FF2-9BD7-E35F6CB4AB1E@oracle.com> <2AD15EB5-255D-455C-A8CC-BD9B11D9D2D8@oracle.com> <1D40C5B1-712A-4CA1-9B19-0C1E407876EB@oracle.com> <278A54B1-D254-4DC3-A8BE-4F0FF296E23F@oracle.com> Message-ID: <86DC9AA1-016B-4899-9111-A7FE2802A972@oracle.com> >>>>>> Please review the (fairly straightforward) JDK changes needed to support launching JavaFX applications in a named module. >>>>>> >>>>>> JBS: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8169289 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/ >>>>>> >>>>>> >>>>> >>>>> Would it be better to refactor line 557-563 and 612-624 and be called in the checkAndLoadMain method after the main class is loaded? >>>> >>>> Yeah, we probably could do that. I'll look into it. >>> >>> Updated with your suggested change: >>> http://cr.openjdk.java.net/~ddehaven/8169289/jdk.1 >> >> Looks fine. I wonder what appClass is intended for and whether it should be set in line 483 instead. >> >> 554 appClass = c; >> >> 600 // record the main class >> 601 appClass = mainClass; >> >> Kumar would know the history. > > It was added as part of the original work to support launching FX applications in JDK 8, it's primarily for error reporting so it reports the correct main class instead of FXHelper. > > You are correct in that it should have been moved too.. I'll update that when I get back. Round 3: http://cr.openjdk.java.net/~ddehaven/8169289/jdk.2 Tested with a jar that had a bad JavaFX-Application-Class and it continued to report the correct class name. -DrD- From mandy.chung at oracle.com Wed Nov 16 20:48:17 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Nov 2016 12:48:17 -0800 Subject: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method In-Reply-To: <86DC9AA1-016B-4899-9111-A7FE2802A972@oracle.com> References: <3160154D-73F2-430C-A943-E75CC9FF4C08@oracle.com> <254E040E-2D2D-4325-A1EA-59FA12995EFE@oracle.com> <3B9F04BD-CF03-4FF2-9BD7-E35F6CB4AB1E@oracle.com> <2AD15EB5-255D-455C-A8CC-BD9B11D9D2D8@oracle.com> <1D40C5B1-712A-4CA1-9B19-0C1E407876EB@oracle.com> <278A54B1-D254-4DC3-A8BE-4F0FF296E23F@oracle.com> <86DC9AA1-016B-4899-9111-A7FE2802A972@oracle.com> Message-ID: <58086C3E-C3E5-4597-9203-094F572B290B@oracle.com> > On Nov 16, 2016, at 12:30 PM, David DeHaven wrote: > > Round 3: > http://cr.openjdk.java.net/~ddehaven/8169289/jdk.2 > > Tested with a jar that had a bad JavaFX-Application-Class and it continued to report the correct class name. +1 Mandy From david.holmes at oracle.com Wed Nov 16 21:27:28 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Nov 2016 07:27:28 +1000 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> <1695A59F-98AB-4821-9E20-AD3FE155EFAE@oracle.com> <0D45991D-20E0-4835-9EFA-C3DCCBA24059@oracle.com> <9a81608c-0973-a421-7bc6-830df99fd960@gmail.com> Message-ID: Peter has highlighted the risk with anything but the most minimal of changes - the more you say the more likely you are saying something that is incorrect. Reachability and the GC relationship to it is extremely complex and can't be summarised in a few words. I would go back to the original simple suggestion to just add "detected": http://cr.openjdk.java.net/~zmajo/8169000/webrev.00 "If a registered reference is detected as unreachable itself, then it will never be enqueued." -- That removes any expectation that you can determine whether or not it will be unreachable based on looking at the source code or reasoning about the bytecodes. Cheers, David ----- On 17/11/2016 2:37 AM, Peter Levart wrote: > Hi, > > On 11/16/2016 05:09 PM, Peter Levart wrote: >>> >>> http://cr.openjdk.java.net/~zmajo/8169000/webrev.03/ >> >> "If a registered reference ceases to be strongly reachable itself (not >> by examining the source code but by looking at the actual state of the >> VM at runtime), it will never be enqueued." >> >> I think this is wrong wording. A Reference object may cease to be >> strongly reachable for some time (even by looking at the actual state >> of the VM at runtime) and then regain strong reachability and then be >> enqueued. If during the period that a Reference object is not strongly >> reachable (even by looking at the actual state of the VM at runtime), >> GC is not run, the Reference object will not be discovered as not >> being strongly reachable and VM will not clear any Soft or Weak >> references having the Reference object as a referent and consequently >> the program will be able to regain strong reachability to it. > > > A counter example: A Reference object may cease to be strongly reachable > by becoming softly reachable. The JVM may even discover it to be softly > reachable (looking at the actual state of the VM at runtime), but by > policy, VM may also see that is has not been softly reachable long > enough and so it will not clear the SoftReference but instead rather > enqueue the SoftReference's referent (our PhantomReference object): > > public class SoftlyReachablePhantomReference { > > static ReferenceQueue rq = new ReferenceQueue<>(); > static Reference> refRef; > > public static void main(final String[] args) throws Exception { > refRef = new SoftReference<>( > new PhantomReference<>( > new Object(), > rq > ) > ); > // <- here > System.gc(); > Reference rmRef = rq.remove(1000); > if (rmRef == null) { > System.out.println("PhantomReference NOT enqueued"); > } else { > System.out.println("PhantomReference enqueued"); > } > } > } > > > Running with -Xcomp, the above program will print: "PhantomReference > enqueued". By just swapping SoftRererence with WeakReference: > > > public class WeaklyReachablePhantomReference { > > static ReferenceQueue rq = new ReferenceQueue<>(); > static Reference> refRef; > > public static void main(final String[] args) throws Exception { > refRef = new WeakReference<>( > new PhantomReference<>( > new Object(), > rq > ) > ); > // <- here > System.gc(); > Reference rmRef = rq.remove(1000); > if (rmRef == null) { > System.out.println("PhantomReference NOT enqueued"); > } else { > System.out.println("PhantomReference enqueued"); > } > } > } > > > ...the program will print: "PhantomReference NOT enqueued". > > This is all expected and by the spec. > > Peter > From mandy.chung at oracle.com Wed Nov 16 21:31:47 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Nov 2016 13:31:47 -0800 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> <1695A59F-98AB-4821-9E20-AD3FE155EFAE@oracle.com> <0D45991D-20E0-4835-9EFA-C3DCCBA24059@oracle.com> Message-ID: > On Nov 16, 2016, at 12:41 AM, Zolt?n Maj? wrote: > > >> When a reference becomes unreachable (not by examining the source code but the actual state of the VM at runtime), it will never be enqueued. > > I also like that wording, thank you! BTW I am not proposing this be added in the spec. My intent is to clarify why I think the current statement in the spec is correct. Mandy From huizhe.wang at oracle.com Wed Nov 16 22:12:47 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 16 Nov 2016 14:12:47 -0800 Subject: RFR (JAXP) 8158619: Very large CDATA section in XML document causes OOME Message-ID: <582CD9DF.8000402@oracle.com> Hi, Please review an enhancement adding a property to allow for specifying the chunk size of CDATA. JBS: https://bugs.openjdk.java.net/browse/JDK-8158619 webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8158619/webrev/ Thanks, Joe From yingqi.lu at intel.com Wed Nov 16 22:14:36 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Wed, 16 Nov 2016 22:14:36 +0000 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <77D7708E-07FE-4E39-BF7A-30799EB8CEA7@intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5135D27@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5139A26@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA513CE96@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA51447D9@ORSMSX113.amr.corp.intel.com> <006c75c4-1404-d66b-737d-e07ea2b493fd@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5166194@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA516782E@ORSMSX113.amr.corp.intel.com> <36CE90D5-B86C-4E0A-A2BD-AC812D4262D1@oracle.com> <66b40d54-fcf7-4258-6499-082742727e66@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5169EFD@ORSMSX113.amr.corp.intel.com>, <482dd41a-89c8-fe56-c9ab-e662a2f957e8@oracle.com> <77D7708E-07FE-4E39-BF7A-30799EB8CEA7@intel.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA518165F@ORSMSX113.amr.corp.intel.com> Hi All, Our most recent version of our DirectIO patch is available at http://cr.openjdk.java.net/~kkharbas/8164900/webrev.04/ In this version, we have modified the following items: 1. Remove ByteBuffer.allocateDirectAligned() and ByteBuffer.isAligned(). Instead, using existing APIs alignmentOffset() and alignedSlice() 2. Use Block Size as the alignment value instead of OS page size 3. Create a function named getBlockSize from FileStore class 4. Implement DirectIO for Windows 5. JTreg test passed for Windows, Linux and OS X with regarding to the DirectIO changes we made Please let us know your comments and feedback. Thank you very much for your consideration! Thanks, Lucy From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Lu, Yingqi Sent: Sunday, November 06, 2016 9:37 AM To: Alan Bateman Cc: Kharbas, Kishor ; David Holmes ; core-libs-dev at openjdk.java.net; nio-dev at openjdk.java.net; Thomas St?fe ; Kaczmarek, Eric Subject: Re: Proposal for adding O_DIRECT support into JDK 9 Hi Alan, Thank you very much for your suggestion. FileStore is a better home for the alignment value. We will use It in our next version of the patch and update here for review soon. Thanks, Lucy Sent from my iPhone On Nov 6, 2016, at 9:04 AM, Alan Bateman > wrote: On 06/11/2016 15:51, Lu, Yingqi wrote: Another approach might be use ioctl to get the block size and use that as the alignment value. I think ioctl is available on UNIX based OSes (please chime in if I miss any OS here) and has a similar call for Windows named DeviceIoControl. The request code of ioctl is different from OS to OS, but we could address that in the native code. A possible approach (I think I mentioned this in one of the early mails) is to have FileStore expose the block size that can be use to align and size the buffer. -Alan From forax at univ-mlv.fr Wed Nov 16 23:00:40 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 17 Nov 2016 00:00:40 +0100 (CET) Subject: JShell doesn't provide a ToolProvider In-Reply-To: References: <1273273610.1599970.1479288219573.JavaMail.zimbra@u-pem.fr> Message-ID: <329846621.2188003.1479337240825.JavaMail.zimbra@u-pem.fr> So i respectfully disagree with Robert :) While the interactive mode of jshell is something important, being able to replay interactive sessions (stored in a file) automatically is in my opinion as important. If the module jdk.jshell provide an implementation for the interface ToolProvider inside the package jdk.internal.shell.tool, it can start JShellTool with exacly the same arguments as the main() does. R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "Remi Forax" , "core-libs-dev" > Envoy?: Mercredi 16 Novembre 2016 12:29:42 > Objet: Re: JShell doesn't provide a ToolProvider > On 16/11/2016 09:23, Remi Forax wrote: > >> Hi all, hi Robert, >> currently, unlike javac or javadoc, there is no way to directly invoke jshell >> (JShellTool) because it lies in an internal package (which is a good idea). >> >> I think the module jdk.jshell should provide a java.util.spi.ToolProvider so i >> can embed jshell, like i can embed any dynmic langage runtimes, in my program >> instead of having to invoke it using the command line (without being able to >> control the exact version of jshell or even if jshell is present in case of a >> custom jdk image). >> > This was discussed as part of introducing the SPI [1], you'll see the > mails from Robert where he points out that this doesn't fit. > > -Alan > > [1] > http://mail.openjdk.java.net/pipermail/compiler-dev/2016-October/010379.html From peter.levart at gmail.com Wed Nov 16 23:15:23 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 17 Nov 2016 00:15:23 +0100 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> <1695A59F-98AB-4821-9E20-AD3FE155EFAE@oracle.com> <0D45991D-20E0-4835-9EFA-C3DCCBA24059@oracle.com> <9a81608c-0973-a421-7bc6-830df99fd960@gmail.com> Message-ID: <3e20c838-dba4-0317-0779-fa1da593c076@gmail.com> Hi Zoltan, On 11/16/2016 10:27 PM, David Holmes wrote: > Peter has highlighted the risk with anything but the most minimal of > changes - the more you say the more likely you are saying something > that is incorrect. Reachability and the GC relationship to it is > extremely complex and can't be summarised in a few words. > > I would go back to the original simple suggestion to just add "detected": > > http://cr.openjdk.java.net/~zmajo/8169000/webrev.00 > > "If a registered reference is detected as unreachable itself, then it > will never be enqueued." > > -- > > That removes any expectation that you can determine whether or not it > will be unreachable based on looking at the source code or reasoning > about the bytecodes. Yes, but it also gives very little helpful information to a programmer. Why are we insisting in specifying when it is guaranteed for a Reference object to *not* be enqueued. This is not very helpful. A more helpful information for a programmer would be to specify when a Reference object is guaranteed to *be* enqueued. Guarantee is given only if the Reference object is kept strongly reachable. If it ceases to be strongly reachable, it may never be enqueued, but it is not guaranteed that it will not be enqueued either. So this is still my favorite: "If a registered reference ceases to be strongly reachable for any period of time, it may become unreachable and never be enqueued. In order to guarantee for a registered reference to be enqueued, it must be kept strongly reachable at all times." Regards, Peter > > Cheers, > David > ----- > > > On 17/11/2016 2:37 AM, Peter Levart wrote: >> Hi, >> >> On 11/16/2016 05:09 PM, Peter Levart wrote: >>>> >>>> http://cr.openjdk.java.net/~zmajo/8169000/webrev.03/ >>> >>> "If a registered reference ceases to be strongly reachable itself (not >>> by examining the source code but by looking at the actual state of the >>> VM at runtime), it will never be enqueued." >>> >>> I think this is wrong wording. A Reference object may cease to be >>> strongly reachable for some time (even by looking at the actual state >>> of the VM at runtime) and then regain strong reachability and then be >>> enqueued. If during the period that a Reference object is not strongly >>> reachable (even by looking at the actual state of the VM at runtime), >>> GC is not run, the Reference object will not be discovered as not >>> being strongly reachable and VM will not clear any Soft or Weak >>> references having the Reference object as a referent and consequently >>> the program will be able to regain strong reachability to it. >> >> >> A counter example: A Reference object may cease to be strongly reachable >> by becoming softly reachable. The JVM may even discover it to be softly >> reachable (looking at the actual state of the VM at runtime), but by >> policy, VM may also see that is has not been softly reachable long >> enough and so it will not clear the SoftReference but instead rather >> enqueue the SoftReference's referent (our PhantomReference object): >> >> public class SoftlyReachablePhantomReference { >> >> static ReferenceQueue rq = new ReferenceQueue<>(); >> static Reference> refRef; >> >> public static void main(final String[] args) throws Exception { >> refRef = new SoftReference<>( >> new PhantomReference<>( >> new Object(), >> rq >> ) >> ); >> // <- here >> System.gc(); >> Reference rmRef = rq.remove(1000); >> if (rmRef == null) { >> System.out.println("PhantomReference NOT enqueued"); >> } else { >> System.out.println("PhantomReference enqueued"); >> } >> } >> } >> >> >> Running with -Xcomp, the above program will print: "PhantomReference >> enqueued". By just swapping SoftRererence with WeakReference: >> >> >> public class WeaklyReachablePhantomReference { >> >> static ReferenceQueue rq = new ReferenceQueue<>(); >> static Reference> refRef; >> >> public static void main(final String[] args) throws Exception { >> refRef = new WeakReference<>( >> new PhantomReference<>( >> new Object(), >> rq >> ) >> ); >> // <- here >> System.gc(); >> Reference rmRef = rq.remove(1000); >> if (rmRef == null) { >> System.out.println("PhantomReference NOT enqueued"); >> } else { >> System.out.println("PhantomReference enqueued"); >> } >> } >> } >> >> >> ...the program will print: "PhantomReference NOT enqueued". >> >> This is all expected and by the spec. >> >> Peter >> From brent.christian at oracle.com Wed Nov 16 23:22:17 2016 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 16 Nov 2016 15:22:17 -0800 Subject: RFR 8136831 : Undefined null behavior in Class[Loader].getResourceXXXX() Message-ID: Hi, Please review my fix for 8136831 - Undefined null behavior in Class[Loader].getResourceXXXX(). Bug: https://bugs.openjdk.java.net/browse/JDK-8136831 Webrev: http://cr.openjdk.java.net/~bchristi/8136831/webrev.00/ Class and ClassLoader have the following public methods for locating resources by name: Class.getResource(String name) Class.getResourceAsStream(String name) ClassLoader.getResource(String name) ClassLoader.getResourceAsStream(String name) ClassLoader.getResources(String name) Of these, only Class.getResourceAsStream() specifies the behavior when passed a null 'name' argument - throw a NullPointerException. All methods throw an NPE in this case (going back at least to JDK 7u), with ClassLoader.getResources() being something of an exception. As described in the bug report, it returns an Enumeration object with a buggy implementation which throws an NPE from hasMoreElements(). As of the module system going into JDK9b111, these methods no longer throw an NPE, but return null (again, with the exception of ClassLoader.getResources(), which now returns a non-buggy Enumeration with working hasMoreElements() method). I believe this issue should be resolved as follows: 1. Restore the historical NPE behavior by adding code to ensure this behavior (instead of relying on it happening incidentally deeper in the code - see the stack traces in the bug report). 2. Specify @throws NPE in the JavaDoc for these methods. For ClassLoader.getResources() this is a change in behavior, though the old behavior of returning a buggy Enumeration is not worth keeping. Better to fail fast, and behave like other related methods. Thanks, -Brent From peter.levart at gmail.com Wed Nov 16 23:29:59 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 17 Nov 2016 00:29:59 +0100 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> <1695A59F-98AB-4821-9E20-AD3FE155EFAE@oracle.com> <0D45991D-20E0-4835-9EFA-C3DCCBA24059@oracle.com> Message-ID: On 11/16/2016 10:31 PM, Mandy Chung wrote: >> On Nov 16, 2016, at 12:41 AM, Zolt?n Maj? wrote: >> >> >>> When a reference becomes unreachable (not by examining the source code but the actual state of the VM at runtime), it will never be enqueued. >> I also like that wording, thank you! > BTW I am not proposing this be added in the spec. My intent is to clarify why I think the current statement in the spec is correct. That's right. But it might also be helpful to tell when the reference may become unreachable. The fact that the transition from not being strongly reachable to being unreachable and reclaimed may happen atomically from the standpoint of the program, is not immediately obvious. Or is it? Regards, Peter > Mandy From paul.sandoz at oracle.com Wed Nov 16 23:34:07 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Nov 2016 15:34:07 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: References: <8cc0d5a9-9245-e6b1-0ff2-616127dbc583@oracle.com> Message-ID: Hi Martin, Glad you looked more closely at the perf aspects of ArrayDeque. I am struggling to determine what has changed since the last revision. Apart from ArrayDeque what files should i be looking at? Thanks, Paul. > On 16 Nov 2016, at 12:14, Martin Buchholz wrote: > > Thanks to Vitaly and Doug for being more concerned about offer/poll > performance than I was initially. ArrayDeque is now back to using the head > + tail + spare slot strategy, which keeps optimal performance for non-bulk > operations, while everything else gets faster. We have new tests and new > benchmarks, as a result of which new bugs were found and fixed, and this > integration wave has grown rather larger than originally intended. > > The JIT-friendly nested loop strategy was successful for making bulk > operations on circular arrays faster, and this is used for both ArrayDeque > and ArrayBlockingQueue. > > + /* > + * VMs excel at optimizing simple array loops where indices are > + * incrementing or decrementing over a valid slice, e.g. > + * > + * for (int i = start; i < end; i++) ... elements[i] > + * > + * Because in a circular array, elements are in general stored in > + * two disjoint such slices, we help the VM by writing unusual > + * nested loops for all traversals over the elements. > + */ > > > Bulk removal operations on array-based collections retreat to a two-pass > algorithm, which is slightly slower (but still O(n)), but continues to > support (questionable) predicates that reentrantly access the collection in > read mode. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ > > On Fri, Oct 21, 2016 at 12:32 PM, Martin Buchholz > wrote: > >> >> >> On Tue, Oct 18, 2016 at 4:18 PM, Martin Buchholz >> wrote: >> >>> >>> >>> On Tue, Oct 18, 2016 at 4:00 PM, Vitaly Davidovich >>> wrote: >>> >>>> >>>>>> * Change in allocation/capacity policy. >>>>>> >>>>>> The removal of the power-of-two restriction, and applying a 1.5x >>>>> growth >>>>>> factor (same as ArrayList) seems sensible. Does this mean that the >>>>> ability >>>>>> to compute the proper array index by using x & (length-1) wasn't >>>>> worth it? >>>>>> Or at least not worth the extra tail wastage? >>>>>> >>>>> >>>>> There's no integer division to optimize, as with hash tables. >>>> >>>> But it does add some new branches, doesn't it? Potentially branches that >>>> aren't taken prior to JIT compilation, but taken later = deopt. >>>> >>> >>> If it's a smidgeon slower, I don't care that much; improvement in >>> flexibility and scalability are more important. >>> >>> Of course, I do care about algorithmic improvements to e.g. removeIf >>> >>> >>>> Curious if you ran some benchmarks on ArrayDeque. >>>> >>> >>> Not yet. Who would like to show how slow the code is? >>> >> >> I revived my ancient IteratorMicroBenchmark for the latest webrev, made it >> a proper jtreg test, added ArrayDeque Jobs, and verified that the new code >> is measurably faster than the old code, at least for the mundane job of >> iterating. >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ >> jsr166-jdk9-integration/ArrayList/ >> >> From david.holmes at oracle.com Wed Nov 16 23:35:14 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Nov 2016 09:35:14 +1000 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: <3e20c838-dba4-0317-0779-fa1da593c076@gmail.com> References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> <1695A59F-98AB-4821-9E20-AD3FE155EFAE@oracle.com> <0D45991D-20E0-4835-9EFA-C3DCCBA24059@oracle.com> <9a81608c-0973-a421-7bc6-830df99fd960@gmail.com> <3e20c838-dba4-0317-0779-fa1da593c076@gmail.com> Message-ID: <27299a0f-9253-ba9f-305b-b9f837ffb3e6@oracle.com> On 17/11/2016 9:15 AM, Peter Levart wrote: > Hi Zoltan, > > > On 11/16/2016 10:27 PM, David Holmes wrote: >> Peter has highlighted the risk with anything but the most minimal of >> changes - the more you say the more likely you are saying something >> that is incorrect. Reachability and the GC relationship to it is >> extremely complex and can't be summarised in a few words. >> >> I would go back to the original simple suggestion to just add "detected": >> >> http://cr.openjdk.java.net/~zmajo/8169000/webrev.00 >> >> "If a registered reference is detected as unreachable itself, then it >> will never be enqueued." >> >> -- >> >> That removes any expectation that you can determine whether or not it >> will be unreachable based on looking at the source code or reasoning >> about the bytecodes. > > Yes, but it also gives very little helpful information to a programmer. > > Why are we insisting in specifying when it is guaranteed for a Reference > object to *not* be enqueued. This is not very helpful. I disagree. The whole point of the statement was to make it clear that for a referent to be enqueued the referee reference type must itself remain reachable. The problem with the statement was that it could be misconstrued as indicating when a referent _must_ not be enqueued. > A more helpful information for a programmer would be to specify when a > Reference object is guaranteed to *be* enqueued. Guarantee is given only > if the Reference object is kept strongly reachable. If it ceases to be > strongly reachable, it may never be enqueued, but it is not guaranteed > that it will not be enqueued either. > > So this is still my favorite: > > "If a registered reference ceases to be strongly reachable for any > period of time, it may become unreachable and never be enqueued. In > order to guarantee for a registered reference to be enqueued, it must be > kept strongly reachable at all times." That seems redundant to me. Given the reachability definitions it reduces to "If a registered reference becomes unreachable it may never be enqueued." David ----- > Regards, Peter > >> >> Cheers, >> David >> ----- >> >> >> On 17/11/2016 2:37 AM, Peter Levart wrote: >>> Hi, >>> >>> On 11/16/2016 05:09 PM, Peter Levart wrote: >>>>> >>>>> http://cr.openjdk.java.net/~zmajo/8169000/webrev.03/ >>>> >>>> "If a registered reference ceases to be strongly reachable itself (not >>>> by examining the source code but by looking at the actual state of the >>>> VM at runtime), it will never be enqueued." >>>> >>>> I think this is wrong wording. A Reference object may cease to be >>>> strongly reachable for some time (even by looking at the actual state >>>> of the VM at runtime) and then regain strong reachability and then be >>>> enqueued. If during the period that a Reference object is not strongly >>>> reachable (even by looking at the actual state of the VM at runtime), >>>> GC is not run, the Reference object will not be discovered as not >>>> being strongly reachable and VM will not clear any Soft or Weak >>>> references having the Reference object as a referent and consequently >>>> the program will be able to regain strong reachability to it. >>> >>> >>> A counter example: A Reference object may cease to be strongly reachable >>> by becoming softly reachable. The JVM may even discover it to be softly >>> reachable (looking at the actual state of the VM at runtime), but by >>> policy, VM may also see that is has not been softly reachable long >>> enough and so it will not clear the SoftReference but instead rather >>> enqueue the SoftReference's referent (our PhantomReference object): >>> >>> public class SoftlyReachablePhantomReference { >>> >>> static ReferenceQueue rq = new ReferenceQueue<>(); >>> static Reference> refRef; >>> >>> public static void main(final String[] args) throws Exception { >>> refRef = new SoftReference<>( >>> new PhantomReference<>( >>> new Object(), >>> rq >>> ) >>> ); >>> // <- here >>> System.gc(); >>> Reference rmRef = rq.remove(1000); >>> if (rmRef == null) { >>> System.out.println("PhantomReference NOT enqueued"); >>> } else { >>> System.out.println("PhantomReference enqueued"); >>> } >>> } >>> } >>> >>> >>> Running with -Xcomp, the above program will print: "PhantomReference >>> enqueued". By just swapping SoftRererence with WeakReference: >>> >>> >>> public class WeaklyReachablePhantomReference { >>> >>> static ReferenceQueue rq = new ReferenceQueue<>(); >>> static Reference> refRef; >>> >>> public static void main(final String[] args) throws Exception { >>> refRef = new WeakReference<>( >>> new PhantomReference<>( >>> new Object(), >>> rq >>> ) >>> ); >>> // <- here >>> System.gc(); >>> Reference rmRef = rq.remove(1000); >>> if (rmRef == null) { >>> System.out.println("PhantomReference NOT enqueued"); >>> } else { >>> System.out.println("PhantomReference enqueued"); >>> } >>> } >>> } >>> >>> >>> ...the program will print: "PhantomReference NOT enqueued". >>> >>> This is all expected and by the spec. >>> >>> Peter >>> > From paul.sandoz at oracle.com Wed Nov 16 23:44:36 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Nov 2016 15:44:36 -0800 Subject: RFR 8136831 : Undefined null behavior in Class[Loader].getResourceXXXX() In-Reply-To: References: Message-ID: <844FDA4B-AD61-4A76-B966-AF8743E70458@oracle.com> Hi Brent, I think it would be better to use Objects.requireNonNull (see other usages in Class etc). IMHO no need to specify a exception message, or test for that (which i think is too brittle). You will need to file a CCC for the change in behaviour of the Enumeration returning getResources. Paul. > On 16 Nov 2016, at 15:22, Brent Christian wrote: > > Hi, > > Please review my fix for 8136831 - Undefined null behavior in Class[Loader].getResourceXXXX(). > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8136831 > Webrev: > http://cr.openjdk.java.net/~bchristi/8136831/webrev.00/ > > > Class and ClassLoader have the following public methods for locating resources by name: > > Class.getResource(String name) > Class.getResourceAsStream(String name) > ClassLoader.getResource(String name) > ClassLoader.getResourceAsStream(String name) > ClassLoader.getResources(String name) > > Of these, only Class.getResourceAsStream() specifies the behavior when passed a null 'name' argument - throw a NullPointerException. > > All methods throw an NPE in this case (going back at least to JDK 7u), with ClassLoader.getResources() being something of an exception. As described in the bug report, it returns an Enumeration object with a buggy implementation which throws an NPE from hasMoreElements(). > > As of the module system going into JDK9b111, these methods no longer throw an NPE, but return null (again, with the exception of ClassLoader.getResources(), which now returns a non-buggy Enumeration with working hasMoreElements() method). > > I believe this issue should be resolved as follows: > > 1. Restore the historical NPE behavior by adding code to ensure this behavior (instead of relying on it happening incidentally deeper in the code - see the stack traces in the bug report). > > 2. Specify @throws NPE in the JavaDoc for these methods. > > For ClassLoader.getResources() this is a change in behavior, though the old behavior of returning a buggy Enumeration is not worth keeping. Better to fail fast, and behave like other related methods. > > Thanks, > -Brent > From paul.sandoz at oracle.com Wed Nov 16 23:50:54 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Nov 2016 15:50:54 -0800 Subject: Proposed patch: further wrapping of FileInputStream's native method In-Reply-To: References: Message-ID: Hi Sunny, If you send me an exported patch with the reviewers in the comment etc i can push for you. Thanks, Paul. > On 9 Nov 2016, at 19:02, Chan, Sunny wrote: > > Hello all, > > I proposed a patch to provide wrapping for some native methods in FileInputStream a while ago in May, and the patch has been reviewed but it has not been integrated. I have checked the patch again with the latest JDK9 dev builds and it still works correctly passing java.io regression tests so could I have someone to sponsor this and integrate this patch? > > Here is the previous threads from email archive: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040901.html I have attached the patch again in this email for reference. > > Sunny Chan > Executive Director > Technology > > Goldman Sachs (Asia) L.L.C. | 39th Floor | The Center | 99 Queens Road Central | Hong Kong > Email: sunny.chan at gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633 > > Learn more about Goldman Sachs > GS.com | Blog | LinkedIn | YouTube | Twitter > > 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. > From peter.levart at gmail.com Thu Nov 17 00:00:31 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 17 Nov 2016 01:00:31 +0100 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: <27299a0f-9253-ba9f-305b-b9f837ffb3e6@oracle.com> References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> <1695A59F-98AB-4821-9E20-AD3FE155EFAE@oracle.com> <0D45991D-20E0-4835-9EFA-C3DCCBA24059@oracle.com> <9a81608c-0973-a421-7bc6-830df99fd960@gmail.com> <3e20c838-dba4-0317-0779-fa1da593c076@gmail.com> <27299a0f-9253-ba9f-305b-b9f837ffb3e6@oracle.com> Message-ID: <1176f94a-507e-929a-1c15-36634c37fd9a@gmail.com> Hi David, On 11/17/2016 12:35 AM, David Holmes wrote: >> Why are we insisting in specifying when it is guaranteed for a Reference >> object to *not* be enqueued. This is not very helpful. > > I disagree. The whole point of the statement was to make it clear that > for a referent to be enqueued the referee reference type must itself > remain reachable. The problem with the statement was that it could be > misconstrued as indicating when a referent _must_ not be enqueued. The original text is correct: "If a registered reference becomes unreachable itself, then it will never be enqueued". And we must actually read it as "then the reference _must_ not be enququed". The transitioning of reachability from unreachable to strongly reachable is not allowed. If a registered reference becomes unreachable then it _must_ not be enqueued as enqueueing would transition it to strongly reachable from unreachable and break the spec. Regards, Peter >> A more helpful information for a programmer would be to specify when a >> Reference object is guaranteed to *be* enqueued. Guarantee is given only >> if the Reference object is kept strongly reachable. If it ceases to be >> strongly reachable, it may never be enqueued, but it is not guaranteed >> that it will not be enqueued either. >> >> So this is still my favorite: >> >> "If a registered reference ceases to be strongly reachable for any >> period of time, it may become unreachable and never be enqueued. In >> order to guarantee for a registered reference to be enqueued, it must be >> kept strongly reachable at all times." > > That seems redundant to me. Given the reachability definitions it > reduces to "If a registered reference becomes unreachable it may never > be enqueued." > > David From martinrb at google.com Thu Nov 17 00:03:18 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 16 Nov 2016 16:03:18 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: References: <8cc0d5a9-9245-e6b1-0ff2-616127dbc583@oracle.com> Message-ID: Apologies for having this wave turn into a tsunami. CopyOnWriteArrayList was rewritten due to finding https://bugs.openjdk.java.net/browse/JDK-8169738 ArrayDeque and ArrayBlockingQueue now both use efficient nested loop idiom for all traversals. Most bulk remove methods in all collection classes were rewritten for efficiency, using similar code. Lots of tests and benchmarks added. On Wed, Nov 16, 2016 at 3:34 PM, Paul Sandoz wrote: > Hi Martin, > > Glad you looked more closely at the perf aspects of ArrayDeque. > > I am struggling to determine what has changed since the last revision. > Apart from ArrayDeque what files should i be looking at? > > Thanks, > Paul. > > > On 16 Nov 2016, at 12:14, Martin Buchholz wrote: > > > > Thanks to Vitaly and Doug for being more concerned about offer/poll > > performance than I was initially. ArrayDeque is now back to using the > head > > + tail + spare slot strategy, which keeps optimal performance for > non-bulk > > operations, while everything else gets faster. We have new tests and new > > benchmarks, as a result of which new bugs were found and fixed, and this > > integration wave has grown rather larger than originally intended. > > > > The JIT-friendly nested loop strategy was successful for making bulk > > operations on circular arrays faster, and this is used for both > ArrayDeque > > and ArrayBlockingQueue. > > > > + /* > > + * VMs excel at optimizing simple array loops where indices are > > + * incrementing or decrementing over a valid slice, e.g. > > + * > > + * for (int i = start; i < end; i++) ... elements[i] > > + * > > + * Because in a circular array, elements are in general stored in > > + * two disjoint such slices, we help the VM by writing unusual > > + * nested loops for all traversals over the elements. > > + */ > > > > > > Bulk removal operations on array-based collections retreat to a two-pass > > algorithm, which is slightly slower (but still O(n)), but continues to > > support (questionable) predicates that reentrantly access the collection > in > > read mode. > > > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ > jsr166-jdk9-integration/ > > > > On Fri, Oct 21, 2016 at 12:32 PM, Martin Buchholz > > wrote: > > > >> > >> > >> On Tue, Oct 18, 2016 at 4:18 PM, Martin Buchholz > >> wrote: > >> > >>> > >>> > >>> On Tue, Oct 18, 2016 at 4:00 PM, Vitaly Davidovich > >>> wrote: > >>> > >>>> > >>>>>> * Change in allocation/capacity policy. > >>>>>> > >>>>>> The removal of the power-of-two restriction, and applying a 1.5x > >>>>> growth > >>>>>> factor (same as ArrayList) seems sensible. Does this mean that the > >>>>> ability > >>>>>> to compute the proper array index by using x & (length-1) wasn't > >>>>> worth it? > >>>>>> Or at least not worth the extra tail wastage? > >>>>>> > >>>>> > >>>>> There's no integer division to optimize, as with hash tables. > >>>> > >>>> But it does add some new branches, doesn't it? Potentially branches > that > >>>> aren't taken prior to JIT compilation, but taken later = deopt. > >>>> > >>> > >>> If it's a smidgeon slower, I don't care that much; improvement in > >>> flexibility and scalability are more important. > >>> > >>> Of course, I do care about algorithmic improvements to e.g. removeIf > >>> > >>> > >>>> Curious if you ran some benchmarks on ArrayDeque. > >>>> > >>> > >>> Not yet. Who would like to show how slow the code is? > >>> > >> > >> I revived my ancient IteratorMicroBenchmark for the latest webrev, made > it > >> a proper jtreg test, added ArrayDeque Jobs, and verified that the new > code > >> is measurably faster than the old code, at least for the mundane job of > >> iterating. > >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ > >> jsr166-jdk9-integration/ArrayList/ > >> > >> > > From masayoshi.okutsu at oracle.com Thu Nov 17 00:04:29 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 17 Nov 2016 09:04:29 +0900 Subject: RFR:JDK-8168906-Tighten permissions granted to the jdk.localedata module In-Reply-To: References: <1d18d1ad-cf80-8131-afcd-c8654f3c191c@oracle.com> <7da1a463-a876-8385-af18-8c5f41cd1f7c@oracle.com> Message-ID: <6706e4e5-be1d-8d61-c1b7-a7249a955011@oracle.com> test/sun/util/locale/provider/Bug8152817.java is a test with a SecurityManager. I18n SQE should have some. Masayoshi On 11/14/2016 11:59 PM, Sean Mullan wrote: > Looks good. Are there any regression tests for this component that run > with a SecurityManager? If not, it would be useful to add some to > ensure that the proper permissions are being granted to this module. > > --Sean > > On 11/14/16 2:27 AM, Rachna Goel wrote: >> sorry, correction to typo >> >> As jdk.localedata module does *not* read any system properties, >> tightened permissions for same. >> >> >> On 14/11/16 12:42 PM, Rachna Goel wrote: >>> Hi, >>> >>> Kindly review fix for JDK-8168906. >>> https://bugs.openjdk.java.net/browse/JDK-8168906 >>> >>> Patch :http://cr.openjdk.java.net/~rgoel/JDK-8168906/webrev/ >>> >>> fix: As jdk.localedata module does read any system properties, >>> tightened permissions for same. >>> >>> Thanks, >>> Rachna >> From masayoshi.okutsu at oracle.com Thu Nov 17 00:04:58 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 17 Nov 2016 09:04:58 +0900 Subject: RFR:JDK-8168906-Tighten permissions granted to the jdk.localedata module In-Reply-To: <5f378665-d589-08d7-59fa-c8ed9638e4a9@oracle.com> References: <1d18d1ad-cf80-8131-afcd-c8654f3c191c@oracle.com> <5f378665-d589-08d7-59fa-c8ed9638e4a9@oracle.com> Message-ID: +1 Masayoshi On 11/15/2016 1:07 AM, Naoto Sato wrote: > +1 > > Naoto > > On 11/13/16 11:12 PM, Rachna Goel wrote: >> Hi, >> >> Kindly review fix for JDK-8168906. >> https://bugs.openjdk.java.net/browse/JDK-8168906 >> >> Patch :http://cr.openjdk.java.net/~rgoel/JDK-8168906/webrev/ >> >> fix: As jdk.localedata module does read any system properties, tightened >> permissions for same. >> >> Thanks, >> Rachna From david.holmes at oracle.com Thu Nov 17 00:09:17 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Nov 2016 10:09:17 +1000 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: <1176f94a-507e-929a-1c15-36634c37fd9a@gmail.com> References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> <1695A59F-98AB-4821-9E20-AD3FE155EFAE@oracle.com> <0D45991D-20E0-4835-9EFA-C3DCCBA24059@oracle.com> <9a81608c-0973-a421-7bc6-830df99fd960@gmail.com> <3e20c838-dba4-0317-0779-fa1da593c076@gmail.com> <27299a0f-9253-ba9f-305b-b9f837ffb3e6@oracle.com> <1176f94a-507e-929a-1c15-36634c37fd9a@gmail.com> Message-ID: <9abbb97f-1b3e-15ff-8661-931e90ca709b@oracle.com> On 17/11/2016 10:00 AM, Peter Levart wrote: > Hi David, > > > On 11/17/2016 12:35 AM, David Holmes wrote: >>> Why are we insisting in specifying when it is guaranteed for a Reference >>> object to *not* be enqueued. This is not very helpful. >> >> I disagree. The whole point of the statement was to make it clear that >> for a referent to be enqueued the referee reference type must itself >> remain reachable. The problem with the statement was that it could be >> misconstrued as indicating when a referent _must_ not be enqueued. > > The original text is correct: "If a registered reference becomes > unreachable itself, then it will never be enqueued". > > And we must actually read it as "then the reference _must_ not be > enququed". You are presuming the reader understands precisely what "becomes unreachable" means. It does not mean "I looked at the source code and at this point the reference is unused therefore it is unreachable and therefore the referent must never be enqueued". It means that the VM detected that the reference was unreachable. Hence the clarification. David > The transitioning of reachability from unreachable to strongly reachable > is not allowed. If a registered reference becomes unreachable then it > _must_ not be enqueued as enqueueing would transition it to strongly > reachable from unreachable and break the spec. > > Regards, Peter > >>> A more helpful information for a programmer would be to specify when a >>> Reference object is guaranteed to *be* enqueued. Guarantee is given only >>> if the Reference object is kept strongly reachable. If it ceases to be >>> strongly reachable, it may never be enqueued, but it is not guaranteed >>> that it will not be enqueued either. >>> >>> So this is still my favorite: >>> >>> "If a registered reference ceases to be strongly reachable for any >>> period of time, it may become unreachable and never be enqueued. In >>> order to guarantee for a registered reference to be enqueued, it must be >>> kept strongly reachable at all times." >> >> That seems redundant to me. Given the reachability definitions it >> reduces to "If a registered reference becomes unreachable it may never >> be enqueued." >> >> David > From claes.redestad at oracle.com Thu Nov 17 00:13:13 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 17 Nov 2016 01:13:13 +0100 Subject: Proposed patch: further wrapping of FileInputStream's native method In-Reply-To: References: Message-ID: <582CF619.3020408@oracle.com> Hi Paul, it appears you missed out on all the fun this time: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044628.html Thanks! /Claes On 2016-11-17 00:50, Paul Sandoz wrote: > Hi Sunny, > > If you send me an exported patch with the reviewers in the comment etc i can push for you. > > Thanks, > Paul. > >> On 9 Nov 2016, at 19:02, Chan, Sunny wrote: >> >> Hello all, >> >> I proposed a patch to provide wrapping for some native methods in FileInputStream a while ago in May, and the patch has been reviewed but it has not been integrated. I have checked the patch again with the latest JDK9 dev builds and it still works correctly passing java.io regression tests so could I have someone to sponsor this and integrate this patch? >> >> Here is the previous threads from email archive: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040901.html I have attached the patch again in this email for reference. >> >> Sunny Chan >> Executive Director >> Technology >> >> Goldman Sachs (Asia) L.L.C. | 39th Floor | The Center | 99 Queens Road Central | Hong Kong >> Email: sunny.chan at gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633 >> >> Learn more about Goldman Sachs >> GS.com | Blog | LinkedIn | YouTube | Twitter >> >> 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. >> > From hboehm at google.com Thu Nov 17 00:59:22 2016 From: hboehm at google.com (Hans Boehm) Date: Wed, 16 Nov 2016 16:59:22 -0800 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: <0828637b-8bc9-3520-1879-0eb13c72dc17@oracle.com> References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> <1695A59F-98AB-4821-9E20-AD3FE155EFAE@oracle.com> <3e44c6db-ba97-3096-9210-56f9c15a2bd9@oracle.com> <0828637b-8bc9-3520-1879-0eb13c72dc17@oracle.com> Message-ID: The rather-hard-to-decode section 12.6.2 essentially tries to pin down exactly when a reference is guaranteed to remain reachable. It may be worth directly pointing to it. (And perhaps wishing the reader luck :-) ) On Wed, Nov 16, 2016 at 12:21 AM, Zolt?n Maj? wrote: > Hi David, > > > On 11/16/2016 03:21 AM, David Holmes wrote: > >> Hi Zoltan, >> >> First, I'm okay with latest webrev. >> > > thank you. > > >> Second, I don't want to confuse things but need to correct one thing ... >> > > I think you rather clarified things. > > >> On 15/11/2016 10:41 PM, Zolt?n Maj? wrote: >> >>> [...] >>> >>> For example, statement (2) can be possibly (mis-)read as the JVM making >>> references unreachable *earlier* than what a programmer may think -- >>> based on the source code.(That is clearly not the case: References are >>> available at least until the latest program point where they are used, >>> otherwise the program would encounter an error.) >>> >> >> Actually it can make references unreachable earlier than may be expected. >> The wording Mandy suggested comes from the JLS itself - see 12.6.1. >> > > That is right -- thank you for pointing to the relevant section of the JLS. > > (Though I agree it isn't the right disclaimer for the current situation - >> where the interpreter keeps the reference reachable longer than naively >> expected). >> > > Please see my reply to Mandy's email. > > > Thank you! > > Best regards, > > > Zoltan > > > >> David >> ----- >> >> It's indeed a JVM "optimization" keep references alive *longer* than it >>> seems to be from the source code. But (1) already encapsulates that >>> without referring to JVM optimizations explicitly. >>> >>> [...] >>>> >>>> >>>> Making it clear ?strongly reachable? is a good suggestion. I don?t >>>> see word-smithing is needed in the original sentence; hence my above >>>> suggested change only adds the word ?strongly? in this sentence. >>>> >>> >>> I agree. >>> >>> Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~zmajo/8169000/webrev.02/ >>> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>> >>>> Mandy >>>> >>> >>> > From brent.christian at oracle.com Thu Nov 17 01:02:08 2016 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 16 Nov 2016 17:02:08 -0800 Subject: RFR 8136831 : Undefined null behavior in Class[Loader].getResourceXXXX() In-Reply-To: <844FDA4B-AD61-4A76-B966-AF8743E70458@oracle.com> References: <844FDA4B-AD61-4A76-B966-AF8743E70458@oracle.com> Message-ID: <1d9ea794-e643-4a07-66a6-6a4196e55f8c@oracle.com> On 11/16/16 3:44 PM, Paul Sandoz wrote: > Hi Brent, > > I think it would be better to use Objects.requireNonNull Yes, thank you - forgot about that. > IMHO no need to specify a exception message, or test for that (which i think is too brittle). OK. Updated webrev: http://cr.openjdk.java.net/~bchristi/8136831/webrev.01/ > You will need to file a CCC for the change in behaviour of the Enumeration returning getResources. And for the new @throws, I should think. Thanks, Paul -Brent >> On 16 Nov 2016, at 15:22, Brent Christian wrote: >> >> Hi, >> >> Please review my fix for 8136831 - Undefined null behavior in Class[Loader].getResourceXXXX(). >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8136831 >> Webrev: >> http://cr.openjdk.java.net/~bchristi/8136831/webrev.00/ >> >> >> Class and ClassLoader have the following public methods for locating resources by name: >> >> Class.getResource(String name) >> Class.getResourceAsStream(String name) >> ClassLoader.getResource(String name) >> ClassLoader.getResourceAsStream(String name) >> ClassLoader.getResources(String name) >> >> Of these, only Class.getResourceAsStream() specifies the behavior when passed a null 'name' argument - throw a NullPointerException. >> >> All methods throw an NPE in this case (going back at least to JDK 7u), with ClassLoader.getResources() being something of an exception. As described in the bug report, it returns an Enumeration object with a buggy implementation which throws an NPE from hasMoreElements(). >> >> As of the module system going into JDK9b111, these methods no longer throw an NPE, but return null (again, with the exception of ClassLoader.getResources(), which now returns a non-buggy Enumeration with working hasMoreElements() method). >> >> I believe this issue should be resolved as follows: >> >> 1. Restore the historical NPE behavior by adding code to ensure this behavior (instead of relying on it happening incidentally deeper in the code - see the stack traces in the bug report). >> >> 2. Specify @throws NPE in the JavaDoc for these methods. >> >> For ClassLoader.getResources() this is a change in behavior, though the old behavior of returning a buggy Enumeration is not worth keeping. Better to fail fast, and behave like other related methods. >> >> Thanks, >> -Brent >> > From paul.sandoz at oracle.com Thu Nov 17 01:06:40 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 16 Nov 2016 17:06:40 -0800 Subject: Proposed patch: further wrapping of FileInputStream's native method In-Reply-To: <582CF619.3020408@oracle.com> References: <582CF619.3020408@oracle.com> Message-ID: > On 16 Nov 2016, at 16:13, Claes Redestad wrote: > > Hi Paul, > > it appears you missed out on all the fun this time: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044628.html > Indeed! I missed that it moved to a separate email thread. Thanks for checking. Paul. From gromero at linux.vnet.ibm.com Thu Nov 17 01:45:50 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 16 Nov 2016 23:45:50 -0200 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation Message-ID: <582D0BCE.2030209@linux.vnet.ibm.com> Hi, Currently, optimization for building fdlibm is disabled, except for the "solaris" OS target [1]. As a consequence on PPC64 (Linux) StrictMath methods like, but not limited to, sin(), cos(), and tan() perform verify poor in comparison to the same methods in Math class [2]: Math StrictMath ========= ========== sin 0m29.984s 1m41.184s cos 0m30.031s 1m41.200s tan 0m31.772s 1m46.976s asin 0m4.577s 0m4.543s acos 0m4.539s 0m4.525s atan 0m12.929s 0m12.896s exp 0m1.071s 0m4.570s log 0m3.272s 0m14.239s log10 0m4.362s 0m20.236s sqrt 0m0.913s 0m0.981s cbrt 0m10.786s 0m10.808s sinh 0m4.438s 0m4.433s cosh 0m4.496s 0m4.478s tanh 0m3.360s 0m3.353s expm1 0m4.076s 0m4.094s log1p 0m13.518s 0m13.527s IEEEremainder 0m38.803s 0m38.909s atan2 0m20.100s 0m20.057s pow 0m14.096s 0m19.938s hypot 0m5.136s 0m5.122s Switching on the O3 optimization can damage precision of those methods, nonetheless it's possible to avoid that side effect and yet get huge benefits of the -O3 optimization on PPC64 if -fno-expensive-optimizations is passed in addition to the -O3 optimization flag. In that sense the following change is proposed to resolve the issue: diff -r 81eb4bd34611 make/lib/CoreLibraries.gmk --- a/make/lib/CoreLibraries.gmk Wed Nov 09 13:37:19 2016 +0100 +++ b/make/lib/CoreLibraries.gmk Wed Nov 16 19:11:11 2016 -0500 @@ -33,10 +33,16 @@ # libfdlibm is statically linked with libjava below and not delivered into the # product on its own. -BUILD_LIBFDLIBM_OPTIMIZATION := HIGH +BUILD_LIBFDLIBM_OPTIMIZATION := NONE -ifneq ($(OPENJDK_TARGET_OS), solaris) - BUILD_LIBFDLIBM_OPTIMIZATION := NONE +ifeq ($(OPENJDK_TARGET_OS), solaris) + BUILD_LIBFDLIBM_OPTIMIZATION := HIGH +endif + +ifeq ($(OPENJDK_TARGET_OS), linux) + ifeq ($(OPENJDK_TARGET_CPU_ARCH), ppc) + BUILD_LIBFDLIBM_OPTIMIZATION := HIGH + endif endif LIBFDLIBM_SRC := $(JDK_TOPDIR)/src/java.base/share/native/libfdlibm @@ -51,6 +57,7 @@ CFLAGS := $(CFLAGS_JDKLIB) $(LIBFDLIBM_CFLAGS), \ CFLAGS_windows_debug := -DLOGGING, \ CFLAGS_aix := -qfloat=nomaf, \ + CFLAGS_linux_ppc := -fno-expensive-optimizations, \ DISABLED_WARNINGS_gcc := sign-compare, \ DISABLED_WARNINGS_microsoft := 4146 4244 4018, \ ARFLAGS := $(ARFLAGS), \ diff -r 2a1f97c0ad3d make/common/NativeCompilation.gmk --- a/make/common/NativeCompilation.gmk Wed Nov 09 15:32:39 2016 +0100 +++ b/make/common/NativeCompilation.gmk Wed Nov 16 19:08:06 2016 -0500 @@ -569,16 +569,19 @@ $1_ALL_OBJS := $$(sort $$($1_EXPECTED_OBJS) $$($1_EXTRA_OBJECT_FILES)) # Pickup extra OPENJDK_TARGET_OS_TYPE and/or OPENJDK_TARGET_OS dependent variables for CFLAGS. - $1_EXTRA_CFLAGS:=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)) $$($1_CFLAGS_$(OPENJDK_TARGET_OS)) + $1_EXTRA_CFLAGS:=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)) $$($1_CFLAGS_$(OPENJDK_TARGET_OS)) \ + $$($1_CFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU_ARCH)) ifneq ($(DEBUG_LEVEL),release) # Pickup extra debug dependent variables for CFLAGS $1_EXTRA_CFLAGS+=$$($1_CFLAGS_debug) $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)_debug) $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_debug) + $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU_ARCH)_debug) else $1_EXTRA_CFLAGS+=$$($1_CFLAGS_release) $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)_release) $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_release) + $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU_ARCH)_release) endif # Pickup extra OPENJDK_TARGET_OS_TYPE and/or OPENJDK_TARGET_OS dependent variables for CXXFLAGS. After enabling the optimization it's possible to again up to 3x on performance regarding the aforementioned methods without losing precision: StrictMath, original StrictMath, optimized ============================ ============================ sin 1.7136493465700542 1m41.184s 1.7136493465700542 0m33.895s cos 0.1709843554185943 1m41.200s 0.1709843554185943 0m33.884s tan -5.5500322522995315E7 1m46.976s -5.5500322522995315E7 0m36.461s asin NaN 0m4.543s NaN 0m3.175s acos NaN 0m4.525s NaN 0m3.211s atan 1.5707961389886132E8 0m12.896s 1.5707961389886132E8 0m7.100s exp Infinity 0m4.570s Infinity 0m3.187s log 1.7420680845245087E9 0m14.239s 1.7420680845245087E9 0m7.170s log10 7.565705562087342E8 0m20.236s 7.565705562087342E8 0m9.610s sqrt 6.66666671666567E11 0m0.981s 6.66666671666567E11 0m0.948s cbrt 3.481191648389617E10 0m10.808s 3.481191648389617E10 0m10.786s sinh Infinity 0m4.433s Infinity 0m3.179s cosh Infinity 0m4.478s Infinity 0m3.174s tanh 9.999999971990079E7 0m3.353s 9.999999971990079E7 0m3.208s expm1 Infinity 0m4.094s Infinity 0m3.185s log1p 1.7420681029451895E9 0m13.527s 1.7420681029451895E9 0m8.756s IEEEremainder 502000.0 0m38.909s 502000.0 0m14.055s atan2 1.570453905253704E8 0m20.057s 1.570453905253704E8 0m10.510s pow Infinity 0m19.938s Infinity 0m20.204s hypot 5.000000099033372E15 0m5.122s 5.000000099033372E15 0m5.130s I believe that as the FC is passed but FEC is not the change can, after the due scrutiny and review, be pushed if a special exception approval grants it. Once on 9, I'll request the downport to 8. Could I open a bug to address that issue? Thank you very much. Regards, Gustavo [1] http://hg.openjdk.java.net/jdk9/hs/jdk/file/81eb4bd34611/make/lib/CoreLibraries.gmk#l39 [2] https://github.com/gromero/strictmath (comparison script used to get the results) From robert.field at oracle.com Thu Nov 17 01:57:55 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 16 Nov 2016 17:57:55 -0800 Subject: JShell doesn't provide a ToolProvider In-Reply-To: <329846621.2188003.1479337240825.JavaMail.zimbra@u-pem.fr> References: <1273273610.1599970.1479288219573.JavaMail.zimbra@u-pem.fr> <329846621.2188003.1479337240825.JavaMail.zimbra@u-pem.fr> Message-ID: <582D0EA3.50504@oracle.com> On 11/16/16 15:00, forax at univ-mlv.fr wrote: > So i respectfully disagree with Robert :) > > While the interactive mode of jshell is something important, being able to replay interactive sessions (stored in a file) automatically is in my opinion as important. > If the module jdk.jshell provide an implementation for the interface ToolProvider inside the package jdk.internal.shell.tool, it can start JShellTool with exacly the same arguments as the main() does. > > R?mi I respectfully AGREE with R?mi. My arguments were for support of an InputStream parameter, and I agree that without that is better than nothing, so I have created: https://bugs.openjdk.java.net/browse/JDK-8169821 The InputStream could be addressed in the SPI by having one more default in ToolProvider, roughly: default int run(InputStream in, PrintStream out, PrintStream err, String... args) { return run(System.in, out, err, args); } Maybe I was unclear -- On 10/04/16 20:42, Robert Field wrote: > > On 10/04/16 20:24, Jonathan Gibbons wrote: >> Hi Robert, >> >> When you invoke jshell from the command line through the command line launcher, there must surely be a simpler entry point that is invoked. Command line entry points don't provide Java Preferences objects, for example. That being said, I agree that jshell does require an input stream, and that is not supported by this SPI. > > This is how main calls that entry-point -- > > public static void main(String[] args) throws Exception { > new JShellTool(System.in, System.out, System.err, System.out, > System.out, System.err, > Preferences.userRoot().node("tool/JShell"), > Locale.getDefault()) > .start(args); > } > > The only additional parameter needed to match this form of use would be: InputStream in. On 10/04/16 21:14, Robert Field wrote: > > On 10/04/16 21:06, Jonathan Gibbons wrote: >> I don't understand: on the one hand you say you don't want the tool to be an API, but then you say you want to fit in with the proposed new ToolProvider SPI. > > Sorry, I was unclear. We don't want to turn the code of the tool into a tool component API. There is an API the tool is built on, we want that as the only API. > > I do want access somewhere to launch the existing tool. -Robert > > ----- Mail original ----- >> De: "Alan Bateman" >> ?: "Remi Forax" , "core-libs-dev" >> Envoy?: Mercredi 16 Novembre 2016 12:29:42 >> Objet: Re: JShell doesn't provide a ToolProvider >> On 16/11/2016 09:23, Remi Forax wrote: >> >>> Hi all, hi Robert, >>> currently, unlike javac or javadoc, there is no way to directly invoke jshell >>> (JShellTool) because it lies in an internal package (which is a good idea). >>> >>> I think the module jdk.jshell should provide a java.util.spi.ToolProvider so i >>> can embed jshell, like i can embed any dynmic langage runtimes, in my program >>> instead of having to invoke it using the command line (without being able to >>> control the exact version of jshell or even if jshell is present in case of a >>> custom jdk image). >>> >> This was discussed as part of introducing the SPI [1], you'll see the >> mails from Robert where he points out that this doesn't fit. >> >> -Alan >> >> [1] >> http://mail.openjdk.java.net/pipermail/compiler-dev/2016-October/010379.html From david.holmes at oracle.com Thu Nov 17 02:31:48 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Nov 2016 12:31:48 +1000 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <582D0BCE.2030209@linux.vnet.ibm.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> Message-ID: <37b58c35-72b2-cc19-f175-6d1cff410213@oracle.com> Adding in build-dev as they need to scrutinize all build changes. David On 17/11/2016 11:45 AM, Gustavo Romero wrote: > Hi, > > Currently, optimization for building fdlibm is disabled, except for the > "solaris" OS target [1]. > > As a consequence on PPC64 (Linux) StrictMath methods like, but not limited to, > sin(), cos(), and tan() perform verify poor in comparison to the same methods > in Math class [2]: > > Math StrictMath > ========= ========== > sin 0m29.984s 1m41.184s > cos 0m30.031s 1m41.200s > tan 0m31.772s 1m46.976s > asin 0m4.577s 0m4.543s > acos 0m4.539s 0m4.525s > atan 0m12.929s 0m12.896s > exp 0m1.071s 0m4.570s > log 0m3.272s 0m14.239s > log10 0m4.362s 0m20.236s > sqrt 0m0.913s 0m0.981s > cbrt 0m10.786s 0m10.808s > sinh 0m4.438s 0m4.433s > cosh 0m4.496s 0m4.478s > tanh 0m3.360s 0m3.353s > expm1 0m4.076s 0m4.094s > log1p 0m13.518s 0m13.527s > IEEEremainder 0m38.803s 0m38.909s > atan2 0m20.100s 0m20.057s > pow 0m14.096s 0m19.938s > hypot 0m5.136s 0m5.122s > > > Switching on the O3 optimization can damage precision of those methods, > nonetheless it's possible to avoid that side effect and yet get huge benefits of > the -O3 optimization on PPC64 if -fno-expensive-optimizations is passed in > addition to the -O3 optimization flag. > > In that sense the following change is proposed to resolve the issue: > > diff -r 81eb4bd34611 make/lib/CoreLibraries.gmk > --- a/make/lib/CoreLibraries.gmk Wed Nov 09 13:37:19 2016 +0100 > +++ b/make/lib/CoreLibraries.gmk Wed Nov 16 19:11:11 2016 -0500 > @@ -33,10 +33,16 @@ > # libfdlibm is statically linked with libjava below and not delivered into the > # product on its own. > > -BUILD_LIBFDLIBM_OPTIMIZATION := HIGH > +BUILD_LIBFDLIBM_OPTIMIZATION := NONE > > -ifneq ($(OPENJDK_TARGET_OS), solaris) > - BUILD_LIBFDLIBM_OPTIMIZATION := NONE > +ifeq ($(OPENJDK_TARGET_OS), solaris) > + BUILD_LIBFDLIBM_OPTIMIZATION := HIGH > +endif > + > +ifeq ($(OPENJDK_TARGET_OS), linux) > + ifeq ($(OPENJDK_TARGET_CPU_ARCH), ppc) > + BUILD_LIBFDLIBM_OPTIMIZATION := HIGH > + endif > endif > > LIBFDLIBM_SRC := $(JDK_TOPDIR)/src/java.base/share/native/libfdlibm > @@ -51,6 +57,7 @@ > CFLAGS := $(CFLAGS_JDKLIB) $(LIBFDLIBM_CFLAGS), \ > CFLAGS_windows_debug := -DLOGGING, \ > CFLAGS_aix := -qfloat=nomaf, \ > + CFLAGS_linux_ppc := -fno-expensive-optimizations, \ > DISABLED_WARNINGS_gcc := sign-compare, \ > DISABLED_WARNINGS_microsoft := 4146 4244 4018, \ > ARFLAGS := $(ARFLAGS), \ > > > diff -r 2a1f97c0ad3d make/common/NativeCompilation.gmk > --- a/make/common/NativeCompilation.gmk Wed Nov 09 15:32:39 2016 +0100 > +++ b/make/common/NativeCompilation.gmk Wed Nov 16 19:08:06 2016 -0500 > @@ -569,16 +569,19 @@ > $1_ALL_OBJS := $$(sort $$($1_EXPECTED_OBJS) $$($1_EXTRA_OBJECT_FILES)) > > # Pickup extra OPENJDK_TARGET_OS_TYPE and/or OPENJDK_TARGET_OS dependent variables for CFLAGS. > - $1_EXTRA_CFLAGS:=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)) $$($1_CFLAGS_$(OPENJDK_TARGET_OS)) > + $1_EXTRA_CFLAGS:=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)) $$($1_CFLAGS_$(OPENJDK_TARGET_OS)) \ > + $$($1_CFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU_ARCH)) > ifneq ($(DEBUG_LEVEL),release) > # Pickup extra debug dependent variables for CFLAGS > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_debug) > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)_debug) > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_debug) > + $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU_ARCH)_debug) > else > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_release) > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)_release) > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_release) > + $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU_ARCH)_release) > endif > > # Pickup extra OPENJDK_TARGET_OS_TYPE and/or OPENJDK_TARGET_OS dependent variables for CXXFLAGS. > > > After enabling the optimization it's possible to again up to 3x on performance > regarding the aforementioned methods without losing precision: > > StrictMath, original StrictMath, optimized > ============================ ============================ > sin 1.7136493465700542 1m41.184s 1.7136493465700542 0m33.895s > cos 0.1709843554185943 1m41.200s 0.1709843554185943 0m33.884s > tan -5.5500322522995315E7 1m46.976s -5.5500322522995315E7 0m36.461s > asin NaN 0m4.543s NaN 0m3.175s > acos NaN 0m4.525s NaN 0m3.211s > atan 1.5707961389886132E8 0m12.896s 1.5707961389886132E8 0m7.100s > exp Infinity 0m4.570s Infinity 0m3.187s > log 1.7420680845245087E9 0m14.239s 1.7420680845245087E9 0m7.170s > log10 7.565705562087342E8 0m20.236s 7.565705562087342E8 0m9.610s > sqrt 6.66666671666567E11 0m0.981s 6.66666671666567E11 0m0.948s > cbrt 3.481191648389617E10 0m10.808s 3.481191648389617E10 0m10.786s > sinh Infinity 0m4.433s Infinity 0m3.179s > cosh Infinity 0m4.478s Infinity 0m3.174s > tanh 9.999999971990079E7 0m3.353s 9.999999971990079E7 0m3.208s > expm1 Infinity 0m4.094s Infinity 0m3.185s > log1p 1.7420681029451895E9 0m13.527s 1.7420681029451895E9 0m8.756s > IEEEremainder 502000.0 0m38.909s 502000.0 0m14.055s > atan2 1.570453905253704E8 0m20.057s 1.570453905253704E8 0m10.510s > pow Infinity 0m19.938s Infinity 0m20.204s > hypot 5.000000099033372E15 0m5.122s 5.000000099033372E15 0m5.130s > > > I believe that as the FC is passed but FEC is not the change can, after the due > scrutiny and review, be pushed if a special exception approval grants it. Once > on 9, I'll request the downport to 8. > > Could I open a bug to address that issue? > > Thank you very much. > > > Regards, > Gustavo > > [1] http://hg.openjdk.java.net/jdk9/hs/jdk/file/81eb4bd34611/make/lib/CoreLibraries.gmk#l39 > [2] https://github.com/gromero/strictmath (comparison script used to get the results) > From huaming.li at oracle.com Thu Nov 17 06:46:43 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 17 Nov 2016 14:46:43 +0800 Subject: RFR of JDK-8168975: java/rmi/activation/Activatable tests fail due to "Port already in use" in RMID.restart() In-Reply-To: <12b34d35-d7de-6268-771f-1c0ac6f883fa@oracle.com> References: <68995a74-8e19-9462-1ff3-cd32a3a40441@oracle.com> <5E268B7B-5C74-456F-BCCC-4CB0670C5E30@oracle.com> <12b34d35-d7de-6268-771f-1c0ac6f883fa@oracle.com> Message-ID: <1a3633ad-33e1-2646-b4e8-9ba492a8f7cf@oracle.com> Hi Chris, Joe, Roger, Thank you for reviewing. Please check the comments inline. new webrev: http://cr.openjdk.java.net/~mli/8168975/webrev.01/ Thank you -Hamlin On 2016/11/17 2:30, joe darcy wrote: > In terms of timeout, please use much shorter timeout, seconds not > minutes. In case of timeout value used in RMID.restart() and RMIDSelectorProvider.inheritedChannel(), I recommend to set it longer, reason is: 1. in most of runs, the test will not face a "port in use" issue, because the time window between RMID.start and RMID.restart is small, so a long timeout value will not impact the test run time; 2. if there is a interloper between RMID.start() and RMID.restart(), then it's better to wait for a longer time to grab the expected port again rather than wait shorter time to get a test failure. > Most JDK regression tests complete in well under 10 seconds and few > tests should run for as long as a minute. After set "sun.rmi.transport.tcp.handshakeTimeout=5000", test will not waste too much time at RMID.lookupSystem, normal tests which use RMID.start and RMID.restart will finish in about dozens of seconds. I guess running time is acceptable. > Also, please scale any timeout if a timeout factor retrieved from the > jtreg environment. This allows the test to behave better on heavily > loaded or slow machines where the test invoker has requested more time. Fixed, scale timeout in RMID.restart and RMIDSelectorProvider.inheritedChannel based on jtreg time factor. > > Thanks, > > -Joe > > > On 11/16/2016 9:01 AM, Chris Hegarty wrote: >>> On 16 Nov 2016, at 07:36, Hamlin Li wrote: >>> >>> Would you please review below fix? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8168975 >>> webrev: http://cr.openjdk.java.net/~mli/8168975/webrev.00/ >> The approach builds on the mechanism put in for 8168975, and seems >> reasonable. >> >> The system property being used to ?pass? the port number is specific to >> the test, and not JDK related so should not be named >> java.nio.channels.spi.SelectorProviderPort. Maybe something like >> openjdk.test.RMIDSelectorProvider.port ? Fixed, modify as "test.java.rmi.testlibrary.RMIDSelectorProvider.port". >> >> -Chris. >> >>> Root Cause: There is a time window between RMID.start() and >>> RMID.restart(), interloper can step in and bind to the port used by >>> RMID in RMID.start(). >>> >>> Solution: Modify RMID.java to use inherited channel when calling >>> RMID.restart. And extend RMIDSelectorProvider.java to try to bind to >>> specific port, no matter 0 or none-zero(for RMID.restart) in a while >>> loop, if timeout just call System.exit to exit rmid and let test fail. >>> >>> >>> Thank you >>> -Hamlin > From Alan.Bateman at oracle.com Thu Nov 17 07:02:13 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Nov 2016 07:02:13 +0000 Subject: RFR 8136831 : Undefined null behavior in Class[Loader].getResourceXXXX() In-Reply-To: References: Message-ID: Brent - the null check in Class::getResourceXXX looks really odd, particularly because resolveName accepts null. Since we've changed this in the jake forest to do the right thing then I'm wondering if it would be better if you dropped this part from your patch, would that be okay? -Alan On 16/11/2016 23:22, Brent Christian wrote: > Hi, > > Please review my fix for 8136831 - Undefined null behavior in > Class[Loader].getResourceXXXX(). > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8136831 > Webrev: > http://cr.openjdk.java.net/~bchristi/8136831/webrev.00/ > > > Class and ClassLoader have the following public methods for locating > resources by name: > > Class.getResource(String name) > Class.getResourceAsStream(String name) > ClassLoader.getResource(String name) > ClassLoader.getResourceAsStream(String name) > ClassLoader.getResources(String name) > > Of these, only Class.getResourceAsStream() specifies the behavior when > passed a null 'name' argument - throw a NullPointerException. > > All methods throw an NPE in this case (going back at least to JDK 7u), > with ClassLoader.getResources() being something of an exception. As > described in the bug report, it returns an Enumeration object with a > buggy implementation which throws an NPE from hasMoreElements(). > > As of the module system going into JDK9b111, these methods no longer > throw an NPE, but return null (again, with the exception of > ClassLoader.getResources(), which now returns a non-buggy Enumeration > with working hasMoreElements() method). > > I believe this issue should be resolved as follows: > > 1. Restore the historical NPE behavior by adding code to ensure this > behavior (instead of relying on it happening incidentally deeper in > the code - see the stack traces in the bug report). > > 2. Specify @throws NPE in the JavaDoc for these methods. > > For ClassLoader.getResources() this is a change in behavior, though > the old behavior of returning a buggy Enumeration is not worth > keeping. Better to fail fast, and behave like other related methods. > > Thanks, > -Brent > From christoph.langer at sap.com Thu Nov 17 07:52:40 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 17 Nov 2016 07:52:40 +0000 Subject: RFR (JAXP) 8158619: Very large CDATA section in XML document causes OOME In-Reply-To: <582CD9DF.8000402@oracle.com> References: <582CD9DF.8000402@oracle.com> Message-ID: Hi Joe, this looks good and contains nice cleanups (some of them I have as well in my changes for 8169631 :) ). Some formatting nits: src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java: line 975 map.put(className+".class", attr); spaces left and right of '+' src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java 168 private final Map> _loadedExternalExtensionFunctions; 175 TransletClassLoader(ClassLoader parent,Map> mapEF) { spaces in Map declaration src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java 288 public Map> getExternalExtensionsMap() { spaces src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaLoader.java 700 LocationArray la = (locations.get(XMLSymbols.EMPTY_STRING)); Braces are unneeded 354 null, null, null, null, JdkXmlUtils.CDATA_CHUNK_SIZE_DEFAULT}; Add 2 more spaces in the beginning and a space before the closing } Best regards Christoph > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf > Of Joe Wang > Sent: Mittwoch, 16. November 2016 23:13 > To: core-libs-dev at openjdk.java.net > Subject: RFR (JAXP) 8158619: Very large CDATA section in XML document > causes OOME > > Hi, > > Please review an enhancement adding a property to allow for specifying > the chunk size of CDATA. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8158619 > webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8158619/webrev/ > > Thanks, > Joe From frank.yuan at oracle.com Thu Nov 17 07:52:57 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Thu, 17 Nov 2016 15:52:57 +0800 Subject: RFR (JAXP) JDK-8169829 ProblemList update for javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh Message-ID: <021201d240a7$9e017f20$da047d60$@oracle.com> Hi all This is to correct the bugid in ProblemList.txt, see Bug: https://bugs.openjdk.java.net/browse/JDK-8169829 Would you like to have a review http://cr.openjdk.java.net/~fyuan/8169829/webrev.00/? Thanks, Frank From sergei.kovalev at oracle.com Thu Nov 17 09:04:27 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Thu, 17 Nov 2016 12:04:27 +0300 Subject: RFR(s): 8169658: javax/rmi tests have undeclared dependencies In-Reply-To: References: Message-ID: <671b1ad8-5c85-b239-90e4-4745bd1be560@oracle.com> Hello, Resending request for review 14.11.16 20:26, Sergei Kovalev wrote: > Hello team, > > Please review a very small fix for tests. > > BugID: https://bugs.openjdk.java.net/browse/JDK-8169658 > WebRev: http://cr.openjdk.java.net/~skovalev/8169658/webrev.00/ > > Issue: Two tests from RMI test group have undeclared dependency on > java.rmi and java.naming modules. > -- With best regards, Sergei From sergei.kovalev at oracle.com Thu Nov 17 09:04:52 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Thu, 17 Nov 2016 12:04:52 +0300 Subject: RFR(s): 8169721: [TESTBUG] com/sun/jndi tests have undeclared dependency on java.naming module In-Reply-To: References: Message-ID: <7b91fc0e-5d21-826e-2d7d-07acf2ee4c5b@oracle.com> Hello, Resending request for review 15.11.16 17:34, Sergei Kovalev wrote: > Hi Team, > > Please review a small fix for tests. > > BugID: https://bugs.openjdk.java.net/browse/JDK-8169721 > Web review: http://cr.openjdk.java.net/~skovalev/8169721/webrev.00/ > > Issue: most tests has missed dependency om java.naming module. > Solution: add missed module declaration for tests. If this possible, > add module declaration to TEST.properties file to avoid modification > of each individual test. > -- With best regards, Sergei From erik.joelsson at oracle.com Thu Nov 17 09:17:33 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 17 Nov 2016 10:17:33 +0100 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <37b58c35-72b2-cc19-f175-6d1cff410213@oracle.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> <37b58c35-72b2-cc19-f175-6d1cff410213@oracle.com> Message-ID: <9dea2dbf-4413-c03e-1cd6-8aceb0e263a0@oracle.com> Hello, Overall this looks reasonable to me. However, if we want to introduce a new possible tuple for specifying compilation flags to SetupNativeCompilation, we (the build team) would prefer if we used OPENJDK_TARGET_CPU instead of OPENJDK_TARGET_CPU_ARCH. /Erik On 2016-11-17 03:31, David Holmes wrote: > Adding in build-dev as they need to scrutinize all build changes. > > David > > On 17/11/2016 11:45 AM, Gustavo Romero wrote: >> Hi, >> >> Currently, optimization for building fdlibm is disabled, except for the >> "solaris" OS target [1]. >> >> As a consequence on PPC64 (Linux) StrictMath methods like, but not >> limited to, >> sin(), cos(), and tan() perform verify poor in comparison to the same >> methods >> in Math class [2]: >> >> Math StrictMath >> ========= ========== >> sin 0m29.984s 1m41.184s >> cos 0m30.031s 1m41.200s >> tan 0m31.772s 1m46.976s >> asin 0m4.577s 0m4.543s >> acos 0m4.539s 0m4.525s >> atan 0m12.929s 0m12.896s >> exp 0m1.071s 0m4.570s >> log 0m3.272s 0m14.239s >> log10 0m4.362s 0m20.236s >> sqrt 0m0.913s 0m0.981s >> cbrt 0m10.786s 0m10.808s >> sinh 0m4.438s 0m4.433s >> cosh 0m4.496s 0m4.478s >> tanh 0m3.360s 0m3.353s >> expm1 0m4.076s 0m4.094s >> log1p 0m13.518s 0m13.527s >> IEEEremainder 0m38.803s 0m38.909s >> atan2 0m20.100s 0m20.057s >> pow 0m14.096s 0m19.938s >> hypot 0m5.136s 0m5.122s >> >> >> Switching on the O3 optimization can damage precision of those methods, >> nonetheless it's possible to avoid that side effect and yet get huge >> benefits of >> the -O3 optimization on PPC64 if -fno-expensive-optimizations is >> passed in >> addition to the -O3 optimization flag. >> >> In that sense the following change is proposed to resolve the issue: >> >> diff -r 81eb4bd34611 make/lib/CoreLibraries.gmk >> --- a/make/lib/CoreLibraries.gmk Wed Nov 09 13:37:19 2016 +0100 >> +++ b/make/lib/CoreLibraries.gmk Wed Nov 16 19:11:11 2016 -0500 >> @@ -33,10 +33,16 @@ >> # libfdlibm is statically linked with libjava below and not >> delivered into the >> # product on its own. >> >> -BUILD_LIBFDLIBM_OPTIMIZATION := HIGH >> +BUILD_LIBFDLIBM_OPTIMIZATION := NONE >> >> -ifneq ($(OPENJDK_TARGET_OS), solaris) >> - BUILD_LIBFDLIBM_OPTIMIZATION := NONE >> +ifeq ($(OPENJDK_TARGET_OS), solaris) >> + BUILD_LIBFDLIBM_OPTIMIZATION := HIGH >> +endif >> + >> +ifeq ($(OPENJDK_TARGET_OS), linux) >> + ifeq ($(OPENJDK_TARGET_CPU_ARCH), ppc) >> + BUILD_LIBFDLIBM_OPTIMIZATION := HIGH >> + endif >> endif >> >> LIBFDLIBM_SRC := $(JDK_TOPDIR)/src/java.base/share/native/libfdlibm >> @@ -51,6 +57,7 @@ >> CFLAGS := $(CFLAGS_JDKLIB) $(LIBFDLIBM_CFLAGS), \ >> CFLAGS_windows_debug := -DLOGGING, \ >> CFLAGS_aix := -qfloat=nomaf, \ >> + CFLAGS_linux_ppc := -fno-expensive-optimizations, \ >> DISABLED_WARNINGS_gcc := sign-compare, \ >> DISABLED_WARNINGS_microsoft := 4146 4244 4018, \ >> ARFLAGS := $(ARFLAGS), \ >> >> >> diff -r 2a1f97c0ad3d make/common/NativeCompilation.gmk >> --- a/make/common/NativeCompilation.gmk Wed Nov 09 15:32:39 2016 >> +0100 >> +++ b/make/common/NativeCompilation.gmk Wed Nov 16 19:08:06 2016 >> -0500 >> @@ -569,16 +569,19 @@ >> $1_ALL_OBJS := $$(sort $$($1_EXPECTED_OBJS) >> $$($1_EXTRA_OBJECT_FILES)) >> >> # Pickup extra OPENJDK_TARGET_OS_TYPE and/or OPENJDK_TARGET_OS >> dependent variables for CFLAGS. >> - $1_EXTRA_CFLAGS:=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)) >> $$($1_CFLAGS_$(OPENJDK_TARGET_OS)) >> + $1_EXTRA_CFLAGS:=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)) >> $$($1_CFLAGS_$(OPENJDK_TARGET_OS)) \ >> + $$($1_CFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU_ARCH)) >> ifneq ($(DEBUG_LEVEL),release) >> # Pickup extra debug dependent variables for CFLAGS >> $1_EXTRA_CFLAGS+=$$($1_CFLAGS_debug) >> $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)_debug) >> $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_debug) >> + >> $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU_ARCH)_debug) >> else >> $1_EXTRA_CFLAGS+=$$($1_CFLAGS_release) >> $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)_release) >> $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_release) >> + >> $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU_ARCH)_release) >> endif >> >> # Pickup extra OPENJDK_TARGET_OS_TYPE and/or OPENJDK_TARGET_OS >> dependent variables for CXXFLAGS. >> >> >> After enabling the optimization it's possible to again up to 3x on >> performance >> regarding the aforementioned methods without losing precision: >> >> StrictMath, original StrictMath, optimized >> ============================ >> ============================ >> sin 1.7136493465700542 1m41.184s 1.7136493465700542 >> 0m33.895s >> cos 0.1709843554185943 1m41.200s 0.1709843554185943 >> 0m33.884s >> tan -5.5500322522995315E7 1m46.976s >> -5.5500322522995315E7 0m36.461s >> asin NaN 0m4.543s >> NaN 0m3.175s >> acos NaN 0m4.525s >> NaN 0m3.211s >> atan 1.5707961389886132E8 0m12.896s >> 1.5707961389886132E8 0m7.100s >> exp Infinity 0m4.570s Infinity 0m3.187s >> log 1.7420680845245087E9 0m14.239s >> 1.7420680845245087E9 0m7.170s >> log10 7.565705562087342E8 0m20.236s 7.565705562087342E8 >> 0m9.610s >> sqrt 6.66666671666567E11 0m0.981s 6.66666671666567E11 >> 0m0.948s >> cbrt 3.481191648389617E10 0m10.808s 3.481191648389617E10 >> 0m10.786s >> sinh Infinity 0m4.433s Infinity 0m3.179s >> cosh Infinity 0m4.478s Infinity 0m3.174s >> tanh 9.999999971990079E7 0m3.353s 9.999999971990079E7 >> 0m3.208s >> expm1 Infinity 0m4.094s Infinity 0m3.185s >> log1p 1.7420681029451895E9 0m13.527s >> 1.7420681029451895E9 0m8.756s >> IEEEremainder 502000.0 0m38.909s 502000.0 0m14.055s >> atan2 1.570453905253704E8 0m20.057s 1.570453905253704E8 >> 0m10.510s >> pow Infinity 0m19.938s Infinity 0m20.204s >> hypot 5.000000099033372E15 0m5.122s >> 5.000000099033372E15 0m5.130s >> >> >> I believe that as the FC is passed but FEC is not the change can, >> after the due >> scrutiny and review, be pushed if a special exception approval grants >> it. Once >> on 9, I'll request the downport to 8. >> >> Could I open a bug to address that issue? >> >> Thank you very much. >> >> >> Regards, >> Gustavo >> >> [1] >> http://hg.openjdk.java.net/jdk9/hs/jdk/file/81eb4bd34611/make/lib/CoreLibraries.gmk#l39 >> [2] https://github.com/gromero/strictmath (comparison script used to >> get the results) >> From daniel.fuchs at oracle.com Thu Nov 17 10:59:14 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 17 Nov 2016 10:59:14 +0000 Subject: RFR (JAXP) 8158619: Very large CDATA section in XML document causes OOME In-Reply-To: <582CD9DF.8000402@oracle.com> References: <582CD9DF.8000402@oracle.com> Message-ID: <9765a7ab-1453-c7f5-02cb-f19fcf95839e@oracle.com> Hi Joe, Good to see some raw type uses corrected :-) nit: there are some very long lines that could be split to help side-by-side reviewing, like e.g. in XSDHandler.java, Parser.java, etc... I know that most of these files already have long lines (and some of them would probably benefit from an automatic reformatting & cleanup sometime), but maybe the new code ought to try to fit the 80 columns convention :-) XMLDocumentFragmentScannerImpl.java: should lines 1715 - 1723 be removed as well? JdkXmlUtils.java 85 if (value.getClass().isAssignableFrom(Integer.class)) { 86 return (Integer)value; 87 } else { 88 return Integer.parseInt((String) value); 89 } I think you got the comparison wrong. Anyway I'd suggest something simpler here: the code above is a bit bizarre. if (value instanceof Number) { return ((Number) value).intValue(); } else if (value instanceof String) { return Integer.parseInt(String.valueOf(value)); } else { throw IllegalArgumentException("Unexpected class: " + value.getClass()); } best regards, -- daniel On 16/11/16 22:12, Joe Wang wrote: > Hi, > > Please review an enhancement adding a property to allow for specifying > the chunk size of CDATA. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8158619 > webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8158619/webrev/ > > Thanks, > Joe > From lance.andersen at oracle.com Thu Nov 17 12:40:13 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 17 Nov 2016 07:40:13 -0500 Subject: RFR (JAXP) JDK-8169829 ProblemList update for javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh In-Reply-To: <021201d240a7$9e017f20$da047d60$@oracle.com> References: <021201d240a7$9e017f20$da047d60$@oracle.com> Message-ID: Hi Frank This is fine. For something this trivial, you can just include the diff in the email vs generating a webrev? Best Lance > On Nov 17, 2016, at 2:52 AM, Frank Yuan wrote: > > Hi all > > > > This is to correct the bugid in ProblemList.txt, see Bug: https://bugs.openjdk.java.net/browse/JDK-8169829 > > > > Would you like to have a review http://cr.openjdk.java.net/~fyuan/8169829/webrev.00/? > > > > > > Thanks, > > > > Frank > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Thu Nov 17 13:43:06 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 17 Nov 2016 08:43:06 -0500 Subject: RFR (JAXP) 8158619: Very large CDATA section in XML document causes OOME In-Reply-To: <582CD9DF.8000402@oracle.com> References: <582CD9DF.8000402@oracle.com> Message-ID: <7B7EDFA7-E895-418E-A8F4-E7B8DC3A5301@oracle.com> Hi Joe, Overall looks good. I agree with Daniel that you might want to reconsider reworking JdkXmlUtils.getValue to make it a bit more robust incase of an surprise Object passed for value. HTH Best Lance > On Nov 16, 2016, at 5:12 PM, Joe Wang wrote: > > Hi, > > Please review an enhancement adding a property to allow for specifying the chunk size of CDATA. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8158619 > webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8158619/webrev/ > > Thanks, > Joe > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From daniel.fuchs at oracle.com Thu Nov 17 15:19:31 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 17 Nov 2016 15:19:31 +0000 Subject: RFR(s): 8169721: [TESTBUG] com/sun/jndi tests have undeclared dependency on java.naming module In-Reply-To: References: Message-ID: <41d5049c-30af-25bf-eff6-0a7837d1eb51@oracle.com> Hi Sergey, I added a System.out.println in UnbindIdempotent (see diff below) to double check which type of context object was expected: Got context: class com.sun.jndi.rmi.registry.RegistryContext This lets me think that this test does not depend on java.naming but rather on jdk.naming.rmi - and that if you simply link with java.naming then the test might simply pass without doing nothing because it gets a NamingException at line 54. Could you please double check this (verify what the test actually does with --limit-mods and your current change)? You might also want to keep the traces I added (below) to improve diagnosis in case of test failures. The other changes look good - I think - though I am not the usual maintainer of this area. best regards, -- daniel diff --git a/test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java b/test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java --- a/test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java +++ b/test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java @@ -49,8 +49,10 @@ try { rctx = (Context)ictx.lookup("rmi://localhost:" + Integer.toString(registryPort)); + System.out.println("Got context: " + rctx.getClass()); } catch (NamingException e) { // Unable to set up for test. + System.out.println("Warning: Can't run test: " + e); return; } On 15/11/16 14:34, Sergei Kovalev wrote: > Hi Team, > > Please review a small fix for tests. > > BugID: https://bugs.openjdk.java.net/browse/JDK-8169721 > Web review: http://cr.openjdk.java.net/~skovalev/8169721/webrev.00/ > > Issue: most tests has missed dependency om java.naming module. > Solution: add missed module declaration for tests. If this possible, add > module declaration to TEST.properties file to avoid modification of each > individual test. > From claes.redestad at oracle.com Thu Nov 17 15:33:22 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 17 Nov 2016 16:33:22 +0100 Subject: RFR: 8169880: Remove the sun.reflect.noCaches option Message-ID: <582DCDC2.3000800@oracle.com> Hi, The undocumented sun.reflect.noCaches option was put in place as a debugging aid when caching was added to core reflection[1], with the intent to remove it once overly inefficient uses of reflection was weeded out[2]. This appears to have been forgotten and should be cleaned up. Webrev: http://cr.openjdk.java.net/~redestad/8169880/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8169880 Thanks! /Claes [1] https://bugs.openjdk.java.net/browse/JDK-4419062 [2] https://bugs.openjdk.java.net/browse/JDK-4430358 From shade at redhat.com Thu Nov 17 15:36:07 2016 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 17 Nov 2016 16:36:07 +0100 Subject: RFR: 8169880: Remove the sun.reflect.noCaches option In-Reply-To: <582DCDC2.3000800@oracle.com> References: <582DCDC2.3000800@oracle.com> Message-ID: <0718b868-2790-cbed-2667-a8ce8b596b5e@redhat.com> On 11/17/2016 04:33 PM, Claes Redestad wrote: > The undocumented sun.reflect.noCaches option was put in place as a > debugging aid when caching was added to core reflection[1], with the > intent to remove it once overly inefficient uses of reflection was > weeded out[2]. This appears to have been forgotten and should be > cleaned up. > > Webrev: http://cr.openjdk.java.net/~redestad/8169880/webrev.01/ I did see this option used in performance tests during recent Reflection caching work, but has no problem with removing it, as it is addable on the spot. Thanks, -Aleksey From claes.redestad at oracle.com Thu Nov 17 15:44:20 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 17 Nov 2016 16:44:20 +0100 Subject: RFR: 8169880: Remove the sun.reflect.noCaches option In-Reply-To: <0718b868-2790-cbed-2667-a8ce8b596b5e@redhat.com> References: <582DCDC2.3000800@oracle.com> <0718b868-2790-cbed-2667-a8ce8b596b5e@redhat.com> Message-ID: <582DD054.4040003@oracle.com> On 2016-11-17 16:36, Aleksey Shipilev wrote: > On 11/17/2016 04:33 PM, Claes Redestad wrote: >> The undocumented sun.reflect.noCaches option was put in place as a >> debugging aid when caching was added to core reflection[1], with the >> intent to remove it once overly inefficient uses of reflection was >> weeded out[2]. This appears to have been forgotten and should be >> cleaned up. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8169880/webrev.01/ > > I did see this option used in performance tests during recent Reflection > caching work, but has no problem with removing it, as it is addable on > the spot. OK, thanks for reviewing! /Claes From Roger.Riggs at Oracle.com Thu Nov 17 15:45:16 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 17 Nov 2016 10:45:16 -0500 Subject: RFR(s): 8169658: javax/rmi tests have undeclared dependencies In-Reply-To: <671b1ad8-5c85-b239-90e4-4745bd1be560@oracle.com> References: <671b1ad8-5c85-b239-90e4-4745bd1be560@oracle.com> Message-ID: <51b18edd-fa06-495c-e373-4034a46bdf7e@Oracle.com> Looks fine Regards, Roger On 11/17/2016 4:04 AM, Sergei Kovalev wrote: > Hello, > > Resending request for review > > > 14.11.16 20:26, Sergei Kovalev wrote: >> Hello team, >> >> Please review a very small fix for tests. >> >> BugID: https://bugs.openjdk.java.net/browse/JDK-8169658 >> WebRev: http://cr.openjdk.java.net/~skovalev/8169658/webrev.00/ >> >> Issue: Two tests from RMI test group have undeclared dependency on >> java.rmi and java.naming modules. >> > From joe.darcy at oracle.com Thu Nov 17 17:35:05 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 17 Nov 2016 09:35:05 -0800 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <582D0BCE.2030209@linux.vnet.ibm.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> Message-ID: Hello, On 11/16/2016 5:45 PM, Gustavo Romero wrote: > Hi, > > Currently, optimization for building fdlibm is disabled, except for the > "solaris" OS target [1]. The reason for that is because historically the Solaris compilers have had sufficient discipline and control regarding floating-point semantics and compiler optimizations to still implement the Java-mandated results when optimization was enabled. The gcc family of compilers, for example, has lacked such discipline. > > As a consequence on PPC64 (Linux) StrictMath methods like, but not limited to, > sin(), cos(), and tan() perform verify poor in comparison to the same methods > in Math class [2]: If you are doing your work against JDK 9, note that the pow, hypot, and cbrt fdlibm methods required by StrictMath have been ported to Java (JDK-8134780: Port fdlibm to Java). I have intentions to port the remaining methods to Java, but it is unclear whether or not this will occur for JDK 9. Methods in the Math class, such as pow, are often intrinsified and use a different algorithm so a straight performance comparison may not be as fair or meaningful in those cases. > > Math StrictMath > ========= ========== > sin 0m29.984s 1m41.184s > cos 0m30.031s 1m41.200s > tan 0m31.772s 1m46.976s > asin 0m4.577s 0m4.543s > acos 0m4.539s 0m4.525s > atan 0m12.929s 0m12.896s > exp 0m1.071s 0m4.570s > log 0m3.272s 0m14.239s > log10 0m4.362s 0m20.236s > sqrt 0m0.913s 0m0.981s > cbrt 0m10.786s 0m10.808s > sinh 0m4.438s 0m4.433s > cosh 0m4.496s 0m4.478s > tanh 0m3.360s 0m3.353s > expm1 0m4.076s 0m4.094s > log1p 0m13.518s 0m13.527s > IEEEremainder 0m38.803s 0m38.909s > atan2 0m20.100s 0m20.057s > pow 0m14.096s 0m19.938s > hypot 0m5.136s 0m5.122s > > > Switching on the O3 optimization can damage precision of those methods, > nonetheless it's possible to avoid that side effect and yet get huge benefits of > the -O3 optimization on PPC64 if -fno-expensive-optimizations is passed in > addition to the -O3 optimization flag. > > In that sense the following change is proposed to resolve the issue: > > diff -r 81eb4bd34611 make/lib/CoreLibraries.gmk > --- a/make/lib/CoreLibraries.gmk Wed Nov 09 13:37:19 2016 +0100 > +++ b/make/lib/CoreLibraries.gmk Wed Nov 16 19:11:11 2016 -0500 > @@ -33,10 +33,16 @@ > # libfdlibm is statically linked with libjava below and not delivered into the > # product on its own. > > -BUILD_LIBFDLIBM_OPTIMIZATION := HIGH > +BUILD_LIBFDLIBM_OPTIMIZATION := NONE > > -ifneq ($(OPENJDK_TARGET_OS), solaris) > - BUILD_LIBFDLIBM_OPTIMIZATION := NONE > +ifeq ($(OPENJDK_TARGET_OS), solaris) > + BUILD_LIBFDLIBM_OPTIMIZATION := HIGH > +endif > + > +ifeq ($(OPENJDK_TARGET_OS), linux) > + ifeq ($(OPENJDK_TARGET_CPU_ARCH), ppc) > + BUILD_LIBFDLIBM_OPTIMIZATION := HIGH > + endif > endif > > LIBFDLIBM_SRC := $(JDK_TOPDIR)/src/java.base/share/native/libfdlibm > @@ -51,6 +57,7 @@ > CFLAGS := $(CFLAGS_JDKLIB) $(LIBFDLIBM_CFLAGS), \ > CFLAGS_windows_debug := -DLOGGING, \ > CFLAGS_aix := -qfloat=nomaf, \ > + CFLAGS_linux_ppc := -fno-expensive-optimizations, \ > DISABLED_WARNINGS_gcc := sign-compare, \ > DISABLED_WARNINGS_microsoft := 4146 4244 4018, \ > ARFLAGS := $(ARFLAGS), \ > > > diff -r 2a1f97c0ad3d make/common/NativeCompilation.gmk > --- a/make/common/NativeCompilation.gmk Wed Nov 09 15:32:39 2016 +0100 > +++ b/make/common/NativeCompilation.gmk Wed Nov 16 19:08:06 2016 -0500 > @@ -569,16 +569,19 @@ > $1_ALL_OBJS := $$(sort $$($1_EXPECTED_OBJS) $$($1_EXTRA_OBJECT_FILES)) > > # Pickup extra OPENJDK_TARGET_OS_TYPE and/or OPENJDK_TARGET_OS dependent variables for CFLAGS. > - $1_EXTRA_CFLAGS:=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)) $$($1_CFLAGS_$(OPENJDK_TARGET_OS)) > + $1_EXTRA_CFLAGS:=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)) $$($1_CFLAGS_$(OPENJDK_TARGET_OS)) \ > + $$($1_CFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU_ARCH)) > ifneq ($(DEBUG_LEVEL),release) > # Pickup extra debug dependent variables for CFLAGS > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_debug) > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)_debug) > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_debug) > + $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU_ARCH)_debug) > else > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_release) > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)_release) > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_release) > + $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU_ARCH)_release) > endif > > # Pickup extra OPENJDK_TARGET_OS_TYPE and/or OPENJDK_TARGET_OS dependent variables for CXXFLAGS. > > > After enabling the optimization it's possible to again up to 3x on performance > regarding the aforementioned methods without losing precision: > > StrictMath, original StrictMath, optimized > ============================ ============================ > sin 1.7136493465700542 1m41.184s 1.7136493465700542 0m33.895s > cos 0.1709843554185943 1m41.200s 0.1709843554185943 0m33.884s > tan -5.5500322522995315E7 1m46.976s -5.5500322522995315E7 0m36.461s > asin NaN 0m4.543s NaN 0m3.175s > acos NaN 0m4.525s NaN 0m3.211s > atan 1.5707961389886132E8 0m12.896s 1.5707961389886132E8 0m7.100s > exp Infinity 0m4.570s Infinity 0m3.187s > log 1.7420680845245087E9 0m14.239s 1.7420680845245087E9 0m7.170s > log10 7.565705562087342E8 0m20.236s 7.565705562087342E8 0m9.610s > sqrt 6.66666671666567E11 0m0.981s 6.66666671666567E11 0m0.948s > cbrt 3.481191648389617E10 0m10.808s 3.481191648389617E10 0m10.786s > sinh Infinity 0m4.433s Infinity 0m3.179s > cosh Infinity 0m4.478s Infinity 0m3.174s > tanh 9.999999971990079E7 0m3.353s 9.999999971990079E7 0m3.208s > expm1 Infinity 0m4.094s Infinity 0m3.185s > log1p 1.7420681029451895E9 0m13.527s 1.7420681029451895E9 0m8.756s > IEEEremainder 502000.0 0m38.909s 502000.0 0m14.055s > atan2 1.570453905253704E8 0m20.057s 1.570453905253704E8 0m10.510s > pow Infinity 0m19.938s Infinity 0m20.204s > hypot 5.000000099033372E15 0m5.122s 5.000000099033372E15 0m5.130s > > > I believe that as the FC is passed but FEC is not the change can, after the due > scrutiny and review, be pushed if a special exception approval grants it. Once > on 9, I'll request the downport to 8. Accumulating the the results of the functions and comparisons the sums is not a sufficiently robust way of checking to see if the optimized versions are indeed equivalent to the non-optimized ones. The specification of StrictMath requires a particular result for each set of floating-point arguments and sums get round-away low-order bits that differ. Running the JDK math library regression tests and corresponding JCK tests is recommended for work in this area. Cheers, -Joe From gromero at linux.vnet.ibm.com Thu Nov 17 17:45:59 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 17 Nov 2016 15:45:59 -0200 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <37b58c35-72b2-cc19-f175-6d1cff410213@oracle.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> <37b58c35-72b2-cc19-f175-6d1cff410213@oracle.com> Message-ID: <582DECD7.4020901@linux.vnet.ibm.com> Hi David, On 17-11-2016 00:31, David Holmes wrote: > Adding in build-dev as they need to scrutinize all build changes. Thanks a lot. Regards, Gustavo From gromero at linux.vnet.ibm.com Thu Nov 17 17:47:40 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 17 Nov 2016 15:47:40 -0200 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <9dea2dbf-4413-c03e-1cd6-8aceb0e263a0@oracle.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> <37b58c35-72b2-cc19-f175-6d1cff410213@oracle.com> <9dea2dbf-4413-c03e-1cd6-8aceb0e263a0@oracle.com> Message-ID: <582DED3C.5030507@linux.vnet.ibm.com> Hi Erik, On 17-11-2016 07:17, Erik Joelsson wrote: > Overall this looks reasonable to me. However, if we want to introduce a new possible tuple for specifying compilation flags to SetupNativeCompilation, we (the build team) would prefer if we used > OPENJDK_TARGET_CPU instead of OPENJDK_TARGET_CPU_ARCH. Got it. Thanks a lot for that info. I'll take that into account. Regards, Gustavo From paul.sandoz at oracle.com Thu Nov 17 18:08:17 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 17 Nov 2016 10:08:17 -0800 Subject: RFR 8169838 java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java failed intermittently Message-ID: <5E46203E-0424-402A-8675-551FE6F2EE1C@oracle.com> Hi, Please review this small update to the spliterator traversing test to remove test cases for BitSet when the Integer.MAX_VALUE bit (or close to) is set. diff -r 382f7f3a1888 test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java --- a/test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java Wed Nov 16 14:26:14 2016 -0800 +++ b/test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java Thu Nov 17 10:03:56 2016 -0800 @@ -892,9 +892,6 @@ { "index 0", IntStream.of(0).toArray() }, { "index 255", IntStream.of(255).toArray() }, { "index 0 and 255", IntStream.of(0, 255).toArray() }, - { "index Integer.MAX_VALUE", IntStream.of(Integer.MAX_VALUE).toArray() }, - { "index Integer.MAX_VALUE - 1", IntStream.of(Integer.MAX_VALUE - 1).toArray() }, - { "index 0 and Integer.MAX_VALUE", IntStream.of(0, Integer.MAX_VALUE).toArray() }, { "every bit", IntStream.range(0, 255).toArray() }, { "step 2", IntStream.range(0, 255).map(f -> f * 2).toArray() }, { "step 3", IntStream.range(0, 255).map(f -> f * 3).toArray() }, Such cases are causing out of memory test failures (not reproduced when running locally). Separately, we need to refactor the spliterator traversing tests into a separate library (which should anyway be done): https://bugs.openjdk.java.net/browse/JDK-8169903 And then add specific BitSet tests with large memory requirements. Thanks, Paul. From paul.sandoz at oracle.com Thu Nov 17 18:25:40 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 17 Nov 2016 10:25:40 -0800 Subject: RFR 8136831 : Undefined null behavior in Class[Loader].getResourceXXXX() In-Reply-To: <1d9ea794-e643-4a07-66a6-6a4196e55f8c@oracle.com> References: <844FDA4B-AD61-4A76-B966-AF8743E70458@oracle.com> <1d9ea794-e643-4a07-66a6-6a4196e55f8c@oracle.com> Message-ID: <8F44D77B-55F4-4EA6-99FE-AAF59D1252AD@oracle.com> > On 16 Nov 2016, at 17:02, Brent Christian wrote: > > On 11/16/16 3:44 PM, Paul Sandoz wrote: >> Hi Brent, >> >> I think it would be better to use Objects.requireNonNull > > Yes, thank you - forgot about that. > >> IMHO no need to specify a exception message, or test for that (which i think is too brittle). > > OK. > > Updated webrev: > http://cr.openjdk.java.net/~bchristi/8136831/webrev.01/ > Looks ok, but has indicated by Alan i would leave Class alone and untested until Jake gets integrated, then follow up with another issue. >> You will need to file a CCC for the change in behaviour of the Enumeration returning getResources. > > And for the new @throws, I should think. > Yes. Thanks, Paul. From gromero at linux.vnet.ibm.com Thu Nov 17 18:31:00 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 17 Nov 2016 16:31:00 -0200 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <582D0BCE.2030209@linux.vnet.ibm.com> Message-ID: <582DF764.70504@linux.vnet.ibm.com> Hi Joe, Thanks a lot for your valuable comments. On 17-11-2016 15:35, joe darcy wrote: >> Currently, optimization for building fdlibm is disabled, except for the >> "solaris" OS target [1]. > > The reason for that is because historically the Solaris compilers have had sufficient discipline and control regarding floating-point semantics and compiler optimizations to still implement the > Java-mandated results when optimization was enabled. The gcc family of compilers, for example, has lacked such discipline. oh, I see. Thanks for clarifying that. I was exactly wondering why fdlibm optimization is off even for x86_x64 as it, AFAICS regarding gcc 5 only, does not affect the precision, even if setting -O3 does not improve the performance as much as on PPC64. >> As a consequence on PPC64 (Linux) StrictMath methods like, but not limited to, >> sin(), cos(), and tan() perform verify poor in comparison to the same methods >> in Math class [2]: > > If you are doing your work against JDK 9, note that the pow, hypot, and cbrt fdlibm methods required by StrictMath have been ported to Java (JDK-8134780: Port fdlibm to Java). I have intentions to > port the remaining methods to Java, but it is unclear whether or not this will occur for JDK 9. Yes, I'm doing my work against 9. So is there any problem if I proceed with my change? I understand that there is no conflict as JDK-8134780 progresses and replaces the StrictMath methods by their counterparts in Java. Please, advice. Is it intended to downport JDK-8134780 to 8? > Methods in the Math class, such as pow, are often intrinsified and use a different algorithm so a straight performance comparison may not be as fair or meaningful in those cases. I agree. It's just that the issue on StrictMath methods was first noted due to that huge gap (Math vs StrictMath) on PPC64, which is not prominent on x64. > Accumulating the the results of the functions and comparisons the sums is not a sufficiently robust way of checking to see if the optimized versions are indeed equivalent to the non-optimized ones. > The specification of StrictMath requires a particular result for each set of floating-point arguments and sums get round-away low-order bits that differ. That's really good point, thanks for letting me know about that. I'll re-test my change under that perspective. > Running the JDK math library regression tests and corresponding JCK tests is recommended for work in this area. Got it. By "the JDK math library regression tests" you mean exactly which test suite? the jtreg tests? For testing against JCK/TCK I'll need some help on that. Thank you very much. Regards, Gustavo From paul.sandoz at oracle.com Thu Nov 17 18:33:40 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 17 Nov 2016 10:33:40 -0800 Subject: RFR: 8169880: Remove the sun.reflect.noCaches option In-Reply-To: <582DCDC2.3000800@oracle.com> References: <582DCDC2.3000800@oracle.com> Message-ID: <98CB1E03-8677-4200-94A0-44E3B41FE38D@oracle.com> +1 Paul. > On 17 Nov 2016, at 07:33, Claes Redestad wrote: > > Hi, > > The undocumented sun.reflect.noCaches option was put in place as a > debugging aid when caching was added to core reflection[1], with the > intent to remove it once overly inefficient uses of reflection was > weeded out[2]. This appears to have been forgotten and should be > cleaned up. > > Webrev: http://cr.openjdk.java.net/~redestad/8169880/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8169880 > > Thanks! > > /Claes > > [1] https://bugs.openjdk.java.net/browse/JDK-4419062 > [2] https://bugs.openjdk.java.net/browse/JDK-4430358 From mandy.chung at oracle.com Thu Nov 17 18:35:55 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 17 Nov 2016 10:35:55 -0800 Subject: RFR: 8169880: Remove the sun.reflect.noCaches option In-Reply-To: <582DCDC2.3000800@oracle.com> References: <582DCDC2.3000800@oracle.com> Message-ID: Looks good. Mandy > On Nov 17, 2016, at 7:33 AM, Claes Redestad wrote: > > Hi, > > The undocumented sun.reflect.noCaches option was put in place as a > debugging aid when caching was added to core reflection[1], with the > intent to remove it once overly inefficient uses of reflection was > weeded out[2]. This appears to have been forgotten and should be > cleaned up. > > Webrev: http://cr.openjdk.java.net/~redestad/8169880/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8169880 > > Thanks! > > /Claes > > [1] https://bugs.openjdk.java.net/browse/JDK-4419062 > [2] https://bugs.openjdk.java.net/browse/JDK-4430358 From claes.redestad at oracle.com Thu Nov 17 18:41:20 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 17 Nov 2016 19:41:20 +0100 Subject: RFR: 8169880: Remove the sun.reflect.noCaches option In-Reply-To: References: <582DCDC2.3000800@oracle.com> Message-ID: <582DF9D0.4080208@oracle.com> Paul, Mandy, thanks for reviewing! /Claes On 2016-11-17 19:35, Mandy Chung wrote: > Looks good. > > Mandy > >> On Nov 17, 2016, at 7:33 AM, Claes Redestad wrote: >> >> Hi, >> >> The undocumented sun.reflect.noCaches option was put in place as a >> debugging aid when caching was added to core reflection[1], with the >> intent to remove it once overly inefficient uses of reflection was >> weeded out[2]. This appears to have been forgotten and should be >> cleaned up. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8169880/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8169880 >> >> Thanks! >> >> /Claes >> >> [1] https://bugs.openjdk.java.net/browse/JDK-4419062 >> [2] https://bugs.openjdk.java.net/browse/JDK-4430358 > From Alan.Bateman at oracle.com Thu Nov 17 19:09:08 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Nov 2016 19:09:08 +0000 Subject: RFR 8136831 : Undefined null behavior in Class[Loader].getResourceXXXX() In-Reply-To: <8F44D77B-55F4-4EA6-99FE-AAF59D1252AD@oracle.com> References: <844FDA4B-AD61-4A76-B966-AF8743E70458@oracle.com> <1d9ea794-e643-4a07-66a6-6a4196e55f8c@oracle.com> <8F44D77B-55F4-4EA6-99FE-AAF59D1252AD@oracle.com> Message-ID: On 17/11/2016 18:25, Paul Sandoz wrote: >> On 16 Nov 2016, at 17:02, Brent Christian wrote: >> >> On 11/16/16 3:44 PM, Paul Sandoz wrote: >>> Hi Brent, >>> >>> I think it would be better to use Objects.requireNonNull >> Yes, thank you - forgot about that. >> >>> IMHO no need to specify a exception message, or test for that (which i think is too brittle). >> OK. >> >> Updated webrev: >> http://cr.openjdk.java.net/~bchristi/8136831/webrev.01/ >> > Looks ok, but has indicated by Alan i would leave Class alone and untested until Jake gets integrated, then follow up with another issue. > > Actually no follow-up needed because it's updated in jake to specify NPE. -Alan From martinrb at google.com Thu Nov 17 19:14:53 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 17 Nov 2016 11:14:53 -0800 Subject: RFR 8169838 java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java failed intermittently In-Reply-To: <5E46203E-0424-402A-8675-551FE6F2EE1C@oracle.com> References: <5E46203E-0424-402A-8675-551FE6F2EE1C@oracle.com> Message-ID: Thanks! Reviewed. In jsr166 tck we introduced the idea of "expensive" tests that only get run when enough resources are available. http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/ArrayDeque8Test.java?view=markup /** * Handle capacities near Integer.MAX_VALUE. * ant -Dvmoptions='-Xms28g -Xmx28g' -Djsr166.testImplementationDetails=true -Djsr166.expensiveTests=true -Djsr166.tckTestClass=ArrayDequeTest -Djsr166.methodFilter=testHuge tck */ public void testHuge() { if (! (testImplementationDetails && expensiveTests && Runtime.getRuntime().maxMemory() > 24L * (1 << 30))) return; On Thu, Nov 17, 2016 at 10:08 AM, Paul Sandoz wrote: > Hi, > > Please review this small update to the spliterator traversing test to > remove test cases for BitSet when the Integer.MAX_VALUE bit (or close to) > is set. > > diff -r 382f7f3a1888 test/java/util/Spliterator/ > SpliteratorTraversingAndSplittingTest.java > --- a/test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java > Wed Nov 16 14:26:14 2016 -0800 > +++ b/test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java > Thu Nov 17 10:03:56 2016 -0800 > @@ -892,9 +892,6 @@ > { "index 0", IntStream.of(0).toArray() }, > { "index 255", IntStream.of(255).toArray() }, > { "index 0 and 255", IntStream.of(0, 255).toArray() }, > - { "index Integer.MAX_VALUE", IntStream.of(Integer.MAX_VALUE).toArray() > }, > - { "index Integer.MAX_VALUE - 1", > IntStream.of(Integer.MAX_VALUE - 1).toArray() }, > - { "index 0 and Integer.MAX_VALUE", IntStream.of(0, > Integer.MAX_VALUE).toArray() }, > { "every bit", IntStream.range(0, 255).toArray() }, > { "step 2", IntStream.range(0, 255).map(f -> f * > 2).toArray() }, > { "step 3", IntStream.range(0, 255).map(f -> f * > 3).toArray() }, > > Such cases are causing out of memory test failures (not reproduced when > running locally). > > > Separately, we need to refactor the spliterator traversing tests into a > separate library (which should anyway be done): > > https://bugs.openjdk.java.net/browse/JDK-8169903 > > And then add specific BitSet tests with large memory requirements. > > Thanks, > Paul. > From huizhe.wang at oracle.com Thu Nov 17 19:58:06 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 17 Nov 2016 11:58:06 -0800 Subject: RFR (JAXP) 8158619: Very large CDATA section in XML document causes OOME In-Reply-To: <7B7EDFA7-E895-418E-A8F4-E7B8DC3A5301@oracle.com> References: <582CD9DF.8000402@oracle.com> <7B7EDFA7-E895-418E-A8F4-E7B8DC3A5301@oracle.com> Message-ID: <582E0BCE.6070803@oracle.com> Thanks Lance, Daniel, and Christoph. I adopted the changes as suggested. http://cr.openjdk.java.net/~joehw/jdk9/8158619/webrev/ The changeset has been in my workspace for over a month now. So it's good to get it out of the way. On raw type, other warnings and obsolete code: we made the top 3 in terms of the number of warnings. We're trying to correct that as we go with fixing a small set at a time within the scope of the current change. It's not being ideal since often times we have to stop where it affects the signatures (or have to expand to other classes). Eventually, we'd have to bite the bullet and conduct a complete overhaul of the code. I actually did it in the jaxp standalone repo with regard to the obsolete types, but it was lost in the middle of transition during the jdk7. On format, I agree with Daniel, we can at least fix the very-long lines near the changes, and not to introduce new ones. For other formats, it's tempting to just hit the NetBeans - format function. But then, it'd generate a huge amount of changes that could make it difficult for the reviewers. One thing we could do is not to include format changes in webrevs, and instead just make a note that NetBeans-format will be done before check-in. But even that might be unnecessary since it would make it hard to trace back changes in the repo. After all is said (about format), we are unfortunately to live with the messy format we inherited, but we shall fix the long lines though. **it's interesting to note that NetBeans-format will remove the line between License header and package name, which is required by the Licencing tool** Thanks, Joe On 11/17/16, 5:43 AM, Lance Andersen wrote: > Hi Joe, > > Overall looks good. > > I agree with Daniel that you might want to reconsider > reworking JdkXmlUtils.getValue to make it a bit more robust incase of > an surprise Object passed for value. > > HTH > Best > Lance > > >> On Nov 16, 2016, at 5:12 PM, Joe Wang > > wrote: >> >> Hi, >> >> Please review an enhancement adding a property to allow for >> specifying the chunk size of CDATA. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8158619 >> webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8158619/webrev/ >> >> >> Thanks, >> Joe >> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From Paul.Sandoz at oracle.com Thu Nov 17 20:03:00 2016 From: Paul.Sandoz at oracle.com (Paul Sandoz) Date: Thu, 17 Nov 2016 12:03:00 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: References: <8cc0d5a9-9245-e6b1-0ff2-616127dbc583@oracle.com> Message-ID: > On 16 Nov 2016, at 16:03, Martin Buchholz wrote: > > Apologies for having this wave turn into a tsunami. > > CopyOnWriteArrayList was rewritten due to finding https://bugs.openjdk.java.net/browse/JDK-8169738 > ArrayDeque and ArrayBlockingQueue now both use efficient nested loop idiom for all traversals. > Most bulk remove methods in all collection classes were rewritten for efficiency, using similar code. > Lots of tests and benchmarks added. Ok, i will just go through all of it. Collection-optimization ? Perhaps consolidate the repeated mini bit set methods as package private static methods on AbstractCollection? Unclear where the j.u.concurrent ones should go though... It?s purely a subjective thing but i would be inclined to change the variable name ?deathRow" to something more neutral such as ?removedBitSet?. The 2 layer nested loop is quite clever, certainly twists the mind when first encountered. It?s arguably more readable if there are two separate, (not-nested) loops, but that also requires two explicit invocations of the action, which may perturb the performance characteristics. ArrayDeque ? 188 public ArrayDeque(int numElements) { 189 elements = new Object[Math.max(1, numElements + 1)]; 190 } What if Integer.MAX_VALUE is passed? 202 public ArrayDeque(Collection c) { 203 elements = new Object[c.size() + 1]; 204 addAll(c); 205 } What if c.size() returns Integer.MAX_VALUE? 226 * Adds i and j, mod modulus. 227 * Precondition and postcondition: 0 <= i < modulus, 0 <= j <= modulus. 228 */ 229 static final int add(int i, int j, int modulus) { Is that upper bound correct for j? 0 <= j < modulus ? 317 c.forEach(e -> addLast(e)); this::addLast, up to you which you prefer 843 public boolean tryAdvance(Consumer action) { 844 if (action == null) 845 throw new NullPointerException(); 846 int t, i; 847 if ((t = fence) < 0) t = getFence(); Is that for optimisation purposes, since the same check is also performed in getFence? If so that seems like overkill 848 if (t == (i = cursor)) 849 return false; 850 final Object[] es; 851 action.accept(nonNullElementAt(es = elements, i)); 852 cursor = inc(i, es.length); Recommend updating cursor before the action 853 return true; 854 } Collection8Test ? 429 public void testRemoveAfterForEachRemaining() { Are tests run by default with testImplementationDetails == true? I am guessing so. Semaphore ? 633 /** 634 * Acquires and returns all permits that are immediately available. 635 * Upon return, zero permits are available. 636 * 637 * @return the number of permits acquired 638 */ 639 public int drainPermits() { 640 return sync.drainPermits(); 641 } Arguably, if positive acquires all permits, otherwise releases all permits. Perhaps: Acquires and returns all permits that are immediately available, otherwise releases all permits (if negative). Upton return, zero permits are available. @return the number of permits acquired, or the number of permits release (a negative value) Probably requires a CCC which i can manage. SplittableRandom ? 533 /** 534 * Generates a pseudorandom number with the indicated number of 535 * low-order bits. Because this class has no subclasses, this 536 * method cannot be invoked or overridden. 537 * 538 * @param bits random bits 539 * @return the next pseudorandom value from this random number 540 * generator's sequence 541 */ 542 protected int next(int bits) { 543 return nextInt() >>> (32 - bits); 544 } 545 Unless i am missing something really subtle, I don?t think this is required since SplittableRandom does not extend from Random (unlike in ThreadLocalRandom), and no associated reflective test is required. ForkJoin ? 69 * tasks that are never joined. All worker threads are initialized 70 * with {@link Thread#isDaemon} set {@code true}. CCC? Thanks, Paul. > > > On Wed, Nov 16, 2016 at 3:34 PM, Paul Sandoz wrote: > Hi Martin, > > Glad you looked more closely at the perf aspects of ArrayDeque. > > I am struggling to determine what has changed since the last revision. Apart from ArrayDeque what files should i be looking at? > > Thanks, > Paul. > > > On 16 Nov 2016, at 12:14, Martin Buchholz wrote: > > > > Thanks to Vitaly and Doug for being more concerned about offer/poll > > performance than I was initially. ArrayDeque is now back to using the head > > + tail + spare slot strategy, which keeps optimal performance for non-bulk > > operations, while everything else gets faster. We have new tests and new > > benchmarks, as a result of which new bugs were found and fixed, and this > > integration wave has grown rather larger than originally intended. > > > > The JIT-friendly nested loop strategy was successful for making bulk > > operations on circular arrays faster, and this is used for both ArrayDeque > > and ArrayBlockingQueue. > > > > + /* > > + * VMs excel at optimizing simple array loops where indices are > > + * incrementing or decrementing over a valid slice, e.g. > > + * > > + * for (int i = start; i < end; i++) ... elements[i] > > + * > > + * Because in a circular array, elements are in general stored in > > + * two disjoint such slices, we help the VM by writing unusual > > + * nested loops for all traversals over the elements. > > + */ > > > > > > Bulk removal operations on array-based collections retreat to a two-pass > > algorithm, which is slightly slower (but still O(n)), but continues to > > support (questionable) predicates that reentrantly access the collection in > > read mode. > > > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ > > > > On Fri, Oct 21, 2016 at 12:32 PM, Martin Buchholz > > wrote: > > > >> > >> > >> On Tue, Oct 18, 2016 at 4:18 PM, Martin Buchholz > >> wrote: > >> > >>> > >>> > >>> On Tue, Oct 18, 2016 at 4:00 PM, Vitaly Davidovich > >>> wrote: > >>> > >>>> > >>>>>> * Change in allocation/capacity policy. > >>>>>> > >>>>>> The removal of the power-of-two restriction, and applying a 1.5x > >>>>> growth > >>>>>> factor (same as ArrayList) seems sensible. Does this mean that the > >>>>> ability > >>>>>> to compute the proper array index by using x & (length-1) wasn't > >>>>> worth it? > >>>>>> Or at least not worth the extra tail wastage? > >>>>>> > >>>>> > >>>>> There's no integer division to optimize, as with hash tables. > >>>> > >>>> But it does add some new branches, doesn't it? Potentially branches that > >>>> aren't taken prior to JIT compilation, but taken later = deopt. > >>>> > >>> > >>> If it's a smidgeon slower, I don't care that much; improvement in > >>> flexibility and scalability are more important. > >>> > >>> Of course, I do care about algorithmic improvements to e.g. removeIf > >>> > >>> > >>>> Curious if you ran some benchmarks on ArrayDeque. > >>>> > >>> > >>> Not yet. Who would like to show how slow the code is? > >>> > >> > >> I revived my ancient IteratorMicroBenchmark for the latest webrev, made it > >> a proper jtreg test, added ArrayDeque Jobs, and verified that the new code > >> is measurably faster than the old code, at least for the mundane job of > >> iterating. > >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ > >> jsr166-jdk9-integration/ArrayList/ > >> > >> > > From mandy.chung at oracle.com Thu Nov 17 20:03:34 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 17 Nov 2016 12:03:34 -0800 Subject: Review Request JDK-8169909 java agent fails to add to class path when the initial module is a named module Message-ID: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169909/webrev.00/ This fixes a regression that causes java agent fails to append to class path when the initial module on the module path but no class path. The AppClassLoader should have a URLClassPath instance set for the support of Java agent, Instrumentation::appendToSystemClassLoaderSearch. This patch also updates JavaClassPathTest to cover more test cases for JAR file and CLASS-PATH attribute. Mandy [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-November/005213.html From daniel.fuchs at oracle.com Thu Nov 17 20:14:28 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 17 Nov 2016 20:14:28 +0000 Subject: RFR (JAXP) 8158619: Very large CDATA section in XML document causes OOME In-Reply-To: <582E0BCE.6070803@oracle.com> References: <582CD9DF.8000402@oracle.com> <7B7EDFA7-E895-418E-A8F4-E7B8DC3A5301@oracle.com> <582E0BCE.6070803@oracle.com> Message-ID: <056f5606-a8d7-51ff-6aad-8bf7533c6819@oracle.com> Looks good to me Joe. best regards, -- daniel On 17/11/16 19:58, Joe Wang wrote: > Thanks Lance, Daniel, and Christoph. I adopted the changes as suggested. > http://cr.openjdk.java.net/~joehw/jdk9/8158619/webrev/ > > The changeset has been in my workspace for over a month now. So it's > good to get it out of the way. > > On raw type, other warnings and obsolete code: > we made the top 3 in terms of the number of warnings. We're trying > to correct that as we go with fixing a small set at a time within the > scope of the current change. It's not being ideal since often times we > have to stop where it affects the signatures (or have to expand to other > classes). Eventually, we'd have to bite the bullet and conduct a > complete overhaul of the code. I actually did it in the jaxp standalone > repo with regard to the obsolete types, but it was lost in the middle of > transition during the jdk7. > > On format, I agree with Daniel, we can at least fix the very-long lines > near the changes, and not to introduce new ones. For other formats, it's > tempting to just hit the NetBeans - format function. But then, it'd > generate a huge amount of changes that could make it difficult for the > reviewers. One thing we could do is not to include format changes in > webrevs, and instead just make a note that NetBeans-format will be done > before check-in. But even that might be unnecessary since it would make > it hard to trace back changes in the repo. > > After all is said (about format), we are unfortunately to live with the > messy format we inherited, but we shall fix the long lines though. > > **it's interesting to note that NetBeans-format will remove the line > between License header and package name, which is required by the > Licencing tool** > > Thanks, > Joe > > On 11/17/16, 5:43 AM, Lance Andersen wrote: >> Hi Joe, >> >> Overall looks good. >> >> I agree with Daniel that you might want to reconsider >> reworking JdkXmlUtils.getValue to make it a bit more robust incase of >> an surprise Object passed for value. >> >> HTH >> Best >> Lance >> >> >>> On Nov 16, 2016, at 5:12 PM, Joe Wang >> > wrote: >>> >>> Hi, >>> >>> Please review an enhancement adding a property to allow for >>> specifying the chunk size of CDATA. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8158619 >>> webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8158619/webrev/ >>> >>> >>> Thanks, >>> Joe >>> >> >> >> >> Lance >> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> From huizhe.wang at oracle.com Thu Nov 17 20:31:20 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 17 Nov 2016 12:31:20 -0800 Subject: RFR (JAXP) 8158619: Very large CDATA section in XML document causes OOME In-Reply-To: <056f5606-a8d7-51ff-6aad-8bf7533c6819@oracle.com> References: <582CD9DF.8000402@oracle.com> <7B7EDFA7-E895-418E-A8F4-E7B8DC3A5301@oracle.com> <582E0BCE.6070803@oracle.com> <056f5606-a8d7-51ff-6aad-8bf7533c6819@oracle.com> Message-ID: <582E1398.3090109@oracle.com> Thanks again, Daniel! -Joe On 11/17/16, 12:14 PM, Daniel Fuchs wrote: > Looks good to me Joe. > > best regards, > > -- daniel > > On 17/11/16 19:58, Joe Wang wrote: >> Thanks Lance, Daniel, and Christoph. I adopted the changes as >> suggested. >> http://cr.openjdk.java.net/~joehw/jdk9/8158619/webrev/ >> >> The changeset has been in my workspace for over a month now. So it's >> good to get it out of the way. >> >> On raw type, other warnings and obsolete code: >> we made the top 3 in terms of the number of warnings. We're trying >> to correct that as we go with fixing a small set at a time within the >> scope of the current change. It's not being ideal since often times we >> have to stop where it affects the signatures (or have to expand to other >> classes). Eventually, we'd have to bite the bullet and conduct a >> complete overhaul of the code. I actually did it in the jaxp standalone >> repo with regard to the obsolete types, but it was lost in the middle of >> transition during the jdk7. >> >> On format, I agree with Daniel, we can at least fix the very-long lines >> near the changes, and not to introduce new ones. For other formats, it's >> tempting to just hit the NetBeans - format function. But then, it'd >> generate a huge amount of changes that could make it difficult for the >> reviewers. One thing we could do is not to include format changes in >> webrevs, and instead just make a note that NetBeans-format will be done >> before check-in. But even that might be unnecessary since it would make >> it hard to trace back changes in the repo. >> >> After all is said (about format), we are unfortunately to live with the >> messy format we inherited, but we shall fix the long lines though. >> >> **it's interesting to note that NetBeans-format will remove the line >> between License header and package name, which is required by the >> Licencing tool** >> >> Thanks, >> Joe >> >> On 11/17/16, 5:43 AM, Lance Andersen wrote: >>> Hi Joe, >>> >>> Overall looks good. >>> >>> I agree with Daniel that you might want to reconsider >>> reworking JdkXmlUtils.getValue to make it a bit more robust incase of >>> an surprise Object passed for value. >>> >>> HTH >>> Best >>> Lance >>> >>> >>>> On Nov 16, 2016, at 5:12 PM, Joe Wang >>> > wrote: >>>> >>>> Hi, >>>> >>>> Please review an enhancement adding a property to allow for >>>> specifying the chunk size of CDATA. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8158619 >>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8158619/webrev/ >>>> >>>> >>>> Thanks, >>>> Joe >>>> >>> >>> >>> >>> >>> Lance >>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >>> > From huizhe.wang at oracle.com Thu Nov 17 20:45:23 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 17 Nov 2016 12:45:23 -0800 Subject: RFR (JAXP) JDK-8169829 ProblemList update for javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh In-Reply-To: References: <021201d240a7$9e017f20$da047d60$@oracle.com> Message-ID: <582E16E3.9000206@oracle.com> +1. Again, if you find a solution for JDK-8169827, that would be good. But it's a low priority since we do have JCK in this area. Thanks, Joe On 11/17/16, 4:40 AM, Lance Andersen wrote: > Hi Frank > > This is fine. > > For something this trivial, you can just include the diff in the email > vs generating a webrev? > > Best > Lance >> On Nov 17, 2016, at 2:52 AM, Frank Yuan > > wrote: >> >> Hi all >> >> >> >> This is to correct the bugid in ProblemList.txt, see Bug: >> https://bugs.openjdk.java.net/browse/JDK-8169829 >> >> >> >> Would you like to have a review >> http://cr.openjdk.java.net/~fyuan/8169829/webrev.00/? >> >> >> >> >> >> >> Thanks, >> >> >> >> Frank >> >> >> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From daniel.fuchs at oracle.com Thu Nov 17 20:58:12 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 17 Nov 2016 20:58:12 +0000 Subject: [JAXP] RFR: 8169778: Add new public methods to get new instances of the JAXP factories builtin system-default implementations In-Reply-To: <582C94F9.9000801@oracle.com> References: <33d048b8-9aea-bc92-8478-0bebc7c2d8b6@oracle.com> <582C94F9.9000801@oracle.com> Message-ID: Hi, On 17/11/16 17:51, Joe Wang wrote: > Hi Daniel, > > Would you think we need to use a consistent description between: > the xxxFactory builtin system-default implementation. > and > The builtin system-default xxxFactory implementation > > That seems to appear only in SchemaFactory and XPathFactory. Also, the > return statement for the XPathFactory missed an "of" in "A new instance > the XPathFactory builtin system-default implementation." For the record, I have updated the webrev with the above above changes: http://cr.openjdk.java.net/~dfuchs/webrev_8169778/webrev.02/ best regards, -- daniel On 16/11/16 17:18, Joe Wang wrote: > > > On 11/16/16, 8:03 AM, Roger Riggs wrote: >> Hi Daniel, >> >> DocumentBuilderFactory and classes: >> - The new methods uses "Creates" instead of "Obtain"; >> perhaps it should be consistent with existing newInstance methods? > > "Obtain" was used in the early version of JAXP, and "Creates" in newer > StAX factories. I used "Creates" as an example to explain the norm of > writing Javadoc (the description is in 3rd person). If we want the > consistency, we could do "Obtains" in the JAXP factories and "Creates" > in StAX, alternatively, we could change all of them. > > Regards, > Joe > >> >> - "Otherwise," and "Otherwise" (with and without ",") are not >> consistent in the webrev. >> >> >> XMLInputFactory.java: >> -line 212: the "system-default" should be inside the braces with the >> @link. >> >> SchemaFactory.java: >> - line 201: (pre-existing typo) "in a implementation" -> "in an >> implementation" >> >> XPathFactory.java >> - line 177: The {@linkplain platform...} doesn't look like a properly >> formed link. >> >> >> XMLOutputFactoryNewInstanceTest >> - line 2, has a 1999 date but is a new file. >> >> Many of the files have long lines (some new) that make side-by-side >> compares not fit on the screen. >> >> Regards, Roger >> >> >> >> >> On 11/16/2016 10:24 AM, Daniel Fuchs wrote: >>> Hi, >>> >>> Please find below a patch for: >>> 8169778: Add new public methods to get new instances of the >>> JAXP factories builtin system-default implementations >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8169778 >>> webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8169778/webrev.00/ >>> >>> best regards, >>> >>> -- daniel >> From Alan.Bateman at oracle.com Thu Nov 17 21:22:07 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Nov 2016 21:22:07 +0000 Subject: Review Request JDK-8169909 java agent fails to add to class path when the initial module is a named module In-Reply-To: References: Message-ID: On 17/11/2016 20:03, Mandy Chung wrote: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169909/webrev.00/ > > This fixes a regression that causes java agent fails to > append to class path when the initial module on the module > path but no class path. The AppClassLoader should have a > URLClassPath instance set for the support of Java agent, > Instrumentation::appendToSystemClassLoaderSearch. > > This patch also updates JavaClassPathTest to cover more test > cases for JAR file and CLASS-PATH attribute. > This looks okay, I just wondering if the source for jdk.test in java/lang/instrument/src should be moved down one directly level so that it's clear which test this code is for. -Alan From joe.darcy at oracle.com Thu Nov 17 21:33:48 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 17 Nov 2016 13:33:48 -0800 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <582DF764.70504@linux.vnet.ibm.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> <582DF764.70504@linux.vnet.ibm.com> Message-ID: Hi Gustavo, On 11/17/2016 10:31 AM, Gustavo Romero wrote: > Hi Joe, > > Thanks a lot for your valuable comments. > > On 17-11-2016 15:35, joe darcy wrote: >>> Currently, optimization for building fdlibm is disabled, except for the >>> "solaris" OS target [1]. >> The reason for that is because historically the Solaris compilers have had sufficient discipline and control regarding floating-point semantics and compiler optimizations to still implement the >> Java-mandated results when optimization was enabled. The gcc family of compilers, for example, has lacked such discipline. > oh, I see. Thanks for clarifying that. I was exactly wondering why fdlibm > optimization is off even for x86_x64 as it, AFAICS regarding gcc 5 only, does > not affect the precision, even if setting -O3 does not improve the performance > as much as on PPC64. The fdlibm code relies on aliasing a two-element array of int with a double to do bit-level reads and writes of floating-point values. As I understand it, the C spec allows compilers to assume values of different types don't overlap in memory. The compilation environment has to be configured in such a way that the C compiler disables code generation and optimization techniques that would run afoul of these fdlibm coding practices. >>> As a consequence on PPC64 (Linux) StrictMath methods like, but not limited to, >>> sin(), cos(), and tan() perform verify poor in comparison to the same methods >>> in Math class [2]: >> If you are doing your work against JDK 9, note that the pow, hypot, and cbrt fdlibm methods required by StrictMath have been ported to Java (JDK-8134780: Port fdlibm to Java). I have intentions to >> port the remaining methods to Java, but it is unclear whether or not this will occur for JDK 9. > Yes, I'm doing my work against 9. So is there any problem if I proceed with my > change? I understand that there is no conflict as JDK-8134780 progresses and > replaces the StrictMath methods by their counterparts in Java. Please, advice. If I manage to finish the fdlibm C -> Java port in JDK 9, the changes you are proposing would eventually be removed as unneeded since the C code wouldn't be there to get compiled anymore. > > Is it intended to downport JDK-8134780 to 8? Such a backport would be technically possible, but we at Oracle don't currently plan to do so. > > >> Methods in the Math class, such as pow, are often intrinsified and use a different algorithm so a straight performance comparison may not be as fair or meaningful in those cases. > I agree. It's just that the issue on StrictMath methods was first noted due to > that huge gap (Math vs StrictMath) on PPC64, which is not prominent on x64. Depending on how Math.{sin, cos} is implemented on PPC64, compiling the fdlibm sin/cos with more aggressive optimizations should not be expected to close the performance gap. In particular, if Math.{sin, cos} is an intrinsic on PPC64 (I haven't checked the sources) that used platform-specific feature (say fused multiply add instructions) then just compiling fdlibm more aggressively wouldn't necessarily make up that gap. To allow cross-platform and cross-release reproducibility, StrictMath is specified to use the particular fdlibm algorithms, which precludes using better algorithms developed more recently. If we were to start with a clean slate today, to get such reproducibility we would specify correctly-rounded behavior of all those methods, but such an approach was much less tractable technical 20+ years ago without benefit of the research that was been done in the interim, such as the work of Prof. Muller and associates: https://lipforge.ens-lyon.fr/projects/crlibm/. > > >> Accumulating the the results of the functions and comparisons the sums is not a sufficiently robust way of checking to see if the optimized versions are indeed equivalent to the non-optimized ones. >> The specification of StrictMath requires a particular result for each set of floating-point arguments and sums get round-away low-order bits that differ. > That's really good point, thanks for letting me know about that. I'll re-test my > change under that perspective. > > >> Running the JDK math library regression tests and corresponding JCK tests is recommended for work in this area. > Got it. By "the JDK math library regression tests" you mean exactly which test > suite? the jtreg tests? Specifically, the regression tests under test/java/lang/Math and test/java/lang/StrictMath in the jdk repository. There are some other math library tests in the hotspot repo, but I don't know where they are offhand. A note on methodologies, when I've been writing test for my port I've tried to include test cases that exercise all the branches point in the code. Due to the large input space (~2^64 for a single-argument method), random sampling alone is an inefficient way to try to find differences in behavior. > For testing against JCK/TCK I'll need some help on that. > I believe the JCK/TCK does have additional testcases relevant here. HTH; thanks, -Joe From mandy.chung at oracle.com Thu Nov 17 21:45:30 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 17 Nov 2016 13:45:30 -0800 Subject: Review Request JDK-8169909 java agent fails to add to class path when the initial module is a named module In-Reply-To: References: Message-ID: <4C9F2808-6705-49CF-9CCA-8B376D156F2A@oracle.com> > On Nov 17, 2016, at 1:22 PM, Alan Bateman wrote: > > > > On 17/11/2016 20:03, Mandy Chung wrote: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169909/webrev.00/ >> >> This fixes a regression that causes java agent fails to >> append to class path when the initial module on the module >> path but no class path. The AppClassLoader should have a >> URLClassPath instance set for the support of Java agent, >> Instrumentation::appendToSystemClassLoaderSearch. >> >> This patch also updates JavaClassPathTest to cover more test >> cases for JAR file and CLASS-PATH attribute. >> > This looks okay, I just wondering if the source for jdk.test in java/lang/instrument/src should be moved down one directly level so that it's clear which test this code is for. Yes it would be clearer: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169909/webrev.01/ Mandy From chris.plummer at oracle.com Thu Nov 17 21:48:36 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 17 Nov 2016 13:48:36 -0800 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <582D0BCE.2030209@linux.vnet.ibm.com> <582DF764.70504@linux.vnet.ibm.com> Message-ID: <5a4a0e96-71b5-247b-60ea-5eb518d2162b@oracle.com> On 11/17/16 1:33 PM, joe darcy wrote: > Hi Gustavo, > > > On 11/17/2016 10:31 AM, Gustavo Romero wrote: >> Hi Joe, >> >> Thanks a lot for your valuable comments. >> >> On 17-11-2016 15:35, joe darcy wrote: >>>> Currently, optimization for building fdlibm is disabled, except for >>>> the >>>> "solaris" OS target [1]. >>> The reason for that is because historically the Solaris compilers >>> have had sufficient discipline and control regarding floating-point >>> semantics and compiler optimizations to still implement the >>> Java-mandated results when optimization was enabled. The gcc family >>> of compilers, for example, has lacked such discipline. >> oh, I see. Thanks for clarifying that. I was exactly wondering why >> fdlibm >> optimization is off even for x86_x64 as it, AFAICS regarding gcc 5 >> only, does >> not affect the precision, even if setting -O3 does not improve the >> performance >> as much as on PPC64. > > The fdlibm code relies on aliasing a two-element array of int with a > double to do bit-level reads and writes of floating-point values. As I > understand it, the C spec allows compilers to assume values of > different types don't overlap in memory. The compilation environment > has to be configured in such a way that the C compiler disables code > generation and optimization techniques that would run afoul of these > fdlibm coding practices. This is the strict aliasing issue right? It's a long standing problem with fdlibm that kept getting worse as gcc got smarter. IIRC, compiling with -fno-strict-aliasing fixes it, but it's been more than 12 years since I last dealt with fdlibm and compiler aliasing issues. Chris > >>>> As a consequence on PPC64 (Linux) StrictMath methods like, but not >>>> limited to, >>>> sin(), cos(), and tan() perform verify poor in comparison to the >>>> same methods >>>> in Math class [2]: >>> If you are doing your work against JDK 9, note that the pow, hypot, >>> and cbrt fdlibm methods required by StrictMath have been ported to >>> Java (JDK-8134780: Port fdlibm to Java). I have intentions to >>> port the remaining methods to Java, but it is unclear whether or not >>> this will occur for JDK 9. >> Yes, I'm doing my work against 9. So is there any problem if I >> proceed with my >> change? I understand that there is no conflict as JDK-8134780 >> progresses and >> replaces the StrictMath methods by their counterparts in Java. >> Please, advice. > > If I manage to finish the fdlibm C -> Java port in JDK 9, the changes > you are proposing would eventually be removed as unneeded since the C > code wouldn't be there to get compiled anymore. > >> >> Is it intended to downport JDK-8134780 to 8? > > Such a backport would be technically possible, but we at Oracle don't > currently plan to do so. > >> >> >>> Methods in the Math class, such as pow, are often intrinsified and >>> use a different algorithm so a straight performance comparison may >>> not be as fair or meaningful in those cases. >> I agree. It's just that the issue on StrictMath methods was first >> noted due to >> that huge gap (Math vs StrictMath) on PPC64, which is not prominent >> on x64. > > Depending on how Math.{sin, cos} is implemented on PPC64, compiling > the fdlibm sin/cos with more aggressive optimizations should not be > expected to close the performance gap. In particular, if Math.{sin, > cos} is an intrinsic on PPC64 (I haven't checked the sources) that > used platform-specific feature (say fused multiply add instructions) > then just compiling fdlibm more aggressively wouldn't necessarily make > up that gap. > > To allow cross-platform and cross-release reproducibility, StrictMath > is specified to use the particular fdlibm algorithms, which precludes > using better algorithms developed more recently. If we were to start > with a clean slate today, to get such reproducibility we would specify > correctly-rounded behavior of all those methods, but such an approach > was much less tractable technical 20+ years ago without benefit of the > research that was been done in the interim, such as the work of Prof. > Muller and associates: https://lipforge.ens-lyon.fr/projects/crlibm/. > >> >> >>> Accumulating the the results of the functions and comparisons the >>> sums is not a sufficiently robust way of checking to see if the >>> optimized versions are indeed equivalent to the non-optimized ones. >>> The specification of StrictMath requires a particular result for >>> each set of floating-point arguments and sums get round-away >>> low-order bits that differ. >> That's really good point, thanks for letting me know about that. I'll >> re-test my >> change under that perspective. >> >> >>> Running the JDK math library regression tests and corresponding JCK >>> tests is recommended for work in this area. >> Got it. By "the JDK math library regression tests" you mean exactly >> which test >> suite? the jtreg tests? > > Specifically, the regression tests under test/java/lang/Math and > test/java/lang/StrictMath in the jdk repository. There are some other > math library tests in the hotspot repo, but I don't know where they > are offhand. > > A note on methodologies, when I've been writing test for my port I've > tried to include test cases that exercise all the branches point in > the code. Due to the large input space (~2^64 for a single-argument > method), random sampling alone is an inefficient way to try to find > differences in behavior. >> For testing against JCK/TCK I'll need some help on that. >> > > I believe the JCK/TCK does have additional testcases relevant here. > > HTH; thanks, > > -Joe From martinrb at google.com Thu Nov 17 21:58:50 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 17 Nov 2016 13:58:50 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: References: <8cc0d5a9-9245-e6b1-0ff2-616127dbc583@oracle.com> Message-ID: On Thu, Nov 17, 2016 at 12:03 PM, Paul Sandoz wrote: > > ForkJoin > ? > > 69 * tasks that are never joined. All worker threads are initialized > 70 * with {@link Thread#isDaemon} set {@code true}. > > CCC? > JDK 7 had """Because ForkJoinPool uses threads in daemon mode, there is typically no need to explicitly shutdown such a pool upon program exit.""" https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ForkJoinPool.html but that was inadvertently dropped. From brent.christian at oracle.com Thu Nov 17 22:00:22 2016 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 17 Nov 2016 14:00:22 -0800 Subject: RFR 8136831 : Undefined null behavior in Class[Loader].getResourceXXXX() In-Reply-To: References: <844FDA4B-AD61-4A76-B966-AF8743E70458@oracle.com> <1d9ea794-e643-4a07-66a6-6a4196e55f8c@oracle.com> <8F44D77B-55F4-4EA6-99FE-AAF59D1252AD@oracle.com> Message-ID: On 11/17/16 11:09 AM, Alan Bateman wrote: > On 17/11/2016 18:25, Paul Sandoz wrote: >> >> Looks ok, but has indicated by Alan i would leave Class alone and >> untested until Jake gets integrated, then follow up with another issue. >> > Actually no follow-up needed because it's updated in jake to specify NPE. Right. I'll focus this fix just on ClassLoader, and the Class changes can come into 9 from jake. BTW, I've not changed the test case. The Class methods throw the expected NPE by virtue of calling up into ClassLoader. http://cr.openjdk.java.net/~bchristi/8136831/webrev.02/ Thanks again, -Brent From martinrb at google.com Thu Nov 17 22:16:36 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 17 Nov 2016 14:16:36 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: References: <8cc0d5a9-9245-e6b1-0ff2-616127dbc583@oracle.com> Message-ID: On Thu, Nov 17, 2016 at 12:03 PM, Paul Sandoz wrote: > > > SplittableRandom > ? > > 533 /** > 534 * Generates a pseudorandom number with the indicated number of > 535 * low-order bits. Because this class has no subclasses, this > 536 * method cannot be invoked or overridden. > 537 * > 538 * @param bits random bits > 539 * @return the next pseudorandom value from this random number > 540 * generator's sequence > 541 */ > 542 protected int next(int bits) { > 543 return nextInt() >>> (32 - bits); > 544 } > 545 > > Unless i am missing something really subtle, I don?t think this is > required since SplittableRandom does not extend from Random (unlike in > ThreadLocalRandom), and no associated reflective test is required. > Thanks! I completely missed that SplittableRandom doesn't extend Random! Reverted changes to SplittableRandom and SplittableRandomTest. I'm regenerating http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ but Paul's review version is available at http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration.2016-11-17/ From paul.sandoz at oracle.com Thu Nov 17 22:29:08 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 17 Nov 2016 14:29:08 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: References: <8cc0d5a9-9245-e6b1-0ff2-616127dbc583@oracle.com> Message-ID: <699C62B0-6AC7-44F1-9B98-FC5E0C23AE68@oracle.com> > On 17 Nov 2016, at 13:58, Martin Buchholz wrote: > > > > On Thu, Nov 17, 2016 at 12:03 PM, Paul Sandoz > wrote: > > ForkJoin > ? > > 69 * tasks that are never joined. All worker threads are initialized > 70 * with {@link Thread#isDaemon} set {@code true}. > > CCC? > > JDK 7 had > """Because ForkJoinPool uses threads in daemon mode, there is typically no need to explicitly shutdown such a pool upon program exit.""" > https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ForkJoinPool.html > > but that was inadvertently dropped. > Ah, i see, ok, no need. Thanks, Paul. From mandy.chung at oracle.com Thu Nov 17 22:49:42 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 17 Nov 2016 14:49:42 -0800 Subject: RFR 8136831 : Undefined null behavior in Class[Loader].getResourceXXXX() In-Reply-To: References: <844FDA4B-AD61-4A76-B966-AF8743E70458@oracle.com> <1d9ea794-e643-4a07-66a6-6a4196e55f8c@oracle.com> <8F44D77B-55F4-4EA6-99FE-AAF59D1252AD@oracle.com> Message-ID: <314CE865-4154-44A7-8057-0C4C5072C7C5@oracle.com> > On Nov 17, 2016, at 2:00 PM, Brent Christian wrote: > > Right. I'll focus this fix just on ClassLoader, and the Class changes can come into 9 from jake. > > BTW, I've not changed the test case. The Class methods throw the expected NPE by virtue of calling up into ClassLoader. > > http://cr.openjdk.java.net/~bchristi/8136831/webrev.02/ Looks good. Nit: do you want to keep this line: 81 System.out.println(cl.getClass().getName() + " returned: " + retVal); @bug id is missing in the test. No need for a new webrev. Mandy From huizhe.wang at oracle.com Thu Nov 17 23:13:50 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 17 Nov 2016 15:13:50 -0800 Subject: RFR (JAXP) 8158619: Very large CDATA section in XML document causes OOME In-Reply-To: <04b0bda453ee4d97a0ac117dbc12efd3@DEWDFE13DE03.global.corp.sap> References: <582CD9DF.8000402@oracle.com> <7B7EDFA7-E895-418E-A8F4-E7B8DC3A5301@oracle.com> <582E0BCE.6070803@oracle.com> <04b0bda453ee4d97a0ac117dbc12efd3@DEWDFE13DE03.global.corp.sap> Message-ID: <582E39AE.1010805@oracle.com> On 11/17/16, 1:50 PM, Langer, Christoph wrote: > > Hi Joe, > > thanks for the clarification about formatting. It was particularly > good for me to learn about the line in between license header and > package name as I was not sure whether it should exist or not. I'll > update my outstanding webrevs with that regards. And I'll keep going > to do formatting and warnings cleanups as I go... > Thanks! That helps a lot. We had over 5000 warnings, hopefully we'd get rid of them all over a period of time. Best, Joe > Best regards > > Christoph > > *From:*Joe Wang [mailto:huizhe.wang at oracle.com] > *Sent:* Donnerstag, 17. November 2016 20:58 > *To:* Lance Andersen > *Cc:* core-libs-dev at openjdk.java.net; daniel Fuchs > ; Langer, Christoph > *Subject:* Re: RFR (JAXP) 8158619: Very large CDATA section in XML > document causes OOME > > Thanks Lance, Daniel, and Christoph. I adopted the changes as suggested. > http://cr.openjdk.java.net/~joehw/jdk9/8158619/webrev/ > > > The changeset has been in my workspace for over a month now. So it's > good to get it out of the way. > > On raw type, other warnings and obsolete code: > we made the top 3 in terms of the number of warnings. We're > trying to correct that as we go with fixing a small set at a time > within the scope of the current change. It's not being ideal since > often times we have to stop where it affects the signatures (or have > to expand to other classes). Eventually, we'd have to bite the bullet > and conduct a complete overhaul of the code. I actually did it in the > jaxp standalone repo with regard to the obsolete types, but it was > lost in the middle of transition during the jdk7. > > On format, I agree with Daniel, we can at least fix the very-long > lines near the changes, and not to introduce new ones. For other > formats, it's tempting to just hit the NetBeans - format function. But > then, it'd generate a huge amount of changes that could make it > difficult for the reviewers. One thing we could do is not to include > format changes in webrevs, and instead just make a note that > NetBeans-format will be done before check-in. But even that might be > unnecessary since it would make it hard to trace back changes in the repo. > > After all is said (about format), we are unfortunately to live with > the messy format we inherited, but we shall fix the long lines though. > > **it's interesting to note that NetBeans-format will remove the line > between License header and package name, which is required by the > Licencing tool** > > Thanks, > Joe > > On 11/17/16, 5:43 AM, Lance Andersen wrote: > > Hi Joe, > > Overall looks good. > > I agree with Daniel that you might want to reconsider > reworking JdkXmlUtils.getValue to make it a bit more robust incase > of an surprise Object passed for value. > > HTH > > Best > > Lance > > On Nov 16, 2016, at 5:12 PM, Joe Wang > wrote: > > Hi, > > Please review an enhancement adding a property to allow for > specifying the chunk size of CDATA. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8158619 > webrevs: > http://cr.openjdk.java.net/~joehw/jdk9/8158619/webrev/ > > > Thanks, > Joe > > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From martinrb at google.com Fri Nov 18 03:17:33 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 17 Nov 2016 19:17:33 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: <699C62B0-6AC7-44F1-9B98-FC5E0C23AE68@oracle.com> References: <8cc0d5a9-9245-e6b1-0ff2-616127dbc583@oracle.com> <699C62B0-6AC7-44F1-9B98-FC5E0C23AE68@oracle.com> Message-ID: Here's an update that adds some explanations, addresses some of Paul's comments, and improves handling of capacities near 2**31. Coincidentally, today I got access to a machine with enough memory to run testHugeCapacity without dying, so that test gets fixed. Previous iterations tried to get rid of the spare slot, and there may be some other lingering vestige of that, as with this test. Index: src/main/java/util/ArrayDeque.java =================================================================== RCS file: /export/home/jsr166/jsr166/jsr166/src/main/java/util/ArrayDeque.java,v retrieving revision 1.113 diff -u -r1.113 ArrayDeque.java --- src/main/java/util/ArrayDeque.java 13 Nov 2016 02:10:09 -0000 1.113 +++ src/main/java/util/ArrayDeque.java 18 Nov 2016 03:09:50 -0000 @@ -68,13 +68,15 @@ * * Because in a circular array, elements are in general stored in * two disjoint such slices, we help the VM by writing unusual - * nested loops for all traversals over the elements. + * nested loops for all traversals over the elements. Having only + * one hot inner loop body instead of two or three eases human + * maintenance and encourages VM loop inlining into the caller. */ /** * The array in which the elements of the deque are stored. - * We guarantee that all array cells not holding deque elements - * are always null. + * All array cells not holding deque elements are always null. + * The array always has at least one null slot (at tail). */ transient Object[] elements; @@ -88,7 +90,8 @@ /** * The index at which the next element would be added to the tail - * of the deque (via addLast(E), add(E), or push(E)). + * of the deque (via addLast(E), add(E), or push(E)); + * elements[tail] is always null. */ transient int tail; @@ -187,7 +190,10 @@ * @param numElements lower bound on initial capacity of the deque */ public ArrayDeque(int numElements) { - elements = new Object[Math.max(1, numElements + 1)]; + elements = + new Object[(numElements < 1) ? 1 : + (numElements == Integer.MAX_VALUE) ? Integer.MAX_VALUE : + numElements + 1]; } /** @@ -201,7 +207,7 @@ * @throws NullPointerException if the specified collection is null */ public ArrayDeque(Collection c) { - elements = new Object[c.size() + 1]; + this(c.size()); addAll(c); } @@ -224,19 +230,21 @@ } /** - * Adds i and j, mod modulus. - * Precondition and postcondition: 0 <= i < modulus, 0 <= j <= modulus. + * Circularly adds the given distance to index i, mod modulus. + * Precondition: 0 <= i < modulus, 0 <= distance <= modulus. + * @return index 0 <= i < modulus */ - static final int add(int i, int j, int modulus) { - if ((i += j) - modulus >= 0) i -= modulus; + static final int add(int i, int distance, int modulus) { + if ((i += distance) - modulus >= 0) distance -= modulus; return i; } /** * Subtracts j from i, mod modulus. - * Index i must be logically ahead of j. - * Returns the "circular distance" from j to i. - * Precondition and postcondition: 0 <= i < modulus, 0 <= j < modulus. + * Index i must be logically ahead of index j. + * Precondition: 0 <= i < modulus, 0 <= j < modulus. + * @return the "circular distance" from j to i; corner case i == j + * is diambiguated to "empty", returning 0. */ static final int sub(int i, int j, int modulus) { if ((i -= j) < 0) i += modulus; @@ -862,9 +870,9 @@ if ((t = fence) < 0) t = getFence(); if (t == (i = cursor)) return false; - final Object[] es; - action.accept(nonNullElementAt(es = elements, i)); + final Object[] es = elements; cursor = inc(i, es.length); + action.accept(nonNullElementAt(es, i)); return true; } @@ -1232,6 +1240,8 @@ /** debugging */ void checkInvariants() { + // Use head and tail fields with empty slot at tail strategy. + // head == tail disambiguates to "empty". try { int capacity = elements.length; // assert head >= 0 && head < capacity; Index: src/main/java/util/concurrent/ArrayBlockingQueue.java =================================================================== RCS file: /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/ArrayBlockingQueue.java,v retrieving revision 1.137 diff -u -r1.137 ArrayBlockingQueue.java --- src/main/java/util/concurrent/ArrayBlockingQueue.java 13 Nov 2016 02:10:09 -0000 1.137 +++ src/main/java/util/concurrent/ArrayBlockingQueue.java 18 Nov 2016 03:09:50 -0000 @@ -58,6 +58,11 @@ public class ArrayBlockingQueue extends AbstractQueue implements BlockingQueue, java.io.Serializable { + /* + * Much of the implementation mechanics, especially the unusual + * nested loops, are shared and co-maintained with ArrayDeque. + */ + /** * Serialization ID. This class relies on default serialization * even for the items array, which is default-serialized, even if @@ -1555,6 +1560,10 @@ // meta-assertions // assert lock.isHeldByCurrentThread(); try { + // Unlike ArrayDeque, we have a count field but no spare slot. + // We prefer ArrayDeque's strategy, but our field layout is + // baked into the serial form, and so is annoying to change. + // putIndex == takeIndex must be disambiguated by checking count. int capacity = items.length; // assert capacity > 0; // assert takeIndex >= 0 && takeIndex < capacity; Index: src/test/tck/ArrayDeque8Test.java =================================================================== RCS file: /export/home/jsr166/jsr166/jsr166/src/test/tck/ArrayDeque8Test.java,v retrieving revision 1.1 diff -u -r1.1 ArrayDeque8Test.java --- src/test/tck/ArrayDeque8Test.java 25 Oct 2016 01:32:55 -0000 1.1 +++ src/test/tck/ArrayDeque8Test.java 18 Nov 2016 03:09:51 -0000 @@ -51,43 +51,42 @@ /** * Handle capacities near Integer.MAX_VALUE. - * ant -Dvmoptions='-Xms28g -Xmx28g' -Djsr166.testImplementationDetails=true -Djsr166.expensiveTests=true -Djsr166.tckTestClass=ArrayDequeTest -Djsr166.methodFilter=testHuge tck + * ant -Dvmoptions='-Xms28g -Xmx28g' -Djsr166.expensiveTests=true -Djsr166.tckTestClass=ArrayDeque8Test -Djsr166.methodFilter=testHugeCapacity tck */ - public void testHuge() { + public void testHugeCapacity() { if (! (testImplementationDetails && expensiveTests && Runtime.getRuntime().maxMemory() > 24L * (1 << 30))) return; - ArrayDeque q; - Integer e = 42; - final int maxSize = Integer.MAX_VALUE - 8; + final Integer e = 42; + final int maxArraySize = Integer.MAX_VALUE - 8; assertThrows(OutOfMemoryError.class, - () -> new ArrayDeque<>(Integer.MAX_VALUE)); + () -> new ArrayDeque(Integer.MAX_VALUE)); { - q = new ArrayDeque<>(maxSize); + ArrayDeque q = new ArrayDeque(maxArraySize - 1); assertEquals(0, q.size()); assertTrue(q.isEmpty()); q = null; } { - q = new ArrayDeque(); - assertTrue(q.addAll(Collections.nCopies(maxSize - 2, e))); + ArrayDeque q = new ArrayDeque(); + assertTrue(q.addAll(Collections.nCopies(maxArraySize - 3, e))); assertEquals(e, q.peekFirst()); assertEquals(e, q.peekLast()); - assertEquals(maxSize - 2, q.size()); + assertEquals(maxArraySize - 3, q.size()); q.addFirst((Integer) 0); q.addLast((Integer) 1); assertEquals((Integer) 0, q.peekFirst()); assertEquals((Integer) 1, q.peekLast()); - assertEquals(maxSize, q.size()); + assertEquals(maxArraySize - 1, q.size()); ArrayDeque qq = q; ArrayDeque smallish = new ArrayDeque( - Collections.nCopies(Integer.MAX_VALUE - maxSize + 1, e)); + Collections.nCopies(Integer.MAX_VALUE - q.size() + 1, e)); assertThrows( IllegalStateException.class, () -> qq.addAll(qq), From martinrb at google.com Fri Nov 18 03:41:05 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 17 Nov 2016 19:41:05 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: References: <8cc0d5a9-9245-e6b1-0ff2-616127dbc583@oracle.com> Message-ID: On Thu, Nov 17, 2016 at 12:03 PM, Paul Sandoz wrote: > > 843 public boolean tryAdvance(Consumer action) { > 844 if (action == null) > 845 throw new NullPointerException(); > 846 int t, i; > 847 if ((t = fence) < 0) t = getFence(); > > Is that for optimisation purposes, since the same check is also performed > in getFence? If so that seems like overkill > > OK: --- src/main/java/util/ArrayDeque.java 18 Nov 2016 03:22:20 -0000 1.114 +++ src/main/java/util/ArrayDeque.java 18 Nov 2016 03:38:23 -0000 @@ -866,9 +866,8 @@ public boolean tryAdvance(Consumer action) { if (action == null) throw new NullPointerException(); - int t, i; - if ((t = fence) < 0) t = getFence(); - if (t == (i = cursor)) + final int t, i; + if ((t = getFence()) == (i = cursor)) return false; final Object[] es = elements; cursor = inc(i, es.length); > > 848 if (t == (i = cursor)) > 849 return false; > 850 final Object[] es; > 851 action.accept(nonNullElementAt(es = elements, i)); > 852 cursor = inc(i, es.length); > From amy.lu at oracle.com Fri Nov 18 04:06:10 2016 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 18 Nov 2016 12:06:10 +0800 Subject: JDK 9 RFR of JDK-8169826: ProblemList update for tools/pack200/CommandLineTests.java Message-ID: <91606863-a659-2c38-70d8-f040fd28ed2a@oracle.com> Please review the patch to correct the bugid in ProblemList.txt for test tools/pack200/CommandLineTests.java bug: https://bugs.openjdk.java.net/browse/JDK-8169826 Thanks, Amy --- old/test/ProblemList.txt 2016-11-18 12:02:17.000000000 +0800 +++ new/test/ProblemList.txt 2016-11-18 12:02:16.000000000 +0800 @@ -250,7 +250,7 @@ # core_tools -tools/pack200/CommandLineTests.java 7143279,8059906 generic-all +tools/pack200/CommandLineTests.java 8059906 generic-all tools/launcher/FXLauncherTest.java 8068049 linux-all,macosx-all From mandy.chung at oracle.com Fri Nov 18 04:09:18 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 17 Nov 2016 20:09:18 -0800 Subject: JDK 9 RFR of JDK-8169826: ProblemList update for tools/pack200/CommandLineTests.java In-Reply-To: <91606863-a659-2c38-70d8-f040fd28ed2a@oracle.com> References: <91606863-a659-2c38-70d8-f040fd28ed2a@oracle.com> Message-ID: +1 Mandy > On Nov 17, 2016, at 8:06 PM, Amy Lu wrote: > > Please review the patch to correct the bugid in ProblemList.txt for test tools/pack200/CommandLineTests.java > > bug: https://bugs.openjdk.java.net/browse/JDK-8169826 > > Thanks, > Amy > > --- old/test/ProblemList.txt 2016-11-18 12:02:17.000000000 +0800 > +++ new/test/ProblemList.txt 2016-11-18 12:02:16.000000000 +0800 > @@ -250,7 +250,7 @@ > > # core_tools > > -tools/pack200/CommandLineTests.java 7143279,8059906 generic-all > +tools/pack200/CommandLineTests.java 8059906 generic-all > > tools/launcher/FXLauncherTest.java 8068049 linux-all,macosx-all > > From martinrb at google.com Fri Nov 18 04:29:12 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 17 Nov 2016 20:29:12 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: References: <8cc0d5a9-9245-e6b1-0ff2-616127dbc583@oracle.com> Message-ID: On Thu, Nov 17, 2016 at 12:03 PM, Paul Sandoz wrote: > > Perhaps consolidate the repeated mini bit set methods as package private > static methods on AbstractCollection? Unclear where the j.u.concurrent ones > should go though... > Deferred. > It?s purely a subjective thing but i would be inclined to change the > variable name ?deathRow" to something more neutral such as ?removedBitSet?. > It's certainly evocative! Especially given that they may get a reprieve from a following predicate! > The 2 layer nested loop is quite clever, certainly twists the mind when > first encountered. It?s arguably more readable if there are two separate, > (not-nested) loops, but that also requires two explicit invocations of the > action, which may perturb the performance characteristics. > After you've written a hundred of these loops, they start to look rather natural/idiomatic. I think these nested loops should be the canonical way to implement traversals of circular buffers in any programming language. The inner loops seem optimal. It seems unlikely we've invented something new here, but maybe... > ArrayDeque > ? > > 188 public ArrayDeque(int numElements) { > 189 elements = new Object[Math.max(1, numElements + 1)]; > 190 } > > What if Integer.MAX_VALUE is passed? > Now tries (and fails!) to allocate a maximal array. > 202 public ArrayDeque(Collection c) { > 203 elements = new Object[c.size() + 1]; > 204 addAll(c); > 205 } > > What if c.size() returns Integer.MAX_VALUE? > > Now delegates to the other constructor. > > 226 * Adds i and j, mod modulus. > 227 * Precondition and postcondition: 0 <= i < modulus, 0 <= j <= > modulus. > 228 */ > 229 static final int add(int i, int j, int modulus) { > > Is that upper bound correct for j? 0 <= j < modulus > j renamed to distance, to emphasize asymmetry. Although in this file, distance will never equal modulus. > > 317 c.forEach(e -> addLast(e)); > > this::addLast, up to you which you prefer > > Meh. Left as is; another vote could tip to the other side. > > 843 public boolean tryAdvance(Consumer action) { > 844 if (action == null) > 845 throw new NullPointerException(); > 846 int t, i; > 847 if ((t = fence) < 0) t = getFence(); > > Is that for optimisation purposes, since the same check is also performed > in getFence? If so that seems like overkill > > done. > > 848 if (t == (i = cursor)) > 849 return false; > 850 final Object[] es; > 851 action.accept(nonNullElementAt(es = elements, i)); > 852 cursor = inc(i, es.length); > > Recommend updating cursor before the action > > done. > > 853 return true; > 854 } > > > > Collection8Test > ? > > 429 public void testRemoveAfterForEachRemaining() { > > Are tests run by default with testImplementationDetails == true? I am > guessing so. > > We run various combinations in jtreg mode. * @run junit/othervm/timeout=1000 -Djsr166.testImplementationDetails=true JSR166TestCase * @run junit/othervm/timeout=1000 -Djava.util.concurrent.ForkJoinPool.common.parallelism=0 -Djsr166.testImplementationDetails=true JSR166TestCase * @run junit/othervm/timeout=1000 -Djava.util.concurrent.ForkJoinPool.common.parallelism=1 -Djava.util.secureRandomSeed=true JSR166TestCase The original target for these tests are the jck, and that is expected to run with the default testImplementationDetails=false From martinrb at google.com Fri Nov 18 04:51:37 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 17 Nov 2016 20:51:37 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: References: <8cc0d5a9-9245-e6b1-0ff2-616127dbc583@oracle.com> Message-ID: On Thu, Nov 17, 2016 at 12:03 PM, Paul Sandoz wrote: > > Semaphore > ? > > 633 /** > 634 * Acquires and returns all permits that are immediately > available. > 635 * Upon return, zero permits are available. > 636 * > 637 * @return the number of permits acquired > 638 */ > 639 public int drainPermits() { > 640 return sync.drainPermits(); > 641 } > > Arguably, if positive acquires all permits, otherwise releases all > permits. Perhaps: > > Acquires and returns all permits that are immediately available, > otherwise releases all permits (if negative). > Upton return, zero permits are available. > > @return the number of permits acquired, or the number of permits release > (a negative value) > > Probably requires a CCC which i can manage. > I agree we can do better along the lines you suggest. I'm hesitant since I don't understand the intended use for drainPermits. From huizhe.wang at oracle.com Fri Nov 18 04:53:24 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 17 Nov 2016 20:53:24 -0800 Subject: RFR: 8169631: [JAXP] XALAN: transformation of XML via namespace-unaware SAX input yields a different result than namespace-unaware DOM input In-Reply-To: <4be5158237814eeb9352fe8fe344e47c@dewdfe13de07.global.corp.sap> References: <313759790392479fa80a10542ab664ec@dewdfe13de07.global.corp.sap> <582A7170.7030100@oracle.com> <4be5158237814eeb9352fe8fe344e47c@dewdfe13de07.global.corp.sap> Message-ID: <582E8944.7090906@oracle.com> On 11/14/16, 11:43 PM, Langer, Christoph wrote: > Hi Joe, > > thanks for looking. > > Can you let me know which smoke test is failing? I didn't see issues so far - I was merely running the jtreg unittests for transformer. I sent the test to your mailbox. > > I stepped back from replacing Vector with ArrayList for m_prefixMappings because the code is using methods indexOf() with a start index and setSize() for which ArrayList has no direct matchings. One could, for sure, add some other coding, e.g. use ArrayList's subList() method for the index based search - but I wouldn't want to run the risk of adding a regression here just because I modified the code and did not well test it. But if you insist, I could have another look. Ok, that's fine. subList would do, but setSize may need a bit more work. Best, Joe > > Best regards > Christoph > >> -----Original Message----- >> From: Joe Wang [mailto:huizhe.wang at oracle.com] >> Sent: Dienstag, 15. November 2016 03:23 >> To: Langer, Christoph >> Cc: core-libs-dev at openjdk.java.net >> Subject: Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via >> namespace-unaware SAX input yields a different result than namespace- >> unaware DOM input >> >> Hi Christoph, >> >> Not all tests have finished yet, but there's at least one failure in the >> smoke test. I'll get to the details when I have time. >> >> Any reason why m_prefixMappings can not be replaced with ArrayList? >> >> Thanks, >> Joe >> >> On 11/14/16, 6:10 AM, Langer, Christoph wrote: >>> Hi, >>> >>> please review this fix for bug 8169631. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8169631 >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169631.0/ >>> >>> When XALAN is handling namespace unaware input, it behaves differently >> while using SAX input compared to DOM input. >>> With both input source types, the class >> com.sun.org.apache.xml.internal.dtm.ref.sax2dtm.SAX2DTM2 converts SAX >> input into a DTM representation for processing by the XALAN transformer. Its >> method startElement takes URI, localname and qName as attribute. In case of >> missing feature namespaces, startElement and localname can be empty. >> However, the function uses the localname value for the call to >> m_expandedNameTable.getExpandedTypeID() and further processing. In the >> case where only qName has data, this leads to issues. >>> When using DOM input, the class >> com.sun.org.apache.xalan.internal.xsltc.trax.DOM2SAX converts the DOM input >> into SAX input. In the case of empty localname, it fills localname with qname >> data. See method getLocalName() [1], called by parse() [2]. >>> When directly using SAX input, the SAX parser calls the startElement() >> function on XALAN's handler with empty uri and localname - which seems >> correct, as per the spec. >>> Both paths end up in SAX2DTM2's startElement(). So I suggest to change this >> method to handle the case when uri and localname are empty and then set >> qname as localname. Maybe one should even change DOM2SAX's >> getLocalName handling to not fill localname with qname in case it is empty >> after SAX2DTM was changed.. >>> Generally, JavaDoc for SAXSource says that "Attempting to transform an input >> source that is not generated with a namespace-aware parser may result in >> errors." But why not fix some of these :) >>> Furthermore I did some cleanups in the code. >>> >>> Thanks and best regards >>> Christoph >>> >>> [1] >> http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/shar >> e/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l139 >>> [2] >> http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/shar >> e/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l279 >>> [3] >> https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/sax/SAXSource >> .html >>> From huizhe.wang at oracle.com Fri Nov 18 05:14:24 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 17 Nov 2016 21:14:24 -0800 Subject: RFR: 8023653: xalan inconsistently parses DOMSource and StreamSource In-Reply-To: References: Message-ID: <582E8E30.2030209@oracle.com> Together with 8169631, I think we need to understand your customer's requirement before spending time on a change that would otherwise be unnecesary. Why would turning off namespace-aware help him? As far as the xml standards and parser/processor are concerned, it's a backward development. A namespace-aware parser is compatible with the ones that don't know about namespaces. The norm then is to always turn it on (although the API had to default to off because of the legacy). Is the user processing some legacy xml code? Thanks, Joe On 11/16/16, 5:41 AM, Langer, Christoph wrote: > Hi, > > to address the long standing bug 8023653 I propose the following change: > > webrev: http://cr.openjdk.java.net/~clanger/webrevs/8023653.0/ > bug: https://bugs.openjdk.java.net/browse/JDK-8023653 > > I think the bug report in general complains that the default for DOMSource input is to parse the input "namespace-unaware" whereas, if XALAN gets a StreamSource as input, it is parsed "namespace-aware". > > Generally I'm against changing either of these defaults (at this time at least) - XALAN StreamSource should be handled namespace aware and changing the default for DocumentBuilderFactory is maybe an option for the Java 10 timeframe, I'd say. However, at the moment it is not possible at all to configure XALAN's handling of StreamSource input to be namespace unaware. That's what I'd like to address with my change. With my modifications it's possible to set the namespace feature on the TransformerFactory (to false). It bases on my other open fix 8169631 which is discussed here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044662.html Only with the corrections for that fix, the SAX parsing that is used for stream sources will be handled correctly. > > The proposed change from the bugreport (change options for the parser of the XSL input before compilation) would not help with the reported issue and also is not a good idea anyway as xsl input needs to be handled with namespaces obviously. > > I did other cleanups in my change as well, the real functional changes are in TransformerFactoryImpl.java, XSLTCDTMManager.java and XMLReaderManager.java. > > Thanks in advance for reviewing. > > Best regards > Christoph > From sha.jiang at oracle.com Fri Nov 18 06:02:43 2016 From: sha.jiang at oracle.com (John Jiang) Date: Fri, 18 Nov 2016 14:02:43 +0800 Subject: RFR[9] JDK-8158916: ProblemList.txt update for com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java In-Reply-To: References: <59dc7e57-3d05-6395-abdc-a0677b487fbb@oracle.com> <0988590c-7530-8470-3b74-56a2a8c3e744@oracle.com> Message-ID: <7e02a877-a014-a8a6-d69e-40320aae53ae@oracle.com> Hi, Track this test issue with a new JBS bug JDK-8169942. Please take a look at the updated webrew: http://cr.openjdk.java.net/~jjiang/8158916/webrev.01/, or the below, --- old/test/ProblemList.txt 2016-11-17 21:29:12.112822913 -0800 +++ new/test/ProblemList.txt 2016-11-17 21:29:11.964822915 -0800 @@ -298,6 +298,6 @@ # jdk_other -com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8141370 linux-i586,macosx-all +com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8169942 linux-i586,macosx-all ############################################################################ Best regards, John Jiang On 2016/11/8 18:53, Daniel Fuchs wrote: > Hi John, > > On 08/11/16 01:30, John Jiang wrote: >> Hi Daniel, >> Thanks for your comments. >> >> On 2016/11/7 19:21, Daniel Fuchs wrote: >>> Hi John, >>> >>> Maybe you should reach out to Rob who fixed JDK-8141370 to >>> make sure this is the right thing to do. >> just cc Rob Mckenna >> >>> >>> It seems the exclusion on problematic platforms [1] was deliberate: >>> >>>> Basically I've separated the failing subtest out into its own file and >>>> excluded it on the (intermittently) failing platforms. >> I see. But it should use an open issue. >> I would like to open a new issue to track this issue. But I don't get >> the exact failure log on DeadSSLLdapTimeoutTest.java, though the failure >> may still be related to SSLHandshakeException. >> When this test was born, it was in the ProblemList, so I suppose it has >> no chance to be executed by our automatic testing systems. > > I see. I agree it's better to have an open bug in the ProblemList. > But I am concerned if that bug is something that we never intend to > fix because the test is not appropriate for those platforms. > > best regards, > > -- daniel > >> >> Best regards, >> John Jiang >> >>> >>> best regards, >>> >>> -- daniel >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037385.html >>> >>> >>> >>> >>> On 07/11/16 02:37, John Jiang wrote: >>>> Hi, >>>> com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java is associated to 8141370 >>>> in ProblemList, though issue JDK-8141370 has been resolved. >>>> In fact, the fix for JDK-8141370 extracted some codes from >>>> com/sun/jndi/ldap/LdapTimeoutTest.java to create >>>> com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java, and put the new test to >>>> ProblemList. >>>> It would be better to remove this item from ProblemList. If >>>> com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java still fails >>>> intermittently, we can put it back to ProblemList with the exact >>>> failure >>>> logs. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8158916 >>>> Webrev: http://cr.openjdk.java.net/~jjiang/8158916/webrev.00/ >>>> >>>> Best regards, >>>> John Jiang >>>> >>> >>> >> > > From huizhe.wang at oracle.com Fri Nov 18 06:35:48 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 17 Nov 2016 22:35:48 -0800 Subject: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE In-Reply-To: References: Message-ID: <582EA144.2000601@oracle.com> Looks fine. License header: in general, don't change / add Year if there's no material change, removing the legacy $Id field in EmptySerializer.java for example, does not constitute a change to the code, so just keep the original year (see below). The initial years for the classes: EmptySerializer.java 2012 SerializerBase.java 2012 ToSAXHandler.java none (meaning if you make changes to this class, just add 2016) ToStream.java 2006 ToUnknownStream.java 2007 XSLOutputAttributes.java none (so keep the original "DO NOT REMOVE OR ALTER!" block) Thanks, Joe On 11/16/16, 6:22 AM, Langer, Christoph wrote: > Hi, > > please review another XALAN fix. > > The Serializer should be able to handle text nodes with null input. There has already been some discussion here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044567.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169772 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169772.0/ > > The actual fix is in ToUnknownStream.java, method "public void characters(String chars) throws SAXException". I don't know if one should even directly return after chars being null or of size() 0. The rest of this change is cleanups and a test case. > > Thanks for reviewing. > > Best regards > Christoph > From forax at univ-mlv.fr Fri Nov 18 07:17:18 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 18 Nov 2016 08:17:18 +0100 (CET) Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: References: Message-ID: <1448961357.2789319.1479453438452.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Martin Buchholz" > ?: "Paul Sandoz" > Cc: "core-libs-dev" > Envoy?: Vendredi 18 Novembre 2016 05:29:12 > Objet: Re: RFR: jsr166 jdk9 integration wave 12 [..] >> 317 c.forEach(e -> addLast(e)); >> >> this::addLast, up to you which you prefer >> >> > Meh. Left as is; another vote could tip to the other side. > > I like the rule that says, use a method reference if you can and a lambda otherwise. so i vote for this::addLast :) R?mi From forax at univ-mlv.fr Fri Nov 18 07:28:56 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 18 Nov 2016 08:28:56 +0100 (CET) Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: References: Message-ID: <89979948.2793795.1479454136976.JavaMail.zimbra@u-pem.fr> Martin, for ArrayDeque, when you start to have methods like @SuppressWarnings("unchecked") static final E elementAt(Object[] es, int i) { return (E) es[i]; } I think it's a better idea to type the field elements as a E[] instead of Object[]. Historically, using Object(] instead of E[] was preferred because it's a kind of 'more true' at runtime, but it will be less true with anyfied generics and as we can see if it leads to introduce method like elementAt, using E[] will make the code more readable. so the constructors should be: @SuppressWarnings("unchecked") public ArrayDeque() { elements = (E[])new Object[16]; } (same transformation for ArrayDeque(int)). And you can remove all the casts to E and the corresponnding SuppressWarnings and remove the method elementAt. R?mi ----- Mail original ----- > De: "Martin Buchholz" > ?: "core-libs-dev" , "Doug Lea"
      , "Stuart Marks" > , "Paul Sandoz" > Envoy?: Mardi 18 Octobre 2016 03:34:34 > Objet: RFR: jsr166 jdk9 integration wave 12 > Most of this is for Stuart - very collection-y. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ > > This includes a rewrite of ArrayDeque to bring it to parity with ArrayList > (except for List features). > The patch includes public methods ensureCapacity, trimToSize, replaceAll as > in ArrayList, but we can defer making them public to a later change (or a > later release), since new public methods are always controversial. But I'd > really like to get the performance/scalability changes in for jdk 9. > > It also includes a redo of ArrayList#removeIf to make it more efficient and > consistent with behavior of other implementations, including ArrayDeque. > > The patches are a little tangled because they step on each other's toes. > File CollectionTest is in "miscellaneous", but it tests both the ArrayDeque > and ArrayList changes. From patrick at reini.net Fri Nov 18 09:19:35 2016 From: patrick at reini.net (Patrick Reinhart) Date: Fri, 18 Nov 2016 10:19:35 +0100 Subject: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors Message-ID: <95e4229aebf14680b20f5757ec725304@reini.net> I was looking at the existing JDK 9 issues for some simple ones I could solve and found this one. I wanted to know if it makes sense to add additional constructors here? Now you need to do this: ------------------------ try { new PrintWriter(file, "UTF-8"); } catch (UnsupportedEncodingException e) { // Ignore, this is required to be supported by the JVM. } The same applies also to the String constructor... Instead the following behaviour is requested: --------------------------------------------- new PrintWriter(file, StandardCharsets.UTF_8)); On the other hand then the next request will be to add constructors also to specify autoflush and so on... -Patrick From daniel.fuchs at oracle.com Fri Nov 18 10:03:21 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 18 Nov 2016 10:03:21 +0000 Subject: RFR[9] JDK-8158916: ProblemList.txt update for com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java In-Reply-To: <7e02a877-a014-a8a6-d69e-40320aae53ae@oracle.com> References: <59dc7e57-3d05-6395-abdc-a0677b487fbb@oracle.com> <0988590c-7530-8470-3b74-56a2a8c3e744@oracle.com> <7e02a877-a014-a8a6-d69e-40320aae53ae@oracle.com> Message-ID: <212fd806-b85d-cf3b-2065-4766ec773753@oracle.com> Hi John, Looks good to me. Should windows-amd64 also be listed? It appears the test also failing there (JDK-8152654) best regards, -- daniel On 18/11/16 06:02, John Jiang wrote: > Hi, > Track this test issue with a new JBS bug JDK-8169942. > Please take a look at the updated webrew: > http://cr.openjdk.java.net/~jjiang/8158916/webrev.01/, or the below, > > --- old/test/ProblemList.txt 2016-11-17 21:29:12.112822913 -0800 > +++ new/test/ProblemList.txt 2016-11-17 21:29:11.964822915 -0800 > @@ -298,6 +298,6 @@ > > # jdk_other > > -com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8141370 > linux-i586,macosx-all > +com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8169942 > linux-i586,macosx-all > > ############################################################################ > > > Best regards, > John Jiang > > > On 2016/11/8 18:53, Daniel Fuchs wrote: >> Hi John, >> >> On 08/11/16 01:30, John Jiang wrote: >>> Hi Daniel, >>> Thanks for your comments. >>> >>> On 2016/11/7 19:21, Daniel Fuchs wrote: >>>> Hi John, >>>> >>>> Maybe you should reach out to Rob who fixed JDK-8141370 to >>>> make sure this is the right thing to do. >>> just cc Rob Mckenna >>> >>>> >>>> It seems the exclusion on problematic platforms [1] was deliberate: >>>> >>>>> Basically I've separated the failing subtest out into its own file and >>>>> excluded it on the (intermittently) failing platforms. >>> I see. But it should use an open issue. >>> I would like to open a new issue to track this issue. But I don't get >>> the exact failure log on DeadSSLLdapTimeoutTest.java, though the failure >>> may still be related to SSLHandshakeException. >>> When this test was born, it was in the ProblemList, so I suppose it has >>> no chance to be executed by our automatic testing systems. >> >> I see. I agree it's better to have an open bug in the ProblemList. >> But I am concerned if that bug is something that we never intend to >> fix because the test is not appropriate for those platforms. >> >> best regards, >> >> -- daniel >> >>> >>> Best regards, >>> John Jiang >>> >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037385.html >>>> >>>> >>>> >>>> >>>> On 07/11/16 02:37, John Jiang wrote: >>>>> Hi, >>>>> com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java is associated to 8141370 >>>>> in ProblemList, though issue JDK-8141370 has been resolved. >>>>> In fact, the fix for JDK-8141370 extracted some codes from >>>>> com/sun/jndi/ldap/LdapTimeoutTest.java to create >>>>> com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java, and put the new test to >>>>> ProblemList. >>>>> It would be better to remove this item from ProblemList. If >>>>> com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java still fails >>>>> intermittently, we can put it back to ProblemList with the exact >>>>> failure >>>>> logs. >>>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8158916 >>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8158916/webrev.00/ >>>>> >>>>> Best regards, >>>>> John Jiang >>>>> >>>> >>>> >>> >> >> > From christoph.langer at sap.com Fri Nov 18 12:38:06 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 18 Nov 2016 12:38:06 +0000 Subject: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE In-Reply-To: <582EA144.2000601@oracle.com> References: <582EA144.2000601@oracle.com> Message-ID: <667b95e296fb48809485a685394c5730@DEWDFE13DE03.global.corp.sap> Hi Joe, thanks for the feedback. I've created a new version of the webrev working in your suggestions, adding some further formatting cleanups in the files and I also moved a small refactoring in TransformerTest.java to this changeset. http://cr.openjdk.java.net/~clanger/webrevs/8169772.1/ >From my end this one is ready for pushing - waiting for your final go. Best regards Christoph From: Joe Wang [mailto:huizhe.wang at oracle.com] Sent: Freitag, 18. November 2016 07:36 To: Langer, Christoph Cc: core-libs-dev at openjdk.java.net Subject: Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE Looks fine. License header: in general, don't change / add Year if there's no material change, removing the legacy $Id field in EmptySerializer.java for example, does not constitute a change to the code, so just keep the original year (see below). The initial years for the classes: EmptySerializer.java 2012 SerializerBase.java 2012 ToSAXHandler.java none (meaning if you make changes to this class, just add 2016) ToStream.java 2006 ToUnknownStream.java 2007 XSLOutputAttributes.java none (so keep the original "DO NOT REMOVE OR ALTER!" block) Thanks, Joe On 11/16/16, 6:22 AM, Langer, Christoph wrote: Hi, please review another XALAN fix. The Serializer should be able to handle text nodes with null input. There has already been some discussion here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044567.html Bug: https://bugs.openjdk.java.net/browse/JDK-8169772 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169772.0/ The actual fix is in ToUnknownStream.java, method "public void characters(String chars) throws SAXException". I don't know if one should even directly return after chars being null or of size() 0. The rest of this change is cleanups and a test case. Thanks for reviewing. Best regards Christoph From dl at cs.oswego.edu Fri Nov 18 12:52:07 2016 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 18 Nov 2016 07:52:07 -0500 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: References: <8cc0d5a9-9245-e6b1-0ff2-616127dbc583@oracle.com> Message-ID: > On Thu, Nov 17, 2016 at 12:03 PM, Paul Sandoz > wrote: > > > Semaphore > ? > > 633 /** > 634 * Acquires and returns all permits that are immediately > available. > 635 * Upon return, zero permits are available. > 636 * > 637 * @return the number of permits acquired > 638 */ > 639 public int drainPermits() { > 640 return sync.drainPermits(); > 641 } > > Arguably, if positive acquires all permits, otherwise releases all > permits. Perhaps: Thank! That's a better way to phrase intent. Reworded to: /** * Acquires and returns all permits that are immediately * available, or if negative permits are available, releases them. * Upon return, zero permits are available. * * @return the number of permits acquired or, if negative, the * number released */ > > Probably requires a CCC which i can manage. > Really? If so, please do. -Doug From dl at cs.oswego.edu Fri Nov 18 13:02:48 2016 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 18 Nov 2016 08:02:48 -0500 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: <89979948.2793795.1479454136976.JavaMail.zimbra@u-pem.fr> References: <89979948.2793795.1479454136976.JavaMail.zimbra@u-pem.fr> Message-ID: <4fe94462-7669-ea8d-9ff0-6b592b4df316@cs.oswego.edu> On 11/18/2016 02:28 AM, Remi Forax wrote: > Martin, > for ArrayDeque, when you start to have methods like > @SuppressWarnings("unchecked") > static final E elementAt(Object[] es, int i) { > return (E) es[i]; > } > > I think it's a better idea to type the field elements as a E[] instead of Object[]. > Historically, using Object(] instead of E[] was preferred because it's a kind of 'more true' at runtime, > but it will be less true with anyfied generics and as we can see if it leads to introduce method like elementAt, using E[] will make the code more readable. > We always use Object[] in cases where anyfication isn't possible (without further code rework) because we rely on null as a distinct value. Elsewhere we do use E[]. -Doug > so the constructors should be: > @SuppressWarnings("unchecked") > public ArrayDeque() { > elements = (E[])new Object[16]; > } > > (same transformation for ArrayDeque(int)). > > And you can remove all the casts to E and the corresponnding SuppressWarnings and remove the method elementAt. > > R?mi > > ----- Mail original ----- >> De: "Martin Buchholz" >> ?: "core-libs-dev" , "Doug Lea"
      , "Stuart Marks" >> , "Paul Sandoz" >> Envoy?: Mardi 18 Octobre 2016 03:34:34 >> Objet: RFR: jsr166 jdk9 integration wave 12 > >> Most of this is for Stuart - very collection-y. >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ >> >> This includes a rewrite of ArrayDeque to bring it to parity with ArrayList >> (except for List features). >> The patch includes public methods ensureCapacity, trimToSize, replaceAll as >> in ArrayList, but we can defer making them public to a later change (or a >> later release), since new public methods are always controversial. But I'd >> really like to get the performance/scalability changes in for jdk 9. >> >> It also includes a redo of ArrayList#removeIf to make it more efficient and >> consistent with behavior of other implementations, including ArrayDeque. >> >> The patches are a little tangled because they step on each other's toes. >> File CollectionTest is in "miscellaneous", but it tests both the ArrayDeque >> and ArrayList changes. > From sergei.kovalev at oracle.com Fri Nov 18 14:09:19 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Fri, 18 Nov 2016 17:09:19 +0300 Subject: RFR(s): 8169721: [TESTBUG] com/sun/jndi tests have undeclared dependency on java.naming module In-Reply-To: <41d5049c-30af-25bf-eff6-0a7837d1eb51@oracle.com> References: <41d5049c-30af-25bf-eff6-0a7837d1eb51@oracle.com> Message-ID: Hi Daniel, Thank you for feedback. You absolutely right about modules. To have an ability to distinguish environment issue from test pass I've added a warning message how you recommended. At least it will have a visible effect. http://cr.openjdk.java.net/~skovalev/8169721/webrev.01/ Looks like I need another approval for one more reviewer. Isn't it? -- With best regards, Sergei 17.11.16 18:19, Daniel Fuchs wrote: > Hi Sergey, > > I added a System.out.println in UnbindIdempotent (see diff below) > to double check which type of context object was expected: > > Got context: class com.sun.jndi.rmi.registry.RegistryContext > > This lets me think that this test does not depend on java.naming > but rather on jdk.naming.rmi - and that if you simply link with > java.naming then the test might simply pass without doing nothing > because it gets a NamingException at line 54. > > Could you please double check this (verify what the test actually > does with --limit-mods and your current change)? > You might also want to keep the traces I added (below) to improve > diagnosis in case of test failures. > > The other changes look good - I think - though I am not > the usual maintainer of this area. > > best regards, > > -- daniel > > diff --git > a/test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java > b/test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java > --- > a/test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java > +++ > b/test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java > @@ -49,8 +49,10 @@ > > try { > rctx = (Context)ictx.lookup("rmi://localhost:" + > Integer.toString(registryPort)); > + System.out.println("Got context: " + rctx.getClass()); > } catch (NamingException e) { > // Unable to set up for test. > + System.out.println("Warning: Can't run test: " + e); > return; > } > > > On 15/11/16 14:34, Sergei Kovalev wrote: >> Hi Team, >> >> Please review a small fix for tests. >> >> BugID: https://bugs.openjdk.java.net/browse/JDK-8169721 >> Web review: http://cr.openjdk.java.net/~skovalev/8169721/webrev.00/ >> >> Issue: most tests has missed dependency om java.naming module. >> Solution: add missed module declaration for tests. If this possible, add >> module declaration to TEST.properties file to avoid modification of each >> individual test. >> From claes.redestad at oracle.com Fri Nov 18 14:52:09 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 18 Nov 2016 15:52:09 +0100 Subject: RFR: 8169993: Class::desiredAssertionStatus should call getClassLoader0 Message-ID: Hi, having classes ask the security manager for permission to access its own class loader when probing for assertion status during class initialization appears pointless. Bug: https://bugs.openjdk.java.net/browse/JDK-8169993 Webrev: http://cr.openjdk.java.net/~redestad/8169993/webrev.01/ Thanks! /Claes From erik.joelsson at oracle.com Fri Nov 18 15:30:20 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 18 Nov 2016 16:30:20 +0100 Subject: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images Message-ID: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> Hello, Please review this change which removes the $ARCH sub directory in the lib directory of the runtime images, which is an outstanding issue from the new runtime images. Most of the changes are in the build, but there are some in hotspot and launcher source. I have verified -testset hotspot and default in JPRT as well as tried to run as many jtreg tests as possible locally. I could only really find two tests that needed to be adjusted. Bug: https://bugs.openjdk.java.net/browse/JDK-8066474 Webrev: http://cr.openjdk.java.net/~erikj/8066474/webrev.01 /Erik From Roger.Riggs at Oracle.com Fri Nov 18 15:40:58 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 18 Nov 2016 10:40:58 -0500 Subject: RFR(s): 8169721: [TESTBUG] com/sun/jndi tests have undeclared dependency on java.naming module In-Reply-To: References: <41d5049c-30af-25bf-eff6-0a7837d1eb51@oracle.com> Message-ID: <1a019811-88c6-1e24-c155-e0b640de24b9@Oracle.com> Hi Sergei, UnbindIdempotent.java: - add 2016 to the copyright. Otherwise looks fine. Regards, Roger On 11/18/2016 9:09 AM, Sergei Kovalev wrote: > Hi Daniel, > > Thank you for feedback. > > You absolutely right about modules. To have an ability to distinguish > environment issue from test pass I've added a warning message how you > recommended. At least it will have a visible effect. > > http://cr.openjdk.java.net/~skovalev/8169721/webrev.01/ > > Looks like I need another approval for one more reviewer. Isn't it? > From daniel.fuchs at oracle.com Fri Nov 18 16:12:27 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 18 Nov 2016 16:12:27 +0000 Subject: RFR(s): 8169721: [TESTBUG] com/sun/jndi tests have undeclared dependency on java.naming module In-Reply-To: References: <41d5049c-30af-25bf-eff6-0a7837d1eb51@oracle.com> Message-ID: On 18/11/16 14:09, Sergei Kovalev wrote: > Hi Daniel, > > Thank you for feedback. > > You absolutely right about modules. To have an ability to distinguish > environment issue from test pass I've added a warning message how you > recommended. At least it will have a visible effect. > > http://cr.openjdk.java.net/~skovalev/8169721/webrev.01/ > > Looks like I need another approval for one more reviewer. Isn't it? > The new version looks good. best regards, -- daniel From Roger.Riggs at Oracle.com Fri Nov 18 16:28:59 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 18 Nov 2016 11:28:59 -0500 Subject: RFR of JDK-8168975: java/rmi/activation/Activatable tests fail due to "Port already in use" in RMID.restart() In-Reply-To: <1a3633ad-33e1-2646-b4e8-9ba492a8f7cf@oracle.com> References: <68995a74-8e19-9462-1ff3-cd32a3a40441@oracle.com> <5E268B7B-5C74-456F-BCCC-4CB0670C5E30@oracle.com> <12b34d35-d7de-6268-771f-1c0ac6f883fa@oracle.com> <1a3633ad-33e1-2646-b4e8-9ba492a8f7cf@oracle.com> Message-ID: Hi Hamlin, RMID.java: - import of LocalTime would lexically follow jva.rmi - 53-54 typos: "ajust" -> "adjust"; "togeter" -> "together" RMIDSelectorProvider.java: - 121, 125 I would have just used System.out.printf directly without introducing a trivial function. Looks fine, Roger Roger On 11/17/2016 1:46 AM, Hamlin Li wrote: > Hi Chris, Joe, Roger, > > Thank you for reviewing. Please check the comments inline. > > new webrev: http://cr.openjdk.java.net/~mli/8168975/webrev.01/ > > > Thank you > -Hamlin > > On 2016/11/17 2:30, joe darcy wrote: >> In terms of timeout, please use much shorter timeout, seconds not >> minutes. > In case of timeout value used in RMID.restart() and > RMIDSelectorProvider.inheritedChannel(), I recommend to set it longer, > reason is: > > 1. in most of runs, the test will not face a "port in use" issue, > because the time window between RMID.start and RMID.restart is small, > so a long timeout value will not impact the test run time; > 2. if there is a interloper between RMID.start() and RMID.restart(), > then it's better to wait for a longer time to grab the expected port > again rather than wait shorter time to get a test failure. > >> Most JDK regression tests complete in well under 10 seconds and few >> tests should run for as long as a minute. > After set "sun.rmi.transport.tcp.handshakeTimeout=5000", test will not > waste too much time at RMID.lookupSystem, normal tests which use > RMID.start and RMID.restart will finish in about dozens of seconds. I > guess running time is acceptable. >> Also, please scale any timeout if a timeout factor retrieved from the >> jtreg environment. This allows the test to behave better on heavily >> loaded or slow machines where the test invoker has requested more time. > Fixed, scale timeout in RMID.restart and > RMIDSelectorProvider.inheritedChannel based on jtreg time factor. >> >> Thanks, >> >> -Joe >> >> >> On 11/16/2016 9:01 AM, Chris Hegarty wrote: >>>> On 16 Nov 2016, at 07:36, Hamlin Li wrote: >>>> >>>> Would you please review below fix? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8168975 >>>> webrev: http://cr.openjdk.java.net/~mli/8168975/webrev.00/ >>> The approach builds on the mechanism put in for 8168975, and seems >>> reasonable. >>> >>> The system property being used to ?pass? the port number is specific to >>> the test, and not JDK related so should not be named >>> java.nio.channels.spi.SelectorProviderPort. Maybe something like >>> openjdk.test.RMIDSelectorProvider.port ? > Fixed, modify as "test.java.rmi.testlibrary.RMIDSelectorProvider.port". >>> >>> -Chris. >>> >>>> Root Cause: There is a time window between RMID.start() and >>>> RMID.restart(), interloper can step in and bind to the port used by >>>> RMID in RMID.start(). >>>> >>>> Solution: Modify RMID.java to use inherited channel when calling >>>> RMID.restart. And extend RMIDSelectorProvider.java to try to bind >>>> to specific port, no matter 0 or none-zero(for RMID.restart) in a >>>> while loop, if timeout just call System.exit to exit rmid and let >>>> test fail. >>>> >>>> >>>> Thank you >>>> -Hamlin >> > From tim.bell at oracle.com Fri Nov 18 16:34:03 2016 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 18 Nov 2016 08:34:03 -0800 Subject: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images In-Reply-To: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> References: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> Message-ID: <9846f58b-0c80-b8ce-674f-cf3fd239b01f@oracle.com> Erik: > Please review this change which removes the $ARCH sub directory in the > lib directory of the runtime images, which is an outstanding issue from > the new runtime images. Most of the changes are in the build, but there > are some in hotspot and launcher source. I have verified -testset > hotspot and default in JPRT as well as tried to run as many jtreg tests > as possible locally. I could only really find two tests that needed to > be adjusted. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066474 > > Webrev: http://cr.openjdk.java.net/~erikj/8066474/webrev.01 hotspot/test/runtime/ThreadSignalMask/exeThreadSignalMask.c jdk/make/copy/Copy-java.desktop.gmk jdk/src/java.base/unix/classes/java/lang/ProcessImpl.java These legal notices need to be updated for 2016. No need to redo the webrev if this is all the feedback you get. Looks fine otherwise. Tim From vladimir.kozlov at oracle.com Fri Nov 18 16:41:29 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Nov 2016 08:41:29 -0800 Subject: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images In-Reply-To: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> References: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> Message-ID: <1b0e979f-bcba-a912-66d8-c1282075461e@oracle.com> Finally! :) Hotspot changes looks fine to me. But you missed hotspot/make/hotspot.script file. Our colleges in RH and SAP should test these changes on their platforms. Next step would be removal of client/server sub-directories on platforms where we have only Server JVM (64-bit JDK has only Server JVM). Thanks, Vladimir On 11/18/16 7:30 AM, Erik Joelsson wrote: > Hello, > > Please review this change which removes the $ARCH sub directory in the > lib directory of the runtime images, which is an outstanding issue from > the new runtime images. Most of the changes are in the build, but there > are some in hotspot and launcher source. I have verified -testset > hotspot and default in JPRT as well as tried to run as many jtreg tests > as possible locally. I could only really find two tests that needed to > be adjusted. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066474 > > Webrev: http://cr.openjdk.java.net/~erikj/8066474/webrev.01 > > /Erik > From martinrb at google.com Fri Nov 18 16:46:34 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 18 Nov 2016 08:46:34 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: <1448961357.2789319.1479453438452.JavaMail.zimbra@u-pem.fr> References: <1448961357.2789319.1479453438452.JavaMail.zimbra@u-pem.fr> Message-ID: On Thu, Nov 17, 2016 at 11:17 PM, Remi Forax wrote: > ----- Mail original ----- > > De: "Martin Buchholz" > > ?: "Paul Sandoz" > > Cc: "core-libs-dev" > > Envoy?: Vendredi 18 Novembre 2016 05:29:12 > > Objet: Re: RFR: jsr166 jdk9 integration wave 12 > > [..] > > > >> 317 c.forEach(e -> addLast(e)); > >> > >> this::addLast, up to you which you prefer > >> > >> > > Meh. Left as is; another vote could tip to the other side. > > > > > > I like the rule that says, use a method reference if you can and a lambda > otherwise. > so i vote for this::addLast :) > > Done! Seems like a good rule to adopt. > R?mi > From paul.sandoz at oracle.com Fri Nov 18 16:52:12 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 18 Nov 2016 08:52:12 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: References: <8cc0d5a9-9245-e6b1-0ff2-616127dbc583@oracle.com> Message-ID: <35F6E6E9-C9EF-4AAD-A5D2-2F097679E321@oracle.com> > On 18 Nov 2016, at 04:52, Doug Lea
      wrote: > > >> On Thu, Nov 17, 2016 at 12:03 PM, Paul Sandoz > > wrote: >> >> >> Semaphore >> ? >> >> 633 /** >> 634 * Acquires and returns all permits that are immediately >> available. >> 635 * Upon return, zero permits are available. >> 636 * >> 637 * @return the number of permits acquired >> 638 */ >> 639 public int drainPermits() { >> 640 return sync.drainPermits(); >> 641 } >> >> Arguably, if positive acquires all permits, otherwise releases all >> permits. Perhaps: > > Thank! That's a better way to phrase intent. Reworded to: > > /** > * Acquires and returns all permits that are immediately > * available, or if negative permits are available, releases them. > * Upon return, zero permits are available. > * > * @return the number of permits acquired or, if negative, the > * number released > */ > Looks good to me. >> >> Probably requires a CCC which i can manage. >> > > Really? Hmm? i don?t really wanna do it :-) but i suppose from the current specification it could be interpreted that no action is taken if there are negative permits. I believe submitter of the associated bug interpreted it that way. > If so, please do. > I?ll take the pain :-) Paul. From martinrb at google.com Fri Nov 18 16:57:37 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 18 Nov 2016 08:57:37 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: <4fe94462-7669-ea8d-9ff0-6b592b4df316@cs.oswego.edu> References: <89979948.2793795.1479454136976.JavaMail.zimbra@u-pem.fr> <4fe94462-7669-ea8d-9ff0-6b592b4df316@cs.oswego.edu> Message-ID: On Fri, Nov 18, 2016 at 5:02 AM, Doug Lea
      wrote: > On 11/18/2016 02:28 AM, Remi Forax wrote: > >> Martin, >> for ArrayDeque, when you start to have methods like >> @SuppressWarnings("unchecked") >> static final E elementAt(Object[] es, int i) { >> return (E) es[i]; >> } >> >> I think it's a better idea to type the field elements as a E[] instead of >> Object[]. >> Historically, using Object(] instead of E[] was preferred because it's a >> kind of 'more true' at runtime, >> but it will be less true with anyfied generics and as we can see if it >> leads to introduce method like elementAt, using E[] will make the code more >> readable. >> >> > We always use Object[] in cases where anyfication isn't possible > (without further code rework) because we rely on null as a distinct > value. Elsewhere we do use E[]. I've always considered using E[] a bigger cheat than the elementAt method, due to the expectation that if reification was ever implemented, then E[] would simply be wrong in a ClassCastException sort of way. I will be surprised if anyfication can be made to work on collection classes without major rewrites. When working with elements that are references, there is a need to null out slots that are no longer used for the benefit of the GC, as well as a special value to mark the slot as free. Sometimes logically removing an element means CASing the reference to null. From paul.sandoz at oracle.com Fri Nov 18 16:58:39 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 18 Nov 2016 08:58:39 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: References: <1448961357.2789319.1479453438452.JavaMail.zimbra@u-pem.fr> Message-ID: > On 18 Nov 2016, at 08:46, Martin Buchholz wrote: > > > > On Thu, Nov 17, 2016 at 11:17 PM, Remi Forax > wrote: > ----- Mail original ----- > > De: "Martin Buchholz" > > > ?: "Paul Sandoz" > > > Cc: "core-libs-dev" > > > Envoy?: Vendredi 18 Novembre 2016 05:29:12 > > Objet: Re: RFR: jsr166 jdk9 integration wave 12 > > [..] > > > >> 317 c.forEach(e -> addLast(e)); > >> > >> this::addLast, up to you which you prefer > >> > >> > > Meh. Left as is; another vote could tip to the other side. > > > > > > I like the rule that says, use a method reference if you can and a lambda otherwise. > so i vote for this::addLast :) > > > Done! Seems like a good rule to adopt. > And FWIW you will get slightly less byte code in the compiled class, because there is no lambda body to de-sugar. Paul. From Derek.White at cavium.com Thu Nov 17 22:47:58 2016 From: Derek.White at cavium.com (White, Derek) Date: Thu, 17 Nov 2016 22:47:58 +0000 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <5a4a0e96-71b5-247b-60ea-5eb518d2162b@oracle.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> <582DF764.70504@linux.vnet.ibm.com> <5a4a0e96-71b5-247b-60ea-5eb518d2162b@oracle.com> Message-ID: Hi Joe, Although neither a floating point expert (as I think I've proven to you over the years), or a gcc expert, I checked with our in-house gcc expert and got this following answer: "Yes using -fno-strict-aliasing fixes the issues. Also there are many forks of fdlibm which has this fixed including the code inside glibc. " FWIW, - Derek -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Chris Plummer Sent: Thursday, November 17, 2016 4:49 PM To: joe darcy ; Gustavo Romero ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Cc: build-dev Subject: Re: PPC64: Poor StrictMath performance due to non-optimized compilation On 11/17/16 1:33 PM, joe darcy wrote: > Hi Gustavo, > > > On 11/17/2016 10:31 AM, Gustavo Romero wrote: >> Hi Joe, >> >> Thanks a lot for your valuable comments. >> >> On 17-11-2016 15:35, joe darcy wrote: >>>> Currently, optimization for building fdlibm is disabled, except for >>>> the "solaris" OS target [1]. >>> The reason for that is because historically the Solaris compilers >>> have had sufficient discipline and control regarding floating-point >>> semantics and compiler optimizations to still implement the >>> Java-mandated results when optimization was enabled. The gcc family >>> of compilers, for example, has lacked such discipline. >> oh, I see. Thanks for clarifying that. I was exactly wondering why >> fdlibm optimization is off even for x86_x64 as it, AFAICS regarding >> gcc 5 only, does not affect the precision, even if setting -O3 does >> not improve the performance as much as on PPC64. > > The fdlibm code relies on aliasing a two-element array of int with a > double to do bit-level reads and writes of floating-point values. As I > understand it, the C spec allows compilers to assume values of > different types don't overlap in memory. The compilation environment > has to be configured in such a way that the C compiler disables code > generation and optimization techniques that would run afoul of these > fdlibm coding practices. This is the strict aliasing issue right? It's a long standing problem with fdlibm that kept getting worse as gcc got smarter. IIRC, compiling with -fno-strict-aliasing fixes it, but it's been more than 12 years since I last dealt with fdlibm and compiler aliasing issues. Chris > >>>> As a consequence on PPC64 (Linux) StrictMath methods like, but not >>>> limited to, sin(), cos(), and tan() perform verify poor in >>>> comparison to the same methods in Math class [2]: >>> If you are doing your work against JDK 9, note that the pow, hypot, >>> and cbrt fdlibm methods required by StrictMath have been ported to >>> Java (JDK-8134780: Port fdlibm to Java). I have intentions to port >>> the remaining methods to Java, but it is unclear whether or not this >>> will occur for JDK 9. >> Yes, I'm doing my work against 9. So is there any problem if I >> proceed with my change? I understand that there is no conflict as >> JDK-8134780 progresses and replaces the StrictMath methods by their >> counterparts in Java. >> Please, advice. > > If I manage to finish the fdlibm C -> Java port in JDK 9, the changes > you are proposing would eventually be removed as unneeded since the C > code wouldn't be there to get compiled anymore. > >> >> Is it intended to downport JDK-8134780 to 8? > > Such a backport would be technically possible, but we at Oracle don't > currently plan to do so. > >> >> >>> Methods in the Math class, such as pow, are often intrinsified and >>> use a different algorithm so a straight performance comparison may >>> not be as fair or meaningful in those cases. >> I agree. It's just that the issue on StrictMath methods was first >> noted due to that huge gap (Math vs StrictMath) on PPC64, which is >> not prominent on x64. > > Depending on how Math.{sin, cos} is implemented on PPC64, compiling > the fdlibm sin/cos with more aggressive optimizations should not be > expected to close the performance gap. In particular, if Math.{sin, > cos} is an intrinsic on PPC64 (I haven't checked the sources) that > used platform-specific feature (say fused multiply add instructions) > then just compiling fdlibm more aggressively wouldn't necessarily make > up that gap. > > To allow cross-platform and cross-release reproducibility, StrictMath > is specified to use the particular fdlibm algorithms, which precludes > using better algorithms developed more recently. If we were to start > with a clean slate today, to get such reproducibility we would specify > correctly-rounded behavior of all those methods, but such an approach > was much less tractable technical 20+ years ago without benefit of the > research that was been done in the interim, such as the work of Prof. > Muller and associates: https://lipforge.ens-lyon.fr/projects/crlibm/. > >> >> >>> Accumulating the the results of the functions and comparisons the >>> sums is not a sufficiently robust way of checking to see if the >>> optimized versions are indeed equivalent to the non-optimized ones. >>> The specification of StrictMath requires a particular result for >>> each set of floating-point arguments and sums get round-away >>> low-order bits that differ. >> That's really good point, thanks for letting me know about that. I'll >> re-test my change under that perspective. >> >> >>> Running the JDK math library regression tests and corresponding JCK >>> tests is recommended for work in this area. >> Got it. By "the JDK math library regression tests" you mean exactly >> which test >> suite? the jtreg tests? > > Specifically, the regression tests under test/java/lang/Math and > test/java/lang/StrictMath in the jdk repository. There are some other > math library tests in the hotspot repo, but I don't know where they > are offhand. > > A note on methodologies, when I've been writing test for my port I've > tried to include test cases that exercise all the branches point in > the code. Due to the large input space (~2^64 for a single-argument > method), random sampling alone is an inefficient way to try to find > differences in behavior. >> For testing against JCK/TCK I'll need some help on that. >> > > I believe the JCK/TCK does have additional testcases relevant here. > > HTH; thanks, > > -Joe From martinrb at google.com Fri Nov 18 17:23:27 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 18 Nov 2016 09:23:27 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: References: <1448961357.2789319.1479453438452.JavaMail.zimbra@u-pem.fr> Message-ID: Here's a few more places to apply Remi's rule: --- src/test/tck/Collection8Test.java 15 Nov 2016 23:08:30 -0000 1.27 +++ src/test/tck/Collection8Test.java 18 Nov 2016 17:21:19 -0000 @@ -304,7 +304,7 @@ switch (rnd.nextInt(4)) { case 0: survivors.addAll(c); break; case 1: survivors.addAll(Arrays.asList(c.toArray())); break; - case 2: c.forEach(e -> survivors.add(e)); break; + case 2: c.forEach(survivors::add); break; case 3: for (Object e : c) survivors.add(e); break; } assertTrue(orig.containsAll(accepts)); @@ -355,11 +355,11 @@ ArrayList forEached = new ArrayList(); ArrayList removeIfed = new ArrayList(); for (Object x : c) iterated.add(x); - c.iterator().forEachRemaining(e -> iteratedForEachRemaining.add(e)); + c.iterator().forEachRemaining(iteratedForEachRemaining::add); for (Spliterator s = c.spliterator(); - s.tryAdvance(e -> tryAdvanced.add(e)); ) {} - c.spliterator().forEachRemaining(e -> spliterated.add(e)); - c.forEach(e -> forEached.add(e)); + s.tryAdvance(tryAdvanced::add); ) {} + c.spliterator().forEachRemaining(spliterated::add); + c.forEach(forEached::add); c.removeIf(e -> { removeIfed.add(e); return false; }); boolean ordered = c.spliterator().hasCharacteristics(Spliterator.ORDERED); @@ -589,7 +589,7 @@ try (PoolCleaner cleaner = cleaner(pool, done)) { threadsStarted.bulkRegister(tasks.size()); futures = tasks.stream() - .map(task -> pool.submit(task)) + .map(pool::submit) .collect(Collectors.toList()); threadsStarted.arriveAndDeregister(); Thread.sleep(testDurationMillis); From paul.sandoz at oracle.com Fri Nov 18 17:45:24 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 18 Nov 2016 09:45:24 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: References: <89979948.2793795.1479454136976.JavaMail.zimbra@u-pem.fr> <4fe94462-7669-ea8d-9ff0-6b592b4df316@cs.oswego.edu> Message-ID: <3C86ACED-9C0B-4B39-8B9F-6426C1E5E1AE@oracle.com> I encourage you to look at the experiments in the valhalla repository. Such as: http://hg.openjdk.java.net/valhalla/valhalla/jdk/file/780c8eba356a/src/java.base/share/classes/java/anyutil/ArrayDeque.java I have no objections to the current change but i expect it to change back at some point, and there will be other changes needed as you point out, but perhaps not as major as you think in some cases, and others perhaps more so, especially to take advantage of value-type optimized data structures. Paul. > On 18 Nov 2016, at 08:57, Martin Buchholz wrote: > > > > On Fri, Nov 18, 2016 at 5:02 AM, Doug Lea
      > wrote: > On 11/18/2016 02:28 AM, Remi Forax wrote: > Martin, > for ArrayDeque, when you start to have methods like > @SuppressWarnings("unchecked") > static final E elementAt(Object[] es, int i) { > return (E) es[i]; > } > > I think it's a better idea to type the field elements as a E[] instead of Object[]. > Historically, using Object(] instead of E[] was preferred because it's a kind of 'more true' at runtime, > but it will be less true with anyfied generics and as we can see if it leads to introduce method like elementAt, using E[] will make the code more readable. > > > We always use Object[] in cases where anyfication isn't possible > (without further code rework) because we rely on null as a distinct > value. Elsewhere we do use E[]. > > I've always considered using E[] a bigger cheat than the elementAt method, due to the expectation that if reification was ever implemented, then E[] would simply be wrong in a ClassCastException sort of way. > > I will be surprised if anyfication can be made to work on collection classes without major rewrites. When working with elements that are references, there is a need to null out slots that are no longer used for the benefit of the GC, as well as a special value to mark the slot as free. Sometimes logically removing an element means CASing the reference to null. From martinrb at google.com Fri Nov 18 18:16:36 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 18 Nov 2016 10:16:36 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: <4445357d-0546-adab-9d81-1c6d606b7e71@oracle.com> References: <8cc0d5a9-9245-e6b1-0ff2-616127dbc583@oracle.com> <4445357d-0546-adab-9d81-1c6d606b7e71@oracle.com> Message-ID: Regarding the testing mess: I think there should be a project to use Junit 5 features to create interface based tests. Then a BlockingDeque implementation could easily pull in all the tests already written for BlockingDeque and its superinterfaces. Tests for interfaces would be found in a predictable location, e.g. test/j/u/c/BlockingDeque/. jtreg probably needs to have junit 5 support added. There should be testing folk excited about doing this! (The historic preference to have such tests in the JCK is an impediment ... ) On Wed, Oct 19, 2016 at 12:19 PM, Stuart Marks wrote: > > > On 10/18/16 11:00 AM, Martin Buchholz wrote: > >> There's already a certain amount of mixing, e.g. stream tests sometimes >> test >> j.u.c. and Queue tests sometimes test all the Queue implementations. >> Unlike >> non-test code, some redundancy and divergence of testing frameworks and >> styles >> is fine. I still haven't found a way of writing shared tests for >> implementations of an interface that I really like. >> > > It's probably the case that divergence of testing frameworks is > unavoidable, or at least it's impractical. I doubt that it's worthwhile to > rewrite all the straight jtreg tests into TestNG, or JUnit, or whatever. > But I'd draw the line before saying this is "fine." [1] > > Maintaining the tests' organization is pretty important. Most of the > collections tests are in jdk/test/java/util though they're spread around a > bit uncomfortably even here. But now it's, oh, ArrayDeque and > ArrayList.removeIf tests are over *here* instead. Having things spread > around increases the likelihood of cases being missed or being tested > redundantly. > > The test groups have to be maintained as well. I know I've been bitten by > problems (not in collections) where I *thought* I had run the right set of > tests, but it ended up that I hadn't, resulting in me breaking the build. > As it turns out, jdk_collections_core doesn't include any ArrayDeque tests. > Hmmm. Well, maybe jdk_collections_core isn't useful. It would have been > nice to know this when I added it last year. :-/ [2] > > As things stand, I'm basically OK with this changeset going in. But it > does seem to highlight some areas that need some future cleanup, > particularly in the tests and the test group declarations. > > s'marks > > [1] http://knowyourmeme.com/memes/this-is-fine > > [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7a0c06013ae6 > > From huizhe.wang at oracle.com Fri Nov 18 19:00:13 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 18 Nov 2016 11:00:13 -0800 Subject: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE In-Reply-To: <667b95e296fb48809485a685394c5730@DEWDFE13DE03.global.corp.sap> References: <582EA144.2000601@oracle.com> <667b95e296fb48809485a685394c5730@DEWDFE13DE03.global.corp.sap> Message-ID: <582F4FBD.3030208@oracle.com> Looks good, Christoph. I assume you'll do an all-test run (all in jaxp/test) before pushing. No need for further review, but it'd be nice to add an "Expected result" for the new test testBug8169772, with/without the fix (e.g. NPE). Best regards, Joe On 11/18/16, 4:38 AM, Langer, Christoph wrote: > > Hi Joe, > > thanks for the feedback. > > I've created a new version of the webrev working in your suggestions, > adding some further formatting cleanups in the files and I also moved > a small refactoring in TransformerTest.java to this changeset. > > http://cr.openjdk.java.net/~clanger/webrevs/8169772.1/ > > > From my end this one is ready for pushing -- waiting for your final go. > > Best regards > > Christoph > > *From:*Joe Wang [mailto:huizhe.wang at oracle.com] > *Sent:* Freitag, 18. November 2016 07:36 > *To:* Langer, Christoph > *Cc:* core-libs-dev at openjdk.java.net > *Subject:* Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with > null valued text node causes NPE > > Looks fine. > > License header: in general, don't change / add Year if there's no > material change, removing the legacy $Id field in EmptySerializer.java > for example, does not constitute a change to the code, so just keep > the original year (see below). > > The initial years for the classes: > EmptySerializer.java 2012 > SerializerBase.java 2012 > ToSAXHandler.java none (meaning if you make changes to > this class, just add 2016) > ToStream.java 2006 > ToUnknownStream.java 2007 > XSLOutputAttributes.java none (so keep the original "DO > NOT REMOVE OR ALTER!" block) > > Thanks, > Joe > > On 11/16/16, 6:22 AM, Langer, Christoph wrote: > > Hi, > > please review another XALAN fix. > > The Serializer should be able to handle text nodes with null input. There has already been some discussion here:http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044567.html > > Bug:https://bugs.openjdk.java.net/browse/JDK-8169772 > Webrev:http://cr.openjdk.java.net/~clanger/webrevs/8169772.0/ > > The actual fix is in ToUnknownStream.java, method "public void characters(String chars) throws SAXException". I don't know if one should even directly return after chars being null or of size() 0. The rest of this change is cleanups and a test case. > > Thanks for reviewing. > > Best regards > Christoph > > > From paul.sandoz at oracle.com Fri Nov 18 19:02:56 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 18 Nov 2016 11:02:56 -0800 Subject: RFR: 8169993: Class::desiredAssertionStatus should call getClassLoader0 In-Reply-To: References: Message-ID: <765CE8A5-C6FB-47B1-A907-D4C90AAB4CF8@oracle.com> > On 18 Nov 2016, at 06:52, Claes Redestad wrote: > > Hi, > > having classes ask the security manager for permission to access its own class loader > when probing for assertion status during class initialization appears pointless. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169993 > Webrev: http://cr.openjdk.java.net/~redestad/8169993/webrev.01/ > +1 Paul. From christoph.langer at sap.com Fri Nov 18 20:17:11 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 18 Nov 2016 20:17:11 +0000 Subject: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE In-Reply-To: <582F4FBD.3030208@oracle.com> References: <582EA144.2000601@oracle.com> <667b95e296fb48809485a685394c5730@DEWDFE13DE03.global.corp.sap> <582F4FBD.3030208@oracle.com> Message-ID: <9fe8c952061c4cf490ab3419fadf70f2@DEWDFE13DE03.global.corp.sap> Hi Joe, Yep, I'll conduct the testing before pushing. With the "Expected Result", you mean some comment for the test method, right? Thanks Christoph From: Joe Wang [mailto:huizhe.wang at oracle.com] Sent: Freitag, 18. November 2016 20:00 To: Langer, Christoph Cc: core-libs-dev at openjdk.java.net Subject: Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE Looks good, Christoph. I assume you'll do an all-test run (all in jaxp/test) before pushing. No need for further review, but it'd be nice to add an "Expected result" for the new test testBug8169772, with/without the fix (e.g. NPE). Best regards, Joe On 11/18/16, 4:38 AM, Langer, Christoph wrote: Hi Joe, thanks for the feedback. I've created a new version of the webrev working in your suggestions, adding some further formatting cleanups in the files and I also moved a small refactoring in TransformerTest.java to this changeset. http://cr.openjdk.java.net/~clanger/webrevs/8169772.1/ >From my end this one is ready for pushing - waiting for your final go. Best regards Christoph From: Joe Wang [mailto:huizhe.wang at oracle.com] Sent: Freitag, 18. November 2016 07:36 To: Langer, Christoph Cc: core-libs-dev at openjdk.java.net Subject: Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE Looks fine. License header: in general, don't change / add Year if there's no material change, removing the legacy $Id field in EmptySerializer.java for example, does not constitute a change to the code, so just keep the original year (see below). The initial years for the classes: EmptySerializer.java 2012 SerializerBase.java 2012 ToSAXHandler.java none (meaning if you make changes to this class, just add 2016) ToStream.java 2006 ToUnknownStream.java 2007 XSLOutputAttributes.java none (so keep the original "DO NOT REMOVE OR ALTER!" block) Thanks, Joe On 11/16/16, 6:22 AM, Langer, Christoph wrote: Hi, please review another XALAN fix. The Serializer should be able to handle text nodes with null input. There has already been some discussion here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044567.html Bug: https://bugs.openjdk.java.net/browse/JDK-8169772 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169772.0/ The actual fix is in ToUnknownStream.java, method "public void characters(String chars) throws SAXException". I don't know if one should even directly return after chars being null or of size() 0. The rest of this change is cleanups and a test case. Thanks for reviewing. Best regards Christoph From magnus.ihse.bursie at oracle.com Fri Nov 18 20:40:58 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 18 Nov 2016 21:40:58 +0100 Subject: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images In-Reply-To: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> References: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> Message-ID: On 2016-11-18 16:30, Erik Joelsson wrote: > Hello, > > Please review this change which removes the $ARCH sub directory in the > lib directory of the runtime images, which is an outstanding issue > from the new runtime images. Most of the changes are in the build, but > there are some in hotspot and launcher source. I have verified > -testset hotspot and default in JPRT as well as tried to run as many > jtreg tests as possible locally. I could only really find two tests > that needed to be adjusted. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066474 > > Webrev: http://cr.openjdk.java.net/~erikj/8066474/webrev.01 Looks good to me. If anything, the switch statement in ProcessImpl.java seems superfluous now, and you could possibly prune that bit even harder. Nice to see this go. :) /Magnus From mandy.chung at oracle.com Fri Nov 18 20:57:00 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 18 Nov 2016 12:57:00 -0800 Subject: RFR: JDK-8168256 - Plugin alias options in jlink --help output seems to be in an arbitrary order In-Reply-To: References: Message-ID: <2F579D82-DF67-46BA-AAF9-EBC70F79D8E7@oracle.com> > On Nov 16, 2016, at 7:00 AM, Jim Laskey (Oracle) wrote: > > Sorts options by full name > > http://cr.openjdk.java.net/~jlaskey/8168256/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8168256 > 113 public Option(boolean hasArg, Processing processing, String name, String shortcut) { 114 this(hasArg, processing, false, name, ""); 115 } should be this(hasArg, processing, false, name, shortcut); 152 } else if (trimmedName.startsWith("-")) { 153 trimmedName = trimmedName.substring(1); 154 } Per JEP 293, jlink is a new tool that should have long form option names. This can be simplified (these 2 lines not needed) and the resource bundle key uses the long form name. Option constructor should validate the name parameter with two slashes prefix. Otherwise, looks good. Mandy From brent.christian at oracle.com Fri Nov 18 21:20:45 2016 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 18 Nov 2016 13:20:45 -0800 Subject: RFR 8136831 : Undefined null behavior in Class[Loader].getResourceXXXX() In-Reply-To: <314CE865-4154-44A7-8057-0C4C5072C7C5@oracle.com> References: <844FDA4B-AD61-4A76-B966-AF8743E70458@oracle.com> <1d9ea794-e643-4a07-66a6-6a4196e55f8c@oracle.com> <8F44D77B-55F4-4EA6-99FE-AAF59D1252AD@oracle.com> <314CE865-4154-44A7-8057-0C4C5072C7C5@oracle.com> Message-ID: Hi, Thank you to Paul for pointing out to me that ClassLoader.resources() also falls into this category. I have updated resources() to follow suit, along with test code (and Mandy's suggested test changes) in this updated webrev: http://cr.openjdk.java.net/~bchristi/8136831/webrev.03/ Thanks, -Brent From christoph.langer at sap.com Fri Nov 18 22:51:11 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 18 Nov 2016 22:51:11 +0000 Subject: RFR: 8169631: [JAXP] XALAN: transformation of XML via namespace-unaware SAX input yields a different result than namespace-unaware DOM input In-Reply-To: <582E8944.7090906@oracle.com> References: <313759790392479fa80a10542ab664ec@dewdfe13de07.global.corp.sap> <582A7170.7030100@oracle.com> <4be5158237814eeb9352fe8fe344e47c@dewdfe13de07.global.corp.sap> <582E8944.7090906@oracle.com> Message-ID: Hi Joe, thanks for the feedback. I've now understood the testcase that you've sent over and the reason that it is reporting failure after my fix is that the output of its transform operation is rather correct now. And before it was wrong. :) The test is comparing the actual result to a "golden" result file in the end and both of these were not looking healthy so far. The reason is that your test is using a namespace unaware SAX Parser as input. With the current JDK XALAN, you could already modify your smoketest to use a namespace aware parser. E.g. replace lines 82 // Use the JAXP way to get an XMLReader 83 XMLReader reader = SAXParserFactory.newInstance().newSAXParser().getXMLReader(); with 82 // Use the JAXP way to get an XMLReader 83 SAXParserFactory spf = SAXParserFactory.newInstance(); 84 spf.setNamespaceAware(true); 85 XMLReader reader = spf.newSAXParser().getXMLReader(); ...and you would already get correct results that also DOM input or Stream Input would yield. So, are there other concerns/issues with this fix? Do you want me to include a transformation operation like the one that your SmokeTest does to TransformerTest which would illustrate the problem with namespace unaware SAX input data? Best regards Christoph > -----Original Message----- > From: Joe Wang [mailto:huizhe.wang at oracle.com] > Sent: Freitag, 18. November 2016 05:53 > To: Langer, Christoph > Cc: core-libs-dev at openjdk.java.net > Subject: Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via > namespace-unaware SAX input yields a different result than namespace- > unaware DOM input > > > > On 11/14/16, 11:43 PM, Langer, Christoph wrote: > > Hi Joe, > > > > thanks for looking. > > > > Can you let me know which smoke test is failing? I didn't see issues so far - I > was merely running the jtreg unittests for transformer. > > I sent the test to your mailbox. > > > > I stepped back from replacing Vector with ArrayList for m_prefixMappings > because the code is using methods indexOf() with a start index and setSize() for > which ArrayList has no direct matchings. One could, for sure, add some other > coding, e.g. use ArrayList's subList() method for the index based search - but I > wouldn't want to run the risk of adding a regression here just because I > modified the code and did not well test it. But if you insist, I could have another > look. > > Ok, that's fine. subList would do, but setSize may need a bit more work. > > Best, > Joe > > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: Joe Wang [mailto:huizhe.wang at oracle.com] > >> Sent: Dienstag, 15. November 2016 03:23 > >> To: Langer, Christoph > >> Cc: core-libs-dev at openjdk.java.net > >> Subject: Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via > >> namespace-unaware SAX input yields a different result than namespace- > >> unaware DOM input > >> > >> Hi Christoph, > >> > >> Not all tests have finished yet, but there's at least one failure in the > >> smoke test. I'll get to the details when I have time. > >> > >> Any reason why m_prefixMappings can not be replaced with ArrayList? > >> > >> Thanks, > >> Joe > >> > >> On 11/14/16, 6:10 AM, Langer, Christoph wrote: > >>> Hi, > >>> > >>> please review this fix for bug 8169631. > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8169631 > >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169631.0/ > >>> > >>> When XALAN is handling namespace unaware input, it behaves differently > >> while using SAX input compared to DOM input. > >>> With both input source types, the class > >> com.sun.org.apache.xml.internal.dtm.ref.sax2dtm.SAX2DTM2 converts SAX > >> input into a DTM representation for processing by the XALAN transformer. > Its > >> method startElement takes URI, localname and qName as attribute. In case > of > >> missing feature namespaces, startElement and localname can be empty. > >> However, the function uses the localname value for the call to > >> m_expandedNameTable.getExpandedTypeID() and further processing. In the > >> case where only qName has data, this leads to issues. > >>> When using DOM input, the class > >> com.sun.org.apache.xalan.internal.xsltc.trax.DOM2SAX converts the DOM > input > >> into SAX input. In the case of empty localname, it fills localname with qname > >> data. See method getLocalName() [1], called by parse() [2]. > >>> When directly using SAX input, the SAX parser calls the startElement() > >> function on XALAN's handler with empty uri and localname - which seems > >> correct, as per the spec. > >>> Both paths end up in SAX2DTM2's startElement(). So I suggest to change > this > >> method to handle the case when uri and localname are empty and then set > >> qname as localname. Maybe one should even change DOM2SAX's > >> getLocalName handling to not fill localname with qname in case it is empty > >> after SAX2DTM was changed.. > >>> Generally, JavaDoc for SAXSource says that "Attempting to transform an > input > >> source that is not generated with a namespace-aware parser may result in > >> errors." But why not fix some of these :) > >>> Furthermore I did some cleanups in the code. > >>> > >>> Thanks and best regards > >>> Christoph > >>> > >>> [1] > >> > http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/shar > >> > e/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l139 > >>> [2] > >> > http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/shar > >> > e/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l279 > >>> [3] > >> > https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/sax/SAXSource > >> .html > >>> From huizhe.wang at oracle.com Fri Nov 18 23:22:54 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 18 Nov 2016 15:22:54 -0800 Subject: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE In-Reply-To: <9fe8c952061c4cf490ab3419fadf70f2@DEWDFE13DE03.global.corp.sap> References: <582EA144.2000601@oracle.com> <667b95e296fb48809485a685394c5730@DEWDFE13DE03.global.corp.sap> <582F4FBD.3030208@oracle.com> <9fe8c952061c4cf490ab3419fadf70f2@DEWDFE13DE03.global.corp.sap> Message-ID: <582F8D4E.6020902@oracle.com> On 11/18/16, 12:17 PM, Langer, Christoph wrote: > > Hi Joe, > > Yep, I'll conduct the testing before pushing. > > With the "Expected Result", you mean some comment for the test method, > right? > Yes, some comment for the test method would do. But I see that you've added assertions? That would be even better. Comments help in this case since without the patch, the process would have thrown an NPE. Once a bug is fixed, SQE will take the new test and verify the fix. Knowing the success/fail (before and after fix) conditions is helpful for them. Thanks, Joe > Thanks > > Christoph > > *From:*Joe Wang [mailto:huizhe.wang at oracle.com] > *Sent:* Freitag, 18. November 2016 20:00 > *To:* Langer, Christoph > *Cc:* core-libs-dev at openjdk.java.net > *Subject:* Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with > null valued text node causes NPE > > Looks good, Christoph. > > I assume you'll do an all-test run (all in jaxp/test) before pushing. > No need for further review, but it'd be nice to add an "Expected > result" for the new test testBug8169772, with/without the fix (e.g. NPE). > > Best regards, > Joe > > On 11/18/16, 4:38 AM, Langer, Christoph wrote: > > Hi Joe, > > thanks for the feedback. > > I've created a new version of the webrev working in your > suggestions, adding some further formatting cleanups in the files > and I also moved a small refactoring in TransformerTest.java to > this changeset. > > http://cr.openjdk.java.net/~clanger/webrevs/8169772.1/ > > > From my end this one is ready for pushing -- waiting for your > final go. > > Best regards > > Christoph > > *From:*Joe Wang [mailto:huizhe.wang at oracle.com] > *Sent:* Freitag, 18. November 2016 07:36 > *To:* Langer, Christoph > > *Cc:* core-libs-dev at openjdk.java.net > > *Subject:* Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM > with null valued text node causes NPE > > Looks fine. > > License header: in general, don't change / add Year if there's no > material change, removing the legacy $Id field in > EmptySerializer.java for example, does not constitute a change to > the code, so just keep the original year (see below). > > The initial years for the classes: > EmptySerializer.java 2012 > SerializerBase.java 2012 > ToSAXHandler.java none (meaning if you make changes to > this class, just add 2016) > ToStream.java 2006 > ToUnknownStream.java 2007 > XSLOutputAttributes.java none (so keep the original > "DO NOT REMOVE OR ALTER!" block) > > Thanks, > Joe > > On 11/16/16, 6:22 AM, Langer, Christoph wrote: > > Hi, > > > > please review another XALAN fix. > > > > The Serializer should be able to handle text nodes with null input. There has already been some discussion here:http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044567.html > > > > Bug:https://bugs.openjdk.java.net/browse/JDK-8169772 > > Webrev:http://cr.openjdk.java.net/~clanger/webrevs/8169772.0/ > > > > The actual fix is in ToUnknownStream.java, method "public void characters(String chars) throws SAXException". I don't know if one should even directly return after chars being null or of size() 0. The rest of this change is cleanups and a test case. > > > > Thanks for reviewing. > > > > Best regards > > Christoph > > > From huizhe.wang at oracle.com Fri Nov 18 23:37:58 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 18 Nov 2016 15:37:58 -0800 Subject: RFR: 8169631: [JAXP] XALAN: transformation of XML via namespace-unaware SAX input yields a different result than namespace-unaware DOM input In-Reply-To: References: <313759790392479fa80a10542ab664ec@dewdfe13de07.global.corp.sap> <582A7170.7030100@oracle.com> <4be5158237814eeb9352fe8fe344e47c@dewdfe13de07.global.corp.sap> <582E8944.7090906@oracle.com> Message-ID: <582F90D6.1040308@oracle.com> Hi Christoph, Thanks for explaining the customer's dilemma with regard to their legacy process. The testcase I sent you was extracted from an internal SQE smoke test. I agree with your analysis, the 'golden' file which has been in there for over 10 years turns out to be wrong and needs to be updated. To fix this issue, we need to get that test fixed, and the check-in of your patch and that of the test need needs to happen simultaneously. Would you mind wanting for me to go through an internal process to get a patch ready, then we can check in almost at the same time? Best, Joe On 11/18/16, 2:51 PM, Langer, Christoph wrote: > Hi Joe, > > thanks for the feedback. > > I've now understood the testcase that you've sent over and the reason that it is reporting failure after my fix is that the output of its transform operation is rather correct now. And before it was wrong. :) > The test is comparing the actual result to a "golden" result file in the end and both of these were not looking healthy so far. The reason is that your test is using a namespace unaware SAX Parser as input. With the current JDK XALAN, you could already modify your smoketest to use a namespace aware parser. > > E.g. replace lines > > 82 // Use the JAXP way to get an XMLReader > 83 XMLReader reader = SAXParserFactory.newInstance().newSAXParser().getXMLReader(); > > with > > 82 // Use the JAXP way to get an XMLReader > 83 SAXParserFactory spf = SAXParserFactory.newInstance(); > 84 spf.setNamespaceAware(true); > 85 XMLReader reader = spf.newSAXParser().getXMLReader(); > > ...and you would already get correct results that also DOM input or Stream Input would yield. > > So, are there other concerns/issues with this fix? Do you want me to include a transformation operation like the one that your SmokeTest does to TransformerTest which would illustrate the problem with namespace unaware SAX input data? > > Best regards > Christoph > >> -----Original Message----- >> From: Joe Wang [mailto:huizhe.wang at oracle.com] >> Sent: Freitag, 18. November 2016 05:53 >> To: Langer, Christoph >> Cc: core-libs-dev at openjdk.java.net >> Subject: Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via >> namespace-unaware SAX input yields a different result than namespace- >> unaware DOM input >> >> >> >> On 11/14/16, 11:43 PM, Langer, Christoph wrote: >>> Hi Joe, >>> >>> thanks for looking. >>> >>> Can you let me know which smoke test is failing? I didn't see issues so far - I >> was merely running the jtreg unittests for transformer. >> >> I sent the test to your mailbox. >>> I stepped back from replacing Vector with ArrayList for m_prefixMappings >> because the code is using methods indexOf() with a start index and setSize() for >> which ArrayList has no direct matchings. One could, for sure, add some other >> coding, e.g. use ArrayList's subList() method for the index based search - but I >> wouldn't want to run the risk of adding a regression here just because I >> modified the code and did not well test it. But if you insist, I could have another >> look. >> >> Ok, that's fine. subList would do, but setSize may need a bit more work. >> >> Best, >> Joe >>> Best regards >>> Christoph >>> >>>> -----Original Message----- >>>> From: Joe Wang [mailto:huizhe.wang at oracle.com] >>>> Sent: Dienstag, 15. November 2016 03:23 >>>> To: Langer, Christoph >>>> Cc: core-libs-dev at openjdk.java.net >>>> Subject: Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via >>>> namespace-unaware SAX input yields a different result than namespace- >>>> unaware DOM input >>>> >>>> Hi Christoph, >>>> >>>> Not all tests have finished yet, but there's at least one failure in the >>>> smoke test. I'll get to the details when I have time. >>>> >>>> Any reason why m_prefixMappings can not be replaced with ArrayList? >>>> >>>> Thanks, >>>> Joe >>>> >>>> On 11/14/16, 6:10 AM, Langer, Christoph wrote: >>>>> Hi, >>>>> >>>>> please review this fix for bug 8169631. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8169631 >>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169631.0/ >>>>> >>>>> When XALAN is handling namespace unaware input, it behaves differently >>>> while using SAX input compared to DOM input. >>>>> With both input source types, the class >>>> com.sun.org.apache.xml.internal.dtm.ref.sax2dtm.SAX2DTM2 converts SAX >>>> input into a DTM representation for processing by the XALAN transformer. >> Its >>>> method startElement takes URI, localname and qName as attribute. In case >> of >>>> missing feature namespaces, startElement and localname can be empty. >>>> However, the function uses the localname value for the call to >>>> m_expandedNameTable.getExpandedTypeID() and further processing. In the >>>> case where only qName has data, this leads to issues. >>>>> When using DOM input, the class >>>> com.sun.org.apache.xalan.internal.xsltc.trax.DOM2SAX converts the DOM >> input >>>> into SAX input. In the case of empty localname, it fills localname with qname >>>> data. See method getLocalName() [1], called by parse() [2]. >>>>> When directly using SAX input, the SAX parser calls the startElement() >>>> function on XALAN's handler with empty uri and localname - which seems >>>> correct, as per the spec. >>>>> Both paths end up in SAX2DTM2's startElement(). So I suggest to change >> this >>>> method to handle the case when uri and localname are empty and then set >>>> qname as localname. Maybe one should even change DOM2SAX's >>>> getLocalName handling to not fill localname with qname in case it is empty >>>> after SAX2DTM was changed.. >>>>> Generally, JavaDoc for SAXSource says that "Attempting to transform an >> input >>>> source that is not generated with a namespace-aware parser may result in >>>> errors." But why not fix some of these :) >>>>> Furthermore I did some cleanups in the code. >>>>> >>>>> Thanks and best regards >>>>> Christoph >>>>> >>>>> [1] >> http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/shar >> e/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l139 >>>>> [2] >> http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/shar >> e/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l279 >>>>> [3] >> https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/sax/SAXSource >>>> .html From mandy.chung at oracle.com Fri Nov 18 23:48:42 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 18 Nov 2016 15:48:42 -0800 Subject: RFR 8136831 : Undefined null behavior in Class[Loader].getResourceXXXX() In-Reply-To: References: <844FDA4B-AD61-4A76-B966-AF8743E70458@oracle.com> <1d9ea794-e643-4a07-66a6-6a4196e55f8c@oracle.com> <8F44D77B-55F4-4EA6-99FE-AAF59D1252AD@oracle.com> <314CE865-4154-44A7-8057-0C4C5072C7C5@oracle.com> Message-ID: +1 Mandy > On Nov 18, 2016, at 1:20 PM, Brent Christian wrote: > > Hi, > > Thank you to Paul for pointing out to me that ClassLoader.resources() also falls into this category. > > I have updated resources() to follow suit, along with test code (and Mandy's suggested test changes) in this updated webrev: > > http://cr.openjdk.java.net/~bchristi/8136831/webrev.03/ > > Thanks, > -Brent > From martinrb at google.com Fri Nov 18 23:54:32 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 18 Nov 2016 15:54:32 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: References: <8cc0d5a9-9245-e6b1-0ff2-616127dbc583@oracle.com> <4445357d-0546-adab-9d81-1c6d606b7e71@oracle.com> Message-ID: No more rework is planned! From huizhe.wang at oracle.com Sat Nov 19 00:49:30 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 18 Nov 2016 16:49:30 -0800 Subject: RFR: 8023653: xalan inconsistently parses DOMSource and StreamSource In-Reply-To: <582E8E30.2030209@oracle.com> References: <582E8E30.2030209@oracle.com> Message-ID: <582FA19A.3050305@oracle.com> Hi Christoph, XMLReaderManager, 175 - 186 can be replace with: JdkXmlUtils.setXMLReaderPropertyIfSupport(reader, NAMESPACES_FEATURE, m_NamespaceAware, false); JdkXmlUtils.setXMLReaderPropertyIfSupport(reader, NAMESPACE_PREFIXES_FEATURE, !m_NamespaceAware, false); The new test can be improved: Test all 4 source types Use a dataprovider (with data fields: Source, Transformer or NamespaceAware, Expected String, etc) Test also Templates to verify the namespace feature is propagated properly Thanks, Joe On 11/17/16, 9:14 PM, Joe Wang wrote: > Together with 8169631, I think we need to understand your customer's > requirement before spending time on a change that would otherwise be > unnecesary. Why would turning off namespace-aware help him? As far as > the xml standards and parser/processor are concerned, it's a backward > development. A namespace-aware parser is compatible with the ones that > don't know about namespaces. The norm then is to always turn it on > (although the API had to default to off because of the legacy). Is the > user processing some legacy xml code? > > Thanks, > Joe > > On 11/16/16, 5:41 AM, Langer, Christoph wrote: >> Hi, >> >> to address the long standing bug 8023653 I propose the following change: >> >> webrev: http://cr.openjdk.java.net/~clanger/webrevs/8023653.0/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8023653 >> >> I think the bug report in general complains that the default for >> DOMSource input is to parse the input "namespace-unaware" whereas, if >> XALAN gets a StreamSource as input, it is parsed "namespace-aware". >> >> Generally I'm against changing either of these defaults (at this time >> at least) - XALAN StreamSource should be handled namespace aware and >> changing the default for DocumentBuilderFactory is maybe an option >> for the Java 10 timeframe, I'd say. However, at the moment it is not >> possible at all to configure XALAN's handling of StreamSource input >> to be namespace unaware. That's what I'd like to address with my >> change. With my modifications it's possible to set the namespace >> feature on the TransformerFactory (to false). It bases on my other >> open fix 8169631 which is discussed here: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044662.html >> Only with the corrections for that fix, the SAX parsing that is used >> for stream sources will be handled correctly. >> >> The proposed change from the bugreport (change options for the parser >> of the XSL input before compilation) would not help with the reported >> issue and also is not a good idea anyway as xsl input needs to be >> handled with namespaces obviously. >> >> I did other cleanups in my change as well, the real functional >> changes are in TransformerFactoryImpl.java, XSLTCDTMManager.java and >> XMLReaderManager.java. >> >> Thanks in advance for reviewing. >> >> Best regards >> Christoph >> From forax at univ-mlv.fr Sat Nov 19 14:37:02 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 19 Nov 2016 15:37:02 +0100 (CET) Subject: JShell doesn't provide a ToolProvider In-Reply-To: <582D0EA3.50504@oracle.com> References: <1273273610.1599970.1479288219573.JavaMail.zimbra@u-pem.fr> <329846621.2188003.1479337240825.JavaMail.zimbra@u-pem.fr> <582D0EA3.50504@oracle.com> Message-ID: <440842550.3433508.1479566222303.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Robert Field" > ?: forax at univ-mlv.fr, "Alan Bateman" > Cc: "core-libs-dev" > Envoy?: Jeudi 17 Novembre 2016 02:57:55 > Objet: Re: JShell doesn't provide a ToolProvider > On 11/16/16 15:00, forax at univ-mlv.fr wrote: >> So i respectfully disagree with Robert :) >> >> While the interactive mode of jshell is something important, being able to >> replay interactive sessions (stored in a file) automatically is in my opinion >> as important. >> If the module jdk.jshell provide an implementation for the interface >> ToolProvider inside the package jdk.internal.shell.tool, it can start >> JShellTool with exacly the same arguments as the main() does. >> >> R?mi > > I respectfully AGREE with R?mi. > > My arguments were for support of an InputStream parameter, and I agree > that without that is better than nothing, so I have created: > > https://bugs.openjdk.java.net/browse/JDK-8169821 > > The InputStream could be addressed in the SPI by having one more default > in ToolProvider, roughly: > > default int run(InputStream in, PrintStream out, PrintStream err, > String... args) { > return run(System.in, out, err, args); > } > > Maybe I was unclear -- Many thanks ! R?mi From david.holmes at oracle.com Sun Nov 20 01:36:42 2016 From: david.holmes at oracle.com (David Holmes) Date: Sun, 20 Nov 2016 11:36:42 +1000 Subject: RFR: 8169993: Class::desiredAssertionStatus should call getClassLoader0 In-Reply-To: References: Message-ID: <38571858-b0c3-6887-92fd-da08a406d689@oracle.com> On 19/11/2016 12:52 AM, Claes Redestad wrote: > Hi, > > having classes ask the security manager for permission to access its own > class loader > when probing for assertion status during class initialization appears > pointless. For our internal JDK classloaders perhaps, but you seem to be extrapolating this to all classloaders and all security manager implementations. This would be an observable change in behaviour so at a minimum should be thoroughly examined before being changed. David > Bug: https://bugs.openjdk.java.net/browse/JDK-8169993 > Webrev: http://cr.openjdk.java.net/~redestad/8169993/webrev.01/ > > Thanks! > > /Claes From claes.redestad at oracle.com Sun Nov 20 11:34:39 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 20 Nov 2016 12:34:39 +0100 Subject: RFR: 8169993: Class::desiredAssertionStatus should call getClassLoader0 In-Reply-To: <38571858-b0c3-6887-92fd-da08a406d689@oracle.com> References: <38571858-b0c3-6887-92fd-da08a406d689@oracle.com> Message-ID: <58318A4F.7060007@oracle.com> Hi, On 2016-11-20 02:36, David Holmes wrote: > On 19/11/2016 12:52 AM, Claes Redestad wrote: >> Hi, >> >> having classes ask the security manager for permission to access its own >> class loader >> when probing for assertion status during class initialization appears >> pointless. > > For our internal JDK classloaders perhaps, but you seem to be > extrapolating this to all classloaders and all security manager > implementations. This would be an observable change in behaviour so at a > minimum should be thoroughly examined before being changed. having desiredAssertionStatus throw an exception during the class initialization itself seems like it would break the world, regardless of intended classloader and security manager behavior (it's also an unspecified behavior for desiredAssertionStatus to throw a SecurityException in the first place) So what would be the possible harm of calling desiredAssertionStatus on a class where doing so previously threw a SecurityException (if such a case exists): we'll get the answer to the question of whether asserts are desired or not for the class. Is this leaking some information about the state of the VM? Sure, but unless I'm gravely mistaken this is a rather useless bit of information for anyone with malicious intent. /Claes > > David > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8169993 >> Webrev: http://cr.openjdk.java.net/~redestad/8169993/webrev.01/ >> >> Thanks! >> >> /Claes From david.holmes at oracle.com Sun Nov 20 22:43:56 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Nov 2016 08:43:56 +1000 Subject: RFR: 8169993: Class::desiredAssertionStatus should call getClassLoader0 In-Reply-To: <58318A4F.7060007@oracle.com> References: <38571858-b0c3-6887-92fd-da08a406d689@oracle.com> <58318A4F.7060007@oracle.com> Message-ID: <8f85037a-20a4-c6f8-11ef-cf85795bef5f@oracle.com> Hi Claes, On 20/11/2016 9:34 PM, Claes Redestad wrote: > Hi, > > On 2016-11-20 02:36, David Holmes wrote: >> On 19/11/2016 12:52 AM, Claes Redestad wrote: >>> Hi, >>> >>> having classes ask the security manager for permission to access its own >>> class loader >>> when probing for assertion status during class initialization appears >>> pointless. >> >> For our internal JDK classloaders perhaps, but you seem to be >> extrapolating this to all classloaders and all security manager >> implementations. This would be an observable change in behaviour so at a >> minimum should be thoroughly examined before being changed. > > having desiredAssertionStatus throw an exception during the class > initialization itself seems like it would break the world, regardless > of intended classloader and security manager behavior (it's also an > unspecified behavior for desiredAssertionStatus to throw a > SecurityException in the first place) Good point. > So what would be the possible harm of calling desiredAssertionStatus on > a class where doing so previously threw a SecurityException (if such a > case exists): we'll get the answer to the question of whether asserts > are desired or not for the class. Is this leaking some information > about the state of the VM? Sure, but unless I'm gravely mistaken this > is a rather useless bit of information for anyone with malicious intent. I'm not devious enough to fathom what someone may or may not do in such circumstances. I just wanted to make sure that before any SM check is removed that it has been given the appropriate thought - which it seems it has. Thanks, David > /Claes > >> >> David >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8169993 >>> Webrev: http://cr.openjdk.java.net/~redestad/8169993/webrev.01/ >>> >>> Thanks! >>> >>> /Claes From huaming.li at oracle.com Mon Nov 21 01:41:18 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Mon, 21 Nov 2016 09:41:18 +0800 Subject: RFR of JDK-8168975: java/rmi/activation/Activatable tests fail due to "Port already in use" in RMID.restart() In-Reply-To: References: <68995a74-8e19-9462-1ff3-cd32a3a40441@oracle.com> <5E268B7B-5C74-456F-BCCC-4CB0670C5E30@oracle.com> <12b34d35-d7de-6268-771f-1c0ac6f883fa@oracle.com> <1a3633ad-33e1-2646-b4e8-9ba492a8f7cf@oracle.com> Message-ID: <7d79148b-75fb-68ac-360a-e4782bded139@oracle.com> Hi Roger, Thank you for reviewing. Modified as you suggested, and pushed. Thank you -Hamlin On 2016/11/19 0:28, Roger Riggs wrote: > Hi Hamlin, > > RMID.java: > - import of LocalTime would lexically follow jva.rmi > > - 53-54 typos: "ajust" -> "adjust"; "togeter" -> "together" > > RMIDSelectorProvider.java: > > - 121, 125 I would have just used System.out.printf directly without > introducing a trivial function. > > Looks fine, Roger > > Roger > > > On 11/17/2016 1:46 AM, Hamlin Li wrote: >> Hi Chris, Joe, Roger, >> >> Thank you for reviewing. Please check the comments inline. >> >> new webrev: http://cr.openjdk.java.net/~mli/8168975/webrev.01/ >> >> >> Thank you >> -Hamlin >> >> On 2016/11/17 2:30, joe darcy wrote: >>> In terms of timeout, please use much shorter timeout, seconds not >>> minutes. >> In case of timeout value used in RMID.restart() and >> RMIDSelectorProvider.inheritedChannel(), I recommend to set it >> longer, reason is: >> >> 1. in most of runs, the test will not face a "port in use" issue, >> because the time window between RMID.start and RMID.restart is small, >> so a long timeout value will not impact the test run time; >> 2. if there is a interloper between RMID.start() and >> RMID.restart(), then it's better to wait for a longer time to grab >> the expected port again rather than wait shorter time to get a test >> failure. >> >>> Most JDK regression tests complete in well under 10 seconds and few >>> tests should run for as long as a minute. >> After set "sun.rmi.transport.tcp.handshakeTimeout=5000", test will >> not waste too much time at RMID.lookupSystem, normal tests which use >> RMID.start and RMID.restart will finish in about dozens of seconds. I >> guess running time is acceptable. >>> Also, please scale any timeout if a timeout factor retrieved from >>> the jtreg environment. This allows the test to behave better on >>> heavily loaded or slow machines where the test invoker has requested >>> more time. >> Fixed, scale timeout in RMID.restart and >> RMIDSelectorProvider.inheritedChannel based on jtreg time factor. >>> >>> Thanks, >>> >>> -Joe >>> >>> >>> On 11/16/2016 9:01 AM, Chris Hegarty wrote: >>>>> On 16 Nov 2016, at 07:36, Hamlin Li wrote: >>>>> >>>>> Would you please review below fix? >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8168975 >>>>> webrev: http://cr.openjdk.java.net/~mli/8168975/webrev.00/ >>>> The approach builds on the mechanism put in for 8168975, and seems >>>> reasonable. >>>> >>>> The system property being used to ?pass? the port number is >>>> specific to >>>> the test, and not JDK related so should not be named >>>> java.nio.channels.spi.SelectorProviderPort. Maybe something like >>>> openjdk.test.RMIDSelectorProvider.port ? >> Fixed, modify as "test.java.rmi.testlibrary.RMIDSelectorProvider.port". >>>> >>>> -Chris. >>>> >>>>> Root Cause: There is a time window between RMID.start() and >>>>> RMID.restart(), interloper can step in and bind to the port used >>>>> by RMID in RMID.start(). >>>>> >>>>> Solution: Modify RMID.java to use inherited channel when calling >>>>> RMID.restart. And extend RMIDSelectorProvider.java to try to bind >>>>> to specific port, no matter 0 or none-zero(for RMID.restart) in a >>>>> while loop, if timeout just call System.exit to exit rmid and let >>>>> test fail. >>>>> >>>>> >>>>> Thank you >>>>> -Hamlin >>> >> > From mandy.chung at oracle.com Mon Nov 21 03:48:11 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Sun, 20 Nov 2016 19:48:11 -0800 Subject: RFR: 8169993: Class::desiredAssertionStatus should call getClassLoader0 In-Reply-To: <38571858-b0c3-6887-92fd-da08a406d689@oracle.com> References: <38571858-b0c3-6887-92fd-da08a406d689@oracle.com> Message-ID: <3521AAFA-D566-4199-87C4-9A3A22587B83@oracle.com> > On Nov 19, 2016, at 5:36 PM, David Holmes wrote: > > On 19/11/2016 12:52 AM, Claes Redestad wrote: >> Hi, >> >> having classes ask the security manager for permission to access its own >> class loader >> when probing for assertion status during class initialization appears >> pointless. > > For our internal JDK classloaders perhaps, but you seem to be extrapolating this to all classloaders and all security manager implementations. This would be an observable change in behaviour so at a minimum should be thoroughly examined before being changed. Class::getClassLoader() is caller-sensitive and it will skip the permission check if the caller?s class loader is the same or ancestor of the class loader being accessed. Class::desiredAssertionStatus calls Class::getClassLoader and so the caller class in this case is java.lang.Class. Effectively no permission check is done and it?s equivalent to calling getClassLoader0. Mandy From mandy.chung at oracle.com Mon Nov 21 04:08:44 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Sun, 20 Nov 2016 20:08:44 -0800 Subject: Review Request JDK-8170062: Problem list java/lang/ClassLoader/platformClassLoader/DefinePlatformClass.java Message-ID: <9611DD6D-B10B-4000-8C41-AE967F8A960E@oracle.com> This test fails on windows but not all configuration. Temporarily put it on problem list for further investigation. diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -124,6 +124,7 @@ # jdk_lang java/lang/StringCoding/CheckEncodings.sh 7008363 generic-all +java/lang/ClassLoader/platformClassLoader/DefinePlatformClass.java 8169639 windows-all Mandy From joe.darcy at oracle.com Mon Nov 21 05:37:52 2016 From: joe.darcy at oracle.com (joe darcy) Date: Sun, 20 Nov 2016 21:37:52 -0800 Subject: Review Request JDK-8170062: Problem list java/lang/ClassLoader/platformClassLoader/DefinePlatformClass.java In-Reply-To: <9611DD6D-B10B-4000-8C41-AE967F8A960E@oracle.com> References: <9611DD6D-B10B-4000-8C41-AE967F8A960E@oracle.com> Message-ID: <427b867e-0c64-209d-f802-ccb608fbc552@oracle.com> +1 -Joe On 11/20/2016 8:08 PM, Mandy Chung wrote: > This test fails on windows but not all configuration. Temporarily put it on problem list for further investigation. > > diff --git a/test/ProblemList.txt b/test/ProblemList.txt > --- a/test/ProblemList.txt > +++ b/test/ProblemList.txt > @@ -124,6 +124,7 @@ > # jdk_lang > > java/lang/StringCoding/CheckEncodings.sh 7008363 generic-all > +java/lang/ClassLoader/platformClassLoader/DefinePlatformClass.java 8169639 windows-all > > Mandy From huaming.li at oracle.com Mon Nov 21 08:33:41 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Mon, 21 Nov 2016 16:33:41 +0800 Subject: RFR of JDK-8170049: tests under java/rmi/activation/ fail with "java.security.AccessControlException: access denied ("java.net.SocketPermission" "localhost:5281" "listen, resolve")" on windows Message-ID: <35e574c8-767a-26e5-c07e-c0547fa56497@oracle.com> Would you please review the patch for below bug? bug: https://bugs.openjdk.java.net/browse/JDK-8170049 webrev: http://cr.openjdk.java.net/~mli/8170049/webrev.00/ The issue is weird, it only happens on windows, and reproducible. All the related tests passed on windows platforms in JPRT, but failed on windows platforms in mach5. Failure is "java.security.AccessControlException: access denied ("java.net.SocketPermission" "localhost:42069" "listen,resolve")", although I don't know the exact root cause (seems it's due to infra rather than test code), I just want to let all failed tests pass, so I choose to modify test policy files. Thank you -Hamlin From kumar.x.srinivasan at oracle.com Mon Nov 21 08:36:21 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 21 Nov 2016 00:36:21 -0800 Subject: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method In-Reply-To: <3160154D-73F2-430C-A943-E75CC9FF4C08@oracle.com> References: <3160154D-73F2-430C-A943-E75CC9FF4C08@oracle.com> Message-ID: <5832B205.5040808@oracle.com> Sorry for the delay, looks good. Kumar > Please review the (fairly straightforward) JDK changes needed to support launching JavaFX applications in a named module. > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8169289 > > Webrev: > http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/ > > > > For reference, here are the openjfx changes needed: > http://cr.openjdk.java.net/~ddehaven/8169289/openjfx-rt.0/ > > The changes can be pushed independently, so no fancy juggling will be needed. Only the LM_MODULE mode fails in any mixed combination, which fails as things stand now. I will file a followup issue to add unit tests, but those tests will go into openjfx and will wait until openjfx and openjdk promoted builds are in sync. I don't think the non-FX modes are affected substantially enough to warrant any test changes on the openjdk side. > > -DrD- > From chris.hegarty at oracle.com Mon Nov 21 09:41:35 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 21 Nov 2016 09:41:35 +0000 Subject: RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order Message-ID: JDK-8155977 updated ObjectInputStream::resolveClass, and resolveProxyClass, to work with the platform class loader, but inadvertently removed the text describing the order in which the call stack is searched, for the 'loader'. The omission, from Java SE 8, is " ... closest such method to the currently executing frame". Similar text should be reinstated. diff --git a/src/java.base/share/classes/java/io/ObjectInputStream.java b/src/java.base/share/classes/java/io/ObjectInputStream.java --- a/src/java.base/share/classes/java/io/ObjectInputStream.java +++ b/src/java.base/share/classes/java/io/ObjectInputStream.java @@ -661,7 +661,8 @@ * method on the current thread's stack whose declaring class is not a * * platform class, then loader is - * the class loader of such class; otherwise, loader + * the class loader corresponding to the class of the closest such + * method to the currently executing frame; otherwise, loader * is the {@linkplain ClassLoader#getPlatformClassLoader() * platform class loader}. If this call results in a * ClassNotFoundException and the name of the passed @@ -725,7 +726,8 @@ * method on the current thread's stack whose declaring class is not a * * platform class, then loader is - * the class loader of such class; otherwise, loader + * the class loader corresponding to the class of the closest such + * method to the currently executing frame; otherwise, loader * is the {@linkplain ClassLoader#getPlatformClassLoader() * platform class loader}. * Unless any of the resolved interfaces are non-public, this same value -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8155977 From bhanu.prakash.gopularam at oracle.com Mon Nov 21 10:08:43 2016 From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam) Date: Mon, 21 Nov 2016 02:08:43 -0800 (PST) Subject: RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale In-Reply-To: <582583AB.3060308@oracle.com> References: <574b23f4-e9cc-cc95-0b7b-6dd5a4bdea68@Oracle.com> <50825aee-4268-451c-a470-4433fb8c437b@default> <582583AB.3060308@oracle.com> Message-ID: <5e455c65-e6eb-4b51-bea3-d0b86dae2a5f@default> Hi Nadeesh, Thanks for the review. Please find the updated webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.02/ Please note that I have used Locale.US instead of Locale.UK as test parameters (variables) depend on that locale. Thank you, Bhanu -----Original Message----- From: nadeesh tv Sent: Friday, November 11, 2016 2:09 PM To: core-libs-dev at openjdk.java.net Subject: Re: RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale Hi Bhanu, I think adding Locale to the formatter will be better For eg: DateTimeFormatter f = builder.parseLenient().appendValue(HOUR_OF_DAY).appendValue(MINUTE_OF_HOUR, 2).appendLiteral('9').toFormatter(Locale.UK); Since other test cases use Locale.UK may be here also you can use UK instead of locale.US. Thanks and Regards, Nadeesh On 11/11/2016 10:57 AM, Bhanu Gopularam wrote: > Hi Roger, > > > > Thanks for the review. I have updated the test to set default locale (and restore it) in only those methods which were causing problem in non English locales. > > > > Please review the updated webrev below: > > Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.01/ > > > > Thanks, > > Bhanu > > > > From: Roger Riggs > Sent: Tuesday, June 21, 2016 8:36 PM > To: Bhanu Gopularam; core-libs-dev at openjdk.java.net > Cc: Stephen Colebourne > Subject: Re: RFR 8158880: > java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail > with zh_CN locale > > > > Hi Bhanu, > > It can be problematic to change the default Locale for the entire > process, especially since many tests are run in the same process. It > would be preferable to set the locale in the DateTimeFormatter builder instead of changing the process wide Locale. > > Please identify the specific test case to apply the fix only where needed. > > Is it only > tck.java.time.format.TCKDateTimeFormatterBuilder.test_appendZoneText_p > arseGenericTimeZonePatterns > where the failure is seen? > > This would be an issue testing any pattern letter with locale dependent behavior. > The locale should be set explicitly in the test. > > BTW, There is a predefined Locale.US that can be used, no need to construct a new Locale. > > Roger > > > > > > On 6/21/2016 6:31 AM, Bhanu Gopularam wrote: > > 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 > > -- Thanks and Regards, Nadeesh TV From goetz.lindenmaier at sap.com Mon Nov 21 11:35:20 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 21 Nov 2016 11:35:20 +0000 Subject: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images In-Reply-To: <1b0e979f-bcba-a912-66d8-c1282075461e@oracle.com> References: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> <1b0e979f-bcba-a912-66d8-c1282075461e@oracle.com> Message-ID: <1156e3bb13944547977e904fd8d79ccb@DEROTE13DE08.global.corp.sap> Hi, we appreciate this change a lot, and also if /server would go away. I built and tested it on linuxppcle, aixppc and linuxs390. There is still a place that refers to a removed variables and breaks the build: jdk/src/java.base/unix/native/libjli/ergo.c:94 LIBARCHNAME You can probably just replace LIBARCHNAME by ARCH which is set to the same value. I would propose to remove VM_CPU from hotspot/test/test_env.sh after you removed the last place where it is used. (VM_BITS is dead, too.) Best regards, Goetz. > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Vladimir Kozlov > Sent: Freitag, 18. November 2016 17:41 > To: Erik Joelsson ; build-dev dev at openjdk.java.net>; core-libs-dev ; > hotspot-dev developers > Subject: Re: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux > and Solaris images > > Finally! :) > > Hotspot changes looks fine to me. But you missed > hotspot/make/hotspot.script file. > > Our colleges in RH and SAP should test these changes on their platforms. > > Next step would be removal of client/server sub-directories on platforms > where we have only Server JVM (64-bit JDK has only Server JVM). > > Thanks, > Vladimir > > On 11/18/16 7:30 AM, Erik Joelsson wrote: > > Hello, > > > > Please review this change which removes the $ARCH sub directory in the > > lib directory of the runtime images, which is an outstanding issue from > > the new runtime images. Most of the changes are in the build, but there > > are some in hotspot and launcher source. I have verified -testset > > hotspot and default in JPRT as well as tried to run as many jtreg tests > > as possible locally. I could only really find two tests that needed to > > be adjusted. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066474 > > > > Webrev: http://cr.openjdk.java.net/~erikj/8066474/webrev.01 > > > > /Erik > > From goetz.lindenmaier at sap.com Mon Nov 21 13:10:15 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 21 Nov 2016 13:10:15 +0000 Subject: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images References: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> <1b0e979f-bcba-a912-66d8-c1282075461e@oracle.com> Message-ID: Hi, linuxx86_64 has the same issue. I tested it with the jdk9/hs repo: jdk/src/java.base/unix/native/libjli/ergo_i586.c: In function ServerClassMachineImpl: jdk/src/java.base/unix/native/libjli/ergo_i586.c:196:30: error: expected ) before LIBARCHNAME Best regards, Goetz > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Montag, 21. November 2016 12:35 > To: 'Vladimir Kozlov' ; Erik Joelsson > ; build-dev ; > core-libs-dev ; hotspot-dev developers > > Subject: RE: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux > and Solaris images > > Hi, > > we appreciate this change a lot, and also if /server would go away. > > I built and tested it on linuxppcle, aixppc and linuxs390. > > There is still a place that refers to a removed variables > and breaks the build: > jdk/src/java.base/unix/native/libjli/ergo.c:94 LIBARCHNAME > You can probably just replace LIBARCHNAME by ARCH which is set to > the same value. > > I would propose to remove VM_CPU from hotspot/test/test_env.sh after > you > removed the last place where it is used. (VM_BITS is dead, too.) > > Best regards, > Goetz. > > > -----Original Message----- > > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > > Behalf Of Vladimir Kozlov > > Sent: Freitag, 18. November 2016 17:41 > > To: Erik Joelsson ; build-dev > dev at openjdk.java.net>; core-libs-dev ; > > hotspot-dev developers > > Subject: Re: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux > > and Solaris images > > > > Finally! :) > > > > Hotspot changes looks fine to me. But you missed > > hotspot/make/hotspot.script file. > > > > Our colleges in RH and SAP should test these changes on their platforms. > > > > Next step would be removal of client/server sub-directories on platforms > > where we have only Server JVM (64-bit JDK has only Server JVM). > > > > Thanks, > > Vladimir > > > > On 11/18/16 7:30 AM, Erik Joelsson wrote: > > > Hello, > > > > > > Please review this change which removes the $ARCH sub directory in the > > > lib directory of the runtime images, which is an outstanding issue from > > > the new runtime images. Most of the changes are in the build, but there > > > are some in hotspot and launcher source. I have verified -testset > > > hotspot and default in JPRT as well as tried to run as many jtreg tests > > > as possible locally. I could only really find two tests that needed to > > > be adjusted. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066474 > > > > > > Webrev: http://cr.openjdk.java.net/~erikj/8066474/webrev.01 > > > > > > /Erik > > > From erik.joelsson at oracle.com Mon Nov 21 13:26:54 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 21 Nov 2016 14:26:54 +0100 Subject: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images In-Reply-To: References: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> <1b0e979f-bcba-a912-66d8-c1282075461e@oracle.com> Message-ID: Hello Goetz, Thanks for trying this out. Note that the ergo* files were removed in JDK-8169001 which is currently in jdk9/dev but not yet in hs. /Erik On 2016-11-21 14:10, Lindenmaier, Goetz wrote: > Hi, > > linuxx86_64 has the same issue. I tested it with the jdk9/hs repo: > > jdk/src/java.base/unix/native/libjli/ergo_i586.c: In function ServerClassMachineImpl: > jdk/src/java.base/unix/native/libjli/ergo_i586.c:196:30: error: expected ) before LIBARCHNAME > > Best regards, > Goetz > >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Montag, 21. November 2016 12:35 >> To: 'Vladimir Kozlov' ; Erik Joelsson >> ; build-dev ; >> core-libs-dev ; hotspot-dev developers >> >> Subject: RE: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux >> and Solaris images >> >> Hi, >> >> we appreciate this change a lot, and also if /server would go away. >> >> I built and tested it on linuxppcle, aixppc and linuxs390. >> >> There is still a place that refers to a removed variables >> and breaks the build: >> jdk/src/java.base/unix/native/libjli/ergo.c:94 LIBARCHNAME >> You can probably just replace LIBARCHNAME by ARCH which is set to >> the same value. >> >> I would propose to remove VM_CPU from hotspot/test/test_env.sh after >> you >> removed the last place where it is used. (VM_BITS is dead, too.) >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>> Behalf Of Vladimir Kozlov >>> Sent: Freitag, 18. November 2016 17:41 >>> To: Erik Joelsson ; build-dev >> dev at openjdk.java.net>; core-libs-dev ; >>> hotspot-dev developers >>> Subject: Re: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux >>> and Solaris images >>> >>> Finally! :) >>> >>> Hotspot changes looks fine to me. But you missed >>> hotspot/make/hotspot.script file. >>> >>> Our colleges in RH and SAP should test these changes on their platforms. >>> >>> Next step would be removal of client/server sub-directories on platforms >>> where we have only Server JVM (64-bit JDK has only Server JVM). >>> >>> Thanks, >>> Vladimir >>> >>> On 11/18/16 7:30 AM, Erik Joelsson wrote: >>>> Hello, >>>> >>>> Please review this change which removes the $ARCH sub directory in the >>>> lib directory of the runtime images, which is an outstanding issue from >>>> the new runtime images. Most of the changes are in the build, but there >>>> are some in hotspot and launcher source. I have verified -testset >>>> hotspot and default in JPRT as well as tried to run as many jtreg tests >>>> as possible locally. I could only really find two tests that needed to >>>> be adjusted. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066474 >>>> >>>> Webrev: http://cr.openjdk.java.net/~erikj/8066474/webrev.01 >>>> >>>> /Erik >>>> From goetz.lindenmaier at sap.com Mon Nov 21 13:43:21 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 21 Nov 2016 13:43:21 +0000 Subject: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images In-Reply-To: References: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> <1b0e979f-bcba-a912-66d8-c1282075461e@oracle.com> Message-ID: Ah, ok, so this is fine. Best regards, Goetz. > -----Original Message----- > From: Erik Joelsson [mailto:erik.joelsson at oracle.com] > Sent: Montag, 21. November 2016 14:27 > To: Lindenmaier, Goetz ; Vladimir Kozlov > ; build-dev ; > core-libs-dev ; hotspot-dev developers > > Subject: Re: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux > and Solaris images > > Hello Goetz, > > Thanks for trying this out. Note that the ergo* files were removed in > JDK-8169001 which is currently in jdk9/dev but not yet in hs. > > /Erik > > > On 2016-11-21 14:10, Lindenmaier, Goetz wrote: > > Hi, > > > > linuxx86_64 has the same issue. I tested it with the jdk9/hs repo: > > > > jdk/src/java.base/unix/native/libjli/ergo_i586.c: In function > ServerClassMachineImpl: > > jdk/src/java.base/unix/native/libjli/ergo_i586.c:196:30: error: expected ) > before LIBARCHNAME > > > > Best regards, > > Goetz > > > >> -----Original Message----- > >> From: Lindenmaier, Goetz > >> Sent: Montag, 21. November 2016 12:35 > >> To: 'Vladimir Kozlov' ; Erik Joelsson > >> ; build-dev ; > >> core-libs-dev ; hotspot-dev > developers > >> > >> Subject: RE: RFR: JDK-8066474: Remove the lib/$ARCH directory from > Linux > >> and Solaris images > >> > >> Hi, > >> > >> we appreciate this change a lot, and also if /server would go away. > >> > >> I built and tested it on linuxppcle, aixppc and linuxs390. > >> > >> There is still a place that refers to a removed variables > >> and breaks the build: > >> jdk/src/java.base/unix/native/libjli/ergo.c:94 LIBARCHNAME > >> You can probably just replace LIBARCHNAME by ARCH which is set to > >> the same value. > >> > >> I would propose to remove VM_CPU from hotspot/test/test_env.sh after > >> you > >> removed the last place where it is used. (VM_BITS is dead, too.) > >> > >> Best regards, > >> Goetz. > >> > >>> -----Original Message----- > >>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > >>> Behalf Of Vladimir Kozlov > >>> Sent: Freitag, 18. November 2016 17:41 > >>> To: Erik Joelsson ; build-dev >>> dev at openjdk.java.net>; core-libs-dev dev at openjdk.java.net>; > >>> hotspot-dev developers > >>> Subject: Re: RFR: JDK-8066474: Remove the lib/$ARCH directory from > Linux > >>> and Solaris images > >>> > >>> Finally! :) > >>> > >>> Hotspot changes looks fine to me. But you missed > >>> hotspot/make/hotspot.script file. > >>> > >>> Our colleges in RH and SAP should test these changes on their platforms. > >>> > >>> Next step would be removal of client/server sub-directories on > platforms > >>> where we have only Server JVM (64-bit JDK has only Server JVM). > >>> > >>> Thanks, > >>> Vladimir > >>> > >>> On 11/18/16 7:30 AM, Erik Joelsson wrote: > >>>> Hello, > >>>> > >>>> Please review this change which removes the $ARCH sub directory in > the > >>>> lib directory of the runtime images, which is an outstanding issue from > >>>> the new runtime images. Most of the changes are in the build, but > there > >>>> are some in hotspot and launcher source. I have verified -testset > >>>> hotspot and default in JPRT as well as tried to run as many jtreg tests > >>>> as possible locally. I could only really find two tests that needed to > >>>> be adjusted. > >>>> > >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066474 > >>>> > >>>> Webrev: http://cr.openjdk.java.net/~erikj/8066474/webrev.01 > >>>> > >>>> /Erik > >>>> From amaembo at gmail.com Mon Nov 21 13:59:03 2016 From: amaembo at gmail.com (Tagir F. Valeev) Date: Mon, 21 Nov 2016 20:59:03 +0700 Subject: 8072784: Better spliterator implementation for BitSet.stream() In-Reply-To: References: Message-ID: <1271248255.20161121205903@gmail.com> Hello! Is it necessary to report SIZED characteristic and calculate the cardinality in advance making two-pass traversal? This improves bitSet.stream().toArray() performance (also bitSet.stream().count(), but it's rare case in practice). However this is just waste of time for any other stream operation. It's possible to remove SIZED characteristic using "wordsInUse << ADDRESS_BITS_PER_WORD" as initial size estimation (or better getFence() result). This would make implementation simpler and a little bit faster for all scenarios excluding toArray(). What do you think? With best regards, Tagir Valeev PS> Hi, PS> Please review this patch implementing a spliterator for BitSet: PS> PS> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8072784-bitset-stream-spliterator/webrev/ PS> The spliterator is SIZED but not SUBSIZED, the bit set?s PS> cardinality is used (same for the iterator) as the size of the PS> root spliterator, and estimates from that are derived thereafter PS> for splits. Splitting attempts to balance the small vs. large, dense vs. sparse cases. PS> Most of the complexity is dealing with the edge case of there PS> being a bit set at Integer.MAX_VALUE. PS> Testing-wise i have leveraged the existing tests. It would be PS> nice to consider placing the spliterator testing functionality PS> into a separate library for reuse as PS> SpliteratorTraversingAndSplittingTest is getting large. Likewise PS> for more formally for streams, which is possible to reuse but a PS> little clunky. I can log issues for those. PS> Paul. From roger.riggs at oracle.com Mon Nov 21 15:02:38 2016 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 21 Nov 2016 10:02:38 -0500 Subject: RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale In-Reply-To: <5e455c65-e6eb-4b51-bea3-d0b86dae2a5f@default> References: <574b23f4-e9cc-cc95-0b7b-6dd5a4bdea68@Oracle.com> <50825aee-4268-451c-a470-4433fb8c437b@default> <582583AB.3060308@oracle.com> <5e455c65-e6eb-4b51-bea3-d0b86dae2a5f@default> Message-ID: <814049e4-69de-a83d-379f-695b7da57e4e@oracle.com> Look good. Thanks, Roger On 11/21/16 5:08 AM, Bhanu Gopularam wrote: > Hi Nadeesh, > > Thanks for the review. Please find the updated webrev: > http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.02/ > > Please note that I have used Locale.US instead of Locale.UK as test parameters (variables) depend on that locale. > > Thank you, > Bhanu > > > -----Original Message----- > From: nadeesh tv > Sent: Friday, November 11, 2016 2:09 PM > To: core-libs-dev at openjdk.java.net > Subject: Re: RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale > > Hi Bhanu, > > > I think adding Locale to the formatter will be better > > For eg: > > DateTimeFormatter f = builder.parseLenient().appendValue(HOUR_OF_DAY).appendValue(MINUTE_OF_HOUR, 2).appendLiteral('9').toFormatter(Locale.UK); > > Since other test cases use Locale.UK may be here also you can use UK instead of locale.US. > > Thanks and Regards, > Nadeesh > > > On 11/11/2016 10:57 AM, Bhanu Gopularam wrote: >> Hi Roger, >> >> >> >> Thanks for the review. I have updated the test to set default locale (and restore it) in only those methods which were causing problem in non English locales. >> >> >> >> Please review the updated webrev below: >> >> Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.01/ >> >> >> >> Thanks, >> >> Bhanu >> >> >> >> From: Roger Riggs >> Sent: Tuesday, June 21, 2016 8:36 PM >> To: Bhanu Gopularam; core-libs-dev at openjdk.java.net >> Cc: Stephen Colebourne >> Subject: Re: RFR 8158880: >> java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail >> with zh_CN locale >> >> >> >> Hi Bhanu, >> >> It can be problematic to change the default Locale for the entire >> process, especially since many tests are run in the same process. It >> would be preferable to set the locale in the DateTimeFormatter builder instead of changing the process wide Locale. >> >> Please identify the specific test case to apply the fix only where needed. >> >> Is it only >> tck.java.time.format.TCKDateTimeFormatterBuilder.test_appendZoneText_p >> arseGenericTimeZonePatterns >> where the failure is seen? >> >> This would be an issue testing any pattern letter with locale dependent behavior. >> The locale should be set explicitly in the test. >> >> BTW, There is a predefined Locale.US that can be used, no need to construct a new Locale. >> >> Roger >> >> >> >> >> >> On 6/21/2016 6:31 AM, Bhanu Gopularam wrote: >> >> 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 >> >> > -- > Thanks and Regards, > Nadeesh TV > From martinrb at google.com Mon Nov 21 15:29:22 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 21 Nov 2016 07:29:22 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: References: <8cc0d5a9-9245-e6b1-0ff2-616127dbc583@oracle.com> Message-ID: Un-OK. Sometimes when microbenchmarking, we stumble upon a code sequence that hotspot likes. I observed 20% improvement with the below, so switching to that: public boolean tryAdvance(Consumer action) { Objects.requireNonNull(action); final Object[] es = elements; if (fence < 0) { fence = tail; cursor = head; } // late-binding final int i; if ((i = cursor) == fence) return false; E e = nonNullElementAt(es, i); cursor = inc(i, es.length); action.accept(e); return true; } On Thu, Nov 17, 2016 at 7:41 PM, Martin Buchholz wrote: > > > On Thu, Nov 17, 2016 at 12:03 PM, Paul Sandoz > wrote: > >> >> 843 public boolean tryAdvance(Consumer action) { >> 844 if (action == null) >> 845 throw new NullPointerException(); >> 846 int t, i; >> 847 if ((t = fence) < 0) t = getFence(); >> >> Is that for optimisation purposes, since the same check is also performed >> in getFence? If so that seems like overkill >> >> > OK: > > --- src/main/java/util/ArrayDeque.java 18 Nov 2016 03:22:20 -0000 1.114 > +++ src/main/java/util/ArrayDeque.java 18 Nov 2016 03:38:23 -0000 > @@ -866,9 +866,8 @@ > public boolean tryAdvance(Consumer action) { > if (action == null) > throw new NullPointerException(); > - int t, i; > - if ((t = fence) < 0) t = getFence(); > - if (t == (i = cursor)) > + final int t, i; > + if ((t = getFence()) == (i = cursor)) > return false; > final Object[] es = elements; > cursor = inc(i, es.length); > > > >> >> 848 if (t == (i = cursor)) >> 849 return false; >> 850 final Object[] es; >> 851 action.accept(nonNullElementAt(es = elements, i)); >> 852 cursor = inc(i, es.length); >> > From roger.riggs at oracle.com Mon Nov 21 15:36:43 2016 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 21 Nov 2016 10:36:43 -0500 Subject: RFR of JDK-8170049: tests under java/rmi/activation/ fail with "java.security.AccessControlException: access denied ("java.net.SocketPermission" "localhost:5281" "listen, resolve")" on windows In-Reply-To: <35e574c8-767a-26e5-c07e-c0547fa56497@oracle.com> References: <35e574c8-767a-26e5-c07e-c0547fa56497@oracle.com> Message-ID: Looks ok. Roger On 11/21/16 3:33 AM, Hamlin Li wrote: > Would you please review the patch for below bug? > > bug: https://bugs.openjdk.java.net/browse/JDK-8170049 > webrev: http://cr.openjdk.java.net/~mli/8170049/webrev.00/ > > The issue is weird, it only happens on windows, and reproducible. All > the related tests passed on windows platforms in JPRT, but failed on > windows platforms in mach5. > > Failure is "java.security.AccessControlException: access denied > ("java.net.SocketPermission" "localhost:42069" "listen,resolve")", > although I don't know the exact root cause (seems it's due to infra > rather than test code), I just want to let all failed tests pass, so I > choose to modify test policy files. > > > Thank you > -Hamlin From naoto.sato at oracle.com Mon Nov 21 16:12:14 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 21 Nov 2016 08:12:14 -0800 Subject: RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale In-Reply-To: <814049e4-69de-a83d-379f-695b7da57e4e@oracle.com> References: <574b23f4-e9cc-cc95-0b7b-6dd5a4bdea68@Oracle.com> <50825aee-4268-451c-a470-4433fb8c437b@default> <582583AB.3060308@oracle.com> <5e455c65-e6eb-4b51-bea3-d0b86dae2a5f@default> <814049e4-69de-a83d-379f-695b7da57e4e@oracle.com> Message-ID: <5b25bae5-836c-9f5c-c4b1-73c9f61bb76c@oracle.com> +1 Naoto On 11/21/16 7:02 AM, Roger Riggs wrote: > Look good. > > Thanks, Roger > > > On 11/21/16 5:08 AM, Bhanu Gopularam wrote: >> Hi Nadeesh, >> >> Thanks for the review. Please find the updated webrev: >> http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.02/ >> >> Please note that I have used Locale.US instead of Locale.UK as test >> parameters (variables) depend on that locale. >> >> Thank you, >> Bhanu >> >> >> -----Original Message----- >> From: nadeesh tv >> Sent: Friday, November 11, 2016 2:09 PM >> To: core-libs-dev at openjdk.java.net >> Subject: Re: RFR 8158880: >> java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail >> with zh_CN locale >> >> Hi Bhanu, >> >> >> I think adding Locale to the formatter will be better >> >> For eg: >> >> DateTimeFormatter f = >> builder.parseLenient().appendValue(HOUR_OF_DAY).appendValue(MINUTE_OF_HOUR, >> 2).appendLiteral('9').toFormatter(Locale.UK); >> >> Since other test cases use Locale.UK may be here also you can use UK >> instead of locale.US. >> >> Thanks and Regards, >> Nadeesh >> >> >> On 11/11/2016 10:57 AM, Bhanu Gopularam wrote: >>> Hi Roger, >>> >>> >>> Thanks for the review. I have updated the test to set default locale >>> (and restore it) in only those methods which were causing problem in >>> non English locales. >>> >>> >>> Please review the updated webrev below: >>> >>> Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.01/ >>> >>> >>> Thanks, >>> >>> Bhanu >>> >>> >>> From: Roger Riggs >>> Sent: Tuesday, June 21, 2016 8:36 PM >>> To: Bhanu Gopularam; core-libs-dev at openjdk.java.net >>> Cc: Stephen Colebourne >>> Subject: Re: RFR 8158880: >>> java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail >>> with zh_CN locale >>> >>> >>> Hi Bhanu, >>> >>> It can be problematic to change the default Locale for the entire >>> process, especially since many tests are run in the same process. It >>> would be preferable to set the locale in the DateTimeFormatter >>> builder instead of changing the process wide Locale. >>> >>> Please identify the specific test case to apply the fix only where >>> needed. >>> >>> Is it only >>> tck.java.time.format.TCKDateTimeFormatterBuilder.test_appendZoneText_p >>> arseGenericTimeZonePatterns >>> where the failure is seen? >>> >>> This would be an issue testing any pattern letter with locale >>> dependent behavior. >>> The locale should be set explicitly in the test. >>> >>> BTW, There is a predefined Locale.US that can be used, no need to >>> construct a new Locale. >>> >>> Roger >>> >>> >>> >>> On 6/21/2016 6:31 AM, Bhanu Gopularam wrote: >>> >>> 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 >>> >>> >> -- >> Thanks and Regards, >> Nadeesh TV >> > From paul.sandoz at oracle.com Mon Nov 21 16:36:47 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 21 Nov 2016 08:36:47 -0800 Subject: 8072784: Better spliterator implementation for BitSet.stream() In-Reply-To: <1271248255.20161121205903@gmail.com> References: <1271248255.20161121205903@gmail.com> Message-ID: <84F5CDB7-DB60-4AC9-85C5-67F18EBEA49C@oracle.com> Hi Tagir, In the original issue i was pondering using SIZED for smaller bit sets and non-SIZED for larger bit sets, since we stride over the longs themselves when calculating the size (should be intrinsic to count the set bits, at least on x86). Supporting both is fairly simple, but you are correct not reporting SIZED would simplify things further and it may not matter in practice. Can you log an issue? I will follow up with some performance analysis. Thanks, Paul. > On 21 Nov 2016, at 05:59, Tagir F. Valeev wrote: > > Hello! > > Is it necessary to report SIZED characteristic and calculate the > cardinality in advance making two-pass traversal? This improves > bitSet.stream().toArray() performance (also bitSet.stream().count(), > but it's rare case in practice). However this is just waste of time > for any other stream operation. It's possible to remove SIZED > characteristic using "wordsInUse << ADDRESS_BITS_PER_WORD" as initial > size estimation (or better getFence() result). This would make > implementation simpler and a little bit faster for all scenarios > excluding toArray(). > > What do you think? > > With best regards, > Tagir Valeev > > > PS> Hi, > > PS> Please review this patch implementing a spliterator for BitSet: > > PS> > PS> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8072784-bitset-stream-spliterator/webrev/ > > PS> The spliterator is SIZED but not SUBSIZED, the bit set?s > PS> cardinality is used (same for the iterator) as the size of the > PS> root spliterator, and estimates from that are derived thereafter > PS> for splits. Splitting attempts to balance the small vs. large, dense vs. sparse cases. > > PS> Most of the complexity is dealing with the edge case of there > PS> being a bit set at Integer.MAX_VALUE. > > > PS> Testing-wise i have leveraged the existing tests. It would be > PS> nice to consider placing the spliterator testing functionality > PS> into a separate library for reuse as > PS> SpliteratorTraversingAndSplittingTest is getting large. Likewise > PS> for more formally for streams, which is possible to reuse but a > PS> little clunky. I can log issues for those. > > PS> Paul. > From paul.sandoz at oracle.com Mon Nov 21 16:47:48 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 21 Nov 2016 08:47:48 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: References: <8cc0d5a9-9245-e6b1-0ff2-616127dbc583@oracle.com> Message-ID: <36B64BBF-7010-45FC-99DD-0207CDAC3BDB@oracle.com> > On 21 Nov 2016, at 07:29, Martin Buchholz wrote: > > Un-OK. Sometimes when microbenchmarking, we stumble upon a code sequence that hotspot likes. I observed 20% improvement with the below, so switching to that: > > public boolean tryAdvance(Consumer action) { > Objects.requireNonNull(action); > final Object[] es = elements; > if (fence < 0) { fence = tail; cursor = head; } // late-binding > final int i; > if ((i = cursor) == fence) > return false; > E e = nonNullElementAt(es, i); > cursor = inc(i, es.length); > action.accept(e); > return true; > } > Ok. I suppose i should stop being surprised at these kind of things, but would like to know, if you happen to, why such an improvement was gained for explicitly inlining the getFence call. Were you reaching some inlining thresholds in hotspot? Paul. > > On Thu, Nov 17, 2016 at 7:41 PM, Martin Buchholz > wrote: > > > On Thu, Nov 17, 2016 at 12:03 PM, Paul Sandoz > wrote: > > 843 public boolean tryAdvance(Consumer action) { > 844 if (action == null) > 845 throw new NullPointerException(); > 846 int t, i; > 847 if ((t = fence) < 0) t = getFence(); > > Is that for optimisation purposes, since the same check is also performed in getFence? If so that seems like overkill > > > OK: > > --- src/main/java/util/ArrayDeque.java 18 Nov 2016 03:22:20 -0000 1.114 > +++ src/main/java/util/ArrayDeque.java 18 Nov 2016 03:38:23 -0000 > @@ -866,9 +866,8 @@ > public boolean tryAdvance(Consumer action) { > if (action == null) > throw new NullPointerException(); > - int t, i; > - if ((t = fence) < 0) t = getFence(); > - if (t == (i = cursor)) > + final int t, i; > + if ((t = getFence()) == (i = cursor)) > return false; > final Object[] es = elements; > cursor = inc(i, es.length); > > > > 848 if (t == (i = cursor)) > 849 return false; > 850 final Object[] es; > 851 action.accept(nonNullElementAt(es = elements, i)); > 852 cursor = inc(i, es.length); > From david.dehaven at oracle.com Mon Nov 21 17:22:33 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 21 Nov 2016 09:22:33 -0800 Subject: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method In-Reply-To: <5832B205.5040808@oracle.com> References: <3160154D-73F2-430C-A943-E75CC9FF4C08@oracle.com> <5832B205.5040808@oracle.com> Message-ID: <58F73B48-4EFF-4EA0-A85F-448BC2612757@oracle.com> No worries, thanks! -DrD- > Sorry for the delay, looks good. > > Kumar > >> Please review the (fairly straightforward) JDK changes needed to support launching JavaFX applications in a named module. >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8169289 >> >> Webrev: >> http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/ >> >> >> >> For reference, here are the openjfx changes needed: >> http://cr.openjdk.java.net/~ddehaven/8169289/openjfx-rt.0/ >> >> The changes can be pushed independently, so no fancy juggling will be needed. Only the LM_MODULE mode fails in any mixed combination, which fails as things stand now. I will file a followup issue to add unit tests, but those tests will go into openjfx and will wait until openjfx and openjdk promoted builds are in sync. I don't think the non-FX modes are affected substantially enough to warrant any test changes on the openjdk side. >> >> -DrD- >> > From martinrb at google.com Mon Nov 21 17:39:52 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 21 Nov 2016 09:39:52 -0800 Subject: RFR: jsr166 jdk9 integration wave 12 In-Reply-To: <36B64BBF-7010-45FC-99DD-0207CDAC3BDB@oracle.com> References: <8cc0d5a9-9245-e6b1-0ff2-616127dbc583@oracle.com> <36B64BBF-7010-45FC-99DD-0207CDAC3BDB@oracle.com> Message-ID: On Mon, Nov 21, 2016 at 8:47 AM, Paul Sandoz wrote: > > On 21 Nov 2016, at 07:29, Martin Buchholz wrote: > > Un-OK. Sometimes when microbenchmarking, we stumble upon a code sequence > that hotspot likes. I observed 20% improvement with the below, so > switching to that: > > public boolean tryAdvance(Consumer action) { > Objects.requireNonNull(action); > final Object[] es = elements; > if (fence < 0) { fence = tail; cursor = head; } // late-binding > final int i; > if ((i = cursor) == fence) > return false; > E e = nonNullElementAt(es, i); > cursor = inc(i, es.length); > action.accept(e); > return true; > } > > > Ok. > > I suppose i should stop being surprised at these kind of things, but would > like to know, if you happen to, why such an improvement was gained for > explicitly inlining the getFence call. Were you reaching some inlining > thresholds in hotspot? > It's worse than that. I had to un-inline AND move the cursor increment into the "middle" of the call to accept. Regarding getFence() - I'm not convinced having a separate method here is ever good for humans or machines, especially when the inlined version is one readable line of code, whereas getFence() has a non-obvious side effect. Regarding moving array access before cursor increment: this makes it easier for hotspot to do the array access checks and cursor increment in parallel; otherwise hotspot (thinks it) needs to defer array access until after cursor is written because it might be out of bounds?! From brent.christian at oracle.com Mon Nov 21 18:36:03 2016 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 21 Nov 2016 10:36:03 -0800 Subject: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError In-Reply-To: <4c9dc49f-c67e-4a0c-634e-f91d44cc0c6a@oracle.com> References: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> <3c4ec322-bbc6-f0a1-14aa-6fbea37da699@gmail.com> <0AA344AE-79D2-4DF6-A24B-E01463519147@oracle.com> <4c9dc49f-c67e-4a0c-634e-f91d44cc0c6a@oracle.com> Message-ID: On 11/11/16 2:16 AM, Alan Bateman wrote: >>> >>> Since there is already a @CallerSensitive protected static method >>> called "registerAsParallelCapable" for subclasses to call from their >>> blocks, the query could be called: >>> >>> isRegisteredAsParallelCapable() ? >>> >>> I doubt this name is already taken by any subclass out there? >>> > It's always a potential compatibility issue to add a final method to a > non-final class but if we can get away with the rename suggested by > Peter then it would be good. Our investigation indicates that odds are very good that "isRegisteredAsParallelCapable" will work, and I see the preference leaning toward keeping this a final instance method. http://cr.openjdk.java.net/~bchristi/8169435/webrev.1/ Thanks, -Brent From mandy.chung at oracle.com Mon Nov 21 19:12:31 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 21 Nov 2016 11:12:31 -0800 Subject: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError In-Reply-To: References: <16af761a-230c-7db1-e511-730e2258370d@oracle.com> <3c4ec322-bbc6-f0a1-14aa-6fbea37da699@gmail.com> <0AA344AE-79D2-4DF6-A24B-E01463519147@oracle.com> <4c9dc49f-c67e-4a0c-634e-f91d44cc0c6a@oracle.com> Message-ID: > On Nov 21, 2016, at 10:36 AM, Brent Christian wrote: > > On 11/11/16 2:16 AM, Alan Bateman wrote: > >>> >>>> Since there is already a @CallerSensitive protected static method >>>> called "registerAsParallelCapable" for subclasses to call from their >>>> blocks, the query could be called: >>>> >>>> isRegisteredAsParallelCapable() ? >>>> >>>> I doubt this name is already taken by any subclass out there? >>>> >> It's always a potential compatibility issue to add a final method to a >> non-final class but if we can get away with the rename suggested by >> Peter then it would be good. > > Our investigation indicates that odds are very good that "isRegisteredAsParallelCapable" will work, and I see the preference leaning toward keeping this a final instance method. > > http://cr.openjdk.java.net/~bchristi/8169435/webrev.1/ +1 Mandy From paul.sandoz at oracle.com Mon Nov 21 19:20:04 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 21 Nov 2016 11:20:04 -0800 Subject: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove Message-ID: Hi, Please review these specification clarifications to the methods Iterator.forEachRemaining and Iterator.remove. Implementations of Iterator.forEachRemaining should have some wiggle room to optimize traversal. (In hindsight we could have done a better job locking such behaviour down in Java 8.) I also took the opportunity to update the Iterable.forEach method. Thanks, Paul. diff -r 4bf7aaa0d611 src/java.base/share/classes/java/lang/Iterable.java --- a/src/java.base/share/classes/java/lang/Iterable.java Thu Nov 17 12:24:51 2016 -0800 +++ b/src/java.base/share/classes/java/lang/Iterable.java Mon Nov 21 10:55:21 2016 -0800 @@ -53,10 +53,12 @@ /** * Performs the given action for each element of the {@code Iterable} * until all elements have been processed or the action throws an - * exception. Unless otherwise specified by the implementing class, - * actions are performed in the order of iteration (if an iteration order - * is specified). Exceptions thrown by the action are relayed to the + * exception. Actions are performed in the order of iteration, if that + * order is specified. Exceptions thrown by the action are relayed to the * caller. + *

      + * The behaviour of this method is unspecified if the action performs + * side-effects that modify the underlying source of elements. * * @implSpec *

      The default implementation behaves as if: diff -r 4bf7aaa0d611 src/java.base/share/classes/java/util/Iterator.java --- a/src/java.base/share/classes/java/util/Iterator.java Thu Nov 17 12:24:51 2016 -0800 +++ b/src/java.base/share/classes/java/util/Iterator.java Mon Nov 21 10:55:21 2016 -0800 @@ -76,10 +76,15 @@ /** * Removes from the underlying collection the last element returned * by this iterator (optional operation). This method can be called - * only once per call to {@link #next}. The behavior of an iterator - * is unspecified if the underlying collection is modified while the - * iteration is in progress in any way other than by calling this - * method. + * only once per call to {@link #next}. + *

      + * The behavior of an iterator is unspecified if: + *

        + *
      • the underlying collection is modified while the iteration is in + * progress in any way other than by calling this method; or + *
      • this method is called after a call to the + * {@link #forEachRemaining forEachRemaining} method. + *
      * * @implSpec * The default implementation throws an instance of @@ -102,6 +107,16 @@ * have been processed or the action throws an exception. Actions are * performed in the order of iteration, if that order is specified. * Exceptions thrown by the action are relayed to the caller. + *

      + * The behavior of an iterator is unspecified if the action performs the + * following side-effects: + *

        + *
      • modifies the underlying collection; or + *
      • calls the {@link #remove remove} method. + *
      + *

      + * Subsequent behavior of an iterator is unspecified if the action throws an + * exception. * * @implSpec *

      The default implementation behaves as if: From paul.sandoz at oracle.com Mon Nov 21 20:30:18 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 21 Nov 2016 12:30:18 -0800 Subject: RFR 8169808 Stream returning methods should specify if they are late binding Message-ID: <2332D5F4-986E-4936-8665-933E64E5E6DE@oracle.com> Hi, Please review this specification clarification for the stream returning methods on CharSequence and BitStream. Those methods specify that the stream is late-binding for mutable sequences. I think those are the only relevant cases, please tell me if there are more! When looking at AbstractStringBuilder i found a bug: @Override public IntStream chars() { byte[] val = this.value; int count = this.count; byte coder = this.coder; checkOffset(count, val.length >> coder); // Reuse String-based spliterator. This requires a supplier to // capture the value and count when the terminal operation is executed return StreamSupport.intStream( () -> coder == LATIN1 ? new StringLatin1.CharsSpliterator(val, 0, count, 0) : new StringUTF16.CharsSpliterator(val, 0, count, 0), Spliterator.ORDERED | Spliterator.SIZED | Spliterator.SUBSIZED, false); } The returned stream is not late-binding since it captures state as local variables. That was an oversight missed in review when the compact string changes were pushed. I will file an issue and fix it (including tests). Paul. diff -r a11577c64a1d src/java.base/share/classes/java/lang/CharSequence.java --- a/src/java.base/share/classes/java/lang/CharSequence.java Mon Nov 21 10:50:01 2016 -0800 +++ b/src/java.base/share/classes/java/lang/CharSequence.java Mon Nov 21 12:17:08 2016 -0800 @@ -121,8 +121,11 @@ * href="{@docRoot}/java/lang/Character.html#unicode">surrogate code * point is passed through uninterpreted. * - *

      If the sequence is mutated while the stream is being read, the - * result is undefined. + *

      The stream binds to this sequence when the terminal stream operation + * commences. If the sequence is modified during that operation then the + * result is undefined. (Specifically, for mutable sequences the + * spliterator for the stream is + * late-binding.) * * @return an IntStream of char values from this sequence * @since 1.8 @@ -168,8 +171,11 @@ * unpaired surrogates, and undefined code units, are zero-extended to * {@code int} values which are then passed to the stream. * - *

      If the sequence is mutated while the stream is being read, the result - * is undefined. + *

      The stream binds to this sequence when the terminal stream operation + * commences. If the sequence is modified during that operation then the + * result is undefined. (Specifically, for mutable sequences the + * spliterator for the stream is + * late-binding.) * * @return an IntStream of Unicode code points from this sequence * @since 1.8 diff -r a11577c64a1d src/java.base/share/classes/java/util/BitSet.java --- a/src/java.base/share/classes/java/util/BitSet.java Mon Nov 21 10:50:01 2016 -0800 +++ b/src/java.base/share/classes/java/util/BitSet.java Mon Nov 21 12:17:08 2016 -0800 @@ -1210,9 +1210,10 @@ * is the number of bits in the set state, equal to the value * returned by the {@link #cardinality()} method. * - *

      The bit set must remain constant during the execution of the - * terminal stream operation. Otherwise, the result of the terminal - * stream operation is undefined. + *

      The stream binds to this bit set when the terminal stream operation + * commences. If the bit set is modified during that operation then the + * result is undefined. (Specifically, the spliterator for the stream is + * late-binding.) * * @return a stream of integers representing set indices * @since 1.8 From martinrb at google.com Mon Nov 21 20:32:29 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 21 Nov 2016 12:32:29 -0800 Subject: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove In-Reply-To: References: Message-ID: Thanks. Seems like progress. The spec below seems like it could be improved, but not sure how... + *

      + * The behavior of an iterator is unspecified if the action performs the + * following side-effects: + *

        + *
      • modifies the underlying collection; or + *
      • calls the {@link #remove remove} method. + *
      + *

      + * Subsequent behavior of an iterator is unspecified if the action throws an + * exception. Maybe """The behavior of an iterator is unspecified if an action modifies the collection in any way (even by calling the {@link #remove remove} method).""" There's the question of what to promise after a call to forEachRemaining (whether or not an action threw). Perhaps a blanket """Subsequent behavior of an iterator is unspecified after a call to this method.""" The default implementation cannot ensure desirable properties we might easily implement for a concrete implementation, e.g. whether the iterator is exhausted after a call to forEachRemaining where an action threw. Should we be aligning Iterator and Spliterator, which have similar questions? From martinrb at google.com Mon Nov 21 20:46:02 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 21 Nov 2016 12:46:02 -0800 Subject: RFR 8169808 Stream returning methods should specify if they are late binding In-Reply-To: <2332D5F4-986E-4936-8665-933E64E5E6DE@oracle.com> References: <2332D5F4-986E-4936-8665-933E64E5E6DE@oracle.com> Message-ID: Thanks, Paul. + *

      The stream binds to this bit set when the terminal stream operation + * commences. If the bit set is modified during that operation then the + * result is undefined. (Specifically, the spliterator for the stream is + * late-binding.) It looks like the parenthetical remark applies only to the first sentence, not the second. If so, it should be moved. The CONCURRENT Spliterators in j.u.c. do not document late-binding, but probably they should, given the implementation effort we've already done to make it so. We could have simple tests that create a Spliterator, add elements to the collection, then verify that they were found in the iteration. Is there a programmatic way for a test to determine whether a Spliterator should be late-binding? On Mon, Nov 21, 2016 at 12:30 PM, Paul Sandoz wrote: > Hi, > > Please review this specification clarification for the stream returning > methods on CharSequence and BitStream. Those methods specify that the > stream is late-binding for mutable sequences. > > I think those are the only relevant cases, please tell me if there are > more! > > When looking at AbstractStringBuilder i found a bug: > > @Override > public IntStream chars() { > byte[] val = this.value; int count = this.count; byte coder = > this.coder; > checkOffset(count, val.length >> coder); > // Reuse String-based spliterator. This requires a supplier to > // capture the value and count when the terminal operation is executed > return StreamSupport.intStream( > () -> coder == LATIN1 ? new StringLatin1.CharsSpliterator(val, > 0, count, 0) > : new StringUTF16.CharsSpliterator(val, > 0, count, 0), > Spliterator.ORDERED | Spliterator.SIZED | Spliterator.SUBSIZED, > false); > } > > The returned stream is not late-binding since it captures state as local > variables. That was an oversight missed in review when the compact string > changes were pushed. I will file an issue and fix it (including tests). > > Paul. > > > diff -r a11577c64a1d src/java.base/share/classes/ > java/lang/CharSequence.java > --- a/src/java.base/share/classes/java/lang/CharSequence.java Mon Nov > 21 10:50:01 2016 -0800 > +++ b/src/java.base/share/classes/java/lang/CharSequence.java Mon Nov > 21 12:17:08 2016 -0800 > @@ -121,8 +121,11 @@ > * href="{@docRoot}/java/lang/Character.html#unicode">surrogate code > * point is passed through uninterpreted. > * > - *

      If the sequence is mutated while the stream is being read, the > - * result is undefined. > + *

      The stream binds to this sequence when the terminal stream > operation > + * commences. If the sequence is modified during that operation then > the > + * result is undefined. (Specifically, for mutable sequences the > + * spliterator for the stream is > + * late-binding.) > * > * @return an IntStream of char values from this sequence > * @since 1.8 > @@ -168,8 +171,11 @@ > * unpaired surrogates, and undefined code units, are zero-extended to > * {@code int} values which are then passed to the stream. > * > - *

      If the sequence is mutated while the stream is being read, the > result > - * is undefined. > + *

      The stream binds to this sequence when the terminal stream > operation > + * commences. If the sequence is modified during that operation then > the > + * result is undefined. (Specifically, for mutable sequences the > + * spliterator for the stream is > + * late-binding.) > * > * @return an IntStream of Unicode code points from this sequence > * @since 1.8 > diff -r a11577c64a1d src/java.base/share/classes/java/util/BitSet.java > --- a/src/java.base/share/classes/java/util/BitSet.java Mon Nov 21 > 10:50:01 2016 -0800 > +++ b/src/java.base/share/classes/java/util/BitSet.java Mon Nov 21 > 12:17:08 2016 -0800 > @@ -1210,9 +1210,10 @@ > * is the number of bits in the set state, equal to the value > * returned by the {@link #cardinality()} method. > * > - *

      The bit set must remain constant during the execution of the > - * terminal stream operation. Otherwise, the result of the terminal > - * stream operation is undefined. > + *

      The stream binds to this bit set when the terminal stream > operation > + * commences. If the bit set is modified during that operation then > the > + * result is undefined. (Specifically, the spliterator for the > stream is > + * late-binding.) > * > * @return a stream of integers representing set indices > * @since 1.8 > From paul.sandoz at oracle.com Mon Nov 21 20:52:22 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 21 Nov 2016 12:52:22 -0800 Subject: RFR 8132964 Spliterator documentation on Priority(Blocking)Queue Message-ID: <60DF86AC-5A61-46D1-B4C6-DC7F3B5A484F@oracle.com> Hi, Please review specification clarifications to PriorityQueue and PriorityBlockingQueue for the spliterator. Ordinarily i would not specify what spliterator characteristics are not reported, but in this case given what is said about iterator I think it reasonable to say it about spliterator (a number of developers have got caught out regarding order, or lack thereof in this case, but i also suspect they never read the specification!) Paul. diff -r eb147f1f232d src/java.base/share/classes/java/util/PriorityQueue.java --- a/src/java.base/share/classes/java/util/PriorityQueue.java Mon Nov 21 12:00:46 2016 -0800 +++ b/src/java.base/share/classes/java/util/PriorityQueue.java Mon Nov 21 12:30:33 2016 -0800 @@ -54,7 +54,8 @@ *

      This class and its iterator implement all of the * optional methods of the {@link Collection} and {@link * Iterator} interfaces. The Iterator provided in method {@link - * #iterator()} is not guaranteed to traverse the elements of + * #iterator()} and the Spliterator provided in method {@link #spliterator()} + * are not guaranteed to traverse the elements of * the priority queue in any particular order. If you need ordered * traversal, consider using {@code Arrays.sort(pq.toArray())}. * @@ -799,7 +800,8 @@ /** * Creates a late-binding * and fail-fast {@link Spliterator} over the elements in this - * queue. + * queue. The spliterator does not traverse elements in any particular order + * (the {@link Spliterator#ORDERED ORDERED} characteristic is not reported). * *

      The {@code Spliterator} reports {@link Spliterator#SIZED}, * {@link Spliterator#SUBSIZED}, and {@link Spliterator#NONNULL}. diff -r eb147f1f232d src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java --- a/src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java Mon Nov 21 12:00:46 2016 -0800 +++ b/src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java Mon Nov 21 12:30:33 2016 -0800 @@ -65,7 +65,8 @@ *

      This class and its iterator implement all of the * optional methods of the {@link Collection} and {@link * Iterator} interfaces. The Iterator provided in method {@link - * #iterator()} is not guaranteed to traverse the elements of + * #iterator()} and the Spliterator provided in method {@link #spliterator()} + * are is not guaranteed to traverse the elements of * the PriorityBlockingQueue in any particular order. If you need * ordered traversal, consider using * {@code Arrays.sort(pq.toArray())}. Also, method {@code drainTo} @@ -994,6 +995,8 @@ /** * Returns a {@link Spliterator} over the elements in this queue. + * The spliterator does not traverse elements in any particular order + * (the {@link Spliterator#ORDERED ORDERED} characteristic is not reported). * *

      The returned spliterator is * weakly consistent. From martinrb at google.com Mon Nov 21 20:57:53 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 21 Nov 2016 12:57:53 -0800 Subject: RFR 8132964 Spliterator documentation on Priority(Blocking)Queue In-Reply-To: <60DF86AC-5A61-46D1-B4C6-DC7F3B5A484F@oracle.com> References: <60DF86AC-5A61-46D1-B4C6-DC7F3B5A484F@oracle.com> Message-ID: Looks good to me! On Mon, Nov 21, 2016 at 12:52 PM, Paul Sandoz wrote: > Hi, > > Please review specification clarifications to PriorityQueue and > PriorityBlockingQueue for the spliterator. Ordinarily i would not specify > what spliterator characteristics are not reported, but in this case given > what is said about iterator I think it reasonable to say it about > spliterator (a number of developers have got caught out regarding order, or > lack thereof in this case, but i also suspect they never read the > specification!) > > Paul. > > diff -r eb147f1f232d src/java.base/share/classes/ > java/util/PriorityQueue.java > --- a/src/java.base/share/classes/java/util/PriorityQueue.java Mon Nov > 21 12:00:46 2016 -0800 > +++ b/src/java.base/share/classes/java/util/PriorityQueue.java Mon Nov > 21 12:30:33 2016 -0800 > @@ -54,7 +54,8 @@ > *

      This class and its iterator implement all of the > * optional methods of the {@link Collection} and {@link > * Iterator} interfaces. The Iterator provided in method {@link > - * #iterator()} is not guaranteed to traverse the elements of > + * #iterator()} and the Spliterator provided in method {@link > #spliterator()} > + * are not guaranteed to traverse the elements of > * the priority queue in any particular order. If you need ordered > * traversal, consider using {@code Arrays.sort(pq.toArray())}. > * > @@ -799,7 +800,8 @@ > /** > * Creates a late-binding > * and fail-fast {@link Spliterator} over the elements in > this > - * queue. > + * queue. The spliterator does not traverse elements in any > particular order > + * (the {@link Spliterator#ORDERED ORDERED} characteristic is not > reported). > * > *

      The {@code Spliterator} reports {@link Spliterator#SIZED}, > * {@link Spliterator#SUBSIZED}, and {@link Spliterator#NONNULL}. > diff -r eb147f1f232d src/java.base/share/classes/java/util/concurrent/ > PriorityBlockingQueue.java > --- a/src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java > Mon Nov 21 12:00:46 2016 -0800 > +++ b/src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java > Mon Nov 21 12:30:33 2016 -0800 > @@ -65,7 +65,8 @@ > *

      This class and its iterator implement all of the > * optional methods of the {@link Collection} and {@link > * Iterator} interfaces. The Iterator provided in method {@link > - * #iterator()} is not guaranteed to traverse the elements of > + * #iterator()} and the Spliterator provided in method {@link > #spliterator()} > + * are is not guaranteed to traverse the elements of > * the PriorityBlockingQueue in any particular order. If you need > * ordered traversal, consider using > * {@code Arrays.sort(pq.toArray())}. Also, method {@code drainTo} > @@ -994,6 +995,8 @@ > > /** > * Returns a {@link Spliterator} over the elements in this queue. > + * The spliterator does not traverse elements in any particular order > + * (the {@link Spliterator#ORDERED ORDERED} characteristic is not > reported). > * > *

      The returned spliterator is > * weakly > consistent. > > From paul.sandoz at oracle.com Mon Nov 21 21:01:59 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 21 Nov 2016 13:01:59 -0800 Subject: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove In-Reply-To: References: Message-ID: <326281B6-70FB-4B38-BC20-FE7D42202464@oracle.com> > On 21 Nov 2016, at 12:32, Martin Buchholz wrote: > > Thanks. Seems like progress. > > The spec below seems like it could be improved, but not sure how... > > + *

      > + * The behavior of an iterator is unspecified if the action performs the > + * following side-effects: > + *

        > + *
      • modifies the underlying collection; or > + *
      • calls the {@link #remove remove} method. > + *
      > + *

      > + * Subsequent behavior of an iterator is unspecified if the action throws an > + * exception. > > > Maybe """The behavior of an iterator is unspecified if an action modifies the collection in any way (even by calling the {@link #remove remove} method).??? I am ok with that. > There's the question of what to promise after a call to forEachRemaining (whether or not an action threw). Perhaps a blanket > """Subsequent behavior of an iterator is unspecified after a call to this method.""" > I think that is overly limiting, it?s exceptions and remove that are problematic. Assuming no exception it is fine to subsequently call next, hasNext and forEachRemaining, each has well defined behaviour (throws NoSuchElementException, false, no-op respectively). > The default implementation cannot ensure desirable properties we might easily implement for a concrete implementation, e.g. whether the iterator is exhausted after a call to forEachRemaining where an action threw. > It does tie our hands somewhat. > Should we be aligning Iterator and Spliterator, which have similar questions? Thankfully Spliterator has no remove and no default methods :-) so we are in an easier position, but yes we could align regarding exceptions thrown by actions. Paul. From paul.sandoz at oracle.com Mon Nov 21 21:06:11 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 21 Nov 2016 13:06:11 -0800 Subject: RFR 8169808 Stream returning methods should specify if they are late binding In-Reply-To: References: <2332D5F4-986E-4936-8665-933E64E5E6DE@oracle.com> Message-ID: > On 21 Nov 2016, at 12:46, Martin Buchholz wrote: > > Thanks, Paul. > > + *

      The stream binds to this bit set when the terminal stream operation > + * commences. If the bit set is modified during that operation then the > + * result is undefined. (Specifically, the spliterator for the stream is > + * late-binding.) > > It looks like the parenthetical remark applies only to the first sentence, not the second. If so, it should be moved. > Yes, i will do that, thanks. > The CONCURRENT Spliterators in j.u.c. do not document late-binding, but probably they should, given the implementation effort we've already done to make it so. > Late-binding really only applies to spliterators not reporting IMMUTABLE or CONCURRENT. What did you have in mind? > We could have simple tests that create a Spliterator, add elements to the collection, then verify that they were found in the iteration. > Is there a programmatic way for a test to determine whether a Spliterator should be late-binding? > See the SpliteratorLateBindingFailFastTest. That could be refactored out as it?s conflating two concepts and is too collection/map focused. Paul. > > > On Mon, Nov 21, 2016 at 12:30 PM, Paul Sandoz wrote: > Hi, > > Please review this specification clarification for the stream returning methods on CharSequence and BitStream. Those methods specify that the stream is late-binding for mutable sequences. > > I think those are the only relevant cases, please tell me if there are more! > > When looking at AbstractStringBuilder i found a bug: > > @Override > public IntStream chars() { > byte[] val = this.value; int count = this.count; byte coder = this.coder; > checkOffset(count, val.length >> coder); > // Reuse String-based spliterator. This requires a supplier to > // capture the value and count when the terminal operation is executed > return StreamSupport.intStream( > () -> coder == LATIN1 ? new StringLatin1.CharsSpliterator(val, 0, count, 0) > : new StringUTF16.CharsSpliterator(val, 0, count, 0), > Spliterator.ORDERED | Spliterator.SIZED | Spliterator.SUBSIZED, > false); > } > > The returned stream is not late-binding since it captures state as local variables. That was an oversight missed in review when the compact string changes were pushed. I will file an issue and fix it (including tests). > > Paul. > > > diff -r a11577c64a1d src/java.base/share/classes/java/lang/CharSequence.java > --- a/src/java.base/share/classes/java/lang/CharSequence.java Mon Nov 21 10:50:01 2016 -0800 > +++ b/src/java.base/share/classes/java/lang/CharSequence.java Mon Nov 21 12:17:08 2016 -0800 > @@ -121,8 +121,11 @@ > * href="{@docRoot}/java/lang/Character.html#unicode">surrogate code > * point is passed through uninterpreted. > * > - *

      If the sequence is mutated while the stream is being read, the > - * result is undefined. > + *

      The stream binds to this sequence when the terminal stream operation > + * commences. If the sequence is modified during that operation then the > + * result is undefined. (Specifically, for mutable sequences the > + * spliterator for the stream is > + * late-binding.) > * > * @return an IntStream of char values from this sequence > * @since 1.8 > @@ -168,8 +171,11 @@ > * unpaired surrogates, and undefined code units, are zero-extended to > * {@code int} values which are then passed to the stream. > * > - *

      If the sequence is mutated while the stream is being read, the result > - * is undefined. > + *

      The stream binds to this sequence when the terminal stream operation > + * commences. If the sequence is modified during that operation then the > + * result is undefined. (Specifically, for mutable sequences the > + * spliterator for the stream is > + * late-binding.) > * > * @return an IntStream of Unicode code points from this sequence > * @since 1.8 > diff -r a11577c64a1d src/java.base/share/classes/java/util/BitSet.java > --- a/src/java.base/share/classes/java/util/BitSet.java Mon Nov 21 10:50:01 2016 -0800 > +++ b/src/java.base/share/classes/java/util/BitSet.java Mon Nov 21 12:17:08 2016 -0800 > @@ -1210,9 +1210,10 @@ > * is the number of bits in the set state, equal to the value > * returned by the {@link #cardinality()} method. > * > - *

      The bit set must remain constant during the execution of the > - * terminal stream operation. Otherwise, the result of the terminal > - * stream operation is undefined. > + *

      The stream binds to this bit set when the terminal stream operation > + * commences. If the bit set is modified during that operation then the > + * result is undefined. (Specifically, the spliterator for the stream is > + * late-binding.) > * > * @return a stream of integers representing set indices > * @since 1.8 > From dl at cs.oswego.edu Mon Nov 21 21:16:36 2016 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 21 Nov 2016 16:16:36 -0500 Subject: RFR 8132964 Spliterator documentation on Priority(Blocking)Queue In-Reply-To: <60DF86AC-5A61-46D1-B4C6-DC7F3B5A484F@oracle.com> References: <60DF86AC-5A61-46D1-B4C6-DC7F3B5A484F@oracle.com> Message-ID: <62885196-ea78-0d72-0b16-84e588b61fab@cs.oswego.edu> On 11/21/2016 03:52 PM, Paul Sandoz wrote: > Hi, > > Please review specification clarifications to PriorityQueue and PriorityBlockingQueue for the spliterator. Ordinarily i would not specify what spliterator characteristics are not reported, but in this case given what is said about iterator I think it reasonable to say it about spliterator (a number of developers have got caught out regarding order, or lack thereof in this case, but i also suspect they never read the specification!) > Sure. It would be nice if there were something we could do to reduce confusion between ordered-but-destructive poll()-loops, vs unordered but-read-only iterators/spliterators. But clarifying here might help a little. -Doug > Paul. > > diff -r eb147f1f232d src/java.base/share/classes/java/util/PriorityQueue.java > --- a/src/java.base/share/classes/java/util/PriorityQueue.java Mon Nov 21 12:00:46 2016 -0800 > +++ b/src/java.base/share/classes/java/util/PriorityQueue.java Mon Nov 21 12:30:33 2016 -0800 > @@ -54,7 +54,8 @@ > *

      This class and its iterator implement all of the > * optional methods of the {@link Collection} and {@link > * Iterator} interfaces. The Iterator provided in method {@link > - * #iterator()} is not guaranteed to traverse the elements of > + * #iterator()} and the Spliterator provided in method {@link #spliterator()} > + * are not guaranteed to traverse the elements of > * the priority queue in any particular order. If you need ordered > * traversal, consider using {@code Arrays.sort(pq.toArray())}. > * > @@ -799,7 +800,8 @@ > /** > * Creates a late-binding > * and fail-fast {@link Spliterator} over the elements in this > - * queue. > + * queue. The spliterator does not traverse elements in any particular order > + * (the {@link Spliterator#ORDERED ORDERED} characteristic is not reported). > * > *

      The {@code Spliterator} reports {@link Spliterator#SIZED}, > * {@link Spliterator#SUBSIZED}, and {@link Spliterator#NONNULL}. > diff -r eb147f1f232d src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java > --- a/src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java Mon Nov 21 12:00:46 2016 -0800 > +++ b/src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java Mon Nov 21 12:30:33 2016 -0800 > @@ -65,7 +65,8 @@ > *

      This class and its iterator implement all of the > * optional methods of the {@link Collection} and {@link > * Iterator} interfaces. The Iterator provided in method {@link > - * #iterator()} is not guaranteed to traverse the elements of > + * #iterator()} and the Spliterator provided in method {@link #spliterator()} > + * are is not guaranteed to traverse the elements of > * the PriorityBlockingQueue in any particular order. If you need > * ordered traversal, consider using > * {@code Arrays.sort(pq.toArray())}. Also, method {@code drainTo} > @@ -994,6 +995,8 @@ > > /** > * Returns a {@link Spliterator} over the elements in this queue. > + * The spliterator does not traverse elements in any particular order > + * (the {@link Spliterator#ORDERED ORDERED} characteristic is not reported). > * > *

      The returned spliterator is > * weakly consistent. > From martinrb at google.com Mon Nov 21 21:21:45 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 21 Nov 2016 13:21:45 -0800 Subject: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove In-Reply-To: <326281B6-70FB-4B38-BC20-FE7D42202464@oracle.com> References: <326281B6-70FB-4B38-BC20-FE7D42202464@oracle.com> Message-ID: On Mon, Nov 21, 2016 at 1:01 PM, Paul Sandoz wrote: > > > There's the question of what to promise after a call to forEachRemaining > (whether or not an action threw). Perhaps a blanket > > """Subsequent behavior of an iterator is unspecified after a call to > this method.""" > > > > I think that is overly limiting, it?s exceptions and remove that are > problematic. Assuming no exception it is fine to subsequently call next, > hasNext and forEachRemaining, each has well defined behaviour (throws > NoSuchElementException, false, no-op respectively). > In a concurrent world, it's not so clear. A linked list based implementation could report hasNext() == false when currentNode.next == null, but that might change before the next call to hasNext(). AFAIK, all of our concrete implementations don't have this property - the iterator being exhausted is a "sticky" property, in part because it's nice to the GC to null out fields at the end. One can imagine an iterator (or spliterator) designed to work differently, e.g. tryAdvance would be a way of "polling" the stream of elements to see whether any are available, and would eventually visit all elements added. Back in the real world, forEachRemaining is a particularly strong hint that this iterator/spliterator should be forever exhausted. Perhaps where that matters (ArrayBlockingQueue) we could even add such a thing to the spec. We discourage use of Iterators with ABQ, in part because in the past there was no way to "close" an Iterator. But now there is! From chris.hegarty at oracle.com Mon Nov 21 21:25:17 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 21 Nov 2016 21:25:17 +0000 Subject: RFR 8132964 Spliterator documentation on Priority(Blocking)Queue In-Reply-To: References: <60DF86AC-5A61-46D1-B4C6-DC7F3B5A484F@oracle.com> Message-ID: > On 21 Nov 2016, at 20:57, Martin Buchholz wrote: > > Looks good to me! +1 -Chris. > On Mon, Nov 21, 2016 at 12:52 PM, Paul Sandoz > wrote: > >> Hi, >> >> Please review specification clarifications to PriorityQueue and >> PriorityBlockingQueue for the spliterator. Ordinarily i would not specify >> what spliterator characteristics are not reported, but in this case given >> what is said about iterator I think it reasonable to say it about >> spliterator (a number of developers have got caught out regarding order, or >> lack thereof in this case, but i also suspect they never read the >> specification!) >> >> Paul. >> >> diff -r eb147f1f232d src/java.base/share/classes/ >> java/util/PriorityQueue.java >> --- a/src/java.base/share/classes/java/util/PriorityQueue.java Mon Nov >> 21 12:00:46 2016 -0800 >> +++ b/src/java.base/share/classes/java/util/PriorityQueue.java Mon Nov >> 21 12:30:33 2016 -0800 >> @@ -54,7 +54,8 @@ >> *

      This class and its iterator implement all of the >> * optional methods of the {@link Collection} and {@link >> * Iterator} interfaces. The Iterator provided in method {@link >> - * #iterator()} is not guaranteed to traverse the elements of >> + * #iterator()} and the Spliterator provided in method {@link >> #spliterator()} >> + * are not guaranteed to traverse the elements of >> * the priority queue in any particular order. If you need ordered >> * traversal, consider using {@code Arrays.sort(pq.toArray())}. >> * >> @@ -799,7 +800,8 @@ >> /** >> * Creates a late-binding >> * and fail-fast {@link Spliterator} over the elements in >> this >> - * queue. >> + * queue. The spliterator does not traverse elements in any >> particular order >> + * (the {@link Spliterator#ORDERED ORDERED} characteristic is not >> reported). >> * >> *

      The {@code Spliterator} reports {@link Spliterator#SIZED}, >> * {@link Spliterator#SUBSIZED}, and {@link Spliterator#NONNULL}. >> diff -r eb147f1f232d src/java.base/share/classes/java/util/concurrent/ >> PriorityBlockingQueue.java >> --- a/src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java >> Mon Nov 21 12:00:46 2016 -0800 >> +++ b/src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java >> Mon Nov 21 12:30:33 2016 -0800 >> @@ -65,7 +65,8 @@ >> *

      This class and its iterator implement all of the >> * optional methods of the {@link Collection} and {@link >> * Iterator} interfaces. The Iterator provided in method {@link >> - * #iterator()} is not guaranteed to traverse the elements of >> + * #iterator()} and the Spliterator provided in method {@link >> #spliterator()} >> + * are is not guaranteed to traverse the elements of >> * the PriorityBlockingQueue in any particular order. If you need >> * ordered traversal, consider using >> * {@code Arrays.sort(pq.toArray())}. Also, method {@code drainTo} >> @@ -994,6 +995,8 @@ >> >> /** >> * Returns a {@link Spliterator} over the elements in this queue. >> + * The spliterator does not traverse elements in any particular order >> + * (the {@link Spliterator#ORDERED ORDERED} characteristic is not >> reported). >> * >> *

      The returned spliterator is >> * weakly >> consistent. >> >> From martinrb at google.com Mon Nov 21 22:19:42 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 21 Nov 2016 14:19:42 -0800 Subject: RFR 8169808 Stream returning methods should specify if they are late binding In-Reply-To: References: <2332D5F4-986E-4936-8665-933E64E5E6DE@oracle.com> Message-ID: On Mon, Nov 21, 2016 at 1:06 PM, Paul Sandoz wrote: > > > The CONCURRENT Spliterators in j.u.c. do not document late-binding, but > probably they should, given the implementation effort we've already done to > make it so. > > > > Late-binding really only applies to spliterators not reporting IMMUTABLE > or CONCURRENT. What did you have in mind? > > j.u.c. Spliterators like in ConcurrentLinkedDeque ... https://bugs.openjdk.java.net/browse/JDK-8169739?focusedCommentId=14022987&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14022987 ... have extra complexity to support the idea that they are never surely exhausted when created, even if the collection happens to have no elements at that point. I was hoping you would have opinions on that (I gave up on making that change). We make an effort to provide this behavior, but we don't promise it to our users! Let's look at the definition: """A late-binding Spliterator binds to the source of elements at the point of first traversal ...""" That applies equally well to concurrent and non-concurrent spliterators! Why don't we specify late-binding for those concurrent spliterators that in fact implement it, or abandon implementing it? From paul.sandoz at oracle.com Mon Nov 21 22:29:23 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 21 Nov 2016 14:29:23 -0800 Subject: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove In-Reply-To: References: <326281B6-70FB-4B38-BC20-FE7D42202464@oracle.com> Message-ID: <8B0187AE-BFDF-4831-A858-2443275FE7D2@oracle.com> > On 21 Nov 2016, at 13:21, Martin Buchholz wrote: > > > > On Mon, Nov 21, 2016 at 1:01 PM, Paul Sandoz > wrote: > > > There's the question of what to promise after a call to forEachRemaining (whether or not an action threw). Perhaps a blanket > > """Subsequent behavior of an iterator is unspecified after a call to this method.""" > > > > I think that is overly limiting, it?s exceptions and remove that are problematic. Assuming no exception it is fine to subsequently call next, hasNext and forEachRemaining, each has well defined behaviour (throws NoSuchElementException, false, no-op respectively). > > In a concurrent world, it's not so clear. Good point, yes, i was thinking non-concurrent, but i would still expect it to hold for weakly consistent iterators. > A linked list based implementation could report hasNext() == false when currentNode.next == null, but that might change before the next call to hasNext(). AFAIK, all of our concrete implementations don't have this property - the iterator being exhausted is a "sticky" property, in part because it's nice to the GC to null out fields at the end. One can imagine an iterator (or spliterator) designed to work differently, e.g. tryAdvance would be a way of "polling" the stream of elements to see whether any are available, and would eventually visit all elements added. > > Back in the real world, forEachRemaining is a particularly strong hint that this iterator/spliterator should be forever exhausted. Yes :-) i would argue as strong a hint as that of hasNext returning false. Paul. > Perhaps where that matters (ArrayBlockingQueue) we could even add such a thing to the spec. We discourage use of Iterators with ABQ, in part because in the past there was no way to "close" an Iterator. But now there is! From martinrb at google.com Mon Nov 21 23:18:11 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 21 Nov 2016 15:18:11 -0800 Subject: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove In-Reply-To: <8B0187AE-BFDF-4831-A858-2443275FE7D2@oracle.com> References: <326281B6-70FB-4B38-BC20-FE7D42202464@oracle.com> <8B0187AE-BFDF-4831-A858-2443275FE7D2@oracle.com> Message-ID: On Mon, Nov 21, 2016 at 2:29 PM, Paul Sandoz wrote: > > A linked list based implementation could report hasNext() == false when > currentNode.next == null, but that might change before the next call to > hasNext(). AFAIK, all of our concrete implementations don't have this > property - the iterator being exhausted is a "sticky" property, in part > because it's nice to the GC to null out fields at the end. One can imagine > an iterator (or spliterator) designed to work differently, e.g. tryAdvance > would be a way of "polling" the stream of elements to see whether any are > available, and would eventually visit all elements added. > > > Back in the real world, forEachRemaining is a particularly strong hint > that this iterator/spliterator should be forever exhausted. > > > Yes :-) i would argue as strong a hint as that of hasNext returning false. > > Stronger, perhaps! There's a corner case where a user sees hasNext() returning false, then calls remove(). Perhaps it's a weird way of deleting the last element. That seems more defensible user code than calling remove() after forEachRemaining. In some classes maintaining the ability to delete the last element is a burden, as in ArrayBlockingQueue. > Paul. > > Perhaps where that matters (ArrayBlockingQueue) we could even add such a > thing to the spec. We discourage use of Iterators with ABQ, in part > because in the past there was no way to "close" an Iterator. But now there > is! > > > From paul.sandoz at oracle.com Mon Nov 21 23:23:21 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 21 Nov 2016 15:23:21 -0800 Subject: RFR 8169808 Stream returning methods should specify if they are late binding In-Reply-To: References: <2332D5F4-986E-4936-8665-933E64E5E6DE@oracle.com> Message-ID: > On 21 Nov 2016, at 14:19, Martin Buchholz wrote: > > > > On Mon, Nov 21, 2016 at 1:06 PM, Paul Sandoz wrote: > > > The CONCURRENT Spliterators in j.u.c. do not document late-binding, but probably they should, given the implementation effort we've already done to make it so. > > > > Late-binding really only applies to spliterators not reporting IMMUTABLE or CONCURRENT. What did you have in mind? > > > j.u.c. Spliterators like in ConcurrentLinkedDeque ... > > https://bugs.openjdk.java.net/browse/JDK-8169739?focusedCommentId=14022987&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14022987 > > ... have extra complexity to support the idea that they are never surely exhausted when created, even if the collection happens to have no elements at that point. I was hoping you would have opinions on that (I gave up on making that change). > Ah, i missed that, sorry. (I believe writing an @ in a comment will notify more explicitly in email.) At the moment late-binding and CONCURRENT are mutually exclusive (see the full definition below). On the specification of Spliterator.CONCURRENT there is this api note: * @apiNote Most concurrent collections maintain a consistency policy * guaranteeing accuracy with respect to elements present at the point of * Spliterator construction, but possibly not reflecting subsequent * additions or removals. In this case i think you could specify a "consistency policy" that if LinkedBlockingDeque is empty on spliterator construction then the spliterator covers no elements and does not reflect subsequent additions or removals. But as you say it would be a change in current behaviour and unless there is a sufficient improvement it would not be worth the change. > We make an effort to provide this behavior, but we don't promise it to our users! > Interesting case. > Let's look at the definition: > """A late-binding Spliterator binds to the source of elements at the point of first traversal ...""" > That applies equally well to concurrent and non-concurrent spliterators! > Why don't we specify late-binding for those concurrent spliterators that in fact implement it, or abandon implementing it? > Here is the complete definition, which is currently focused on mutable non-concurrent sources: *

      A Spliterator that does not report {@code IMMUTABLE} or * {@code CONCURRENT} is expected to have a documented policy concerning: * when the spliterator binds to the element source; and detection of * structural interference of the element source detected after binding. A * late-binding Spliterator binds to the source of elements at the * point of first traversal, first split, or first query for estimated size, * rather than at the time the Spliterator is created. A Spliterator that is * not late-binding binds to the source of elements at the point of * construction or first invocation of any method. Modifications made to the * source prior to binding are reflected when the Spliterator is traversed. * After binding a Spliterator should, on a best-effort basis, throw * {@link ConcurrentModificationException} if structural interference is * detected. Spliterators that do this are called fail-fast. The * bulk traversal method ({@link #forEachRemaining forEachRemaining()}) of a * Spliterator may optimize traversal and check for structural interference * after all elements have been traversed, rather than checking per-element and * failing immediately. Paul. From gromero at linux.vnet.ibm.com Tue Nov 22 00:27:10 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 21 Nov 2016 22:27:10 -0200 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <582D0BCE.2030209@linux.vnet.ibm.com> <582DF764.70504@linux.vnet.ibm.com> Message-ID: <583390DE.5050406@linux.vnet.ibm.com> Hi Joe, On 17-11-2016 19:33, joe darcy wrote: >>>> Currently, optimization for building fdlibm is disabled, except for the >>>> "solaris" OS target [1]. >>> The reason for that is because historically the Solaris compilers have had sufficient discipline and control regarding floating-point semantics and compiler optimizations to still implement the >>> Java-mandated results when optimization was enabled. The gcc family of compilers, for example, has lacked such discipline. >> oh, I see. Thanks for clarifying that. I was exactly wondering why fdlibm >> optimization is off even for x86_x64 as it, AFAICS regarding gcc 5 only, does >> not affect the precision, even if setting -O3 does not improve the performance >> as much as on PPC64. > > The fdlibm code relies on aliasing a two-element array of int with a double to do bit-level reads and writes of floating-point values. As I understand it, the C spec allows compilers to assume values > of different types don't overlap in memory. The compilation environment has to be configured in such a way that the C compiler disables code generation and optimization techniques that would run afoul > of these fdlibm coding practices. On discussing with the Power toolchain folks we narrowed down the issue on PPC64 to the FMA. -fno-strict-aliasing has no effect and when used with an aggressive optimization does not solve the issue on precision. Thus -ffp-contract=off is the best options we have by now to optimize the fdlibm on PPC64. >>> Methods in the Math class, such as pow, are often intrinsified and use a different algorithm so a straight performance comparison may not be as fair or meaningful in those cases. >> I agree. It's just that the issue on StrictMath methods was first noted due to >> that huge gap (Math vs StrictMath) on PPC64, which is not prominent on x64. > > Depending on how Math.{sin, cos} is implemented on PPC64, compiling the fdlibm sin/cos with more aggressive optimizations should not be expected to close the performance gap. In particular, if > Math.{sin, cos} is an intrinsic on PPC64 (I haven't checked the sources) that used platform-specific feature (say fused multiply add instructions) then just compiling fdlibm more aggressively wouldn't > necessarily make up that gap. In our case (PPC64) it does close the gap. Non-optimized code will suffer a lot, for instance, from load-hit-store issues. Contrary to what happens on PPC64, the gap on x64 seems to be quite small as you said. > > To allow cross-platform and cross-release reproducibility, StrictMath is specified to use the particular fdlibm algorithms, which precludes using better algorithms developed more recently. If we were > to start with a clean slate today, to get such reproducibility we would specify correctly-rounded behavior of all those methods, but such an approach was much less tractable technical 20+ years ago > without benefit of the research that was been done in the interim, such as the work of Prof. Muller and associates: https://lipforge.ens-lyon.fr/projects/crlibm/. > >> >> >>> Accumulating the the results of the functions and comparisons the sums is not a sufficiently robust way of checking to see if the optimized versions are indeed equivalent to the non-optimized ones. >>> The specification of StrictMath requires a particular result for each set of floating-point arguments and sums get round-away low-order bits that differ. >> That's really good point, thanks for letting me know about that. I'll re-test my >> change under that perspective. >> >> >>> Running the JDK math library regression tests and corresponding JCK tests is recommended for work in this area. >> Got it. By "the JDK math library regression tests" you mean exactly which test >> suite? the jtreg tests? > > Specifically, the regression tests under test/java/lang/Math and test/java/lang/StrictMath in the jdk repository. There are some other math library tests in the hotspot repo, but I don't know where > they are offhand. > > A note on methodologies, when I've been writing test for my port I've tried to include test cases that exercise all the branches point in the code. Due to the large input space (~2^64 for a > single-argument method), random sampling alone is an inefficient way to try to find differences in behavior. >> For testing against JCK/TCK I'll need some help on that. >> > > I believe the JCK/TCK does have additional testcases relevant here. > > HTH; thanks, > > -Joe > Thank you very much for the valuable comments. I'll send a webrev accordingly for review. I filed a bug: https://bugs.openjdk.java.net/browse/JDK-8170153 Best regards, Gustavo From gromero at linux.vnet.ibm.com Tue Nov 22 00:34:37 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 21 Nov 2016 22:34:37 -0200 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <5a4a0e96-71b5-247b-60ea-5eb518d2162b@oracle.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> <582DF764.70504@linux.vnet.ibm.com> <5a4a0e96-71b5-247b-60ea-5eb518d2162b@oracle.com> Message-ID: <5833929D.9000602@linux.vnet.ibm.com> Hi Chris, On 17-11-2016 19:48, Chris Plummer wrote: >> The fdlibm code relies on aliasing a two-element array of int with a double to do bit-level reads and writes of floating-point values. As I understand it, the C spec allows compilers to assume >> values of different types don't overlap in memory. The compilation environment has to be configured in such a way that the C compiler disables code generation and optimization techniques that would >> run afoul of these fdlibm coding practices. > This is the strict aliasing issue right? It's a long standing problem with fdlibm that kept getting worse as gcc got smarter. IIRC, compiling with -fno-strict-aliasing fixes it, but it's been more > than 12 years since I last dealt with fdlibm and compiler aliasing issues. I've tested with -O3 and -fno-strict-aliasing as you suggested but it did not fix the fp precision issue on PPC64. After finding that -fno-expensive-optimizations solved the problem, we narrowed down the problem to the FMA: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 Thank you. Regards, Gustavo From gromero at linux.vnet.ibm.com Tue Nov 22 00:41:34 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 21 Nov 2016 22:41:34 -0200 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <582D0BCE.2030209@linux.vnet.ibm.com> <582DF764.70504@linux.vnet.ibm.com> <5a4a0e96-71b5-247b-60ea-5eb518d2162b@oracle.com> Message-ID: <5833943E.9010807@linux.vnet.ibm.com> Hi Derek, On 17-11-2016 20:47, White, Derek wrote: > Hi Joe, > > Although neither a floating point expert (as I think I've proven to you over the years), or a gcc expert, I checked with our in-house gcc expert and got this following answer: > > "Yes using -fno-strict-aliasing fixes the issues. Also there are many forks of fdlibm which has this fixed including the code inside glibc. " I've tried on PPC64 -O3 and -fno-strict-aliasing but it didn't work. Disabling the FMA fixed the issue although. Do you know if the gap between Math and StrictMath is also huge on aarch64? Thank you. Regards, Gustavo: From joe.darcy at oracle.com Tue Nov 22 00:42:10 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 21 Nov 2016 16:42:10 -0800 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <5833929D.9000602@linux.vnet.ibm.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> <582DF764.70504@linux.vnet.ibm.com> <5a4a0e96-71b5-247b-60ea-5eb518d2162b@oracle.com> <5833929D.9000602@linux.vnet.ibm.com> Message-ID: <8d21cafc-a4f5-0ed7-1f8f-4c40ccf4ecbe@oracle.com> Hello, On 11/21/2016 4:34 PM, Gustavo Romero wrote: > Hi Chris, > > On 17-11-2016 19:48, Chris Plummer wrote: >>> The fdlibm code relies on aliasing a two-element array of int with a double to do bit-level reads and writes of floating-point values. As I understand it, the C spec allows compilers to assume >>> values of different types don't overlap in memory. The compilation environment has to be configured in such a way that the C compiler disables code generation and optimization techniques that would >>> run afoul of these fdlibm coding practices. >> This is the strict aliasing issue right? It's a long standing problem with fdlibm that kept getting worse as gcc got smarter. IIRC, compiling with -fno-strict-aliasing fixes it, but it's been more >> than 12 years since I last dealt with fdlibm and compiler aliasing issues. > I've tested with -O3 and -fno-strict-aliasing as you suggested but it did not > fix the fp precision issue on PPC64. > > After finding that -fno-expensive-optimizations solved the problem, we narrowed > down the problem to the FMA: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 > > That makes sense; an FMA will by its nature provide different results than separate (unfused) multiple and add operations. While the polynomials used in fdlibm would benefit performance-wise from implicit replacement with FMA, such a replacement would violate the StrictMath contract. Therefore, if FDLIBM is left in C sources, it must be compiled in such a way that FMA is *not* substituted for multiply and add. Thanks, -Joe From gromero at linux.vnet.ibm.com Tue Nov 22 00:43:49 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 21 Nov 2016 22:43:49 -0200 Subject: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation Message-ID: <583394C5.3030206@linux.vnet.ibm.com> Hi, Could the following change be reviewed, please? webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/ webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/jdk/ bug: https://bugs.openjdk.java.net/browse/JDK-8170153 It enables fdlibm optimization on Linux PPC64 LE & BE and hence speeds up the StrictMath methods (in some cases up to 3x) on that platform. On PPC64 fdlibm optimization can be done without precision issues if floating-point expression contraction is disable, i.e. if the compiler does not use floating-point multiply-add (FMA). For further details please refer to gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 No regression was observed on Math and StrictMath tests: Passed: java/lang/Math/AbsPositiveZero.java Passed: java/lang/Math/Atan2Tests.java Passed: java/lang/Math/CeilAndFloorTests.java Passed: java/lang/Math/CubeRootTests.java Passed: java/lang/Math/DivModTests.java Passed: java/lang/Math/ExactArithTests.java Passed: java/lang/Math/Expm1Tests.java Passed: java/lang/Math/FusedMultiplyAddTests.java Passed: java/lang/Math/HyperbolicTests.java Passed: java/lang/Math/HypotTests.java Passed: java/lang/Math/IeeeRecommendedTests.java Passed: java/lang/Math/Log10Tests.java Passed: java/lang/Math/Log1pTests.java Passed: java/lang/Math/MinMax.java Passed: java/lang/Math/MultiplicationTests.java Passed: java/lang/Math/PowTests.java Passed: java/lang/Math/Rint.java Passed: java/lang/Math/RoundTests.java Passed: java/lang/Math/SinCosCornerCasesTests.java Passed: java/lang/Math/TanTests.java Passed: java/lang/Math/WorstCaseTests.java Test results: passed: 21 Passed: java/lang/StrictMath/CubeRootTests.java Passed: java/lang/StrictMath/ExactArithTests.java Passed: java/lang/StrictMath/Expm1Tests.java Passed: java/lang/StrictMath/HyperbolicTests.java Passed: java/lang/StrictMath/HypotTests.java Passed: java/lang/StrictMath/Log10Tests.java Passed: java/lang/StrictMath/Log1pTests.java Passed: java/lang/StrictMath/PowTests.java Test results: passed: 8 and also on the following hotspot tests: Passed: compiler/intrinsics/mathexact/sanity/AddExactIntTest.java Passed: compiler/intrinsics/mathexact/sanity/AddExactLongTest.java Passed: compiler/intrinsics/mathexact/sanity/DecrementExactIntTest.java Passed: compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java Passed: compiler/intrinsics/mathexact/sanity/IncrementExactIntTest.java Passed: compiler/intrinsics/mathexact/sanity/IncrementExactLongTest.java Passed: compiler/intrinsics/mathexact/sanity/MultiplyExactIntTest.java Passed: compiler/intrinsics/mathexact/sanity/MultiplyExactLongTest.java Passed: compiler/intrinsics/mathexact/sanity/NegateExactIntTest.java Passed: compiler/intrinsics/mathexact/sanity/NegateExactLongTest.java Passed: compiler/intrinsics/mathexact/sanity/SubtractExactIntTest.java Passed: compiler/intrinsics/mathexact/sanity/SubtractExactLongTest.java Passed: compiler/intrinsics/mathexact/AddExactICondTest.java Passed: compiler/intrinsics/mathexact/AddExactIConstantTest.java Passed: compiler/intrinsics/mathexact/AddExactILoadTest.java Passed: compiler/intrinsics/mathexact/AddExactILoopDependentTest.java Passed: compiler/intrinsics/mathexact/AddExactINonConstantTest.java Passed: compiler/intrinsics/mathexact/AddExactIRepeatTest.java Passed: compiler/intrinsics/mathexact/AddExactLConstantTest.java Passed: compiler/intrinsics/mathexact/AddExactLNonConstantTest.java Passed: compiler/intrinsics/mathexact/CompareTest.java Passed: compiler/intrinsics/mathexact/DecExactITest.java Passed: compiler/intrinsics/mathexact/DecExactLTest.java Passed: compiler/intrinsics/mathexact/GVNTest.java Passed: compiler/intrinsics/mathexact/IncExactITest.java Passed: compiler/intrinsics/mathexact/IncExactLTest.java Passed: compiler/intrinsics/mathexact/MulExactICondTest.java Passed: compiler/intrinsics/mathexact/MulExactIConstantTest.java Passed: compiler/intrinsics/mathexact/MulExactILoadTest.java Passed: compiler/intrinsics/mathexact/MulExactILoopDependentTest.java Passed: compiler/intrinsics/mathexact/MulExactINonConstantTest.java Passed: compiler/intrinsics/mathexact/MulExactIRepeatTest.java Passed: compiler/intrinsics/mathexact/MulExactLConstantTest.java Passed: compiler/intrinsics/mathexact/MulExactLNonConstantTest.java Passed: compiler/intrinsics/mathexact/NegExactIConstantTest.java Passed: compiler/intrinsics/mathexact/NegExactILoadTest.java Passed: compiler/intrinsics/mathexact/NegExactILoopDependentTest.java Passed: compiler/intrinsics/mathexact/NegExactINonConstantTest.java Passed: compiler/intrinsics/mathexact/NegExactLConstantTest.java Passed: compiler/intrinsics/mathexact/NegExactLNonConstantTest.java Passed: compiler/intrinsics/mathexact/NestedMathExactTest.java Passed: compiler/intrinsics/mathexact/SplitThruPhiTest.java Passed: compiler/intrinsics/mathexact/SubExactICondTest.java Passed: compiler/intrinsics/mathexact/SubExactIConstantTest.java Passed: compiler/intrinsics/mathexact/SubExactILoadTest.java Passed: compiler/intrinsics/mathexact/SubExactILoopDependentTest.java Passed: compiler/intrinsics/mathexact/SubExactINonConstantTest.java Passed: compiler/intrinsics/mathexact/SubExactIRepeatTest.java Passed: compiler/intrinsics/mathexact/SubExactLConstantTest.java Passed: compiler/intrinsics/mathexact/SubExactLNonConstantTest.java Test results: passed: 50 Thank you. Regards, Gustavo From chris.plummer at oracle.com Tue Nov 22 01:33:08 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 21 Nov 2016 17:33:08 -0800 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <583390DE.5050406@linux.vnet.ibm.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> <582DF764.70504@linux.vnet.ibm.com> <583390DE.5050406@linux.vnet.ibm.com> Message-ID: On 11/21/16 4:27 PM, Gustavo Romero wrote: > Hi Joe, > > On 17-11-2016 19:33, joe darcy wrote: >>>>> Currently, optimization for building fdlibm is disabled, except for the >>>>> "solaris" OS target [1]. >>>> The reason for that is because historically the Solaris compilers have had sufficient discipline and control regarding floating-point semantics and compiler optimizations to still implement the >>>> Java-mandated results when optimization was enabled. The gcc family of compilers, for example, has lacked such discipline. >>> oh, I see. Thanks for clarifying that. I was exactly wondering why fdlibm >>> optimization is off even for x86_x64 as it, AFAICS regarding gcc 5 only, does >>> not affect the precision, even if setting -O3 does not improve the performance >>> as much as on PPC64. >> The fdlibm code relies on aliasing a two-element array of int with a double to do bit-level reads and writes of floating-point values. As I understand it, the C spec allows compilers to assume values >> of different types don't overlap in memory. The compilation environment has to be configured in such a way that the C compiler disables code generation and optimization techniques that would run afoul >> of these fdlibm coding practices. > On discussing with the Power toolchain folks we narrowed down the issue on PPC64 > to the FMA. -fno-strict-aliasing has no effect and when used with an aggressive > optimization does not solve the issue on precision. Thus -ffp-contract=off is > the best options we have by now to optimize the fdlibm on PPC64. Ah! I should have thought of this. I dealt with with fdlibm FMA issues on ppc about 15 years ago. At the time -mno-fused-madd was the solution. I don't think -ffp-contract=off existed back then. Chris > > >>>> Methods in the Math class, such as pow, are often intrinsified and use a different algorithm so a straight performance comparison may not be as fair or meaningful in those cases. >>> I agree. It's just that the issue on StrictMath methods was first noted due to >>> that huge gap (Math vs StrictMath) on PPC64, which is not prominent on x64. >> Depending on how Math.{sin, cos} is implemented on PPC64, compiling the fdlibm sin/cos with more aggressive optimizations should not be expected to close the performance gap. In particular, if >> Math.{sin, cos} is an intrinsic on PPC64 (I haven't checked the sources) that used platform-specific feature (say fused multiply add instructions) then just compiling fdlibm more aggressively wouldn't >> necessarily make up that gap. > In our case (PPC64) it does close the gap. Non-optimized code will suffer a lot, > for instance, from load-hit-store issues. Contrary to what happens on PPC64, the > gap on x64 seems to be quite small as you said. > > >> To allow cross-platform and cross-release reproducibility, StrictMath is specified to use the particular fdlibm algorithms, which precludes using better algorithms developed more recently. If we were >> to start with a clean slate today, to get such reproducibility we would specify correctly-rounded behavior of all those methods, but such an approach was much less tractable technical 20+ years ago >> without benefit of the research that was been done in the interim, such as the work of Prof. Muller and associates: https://lipforge.ens-lyon.fr/projects/crlibm/. >> >>> >>>> Accumulating the the results of the functions and comparisons the sums is not a sufficiently robust way of checking to see if the optimized versions are indeed equivalent to the non-optimized ones. >>>> The specification of StrictMath requires a particular result for each set of floating-point arguments and sums get round-away low-order bits that differ. >>> That's really good point, thanks for letting me know about that. I'll re-test my >>> change under that perspective. >>> >>> >>>> Running the JDK math library regression tests and corresponding JCK tests is recommended for work in this area. >>> Got it. By "the JDK math library regression tests" you mean exactly which test >>> suite? the jtreg tests? >> Specifically, the regression tests under test/java/lang/Math and test/java/lang/StrictMath in the jdk repository. There are some other math library tests in the hotspot repo, but I don't know where >> they are offhand. >> >> A note on methodologies, when I've been writing test for my port I've tried to include test cases that exercise all the branches point in the code. Due to the large input space (~2^64 for a >> single-argument method), random sampling alone is an inefficient way to try to find differences in behavior. >>> For testing against JCK/TCK I'll need some help on that. >>> >> I believe the JCK/TCK does have additional testcases relevant here. >> >> HTH; thanks, >> >> -Joe >> > Thank you very much for the valuable comments. > > I'll send a webrev accordingly for review. > > I filed a bug: https://bugs.openjdk.java.net/browse/JDK-8170153 > > > Best regards, > Gustavo > From huaming.li at oracle.com Tue Nov 22 02:50:45 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Tue, 22 Nov 2016 10:50:45 +0800 Subject: RFR of JDK-8153543: java/rmi/transport/reuseDefaultPort/ReuseDefaultPort.java fails intermittently Message-ID: Would you please review the patch for below bug? bug: https://bugs.openjdk.java.net/browse/JDK-8153543 webrev: http://cr.openjdk.java.net/~mli/8153543/webrev.00/ Root cause: between "TestLibrary.getUnusedRandomPort()" and "UnicastRemoteObject.exportObject(impl, 0);", there is time window, interloper might step in and get the port. Solution: use port 0 to create server socket in RMI socket factory, then pass the exact port back. Thank you -Hamlin From amy.lu at oracle.com Tue Nov 22 03:26:37 2016 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 22 Nov 2016 11:26:37 +0800 Subject: JDK 9 RFR of JDK-8170158: Remove ClassLoader/platformClassLoader/DefinePlatformClass.java from ProblemList Message-ID: <8b014c05-6227-df1e-c7eb-b538c8e29d2c@oracle.com> Please review the patch to bring back java/lang/ClassLoader/platformClassLoader/DefinePlatformClass.java It's clear now that the reported failure was caused by machine wrong time setting. bug: https://bugs.openjdk.java.net/browse/JDK-8170158 Thanks, Amy --- old/test/ProblemList.txt 2016-11-22 11:21:44.000000000 +0800 +++ new/test/ProblemList.txt 2016-11-22 11:21:44.000000000 +0800 @@ -124,7 +124,6 @@ # jdk_lang java/lang/StringCoding/CheckEncodings.sh 7008363 generic-all -java/lang/ClassLoader/platformClassLoader/DefinePlatformClass.java 8169639 windows-all ############################################################################ From amaembo at gmail.com Tue Nov 22 03:44:26 2016 From: amaembo at gmail.com (Tagir Valeev) Date: Tue, 22 Nov 2016 10:44:26 +0700 Subject: RFR 8169808 Stream returning methods should specify if they are late binding In-Reply-To: <2332D5F4-986E-4936-8665-933E64E5E6DE@oracle.com> References: <2332D5F4-986E-4936-8665-933E64E5E6DE@oracle.com> Message-ID: Hello! > diff -r a11577c64a1d src/java.base/share/classes/java/lang/CharSequence.java > --- a/src/java.base/share/classes/java/lang/CharSequence.java Mon Nov 21 10:50:01 2016 -0800 > +++ b/src/java.base/share/classes/java/lang/CharSequence.java Mon Nov 21 12:17:08 2016 -0800 > @@ -121,8 +121,11 @@ > * href="{@docRoot}/java/lang/Character.html#unicode">surrogate code > * point is passed through uninterpreted. > * > - *

      If the sequence is mutated while the stream is being read, the > - * result is undefined. > + *

      The stream binds to this sequence when the terminal stream operation > + * commences. If the sequence is modified during that operation then the > + * result is undefined. (Specifically, for mutable sequences the > + * spliterator for the stream is > + * late-binding.) As this an interface method with default implementation, I think, it should be clear whether this states a method contract for all implementors or an implementation detail of the default implementation. Here it's not in the @implNote section, so I assume that the new statement tightens the specification for all possible implementors (probably making valid Java-8 code invalid in Java-9 if somebody reimplemented chars() for custom CharSequence in non-late-binding manner). Is this spec change intended? With best regards, Tagir Valeev. From amaembo at gmail.com Tue Nov 22 04:00:15 2016 From: amaembo at gmail.com (Tagir Valeev) Date: Tue, 22 Nov 2016 11:00:15 +0700 Subject: 8072784: Better spliterator implementation for BitSet.stream() In-Reply-To: <84F5CDB7-DB60-4AC9-85C5-67F18EBEA49C@oracle.com> References: <1271248255.20161121205903@gmail.com> <84F5CDB7-DB60-4AC9-85C5-67F18EBEA49C@oracle.com> Message-ID: Hello! > Hi Tagir, > > In the original issue i was pondering using SIZED for smaller bit sets and non-SIZED for larger bit sets, since we stride over the longs themselves when calculating the size (should be intrinsic to count the set bits, at least on x86). Supporting both is fairly simple, but you are correct not reporting SIZED would simplify things further and it may not matter in practice. > > Can you log an issue? I will follow up with some performance analysis. Sure, here it is: https://bugs.openjdk.java.net/browse/JDK-8170159 Probably it would be optimal not to call cardinality until it's actually queried. Unfortunately current stream implementation always queries getExactSizeIfKnown() (passing it into sink.begin()) even if it's not actually used (which is most of the cases). With best regards, Tagir Valeev. > > Thanks, > Paul. > >> On 21 Nov 2016, at 05:59, Tagir F. Valeev wrote: >> >> Hello! >> >> Is it necessary to report SIZED characteristic and calculate the >> cardinality in advance making two-pass traversal? This improves >> bitSet.stream().toArray() performance (also bitSet.stream().count(), >> but it's rare case in practice). However this is just waste of time >> for any other stream operation. It's possible to remove SIZED >> characteristic using "wordsInUse << ADDRESS_BITS_PER_WORD" as initial >> size estimation (or better getFence() result). This would make >> implementation simpler and a little bit faster for all scenarios >> excluding toArray(). >> >> What do you think? >> >> With best regards, >> Tagir Valeev >> >> >> PS> Hi, >> >> PS> Please review this patch implementing a spliterator for BitSet: >> >> PS> >> PS> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8072784-bitset-stream-spliterator/webrev/ >> >> PS> The spliterator is SIZED but not SUBSIZED, the bit set?s >> PS> cardinality is used (same for the iterator) as the size of the >> PS> root spliterator, and estimates from that are derived thereafter >> PS> for splits. Splitting attempts to balance the small vs. large, dense vs. sparse cases. >> >> PS> Most of the complexity is dealing with the edge case of there >> PS> being a bit set at Integer.MAX_VALUE. >> >> >> PS> Testing-wise i have leveraged the existing tests. It would be >> PS> nice to consider placing the spliterator testing functionality >> PS> into a separate library for reuse as >> PS> SpliteratorTraversingAndSplittingTest is getting large. Likewise >> PS> for more formally for streams, which is possible to reuse but a >> PS> little clunky. I can log issues for those. >> >> PS> Paul. >> > From christoph.langer at sap.com Tue Nov 22 08:38:08 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 22 Nov 2016 08:38:08 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") Message-ID: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> Hi, I'm currently struggling while running jtreg tests for the jaxp depot. There are several tests that fail with the same symptom. I always get exceptions like: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessDeclaredMembers") at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:471) at java.base/java.security.AccessController.checkPermission(AccessController.java:894) at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:548) at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) at org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) at org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) at org.testng.internal.Parameters.findDataProvider(Parameters.java:323) at org.testng.internal.Parameters.findDataProvider(Parameters.java:259) at org.testng.internal.Parameters.handleParameters(Parameters.java:419) at org.testng.internal.Invoker.handleParameters(Invoker.java:1274) at org.testng.internal.Invoker.createParameters(Invoker.java:989) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:782) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244) at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) at org.testng.TestNG.run(TestNG.java:1064) at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:224) at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:188) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:537) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) For instance the test javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like this. It's calling "testng -DrunSecMngr=true" and obviously some important permission for testing is missing with that. I'm using most current jtreg (with testng-6.9.10.jar) Thanks for any help. Best regards Christoph From frank.yuan at oracle.com Tue Nov 22 09:03:32 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Tue, 22 Nov 2016 17:03:32 +0800 Subject: RFR JDK-8170170 Problem list ExternalEditorTest.java on all platforms Message-ID: <037601d2449f$4e5be5e0$eb13b1a0$@oracle.com> Hi All This is a problem list update in langtools repo: diff -r f4b6b78a1200 test/ProblemList.txt --- a/test/ProblemList.txt Mon Nov 21 12:28:56 2016 -0800 +++ b/test/ProblemList.txt Tue Nov 22 16:34:24 2016 +0800 @@ -38,7 +38,7 @@ jdk/jshell/EditorPadTest.java 8161276 windows-all Test set-up cannot press buttons jdk/jshell/ToolBasicTest.java 8139873 generic-all JShell tests failing -jdk/jshell/ExternalEditorTest.java 8170108 windows-all +jdk/jshell/ExternalEditorTest.java 8169828 generic-all Bug: https://bugs.openjdk.java.net/browse/JDK-8170170 Anyone would like to have a look? Thanks Frank From chris.hegarty at oracle.com Tue Nov 22 09:08:03 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Nov 2016 09:08:03 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> Message-ID: <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> Hi Christoph, Can you please ensure that your build of jtreg contains the fix for 7901792 [1]. 7901792 grants /lib/testng.jar all permissions. -Chris. [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 > On 22 Nov 2016, at 08:38, Langer, Christoph wrote: > > Hi, > > I'm currently struggling while running jtreg tests for the jaxp depot. > > There are several tests that fail with the same symptom. I always get exceptions like: > java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessDeclaredMembers") > at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:471) > at java.base/java.security.AccessController.checkPermission(AccessController.java:894) > at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:548) > at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) > at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) > at org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) > at org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) > at org.testng.internal.Parameters.findDataProvider(Parameters.java:323) > at org.testng.internal.Parameters.findDataProvider(Parameters.java:259) > at org.testng.internal.Parameters.handleParameters(Parameters.java:419) > at org.testng.internal.Invoker.handleParameters(Invoker.java:1274) > at org.testng.internal.Invoker.createParameters(Invoker.java:989) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) > at org.testng.TestRunner.privateRun(TestRunner.java:782) > at org.testng.TestRunner.run(TestRunner.java:632) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) > at org.testng.SuiteRunner.run(SuiteRunner.java:268) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) > at org.testng.TestNG.run(TestNG.java:1064) > at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:224) > at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:188) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:537) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) > at java.base/java.lang.Thread.run(Thread.java:844) > > For instance the test javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like this. > > It's calling "testng -DrunSecMngr=true" and obviously some important permission for testing is missing with that. > > I'm using most current jtreg (with testng-6.9.10.jar) > > > Thanks for any help. > > > Best regards > Christoph From chris.hegarty at oracle.com Tue Nov 22 09:12:23 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Nov 2016 09:12:23 +0000 Subject: RFR of JDK-8153543: java/rmi/transport/reuseDefaultPort/ReuseDefaultPort.java fails intermittently In-Reply-To: References: Message-ID: > On 22 Nov 2016, at 02:50, Hamlin Li wrote: > > Would you please review the patch for below bug? > > bug: https://bugs.openjdk.java.net/browse/JDK-8153543 > webrev: http://cr.openjdk.java.net/~mli/8153543/webrev.00/ Looks fine Hamlin. -Chris. > Root cause: between "TestLibrary.getUnusedRandomPort()" and "UnicastRemoteObject.exportObject(impl, 0);", there is time window, interloper might step in and get the port. > Solution: use port 0 to create server socket in RMI socket factory, then pass the exact port back. > > Thank you > -Hamlin From rachna.goel at oracle.com Tue Nov 22 09:30:08 2016 From: rachna.goel at oracle.com (Rachna Goel) Date: Tue, 22 Nov 2016 15:00:08 +0530 Subject: RFR: JDK-8075577: java.time does not support HOST provider Message-ID: Hi, Please review fix for JDK-8075577. Bug : https://bugs.openjdk.java.net/browse/JDK-8075577 webrev : http://cr.openjdk.java.net/~rgoel/JDK-8075577/webrev.01/ Fix is to introduce new private spi "sun.text.spi.JavaTimeDateTimePatternProvider.java" to retrieve LocaleProvider specific Date/Time Patterns for "java.time" . Thanks, Rachna From christoph.langer at sap.com Tue Nov 22 09:43:13 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 22 Nov 2016 09:43:13 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> Message-ID: Hi Chris, thanks for this hint. However, we've already seen this change and rebuilt jtreg with the latest jtreg repo. But it doesn't change a thing. Also, the download from https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ where I would suppose latest jtreg sources were used, don't help. Am I missing something? Best regards Christoph > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Dienstag, 22. November 2016 10:08 > To: Langer, Christoph > Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; jtreg- > use at openjdk.java.net > Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > "accessDeclaredMembers") > > Hi Christoph, > > Can you please ensure that your build of jtreg contains the fix for 7901792 [1]. > 7901792 grants /lib/testng.jar all permissions. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 > > > On 22 Nov 2016, at 08:38, Langer, Christoph > wrote: > > > > Hi, > > > > I'm currently struggling while running jtreg tests for the jaxp depot. > > > > There are several tests that fail with the same symptom. I always get > exceptions like: > > java.security.AccessControlException: access denied > ("java.lang.RuntimePermission" "accessDeclaredMembers") > > at > java.base/java.security.AccessControlContext.checkPermission(AccessControlCo > ntext.java:471) > > at > java.base/java.security.AccessController.checkPermission(AccessController.java > :894) > > at > java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 > 48) > > at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) > > at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) > > at org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) > > at > org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) > > at org.testng.internal.Parameters.findDataProvider(Parameters.java:323) > > at org.testng.internal.Parameters.findDataProvider(Parameters.java:259) > > at > org.testng.internal.Parameters.handleParameters(Parameters.java:419) > > at org.testng.internal.Invoker.handleParameters(Invoker.java:1274) > > at org.testng.internal.Invoker.createParameters(Invoker.java:989) > > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) > > at > org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. > java:129) > > at > org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) > > at org.testng.TestRunner.privateRun(TestRunner.java:782) > > at org.testng.TestRunner.run(TestRunner.java:632) > > at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) > > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) > > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) > > at org.testng.SuiteRunner.run(SuiteRunner.java:268) > > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244) > > at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) > > at org.testng.TestNG.run(TestNG.java:1064) > > at > com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: > 224) > > at > com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: > 188) > > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod > AccessorImpl.java:62) > > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin > gMethodAccessorImpl.java:43) > > at java.base/java.lang.reflect.Method.invoke(Method.java:537) > > at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j > ava:110) > > at java.base/java.lang.Thread.run(Thread.java:844) > > > > For instance the test > javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like this. > > > > It's calling "testng -DrunSecMngr=true" and obviously some important > permission for testing is missing with that. > > > > I'm using most current jtreg (with testng-6.9.10.jar) > > > > > > Thanks for any help. > > > > > > Best regards > > Christoph From chris.hegarty at oracle.com Tue Nov 22 10:03:20 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Nov 2016 10:03:20 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> Message-ID: > On 22 Nov 2016, at 09:43, Langer, Christoph wrote: > > Hi Chris, > > thanks for this hint. However, we've already seen this change and rebuilt jtreg with the latest jtreg repo. But it doesn't change a thing. > > Also, the download from https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ where I would suppose latest jtreg sources were used, don't help. > > Am I missing something? Is it possible to post, or upload to cr.o.j.n, the jtr of the failing test? -Chris. > Best regards > Christoph > >> -----Original Message----- >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >> Sent: Dienstag, 22. November 2016 10:08 >> To: Langer, Christoph >> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; jtreg- >> use at openjdk.java.net >> Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" >> "accessDeclaredMembers") >> >> Hi Christoph, >> >> Can you please ensure that your build of jtreg contains the fix for 7901792 [1]. >> 7901792 grants /lib/testng.jar all permissions. >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 >> >>> On 22 Nov 2016, at 08:38, Langer, Christoph >> wrote: >>> >>> Hi, >>> >>> I'm currently struggling while running jtreg tests for the jaxp depot. >>> >>> There are several tests that fail with the same symptom. I always get >> exceptions like: >>> java.security.AccessControlException: access denied >> ("java.lang.RuntimePermission" "accessDeclaredMembers") >>> at >> java.base/java.security.AccessControlContext.checkPermission(AccessControlCo >> ntext.java:471) >>> at >> java.base/java.security.AccessController.checkPermission(AccessController.java >> :894) >>> at >> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 >> 48) >>> at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) >>> at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) >>> at org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) >>> at >> org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) >>> at org.testng.internal.Parameters.findDataProvider(Parameters.java:323) >>> at org.testng.internal.Parameters.findDataProvider(Parameters.java:259) >>> at >> org.testng.internal.Parameters.handleParameters(Parameters.java:419) >>> at org.testng.internal.Invoker.handleParameters(Invoker.java:1274) >>> at org.testng.internal.Invoker.createParameters(Invoker.java:989) >>> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) >>> at >> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. >> java:129) >>> at >> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) >>> at org.testng.TestRunner.privateRun(TestRunner.java:782) >>> at org.testng.TestRunner.run(TestRunner.java:632) >>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) >>> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) >>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) >>> at org.testng.SuiteRunner.run(SuiteRunner.java:268) >>> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) >>> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) >>> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244) >>> at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) >>> at org.testng.TestNG.run(TestNG.java:1064) >>> at >> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >> 224) >>> at >> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >> 188) >>> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >>> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod >> AccessorImpl.java:62) >>> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin >> gMethodAccessorImpl.java:43) >>> at java.base/java.lang.reflect.Method.invoke(Method.java:537) >>> at >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j >> ava:110) >>> at java.base/java.lang.Thread.run(Thread.java:844) >>> >>> For instance the test >> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like this. >>> >>> It's calling "testng -DrunSecMngr=true" and obviously some important >> permission for testing is missing with that. >>> >>> I'm using most current jtreg (with testng-6.9.10.jar) >>> >>> >>> Thanks for any help. >>> >>> >>> Best regards >>> Christoph > From daniel.fuchs at oracle.com Tue Nov 22 10:21:58 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 22 Nov 2016 10:21:58 +0000 Subject: JDK 9 RFR of JDK-8170158: Remove ClassLoader/platformClassLoader/DefinePlatformClass.java from ProblemList In-Reply-To: <8b014c05-6227-df1e-c7eb-b538c8e29d2c@oracle.com> References: <8b014c05-6227-df1e-c7eb-b538c8e29d2c@oracle.com> Message-ID: <4c453cd2-fa50-676a-469c-b8c866a082d2@oracle.com> Looks good Amy! best regards, -- daniel On 22/11/16 03:26, Amy Lu wrote: > Please review the patch to bring back > java/lang/ClassLoader/platformClassLoader/DefinePlatformClass.java > > It's clear now that the reported failure was caused by machine wrong > time setting. > > bug: https://bugs.openjdk.java.net/browse/JDK-8170158 > > Thanks, > Amy > > --- old/test/ProblemList.txt 2016-11-22 11:21:44.000000000 +0800 > +++ new/test/ProblemList.txt 2016-11-22 11:21:44.000000000 +0800 > @@ -124,7 +124,6 @@ > # jdk_lang > > java/lang/StringCoding/CheckEncodings.sh 7008363 generic-all > -java/lang/ClassLoader/platformClassLoader/DefinePlatformClass.java > 8169639 windows-all > > ############################################################################ > > > From christoph.langer at sap.com Tue Nov 22 10:52:55 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 22 Nov 2016 10:52:55 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> Message-ID: Yes, please find it here: http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Dienstag, 22. November 2016 11:03 > To: Langer, Christoph > Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; jtreg- > use at openjdk.java.net > Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > "accessDeclaredMembers") > > > > On 22 Nov 2016, at 09:43, Langer, Christoph > wrote: > > > > Hi Chris, > > > > thanks for this hint. However, we've already seen this change and rebuilt > jtreg with the latest jtreg repo. But it doesn't change a thing. > > > > Also, the download from https://adopt- > openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ where I would > suppose latest jtreg sources were used, don't help. > > > > Am I missing something? > > Is it possible to post, or upload to cr.o.j.n, the jtr of the failing test? > > -Chris. > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > >> Sent: Dienstag, 22. November 2016 10:08 > >> To: Langer, Christoph > >> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; jtreg- > >> use at openjdk.java.net > >> Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > >> "accessDeclaredMembers") > >> > >> Hi Christoph, > >> > >> Can you please ensure that your build of jtreg contains the fix for 7901792 > [1]. > >> 7901792 grants /lib/testng.jar all permissions. > >> > >> -Chris. > >> > >> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 > >> > >>> On 22 Nov 2016, at 08:38, Langer, Christoph > >> wrote: > >>> > >>> Hi, > >>> > >>> I'm currently struggling while running jtreg tests for the jaxp depot. > >>> > >>> There are several tests that fail with the same symptom. I always get > >> exceptions like: > >>> java.security.AccessControlException: access denied > >> ("java.lang.RuntimePermission" "accessDeclaredMembers") > >>> at > >> > java.base/java.security.AccessControlContext.checkPermission(AccessControlCo > >> ntext.java:471) > >>> at > >> > java.base/java.security.AccessController.checkPermission(AccessController.java > >> :894) > >>> at > >> > java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 > >> 48) > >>> at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) > >>> at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) > >>> at > org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) > >>> at > >> org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) > >>> at > org.testng.internal.Parameters.findDataProvider(Parameters.java:323) > >>> at > org.testng.internal.Parameters.findDataProvider(Parameters.java:259) > >>> at > >> org.testng.internal.Parameters.handleParameters(Parameters.java:419) > >>> at org.testng.internal.Invoker.handleParameters(Invoker.java:1274) > >>> at org.testng.internal.Invoker.createParameters(Invoker.java:989) > >>> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) > >>> at > >> > org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. > >> java:129) > >>> at > >> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) > >>> at org.testng.TestRunner.privateRun(TestRunner.java:782) > >>> at org.testng.TestRunner.run(TestRunner.java:632) > >>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) > >>> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) > >>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) > >>> at org.testng.SuiteRunner.run(SuiteRunner.java:268) > >>> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > >>> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > >>> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244) > >>> at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) > >>> at org.testng.TestNG.run(TestNG.java:1064) > >>> at > >> > com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: > >> 224) > >>> at > >> > com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: > >> 188) > >>> at > >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > >> Method) > >>> at > >> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod > >> AccessorImpl.java:62) > >>> at > >> > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin > >> gMethodAccessorImpl.java:43) > >>> at java.base/java.lang.reflect.Method.invoke(Method.java:537) > >>> at > >> > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j > >> ava:110) > >>> at java.base/java.lang.Thread.run(Thread.java:844) > >>> > >>> For instance the test > >> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like this. > >>> > >>> It's calling "testng -DrunSecMngr=true" and obviously some important > >> permission for testing is missing with that. > >>> > >>> I'm using most current jtreg (with testng-6.9.10.jar) > >>> > >>> > >>> Thanks for any help. > >>> > >>> > >>> Best regards > >>> Christoph > > From daniel.fuchs at oracle.com Tue Nov 22 11:24:43 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 22 Nov 2016 11:24:43 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> Message-ID: Hi Christoph, Is there anything funny with the place jtreg is installed? like: - path contains whitespaces - path is accessible through links or mount points... It seems clear that the issue here is that testng classes are missing some permissions, so I was wondering whether that could be caused by the actual path to testng.jar not matching the path injected in the policy file. I'm using jtreg 4.2 fcs b03, and have no issues with the jaxp tests: $ cd jaxp/tests $ rm -r JT* $ jtreg -verbose:summary -ignore:quiet -jdk ../../build/macosx-x86_64-normal-server-release/images/jdk javax/ => the only test that fails is javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh, but that's expected (it's in the ProblemList.txt). The other thing to take care of, is not to run two jtreg process concurrently if they point to the same JT* directories. If you do that then you might experience weird failures with permissions issues (it seems to mess the policy files). best regards, -- daniel On 22/11/16 10:52, Langer, Christoph wrote: > Yes, please find it here: http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr > > >> -----Original Message----- >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >> Sent: Dienstag, 22. November 2016 11:03 >> To: Langer, Christoph >> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; jtreg- >> use at openjdk.java.net >> Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" >> "accessDeclaredMembers") >> >> >>> On 22 Nov 2016, at 09:43, Langer, Christoph >> wrote: >>> >>> Hi Chris, >>> >>> thanks for this hint. However, we've already seen this change and rebuilt >> jtreg with the latest jtreg repo. But it doesn't change a thing. >>> >>> Also, the download from https://adopt- >> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ where I would >> suppose latest jtreg sources were used, don't help. >>> >>> Am I missing something? >> >> Is it possible to post, or upload to cr.o.j.n, the jtr of the failing test? >> >> -Chris. >> >>> Best regards >>> Christoph >>> >>>> -----Original Message----- >>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>> Sent: Dienstag, 22. November 2016 10:08 >>>> To: Langer, Christoph >>>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; jtreg- >>>> use at openjdk.java.net >>>> Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" >>>> "accessDeclaredMembers") >>>> >>>> Hi Christoph, >>>> >>>> Can you please ensure that your build of jtreg contains the fix for 7901792 >> [1]. >>>> 7901792 grants /lib/testng.jar all permissions. >>>> >>>> -Chris. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 >>>> >>>>> On 22 Nov 2016, at 08:38, Langer, Christoph >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I'm currently struggling while running jtreg tests for the jaxp depot. >>>>> >>>>> There are several tests that fail with the same symptom. I always get >>>> exceptions like: >>>>> java.security.AccessControlException: access denied >>>> ("java.lang.RuntimePermission" "accessDeclaredMembers") >>>>> at >>>> >> java.base/java.security.AccessControlContext.checkPermission(AccessControlCo >>>> ntext.java:471) >>>>> at >>>> >> java.base/java.security.AccessController.checkPermission(AccessController.java >>>> :894) >>>>> at >>>> >> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 >>>> 48) >>>>> at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) >>>>> at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) >>>>> at >> org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) >>>>> at >>>> org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) >>>>> at >> org.testng.internal.Parameters.findDataProvider(Parameters.java:323) >>>>> at >> org.testng.internal.Parameters.findDataProvider(Parameters.java:259) >>>>> at >>>> org.testng.internal.Parameters.handleParameters(Parameters.java:419) >>>>> at org.testng.internal.Invoker.handleParameters(Invoker.java:1274) >>>>> at org.testng.internal.Invoker.createParameters(Invoker.java:989) >>>>> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) >>>>> at >>>> >> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. >>>> java:129) >>>>> at >>>> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) >>>>> at org.testng.TestRunner.privateRun(TestRunner.java:782) >>>>> at org.testng.TestRunner.run(TestRunner.java:632) >>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) >>>>> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) >>>>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) >>>>> at org.testng.SuiteRunner.run(SuiteRunner.java:268) >>>>> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) >>>>> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) >>>>> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244) >>>>> at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) >>>>> at org.testng.TestNG.run(TestNG.java:1064) >>>>> at >>>> >> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>> 224) >>>>> at >>>> >> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>> 188) >>>>> at >>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>> Method) >>>>> at >>>> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod >>>> AccessorImpl.java:62) >>>>> at >>>> >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin >>>> gMethodAccessorImpl.java:43) >>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:537) >>>>> at >>>> >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j >>>> ava:110) >>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>> >>>>> For instance the test >>>> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like this. >>>>> >>>>> It's calling "testng -DrunSecMngr=true" and obviously some important >>>> permission for testing is missing with that. >>>>> >>>>> I'm using most current jtreg (with testng-6.9.10.jar) >>>>> >>>>> >>>>> Thanks for any help. >>>>> >>>>> >>>>> Best regards >>>>> Christoph >>> > From christoph.langer at sap.com Tue Nov 22 11:33:11 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 22 Nov 2016 11:33:11 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> Message-ID: <928722e31ddb4d20a8a15906d01d5c92@DEWDFE13DE03.global.corp.sap> Hi Daniel, I checked your suggestion with the paths and moved my jtreg to a local disk - but nothing changed. I don't see any policy that is being manipulated. I found out, by adding some debug printing code, that inside jtreg, the addGrantEntry() method is not called at all... Is some policy file missing? Thanks Christoph > -----Original Message----- > From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com] > Sent: Dienstag, 22. November 2016 12:25 > To: Langer, Christoph ; Chris Hegarty > > Cc: code-tools-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- > use at openjdk.java.net > Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > "accessDeclaredMembers") > > Hi Christoph, > > Is there anything funny with the place jtreg is installed? > like: > - path contains whitespaces > - path is accessible through links or mount points... > > It seems clear that the issue here is that testng classes are > missing some permissions, so I was wondering whether that could > be caused by the actual path to testng.jar not matching the > path injected in the policy file. > > I'm using jtreg 4.2 fcs b03, and have no issues with the jaxp tests: > > $ cd jaxp/tests > $ rm -r JT* > $ jtreg -verbose:summary -ignore:quiet -jdk > ../../build/macosx-x86_64-normal-server-release/images/jdk javax/ > > => the only test that fails is > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh, but that's > expected (it's in the ProblemList.txt). > > The other thing to take care of, is not to run two jtreg process > concurrently if they point to the same JT* directories. If you do > that then you might experience weird failures with permissions > issues (it seems to mess the policy files). > > best regards, > > -- daniel > > On 22/11/16 10:52, Langer, Christoph wrote: > > Yes, please find it here: > http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr > > > > > >> -----Original Message----- > >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > >> Sent: Dienstag, 22. November 2016 11:03 > >> To: Langer, Christoph > >> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; jtreg- > >> use at openjdk.java.net > >> Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > >> "accessDeclaredMembers") > >> > >> > >>> On 22 Nov 2016, at 09:43, Langer, Christoph > >> wrote: > >>> > >>> Hi Chris, > >>> > >>> thanks for this hint. However, we've already seen this change and rebuilt > >> jtreg with the latest jtreg repo. But it doesn't change a thing. > >>> > >>> Also, the download from https://adopt- > >> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ where I > would > >> suppose latest jtreg sources were used, don't help. > >>> > >>> Am I missing something? > >> > >> Is it possible to post, or upload to cr.o.j.n, the jtr of the failing test? > >> > >> -Chris. > >> > >>> Best regards > >>> Christoph > >>> > >>>> -----Original Message----- > >>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > >>>> Sent: Dienstag, 22. November 2016 10:08 > >>>> To: Langer, Christoph > >>>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; > jtreg- > >>>> use at openjdk.java.net > >>>> Subject: Re: Issues running JAXP jtreg tests > ("java.lang.RuntimePermission" > >>>> "accessDeclaredMembers") > >>>> > >>>> Hi Christoph, > >>>> > >>>> Can you please ensure that your build of jtreg contains the fix for 7901792 > >> [1]. > >>>> 7901792 grants /lib/testng.jar all permissions. > >>>> > >>>> -Chris. > >>>> > >>>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 > >>>> > >>>>> On 22 Nov 2016, at 08:38, Langer, Christoph > > >>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> I'm currently struggling while running jtreg tests for the jaxp depot. > >>>>> > >>>>> There are several tests that fail with the same symptom. I always get > >>>> exceptions like: > >>>>> java.security.AccessControlException: access denied > >>>> ("java.lang.RuntimePermission" "accessDeclaredMembers") > >>>>> at > >>>> > >> > java.base/java.security.AccessControlContext.checkPermission(AccessControlCo > >>>> ntext.java:471) > >>>>> at > >>>> > >> > java.base/java.security.AccessController.checkPermission(AccessController.java > >>>> :894) > >>>>> at > >>>> > >> > java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 > >>>> 48) > >>>>> at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) > >>>>> at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) > >>>>> at > >> org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) > >>>>> at > >>>> > org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) > >>>>> at > >> org.testng.internal.Parameters.findDataProvider(Parameters.java:323) > >>>>> at > >> org.testng.internal.Parameters.findDataProvider(Parameters.java:259) > >>>>> at > >>>> org.testng.internal.Parameters.handleParameters(Parameters.java:419) > >>>>> at org.testng.internal.Invoker.handleParameters(Invoker.java:1274) > >>>>> at org.testng.internal.Invoker.createParameters(Invoker.java:989) > >>>>> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) > >>>>> at > >>>> > >> > org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. > >>>> java:129) > >>>>> at > >>>> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) > >>>>> at org.testng.TestRunner.privateRun(TestRunner.java:782) > >>>>> at org.testng.TestRunner.run(TestRunner.java:632) > >>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) > >>>>> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) > >>>>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) > >>>>> at org.testng.SuiteRunner.run(SuiteRunner.java:268) > >>>>> at > org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > >>>>> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > >>>>> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244) > >>>>> at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) > >>>>> at org.testng.TestNG.run(TestNG.java:1064) > >>>>> at > >>>> > >> > com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: > >>>> 224) > >>>>> at > >>>> > >> > com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: > >>>> 188) > >>>>> at > >>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > >>>> Method) > >>>>> at > >>>> > >> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod > >>>> AccessorImpl.java:62) > >>>>> at > >>>> > >> > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin > >>>> gMethodAccessorImpl.java:43) > >>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:537) > >>>>> at > >>>> > >> > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j > >>>> ava:110) > >>>>> at java.base/java.lang.Thread.run(Thread.java:844) > >>>>> > >>>>> For instance the test > >>>> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like this. > >>>>> > >>>>> It's calling "testng -DrunSecMngr=true" and obviously some important > >>>> permission for testing is missing with that. > >>>>> > >>>>> I'm using most current jtreg (with testng-6.9.10.jar) > >>>>> > >>>>> > >>>>> Thanks for any help. > >>>>> > >>>>> > >>>>> Best regards > >>>>> Christoph > >>> > > From volker.simonis at gmail.com Tue Nov 22 12:13:42 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 22 Nov 2016 13:13:42 +0100 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> Message-ID: Hi Daniel, thanks for your support - this problem really drives us crazy! What version of jtreg are you using? If you are using a central one which was configured and build by Oracle, could you please also try with the one from https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ ? Where can we find the generated policy files? It seems they get deleted during test post-run cleanup phase (at least I could not find any of them under JTwork). Is there a way to get a more detailed trace on how JTreg executes testng and to leave all the generated files in place after the test? I'm currently running the following JAXP test and get the same error as described by Christoph: /tmp/jtreg/bin/jtreg -verbose:summary -jdk /output-jdk9-hs-dbg/images/jdk/ /OpenJDK/jdk9-hs/jaxp/test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.java What I don't really understand is how this is supposed to work at all, because every JAXP test which runs with "-DrunSecMngr=true" will execute the following code from JAXPPolicyManager: /* * Install a SecurityManager along with a default Policy to allow testNG to * run when there is a security manager. */ private JAXPPolicyManager() { // Backing up policy and security manager for restore policyBackup = Policy.getPolicy(); smBackup = System.getSecurityManager(); // Set customized policy setDefaultPermissions(); Policy.setPolicy(policy); System.setSecurityManager(new SecurityManager()); } Won't this code override the settings from the policy file which was potentially installed by jtreg for testng? The setDefaultPermissions() sets some special permissions for testng, but not "accessDeclaredMembers": private void setDefaultPermissions() { //Permissions to set security manager and policy addPermission(new SecurityPermission("getPolicy")); addPermission(new SecurityPermission("setPolicy")); addPermission(new RuntimePermission("setSecurityManager")); //Properties that jtreg and TestNG require addPermission(new PropertyPermission("testng.show.stack.frames", "read")); addPermission(new PropertyPermission("test.src", "read")); addPermission(new PropertyPermission("test.classes", "read")); addPermission(new PropertyPermission("dataproviderthreadcount", "read")); addPermission(new PropertyPermission("experimental", "read")); } If I add the line: addPermission(new RuntimePermission("accessDeclaredMembers")); to setDefaultPermissions(), the test will succeed. I saw that an early version of "JDK-8067170: Enable security manager on JAXP unit tests" contained that extra permission, but you objected (http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042520.html) and it was removed in the final version. Any more hints? Thanks, Volker On Tue, Nov 22, 2016 at 12:24 PM, Daniel Fuchs wrote: > Hi Christoph, > > Is there anything funny with the place jtreg is installed? > like: > - path contains whitespaces > - path is accessible through links or mount points... > > It seems clear that the issue here is that testng classes are > missing some permissions, so I was wondering whether that could > be caused by the actual path to testng.jar not matching the > path injected in the policy file. > > I'm using jtreg 4.2 fcs b03, and have no issues with the jaxp tests: > > $ cd jaxp/tests > $ rm -r JT* > $ jtreg -verbose:summary -ignore:quiet -jdk > ../../build/macosx-x86_64-normal-server-release/images/jdk javax/ > > => the only test that fails is > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh, but that's expected > (it's in the ProblemList.txt). > > The other thing to take care of, is not to run two jtreg process > concurrently if they point to the same JT* directories. If you do > that then you might experience weird failures with permissions > issues (it seems to mess the policy files). > > best regards, > > -- daniel > > > On 22/11/16 10:52, Langer, Christoph wrote: >> >> Yes, please find it here: >> http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr >> >> >>> -----Original Message----- >>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>> Sent: Dienstag, 22. November 2016 11:03 >>> To: Langer, Christoph >>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; >>> jtreg- >>> use at openjdk.java.net >>> Subject: Re: Issues running JAXP jtreg tests >>> ("java.lang.RuntimePermission" >>> "accessDeclaredMembers") >>> >>> >>>> On 22 Nov 2016, at 09:43, Langer, Christoph >>> >>> wrote: >>>> >>>> >>>> Hi Chris, >>>> >>>> thanks for this hint. However, we've already seen this change and >>>> rebuilt >>> >>> jtreg with the latest jtreg repo. But it doesn't change a thing. >>>> >>>> >>>> Also, the download from https://adopt- >>> >>> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ where I >>> would >>> suppose latest jtreg sources were used, don't help. >>>> >>>> >>>> Am I missing something? >>> >>> >>> Is it possible to post, or upload to cr.o.j.n, the jtr of the failing >>> test? >>> >>> -Chris. >>> >>>> Best regards >>>> Christoph >>>> >>>>> -----Original Message----- >>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>>> Sent: Dienstag, 22. November 2016 10:08 >>>>> To: Langer, Christoph >>>>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; >>>>> jtreg- >>>>> use at openjdk.java.net >>>>> Subject: Re: Issues running JAXP jtreg tests >>>>> ("java.lang.RuntimePermission" >>>>> "accessDeclaredMembers") >>>>> >>>>> Hi Christoph, >>>>> >>>>> Can you please ensure that your build of jtreg contains the fix for >>>>> 7901792 >>> >>> [1]. >>>>> >>>>> 7901792 grants /lib/testng.jar all permissions. >>>>> >>>>> -Chris. >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 >>>>> >>>>>> On 22 Nov 2016, at 08:38, Langer, Christoph >>>>> >>>>> wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> I'm currently struggling while running jtreg tests for the jaxp depot. >>>>>> >>>>>> There are several tests that fail with the same symptom. I always get >>>>> >>>>> exceptions like: >>>>>> >>>>>> java.security.AccessControlException: access denied >>>>> >>>>> ("java.lang.RuntimePermission" "accessDeclaredMembers") >>>>>> >>>>>> at >>>>> >>>>> >>> >>> java.base/java.security.AccessControlContext.checkPermission(AccessControlCo >>>>> >>>>> ntext.java:471) >>>>>> >>>>>> at >>>>> >>>>> >>> >>> java.base/java.security.AccessController.checkPermission(AccessController.java >>>>> >>>>> :894) >>>>>> >>>>>> at >>>>> >>>>> >>> >>> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 >>>>> >>>>> 48) >>>>>> >>>>>> at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) >>>>>> at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) >>>>>> at >>> >>> org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) >>>>>> >>>>>> at >>>>> >>>>> >>>>> org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) >>>>>> >>>>>> at >>> >>> org.testng.internal.Parameters.findDataProvider(Parameters.java:323) >>>>>> >>>>>> at >>> >>> org.testng.internal.Parameters.findDataProvider(Parameters.java:259) >>>>>> >>>>>> at >>>>> >>>>> org.testng.internal.Parameters.handleParameters(Parameters.java:419) >>>>>> >>>>>> at >>>>>> org.testng.internal.Invoker.handleParameters(Invoker.java:1274) >>>>>> at >>>>>> org.testng.internal.Invoker.createParameters(Invoker.java:989) >>>>>> at >>>>>> org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) >>>>>> at >>>>> >>>>> >>> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. >>>>> >>>>> java:129) >>>>>> >>>>>> at >>>>> >>>>> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) >>>>>> >>>>>> at org.testng.TestRunner.privateRun(TestRunner.java:782) >>>>>> at org.testng.TestRunner.run(TestRunner.java:632) >>>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) >>>>>> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) >>>>>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) >>>>>> at org.testng.SuiteRunner.run(SuiteRunner.java:268) >>>>>> at >>>>>> org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) >>>>>> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) >>>>>> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244) >>>>>> at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) >>>>>> at org.testng.TestNG.run(TestNG.java:1064) >>>>>> at >>>>> >>>>> >>> >>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>> >>>>> 224) >>>>>> >>>>>> at >>>>> >>>>> >>> >>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>> >>>>> 188) >>>>>> >>>>>> at >>>>> >>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>> Method) >>>>>> >>>>>> at >>>>> >>>>> >>> >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod >>>>> >>>>> AccessorImpl.java:62) >>>>>> >>>>>> at >>>>> >>>>> >>> >>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin >>>>> >>>>> gMethodAccessorImpl.java:43) >>>>>> >>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:537) >>>>>> at >>>>> >>>>> >>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j >>>>> >>>>> ava:110) >>>>>> >>>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>>> >>>>>> For instance the test >>>>> >>>>> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like >>>>> this. >>>>>> >>>>>> >>>>>> It's calling "testng -DrunSecMngr=true" and obviously some important >>>>> >>>>> permission for testing is missing with that. >>>>>> >>>>>> >>>>>> I'm using most current jtreg (with testng-6.9.10.jar) >>>>>> >>>>>> >>>>>> Thanks for any help. >>>>>> >>>>>> >>>>>> Best regards >>>>>> Christoph >>>> >>>> >> > From chris.hegarty at oracle.com Tue Nov 22 12:25:16 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Nov 2016 12:25:16 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> Message-ID: Volker, Just to add, jtreg has support in its tags to start the test VM with a security manager and a specified policy. In the case of the test failure you are seeing, the built-in jtreg support is not being used. Instead, the test is executing with a test-specific system property that is being used to trigger the programatic setting of a security manager with a generated policy. I think this explains why you are not seeing any policy file in the JTwork directory. What is odd is that the stack trace you are seeing appears to be before the test?s main entry point, so I would not expect to the security manager to be active at this point ( since no test code has run ). My previous comment regarding 7901792 is not relevant since it relates to tests executing with a security manager set through jtreg tags. Is there anything in the environment that could trigger the VM to start up with a security manager enabled? -Chris. > On 22 Nov 2016, at 12:13, Volker Simonis wrote: > > Hi Daniel, > > thanks for your support - this problem really drives us crazy! > > What version of jtreg are you using? > If you are using a central one which was configured and build by > Oracle, could you please also try with the one from > https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ > ? > > Where can we find the generated policy files? It seems they get > deleted during test post-run cleanup phase (at least I could not find > any of them under JTwork). Is there a way to get a more detailed trace > on how JTreg executes testng and to leave all the generated files in > place after the test? > > I'm currently running the following JAXP test and get the same error > as described by Christoph: > > /tmp/jtreg/bin/jtreg -verbose:summary -jdk > /output-jdk9-hs-dbg/images/jdk/ > /OpenJDK/jdk9-hs/jaxp/test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.java > > What I don't really understand is how this is supposed to work at all, > because every JAXP test which runs with "-DrunSecMngr=true" will > execute the following code from JAXPPolicyManager: > > /* > * Install a SecurityManager along with a default Policy to allow testNG to > * run when there is a security manager. > */ > private JAXPPolicyManager() { > // Backing up policy and security manager for restore > policyBackup = Policy.getPolicy(); > smBackup = System.getSecurityManager(); > > // Set customized policy > setDefaultPermissions(); > Policy.setPolicy(policy); > System.setSecurityManager(new SecurityManager()); > } > > Won't this code override the settings from the policy file which was > potentially installed by jtreg for testng? > > The setDefaultPermissions() sets some special permissions for testng, > but not "accessDeclaredMembers": > > private void setDefaultPermissions() { > //Permissions to set security manager and policy > addPermission(new SecurityPermission("getPolicy")); > addPermission(new SecurityPermission("setPolicy")); > addPermission(new RuntimePermission("setSecurityManager")); > //Properties that jtreg and TestNG require > addPermission(new > PropertyPermission("testng.show.stack.frames", "read")); > addPermission(new PropertyPermission("test.src", "read")); > addPermission(new PropertyPermission("test.classes", "read")); > addPermission(new > PropertyPermission("dataproviderthreadcount", "read")); > addPermission(new PropertyPermission("experimental", "read")); > } > > If I add the line: > > addPermission(new RuntimePermission("accessDeclaredMembers")); > > to setDefaultPermissions(), the test will succeed. > > I saw that an early version of "JDK-8067170: Enable security manager > on JAXP unit tests" contained that extra permission, but you objected > (http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042520.html) > and it was removed in the final version. > > Any more hints? > > Thanks, > Volker > > > On Tue, Nov 22, 2016 at 12:24 PM, Daniel Fuchs wrote: >> Hi Christoph, >> >> Is there anything funny with the place jtreg is installed? >> like: >> - path contains whitespaces >> - path is accessible through links or mount points... >> >> It seems clear that the issue here is that testng classes are >> missing some permissions, so I was wondering whether that could >> be caused by the actual path to testng.jar not matching the >> path injected in the policy file. >> >> I'm using jtreg 4.2 fcs b03, and have no issues with the jaxp tests: >> >> $ cd jaxp/tests >> $ rm -r JT* >> $ jtreg -verbose:summary -ignore:quiet -jdk >> ../../build/macosx-x86_64-normal-server-release/images/jdk javax/ >> >> => the only test that fails is >> javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh, but that's expected >> (it's in the ProblemList.txt). >> >> The other thing to take care of, is not to run two jtreg process >> concurrently if they point to the same JT* directories. If you do >> that then you might experience weird failures with permissions >> issues (it seems to mess the policy files). >> >> best regards, >> >> -- daniel >> >> >> On 22/11/16 10:52, Langer, Christoph wrote: >>> >>> Yes, please find it here: >>> http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr >>> >>> >>>> -----Original Message----- >>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>> Sent: Dienstag, 22. November 2016 11:03 >>>> To: Langer, Christoph >>>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; >>>> jtreg- >>>> use at openjdk.java.net >>>> Subject: Re: Issues running JAXP jtreg tests >>>> ("java.lang.RuntimePermission" >>>> "accessDeclaredMembers") >>>> >>>> >>>>> On 22 Nov 2016, at 09:43, Langer, Christoph >>>> >>>> wrote: >>>>> >>>>> >>>>> Hi Chris, >>>>> >>>>> thanks for this hint. However, we've already seen this change and >>>>> rebuilt >>>> >>>> jtreg with the latest jtreg repo. But it doesn't change a thing. >>>>> >>>>> >>>>> Also, the download from https://adopt- >>>> >>>> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ where I >>>> would >>>> suppose latest jtreg sources were used, don't help. >>>>> >>>>> >>>>> Am I missing something? >>>> >>>> >>>> Is it possible to post, or upload to cr.o.j.n, the jtr of the failing >>>> test? >>>> >>>> -Chris. >>>> >>>>> Best regards >>>>> Christoph >>>>> >>>>>> -----Original Message----- >>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>>>> Sent: Dienstag, 22. November 2016 10:08 >>>>>> To: Langer, Christoph >>>>>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; >>>>>> jtreg- >>>>>> use at openjdk.java.net >>>>>> Subject: Re: Issues running JAXP jtreg tests >>>>>> ("java.lang.RuntimePermission" >>>>>> "accessDeclaredMembers") >>>>>> >>>>>> Hi Christoph, >>>>>> >>>>>> Can you please ensure that your build of jtreg contains the fix for >>>>>> 7901792 >>>> >>>> [1]. >>>>>> >>>>>> 7901792 grants /lib/testng.jar all permissions. >>>>>> >>>>>> -Chris. >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 >>>>>> >>>>>>> On 22 Nov 2016, at 08:38, Langer, Christoph >>>>>> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I'm currently struggling while running jtreg tests for the jaxp depot. >>>>>>> >>>>>>> There are several tests that fail with the same symptom. I always get >>>>>> >>>>>> exceptions like: >>>>>>> >>>>>>> java.security.AccessControlException: access denied >>>>>> >>>>>> ("java.lang.RuntimePermission" "accessDeclaredMembers") >>>>>>> >>>>>>> at >>>>>> >>>>>> >>>> >>>> java.base/java.security.AccessControlContext.checkPermission(AccessControlCo >>>>>> >>>>>> ntext.java:471) >>>>>>> >>>>>>> at >>>>>> >>>>>> >>>> >>>> java.base/java.security.AccessController.checkPermission(AccessController.java >>>>>> >>>>>> :894) >>>>>>> >>>>>>> at >>>>>> >>>>>> >>>> >>>> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 >>>>>> >>>>>> 48) >>>>>>> >>>>>>> at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) >>>>>>> at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) >>>>>>> at >>>> >>>> org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) >>>>>>> >>>>>>> at >>>>>> >>>>>> >>>>>> org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) >>>>>>> >>>>>>> at >>>> >>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:323) >>>>>>> >>>>>>> at >>>> >>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:259) >>>>>>> >>>>>>> at >>>>>> >>>>>> org.testng.internal.Parameters.handleParameters(Parameters.java:419) >>>>>>> >>>>>>> at >>>>>>> org.testng.internal.Invoker.handleParameters(Invoker.java:1274) >>>>>>> at >>>>>>> org.testng.internal.Invoker.createParameters(Invoker.java:989) >>>>>>> at >>>>>>> org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) >>>>>>> at >>>>>> >>>>>> >>>> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. >>>>>> >>>>>> java:129) >>>>>>> >>>>>>> at >>>>>> >>>>>> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) >>>>>>> >>>>>>> at org.testng.TestRunner.privateRun(TestRunner.java:782) >>>>>>> at org.testng.TestRunner.run(TestRunner.java:632) >>>>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) >>>>>>> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) >>>>>>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) >>>>>>> at org.testng.SuiteRunner.run(SuiteRunner.java:268) >>>>>>> at >>>>>>> org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) >>>>>>> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) >>>>>>> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244) >>>>>>> at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) >>>>>>> at org.testng.TestNG.run(TestNG.java:1064) >>>>>>> at >>>>>> >>>>>> >>>> >>>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>>> >>>>>> 224) >>>>>>> >>>>>>> at >>>>>> >>>>>> >>>> >>>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>>> >>>>>> 188) >>>>>>> >>>>>>> at >>>>>> >>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>> Method) >>>>>>> >>>>>>> at >>>>>> >>>>>> >>>> >>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod >>>>>> >>>>>> AccessorImpl.java:62) >>>>>>> >>>>>>> at >>>>>> >>>>>> >>>> >>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin >>>>>> >>>>>> gMethodAccessorImpl.java:43) >>>>>>> >>>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:537) >>>>>>> at >>>>>> >>>>>> >>>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j >>>>>> >>>>>> ava:110) >>>>>>> >>>>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>>>> >>>>>>> For instance the test >>>>>> >>>>>> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like >>>>>> this. >>>>>>> >>>>>>> >>>>>>> It's calling "testng -DrunSecMngr=true" and obviously some important >>>>>> >>>>>> permission for testing is missing with that. >>>>>>> >>>>>>> >>>>>>> I'm using most current jtreg (with testng-6.9.10.jar) >>>>>>> >>>>>>> >>>>>>> Thanks for any help. >>>>>>> >>>>>>> >>>>>>> Best regards >>>>>>> Christoph >>>>> >>>>> >>> >> From daniel.fuchs at oracle.com Tue Nov 22 12:32:32 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 22 Nov 2016 12:32:32 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> Message-ID: Hi Volker, On 22/11/16 12:25, Chris Hegarty wrote: > Volker, > > Just to add, jtreg has support in its tags to start the test VM with a > security manager and a specified policy. In the case of the test failure > you are seeing, the built-in jtreg support is not being used. Instead, > the test is executing with a test-specific system property that is being > used to trigger the programatic setting of a security manager with a > generated policy. I think this explains why you are not seeing any > policy file in the JTwork directory. > > What is odd is that the stack trace you are seeing appears to be > before the test?s main entry point, so I would not expect to the > security manager to be active at this point ( since no test code > has run ). My previous comment regarding 7901792 is not relevant > since it relates to tests executing with a security manager set > through jtreg tags. I agree with Chris - I believe CODETOOLS-7901792 was a red herring. I'm going to try the jtreg you pointed at and see if there's any difference (I'm using jtreg 4.2 fcs b03). > Is there anything in the environment that could trigger the VM > to start up with a security manager enabled? This is a good question. best regards, -- daniel > > -Chris. > >> On 22 Nov 2016, at 12:13, Volker Simonis wrote: >> >> Hi Daniel, >> >> thanks for your support - this problem really drives us crazy! >> >> What version of jtreg are you using? >> If you are using a central one which was configured and build by >> Oracle, could you please also try with the one from >> https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ >> ? >> >> Where can we find the generated policy files? It seems they get >> deleted during test post-run cleanup phase (at least I could not find >> any of them under JTwork). Is there a way to get a more detailed trace >> on how JTreg executes testng and to leave all the generated files in >> place after the test? >> >> I'm currently running the following JAXP test and get the same error >> as described by Christoph: >> >> /tmp/jtreg/bin/jtreg -verbose:summary -jdk >> /output-jdk9-hs-dbg/images/jdk/ >> /OpenJDK/jdk9-hs/jaxp/test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.java >> >> What I don't really understand is how this is supposed to work at all, >> because every JAXP test which runs with "-DrunSecMngr=true" will >> execute the following code from JAXPPolicyManager: >> >> /* >> * Install a SecurityManager along with a default Policy to allow testNG to >> * run when there is a security manager. >> */ >> private JAXPPolicyManager() { >> // Backing up policy and security manager for restore >> policyBackup = Policy.getPolicy(); >> smBackup = System.getSecurityManager(); >> >> // Set customized policy >> setDefaultPermissions(); >> Policy.setPolicy(policy); >> System.setSecurityManager(new SecurityManager()); >> } >> >> Won't this code override the settings from the policy file which was >> potentially installed by jtreg for testng? >> >> The setDefaultPermissions() sets some special permissions for testng, >> but not "accessDeclaredMembers": >> >> private void setDefaultPermissions() { >> //Permissions to set security manager and policy >> addPermission(new SecurityPermission("getPolicy")); >> addPermission(new SecurityPermission("setPolicy")); >> addPermission(new RuntimePermission("setSecurityManager")); >> //Properties that jtreg and TestNG require >> addPermission(new >> PropertyPermission("testng.show.stack.frames", "read")); >> addPermission(new PropertyPermission("test.src", "read")); >> addPermission(new PropertyPermission("test.classes", "read")); >> addPermission(new >> PropertyPermission("dataproviderthreadcount", "read")); >> addPermission(new PropertyPermission("experimental", "read")); >> } >> >> If I add the line: >> >> addPermission(new RuntimePermission("accessDeclaredMembers")); >> >> to setDefaultPermissions(), the test will succeed. >> >> I saw that an early version of "JDK-8067170: Enable security manager >> on JAXP unit tests" contained that extra permission, but you objected >> (http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042520.html) >> and it was removed in the final version. >> >> Any more hints? >> >> Thanks, >> Volker >> >> >> On Tue, Nov 22, 2016 at 12:24 PM, Daniel Fuchs wrote: >>> Hi Christoph, >>> >>> Is there anything funny with the place jtreg is installed? >>> like: >>> - path contains whitespaces >>> - path is accessible through links or mount points... >>> >>> It seems clear that the issue here is that testng classes are >>> missing some permissions, so I was wondering whether that could >>> be caused by the actual path to testng.jar not matching the >>> path injected in the policy file. >>> >>> I'm using jtreg 4.2 fcs b03, and have no issues with the jaxp tests: >>> >>> $ cd jaxp/tests >>> $ rm -r JT* >>> $ jtreg -verbose:summary -ignore:quiet -jdk >>> ../../build/macosx-x86_64-normal-server-release/images/jdk javax/ >>> >>> => the only test that fails is >>> javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh, but that's expected >>> (it's in the ProblemList.txt). >>> >>> The other thing to take care of, is not to run two jtreg process >>> concurrently if they point to the same JT* directories. If you do >>> that then you might experience weird failures with permissions >>> issues (it seems to mess the policy files). >>> >>> best regards, >>> >>> -- daniel >>> >>> >>> On 22/11/16 10:52, Langer, Christoph wrote: >>>> >>>> Yes, please find it here: >>>> http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr >>>> >>>> >>>>> -----Original Message----- >>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>>> Sent: Dienstag, 22. November 2016 11:03 >>>>> To: Langer, Christoph >>>>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; >>>>> jtreg- >>>>> use at openjdk.java.net >>>>> Subject: Re: Issues running JAXP jtreg tests >>>>> ("java.lang.RuntimePermission" >>>>> "accessDeclaredMembers") >>>>> >>>>> >>>>>> On 22 Nov 2016, at 09:43, Langer, Christoph >>>>> >>>>> wrote: >>>>>> >>>>>> >>>>>> Hi Chris, >>>>>> >>>>>> thanks for this hint. However, we've already seen this change and >>>>>> rebuilt >>>>> >>>>> jtreg with the latest jtreg repo. But it doesn't change a thing. >>>>>> >>>>>> >>>>>> Also, the download from https://adopt- >>>>> >>>>> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ where I >>>>> would >>>>> suppose latest jtreg sources were used, don't help. >>>>>> >>>>>> >>>>>> Am I missing something? >>>>> >>>>> >>>>> Is it possible to post, or upload to cr.o.j.n, the jtr of the failing >>>>> test? >>>>> >>>>> -Chris. >>>>> >>>>>> Best regards >>>>>> Christoph >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>>>>> Sent: Dienstag, 22. November 2016 10:08 >>>>>>> To: Langer, Christoph >>>>>>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; >>>>>>> jtreg- >>>>>>> use at openjdk.java.net >>>>>>> Subject: Re: Issues running JAXP jtreg tests >>>>>>> ("java.lang.RuntimePermission" >>>>>>> "accessDeclaredMembers") >>>>>>> >>>>>>> Hi Christoph, >>>>>>> >>>>>>> Can you please ensure that your build of jtreg contains the fix for >>>>>>> 7901792 >>>>> >>>>> [1]. >>>>>>> >>>>>>> 7901792 grants /lib/testng.jar all permissions. >>>>>>> >>>>>>> -Chris. >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 >>>>>>> >>>>>>>> On 22 Nov 2016, at 08:38, Langer, Christoph >>>>>>> >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'm currently struggling while running jtreg tests for the jaxp depot. >>>>>>>> >>>>>>>> There are several tests that fail with the same symptom. I always get >>>>>>> >>>>>>> exceptions like: >>>>>>>> >>>>>>>> java.security.AccessControlException: access denied >>>>>>> >>>>>>> ("java.lang.RuntimePermission" "accessDeclaredMembers") >>>>>>>> >>>>>>>> at >>>>>>> >>>>>>> >>>>> >>>>> java.base/java.security.AccessControlContext.checkPermission(AccessControlCo >>>>>>> >>>>>>> ntext.java:471) >>>>>>>> >>>>>>>> at >>>>>>> >>>>>>> >>>>> >>>>> java.base/java.security.AccessController.checkPermission(AccessController.java >>>>>>> >>>>>>> :894) >>>>>>>> >>>>>>>> at >>>>>>> >>>>>>> >>>>> >>>>> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 >>>>>>> >>>>>>> 48) >>>>>>>> >>>>>>>> at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) >>>>>>>> at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) >>>>>>>> at >>>>> >>>>> org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) >>>>>>>> >>>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) >>>>>>>> >>>>>>>> at >>>>> >>>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:323) >>>>>>>> >>>>>>>> at >>>>> >>>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:259) >>>>>>>> >>>>>>>> at >>>>>>> >>>>>>> org.testng.internal.Parameters.handleParameters(Parameters.java:419) >>>>>>>> >>>>>>>> at >>>>>>>> org.testng.internal.Invoker.handleParameters(Invoker.java:1274) >>>>>>>> at >>>>>>>> org.testng.internal.Invoker.createParameters(Invoker.java:989) >>>>>>>> at >>>>>>>> org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) >>>>>>>> at >>>>>>> >>>>>>> >>>>> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. >>>>>>> >>>>>>> java:129) >>>>>>>> >>>>>>>> at >>>>>>> >>>>>>> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) >>>>>>>> >>>>>>>> at org.testng.TestRunner.privateRun(TestRunner.java:782) >>>>>>>> at org.testng.TestRunner.run(TestRunner.java:632) >>>>>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) >>>>>>>> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) >>>>>>>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) >>>>>>>> at org.testng.SuiteRunner.run(SuiteRunner.java:268) >>>>>>>> at >>>>>>>> org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) >>>>>>>> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) >>>>>>>> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244) >>>>>>>> at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) >>>>>>>> at org.testng.TestNG.run(TestNG.java:1064) >>>>>>>> at >>>>>>> >>>>>>> >>>>> >>>>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>>>> >>>>>>> 224) >>>>>>>> >>>>>>>> at >>>>>>> >>>>>>> >>>>> >>>>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>>>> >>>>>>> 188) >>>>>>>> >>>>>>>> at >>>>>>> >>>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>> Method) >>>>>>>> >>>>>>>> at >>>>>>> >>>>>>> >>>>> >>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod >>>>>>> >>>>>>> AccessorImpl.java:62) >>>>>>>> >>>>>>>> at >>>>>>> >>>>>>> >>>>> >>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin >>>>>>> >>>>>>> gMethodAccessorImpl.java:43) >>>>>>>> >>>>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:537) >>>>>>>> at >>>>>>> >>>>>>> >>>>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j >>>>>>> >>>>>>> ava:110) >>>>>>>> >>>>>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>>>>> >>>>>>>> For instance the test >>>>>>> >>>>>>> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like >>>>>>> this. >>>>>>>> >>>>>>>> >>>>>>>> It's calling "testng -DrunSecMngr=true" and obviously some important >>>>>>> >>>>>>> permission for testing is missing with that. >>>>>>>> >>>>>>>> >>>>>>>> I'm using most current jtreg (with testng-6.9.10.jar) >>>>>>>> >>>>>>>> >>>>>>>> Thanks for any help. >>>>>>>> >>>>>>>> >>>>>>>> Best regards >>>>>>>> Christoph >>>>>> >>>>>> >>>> >>> > From daniel.fuchs at oracle.com Tue Nov 22 12:42:14 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 22 Nov 2016 12:42:14 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> Message-ID: <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> Hi guys, Are you running the tests with the exploded jdk or with the image? I'm seeing failures with the exploded jdk. That could explain the difference with permission checks. best regards, -- daniel On 22/11/16 12:32, Daniel Fuchs wrote: > Hi Volker, > > On 22/11/16 12:25, Chris Hegarty wrote: >> Volker, >> >> Just to add, jtreg has support in its tags to start the test VM with a >> security manager and a specified policy. In the case of the test failure >> you are seeing, the built-in jtreg support is not being used. Instead, >> the test is executing with a test-specific system property that is being >> used to trigger the programatic setting of a security manager with a >> generated policy. I think this explains why you are not seeing any >> policy file in the JTwork directory. >> >> What is odd is that the stack trace you are seeing appears to be >> before the test?s main entry point, so I would not expect to the >> security manager to be active at this point ( since no test code >> has run ). My previous comment regarding 7901792 is not relevant >> since it relates to tests executing with a security manager set >> through jtreg tags. > > I agree with Chris - I believe CODETOOLS-7901792 was a red herring. > I'm going to try the jtreg you pointed at and see if there's any > difference (I'm using jtreg 4.2 fcs b03). > >> Is there anything in the environment that could trigger the VM >> to start up with a security manager enabled? > > This is a good question. > > best regards, > > -- daniel > >> >> -Chris. >> >>> On 22 Nov 2016, at 12:13, Volker Simonis >>> wrote: >>> >>> Hi Daniel, >>> >>> thanks for your support - this problem really drives us crazy! >>> >>> What version of jtreg are you using? >>> If you are using a central one which was configured and build by >>> Oracle, could you please also try with the one from >>> https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ >>> >>> ? >>> >>> Where can we find the generated policy files? It seems they get >>> deleted during test post-run cleanup phase (at least I could not find >>> any of them under JTwork). Is there a way to get a more detailed trace >>> on how JTreg executes testng and to leave all the generated files in >>> place after the test? >>> >>> I'm currently running the following JAXP test and get the same error >>> as described by Christoph: >>> >>> /tmp/jtreg/bin/jtreg -verbose:summary -jdk >>> /output-jdk9-hs-dbg/images/jdk/ >>> /OpenJDK/jdk9-hs/jaxp/test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.java >>> >>> >>> What I don't really understand is how this is supposed to work at all, >>> because every JAXP test which runs with "-DrunSecMngr=true" will >>> execute the following code from JAXPPolicyManager: >>> >>> /* >>> * Install a SecurityManager along with a default Policy to allow >>> testNG to >>> * run when there is a security manager. >>> */ >>> private JAXPPolicyManager() { >>> // Backing up policy and security manager for restore >>> policyBackup = Policy.getPolicy(); >>> smBackup = System.getSecurityManager(); >>> >>> // Set customized policy >>> setDefaultPermissions(); >>> Policy.setPolicy(policy); >>> System.setSecurityManager(new SecurityManager()); >>> } >>> >>> Won't this code override the settings from the policy file which was >>> potentially installed by jtreg for testng? >>> >>> The setDefaultPermissions() sets some special permissions for testng, >>> but not "accessDeclaredMembers": >>> >>> private void setDefaultPermissions() { >>> //Permissions to set security manager and policy >>> addPermission(new SecurityPermission("getPolicy")); >>> addPermission(new SecurityPermission("setPolicy")); >>> addPermission(new RuntimePermission("setSecurityManager")); >>> //Properties that jtreg and TestNG require >>> addPermission(new >>> PropertyPermission("testng.show.stack.frames", "read")); >>> addPermission(new PropertyPermission("test.src", "read")); >>> addPermission(new PropertyPermission("test.classes", "read")); >>> addPermission(new >>> PropertyPermission("dataproviderthreadcount", "read")); >>> addPermission(new PropertyPermission("experimental", "read")); >>> } >>> >>> If I add the line: >>> >>> addPermission(new RuntimePermission("accessDeclaredMembers")); >>> >>> to setDefaultPermissions(), the test will succeed. >>> >>> I saw that an early version of "JDK-8067170: Enable security manager >>> on JAXP unit tests" contained that extra permission, but you objected >>> (http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042520.html) >>> >>> and it was removed in the final version. >>> >>> Any more hints? >>> >>> Thanks, >>> Volker >>> >>> >>> On Tue, Nov 22, 2016 at 12:24 PM, Daniel Fuchs >>> wrote: >>>> Hi Christoph, >>>> >>>> Is there anything funny with the place jtreg is installed? >>>> like: >>>> - path contains whitespaces >>>> - path is accessible through links or mount points... >>>> >>>> It seems clear that the issue here is that testng classes are >>>> missing some permissions, so I was wondering whether that could >>>> be caused by the actual path to testng.jar not matching the >>>> path injected in the policy file. >>>> >>>> I'm using jtreg 4.2 fcs b03, and have no issues with the jaxp tests: >>>> >>>> $ cd jaxp/tests >>>> $ rm -r JT* >>>> $ jtreg -verbose:summary -ignore:quiet -jdk >>>> ../../build/macosx-x86_64-normal-server-release/images/jdk javax/ >>>> >>>> => the only test that fails is >>>> javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh, but that's >>>> expected >>>> (it's in the ProblemList.txt). >>>> >>>> The other thing to take care of, is not to run two jtreg process >>>> concurrently if they point to the same JT* directories. If you do >>>> that then you might experience weird failures with permissions >>>> issues (it seems to mess the policy files). >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> >>>> On 22/11/16 10:52, Langer, Christoph wrote: >>>>> >>>>> Yes, please find it here: >>>>> http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>>>> Sent: Dienstag, 22. November 2016 11:03 >>>>>> To: Langer, Christoph >>>>>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; >>>>>> jtreg- >>>>>> use at openjdk.java.net >>>>>> Subject: Re: Issues running JAXP jtreg tests >>>>>> ("java.lang.RuntimePermission" >>>>>> "accessDeclaredMembers") >>>>>> >>>>>> >>>>>>> On 22 Nov 2016, at 09:43, Langer, Christoph >>>>>>> >>>>>> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Hi Chris, >>>>>>> >>>>>>> thanks for this hint. However, we've already seen this change and >>>>>>> rebuilt >>>>>> >>>>>> jtreg with the latest jtreg repo. But it doesn't change a thing. >>>>>>> >>>>>>> >>>>>>> Also, the download from https://adopt- >>>>>> >>>>>> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ >>>>>> where I >>>>>> would >>>>>> suppose latest jtreg sources were used, don't help. >>>>>>> >>>>>>> >>>>>>> Am I missing something? >>>>>> >>>>>> >>>>>> Is it possible to post, or upload to cr.o.j.n, the jtr of the failing >>>>>> test? >>>>>> >>>>>> -Chris. >>>>>> >>>>>>> Best regards >>>>>>> Christoph >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>>>>>> Sent: Dienstag, 22. November 2016 10:08 >>>>>>>> To: Langer, Christoph >>>>>>>> Cc: core-libs-dev at openjdk.java.net; >>>>>>>> code-tools-dev at openjdk.java.net; >>>>>>>> jtreg- >>>>>>>> use at openjdk.java.net >>>>>>>> Subject: Re: Issues running JAXP jtreg tests >>>>>>>> ("java.lang.RuntimePermission" >>>>>>>> "accessDeclaredMembers") >>>>>>>> >>>>>>>> Hi Christoph, >>>>>>>> >>>>>>>> Can you please ensure that your build of jtreg contains the fix for >>>>>>>> 7901792 >>>>>> >>>>>> [1]. >>>>>>>> >>>>>>>> 7901792 grants /lib/testng.jar all permissions. >>>>>>>> >>>>>>>> -Chris. >>>>>>>> >>>>>>>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 >>>>>>>> >>>>>>>>> On 22 Nov 2016, at 08:38, Langer, Christoph >>>>>>>>> >>>>>>>> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I'm currently struggling while running jtreg tests for the jaxp >>>>>>>>> depot. >>>>>>>>> >>>>>>>>> There are several tests that fail with the same symptom. I >>>>>>>>> always get >>>>>>>> >>>>>>>> exceptions like: >>>>>>>>> >>>>>>>>> java.security.AccessControlException: access denied >>>>>>>> >>>>>>>> ("java.lang.RuntimePermission" "accessDeclaredMembers") >>>>>>>>> >>>>>>>>> at >>>>>>>> >>>>>>>> >>>>>> >>>>>> java.base/java.security.AccessControlContext.checkPermission(AccessControlCo >>>>>> >>>>>>>> >>>>>>>> ntext.java:471) >>>>>>>>> >>>>>>>>> at >>>>>>>> >>>>>>>> >>>>>> >>>>>> java.base/java.security.AccessController.checkPermission(AccessController.java >>>>>> >>>>>>>> >>>>>>>> :894) >>>>>>>>> >>>>>>>>> at >>>>>>>> >>>>>>>> >>>>>> >>>>>> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 >>>>>> >>>>>>>> >>>>>>>> 48) >>>>>>>>> >>>>>>>>> at >>>>>>>>> java.base/java.lang.Class.checkMemberAccess(Class.java:2595) >>>>>>>>> at >>>>>>>>> java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) >>>>>>>>> at >>>>>> >>>>>> org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) >>>>>>>>> >>>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) >>>>>>>> >>>>>>>>> >>>>>>>>> at >>>>>> >>>>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:323) >>>>>>>>> >>>>>>>>> at >>>>>> >>>>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:259) >>>>>>>>> >>>>>>>>> at >>>>>>>> >>>>>>>> org.testng.internal.Parameters.handleParameters(Parameters.java:419) >>>>>>>> >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.testng.internal.Invoker.handleParameters(Invoker.java:1274) >>>>>>>>> at >>>>>>>>> org.testng.internal.Invoker.createParameters(Invoker.java:989) >>>>>>>>> at >>>>>>>>> org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) >>>>>>>>> at >>>>>>>> >>>>>>>> >>>>>> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. >>>>>> >>>>>>>> >>>>>>>> java:129) >>>>>>>>> >>>>>>>>> at >>>>>>>> >>>>>>>> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) >>>>>>>>> >>>>>>>>> at org.testng.TestRunner.privateRun(TestRunner.java:782) >>>>>>>>> at org.testng.TestRunner.run(TestRunner.java:632) >>>>>>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) >>>>>>>>> at >>>>>>>>> org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) >>>>>>>>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) >>>>>>>>> at org.testng.SuiteRunner.run(SuiteRunner.java:268) >>>>>>>>> at >>>>>>>>> org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) >>>>>>>>> at >>>>>>>>> org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) >>>>>>>>> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244) >>>>>>>>> at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) >>>>>>>>> at org.testng.TestNG.run(TestNG.java:1064) >>>>>>>>> at >>>>>>>> >>>>>>>> >>>>>> >>>>>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>>> >>>>>>>> >>>>>>>> 224) >>>>>>>>> >>>>>>>>> at >>>>>>>> >>>>>>>> >>>>>> >>>>>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>>> >>>>>>>> >>>>>>>> 188) >>>>>>>>> >>>>>>>>> at >>>>>>>> >>>>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>>> >>>>>>>> Method) >>>>>>>>> >>>>>>>>> at >>>>>>>> >>>>>>>> >>>>>> >>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod >>>>>> >>>>>>>> >>>>>>>> AccessorImpl.java:62) >>>>>>>>> >>>>>>>>> at >>>>>>>> >>>>>>>> >>>>>> >>>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin >>>>>> >>>>>>>> >>>>>>>> gMethodAccessorImpl.java:43) >>>>>>>>> >>>>>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:537) >>>>>>>>> at >>>>>>>> >>>>>>>> >>>>>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j >>>>>> >>>>>>>> >>>>>>>> ava:110) >>>>>>>>> >>>>>>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>>>>>> >>>>>>>>> For instance the test >>>>>>>> >>>>>>>> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like >>>>>>>> this. >>>>>>>>> >>>>>>>>> >>>>>>>>> It's calling "testng -DrunSecMngr=true" and obviously some >>>>>>>>> important >>>>>>>> >>>>>>>> permission for testing is missing with that. >>>>>>>>> >>>>>>>>> >>>>>>>>> I'm using most current jtreg (with testng-6.9.10.jar) >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks for any help. >>>>>>>>> >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> Christoph >>>>>>> >>>>>>> >>>>> >>>> >> > From denis.kononenko at oracle.com Tue Nov 22 12:51:07 2016 From: denis.kononenko at oracle.com (Denis Kononenko) Date: Tue, 22 Nov 2016 04:51:07 -0800 (PST) Subject: [9] RFR: 8170120: Several new jimage testcases should be excluded due to their failures Message-ID: <0d57289f-6d88-4c32-981d-f2a4fe97c656@default> Hi, Could someone please review this small fix. Recently several failing test cases were delivered into jdk9-dev by my mistake (https://bugs.openjdk.java.net/browse/JDK-8167240). I've just renamed these test cases to temporarily avoid their execution. They should be renamed back when appropriate fixes for 4 product bugs are delivered. Also I've fixed testcase JImageVerifyTest.testVerifyNotExistingImage, it contained a regrettable error and duplicated another test case (testVerifyImageNotSpecified). BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170120 WEBREV: http://cr.openjdk.java.net/~dkononenko/8170120/webrev.00 Now the tests have 100% pass rate. JImageListTest: Invoking testList jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testListHelp jimage [list, -h] jimage [list, --help] Invoking testListVerbose jimage [list, --verbose, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testListIncludeAllWithGlob jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] jimage [list, --include, **, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testListIncludeWithGlob jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] jimage [list, --include, /java.base/java/util/zip/**, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testListIncludeNoMatchWithGlob jimage [list, --include, not_matching, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testListIncludeAllWithExplicitGlob jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] jimage [list, --include, glob:**, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testListIncludeAllWithRegex jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] jimage [list, --include, regex:.*, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testListIncludeWithRegex jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] jimage [list, --include, regex:/java.base/java/text/.*, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testListIncludeNoMatchWithRegex jimage [list, --include, regex:not_matching, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testListIncludeMultiplePatterns jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] jimage [list, --include, glob:/java.base/java/time/**,regex:/java.base/java/util/zip/.*, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testListNotExistingImage jimage [list, ./not_existing_image] Invoking testListWithUnknownOption jimage [list, --unknown] STDERR: STATUS:Passed. JImageExtractTest: Invoking testExtract jimage [extract, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testExtractHelp jimage [extract, --help] jimage [extract, --help] Invoking testExtractToDir jimage [extract, --dir, ./JImageExtractTest3092688479608335903, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testExtractNotExistingImage jimage [extract, ./not_existing_image] Invoking testExtractToUnspecifiedDir jimage [extract, --dir, --, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testExtractToNotExistingDir jimage [extract, --dir, ./JImageExtractTest9794403129293432977, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testExtractFromDir jimage [extract, home/dnk/projects/oracle/jdk-9/lib] Invoking testExtractToDirBySymlink jimage [extract, --dir, ./symlink, /home/dnk/projects/oracle/jdk-9/lib/modules] STDERR: STATUS:Passed. JImageVerifyTest: Invoking testVerify jimage [verify, /home/dnk/projects/oracle/jdk-9/lib/modules] Invoking testVerifyHelp jimage [verify, -h] jimage [verify, --help] Invoking testVerifyNotExistingImage jimage [verify, ./not_existing_image] Invoking testVerifyWithUnknownOption jimage [verify, --unknown] STDERR: STATUS:Passed. Also I need a sponsor to push the change into jdk9-dev. Thank you, Denis. From christoph.langer at sap.com Tue Nov 22 13:01:02 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 22 Nov 2016 13:01:02 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> Message-ID: <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> Hi, we are running jtreg with something like -jdk:/images/jdk. So would that be the exploded version or not? FWIW: I think all test that fail don't have void test methods but the test methods expect input parameters and hence a tag @Test(dataProvider = "...") exists. Can it be that we are using a testng framework that is "too new" and maybe contains something which makes it not work in the jaxp scenario? Best, Christoph > -----Original Message----- > From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com] > Sent: Dienstag, 22. November 2016 13:42 > To: Volker Simonis ; Langer, Christoph > ; Langer, Christoph > Cc: Chris Hegarty ; code-tools- > dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- > use at openjdk.java.net > Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > "accessDeclaredMembers") > > Hi guys, > > Are you running the tests with the exploded jdk or with the image? > > I'm seeing failures with the exploded jdk. > > That could explain the difference with permission checks. > > best regards, > > -- daniel > > > On 22/11/16 12:32, Daniel Fuchs wrote: > > Hi Volker, > > > > On 22/11/16 12:25, Chris Hegarty wrote: > >> Volker, > >> > >> Just to add, jtreg has support in its tags to start the test VM with a > >> security manager and a specified policy. In the case of the test failure > >> you are seeing, the built-in jtreg support is not being used. Instead, > >> the test is executing with a test-specific system property that is being > >> used to trigger the programatic setting of a security manager with a > >> generated policy. I think this explains why you are not seeing any > >> policy file in the JTwork directory. > >> > >> What is odd is that the stack trace you are seeing appears to be > >> before the test?s main entry point, so I would not expect to the > >> security manager to be active at this point ( since no test code > >> has run ). My previous comment regarding 7901792 is not relevant > >> since it relates to tests executing with a security manager set > >> through jtreg tags. > > > > I agree with Chris - I believe CODETOOLS-7901792 was a red herring. > > I'm going to try the jtreg you pointed at and see if there's any > > difference (I'm using jtreg 4.2 fcs b03). > > > >> Is there anything in the environment that could trigger the VM > >> to start up with a security manager enabled? > > > > This is a good question. > > > > best regards, > > > > -- daniel > > > >> > >> -Chris. > >> > >>> On 22 Nov 2016, at 12:13, Volker Simonis > >>> wrote: > >>> > >>> Hi Daniel, > >>> > >>> thanks for your support - this problem really drives us crazy! > >>> > >>> What version of jtreg are you using? > >>> If you are using a central one which was configured and build by > >>> Oracle, could you please also try with the one from > >>> https://adopt- > openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ > >>> > >>> ? > >>> > >>> Where can we find the generated policy files? It seems they get > >>> deleted during test post-run cleanup phase (at least I could not find > >>> any of them under JTwork). Is there a way to get a more detailed trace > >>> on how JTreg executes testng and to leave all the generated files in > >>> place after the test? > >>> > >>> I'm currently running the following JAXP test and get the same error > >>> as described by Christoph: > >>> > >>> /tmp/jtreg/bin/jtreg -verbose:summary -jdk > >>> /output-jdk9-hs-dbg/images/jdk/ > >>> /OpenJDK/jdk9- > hs/jaxp/test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.jav > a > >>> > >>> > >>> What I don't really understand is how this is supposed to work at all, > >>> because every JAXP test which runs with "-DrunSecMngr=true" will > >>> execute the following code from JAXPPolicyManager: > >>> > >>> /* > >>> * Install a SecurityManager along with a default Policy to allow > >>> testNG to > >>> * run when there is a security manager. > >>> */ > >>> private JAXPPolicyManager() { > >>> // Backing up policy and security manager for restore > >>> policyBackup = Policy.getPolicy(); > >>> smBackup = System.getSecurityManager(); > >>> > >>> // Set customized policy > >>> setDefaultPermissions(); > >>> Policy.setPolicy(policy); > >>> System.setSecurityManager(new SecurityManager()); > >>> } > >>> > >>> Won't this code override the settings from the policy file which was > >>> potentially installed by jtreg for testng? > >>> > >>> The setDefaultPermissions() sets some special permissions for testng, > >>> but not "accessDeclaredMembers": > >>> > >>> private void setDefaultPermissions() { > >>> //Permissions to set security manager and policy > >>> addPermission(new SecurityPermission("getPolicy")); > >>> addPermission(new SecurityPermission("setPolicy")); > >>> addPermission(new RuntimePermission("setSecurityManager")); > >>> //Properties that jtreg and TestNG require > >>> addPermission(new > >>> PropertyPermission("testng.show.stack.frames", "read")); > >>> addPermission(new PropertyPermission("test.src", "read")); > >>> addPermission(new PropertyPermission("test.classes", "read")); > >>> addPermission(new > >>> PropertyPermission("dataproviderthreadcount", "read")); > >>> addPermission(new PropertyPermission("experimental", "read")); > >>> } > >>> > >>> If I add the line: > >>> > >>> addPermission(new RuntimePermission("accessDeclaredMembers")); > >>> > >>> to setDefaultPermissions(), the test will succeed. > >>> > >>> I saw that an early version of "JDK-8067170: Enable security manager > >>> on JAXP unit tests" contained that extra permission, but you objected > >>> (http://mail.openjdk.java.net/pipermail/core-libs-dev/2016- > July/042520.html) > >>> > >>> and it was removed in the final version. > >>> > >>> Any more hints? > >>> > >>> Thanks, > >>> Volker > >>> > >>> > >>> On Tue, Nov 22, 2016 at 12:24 PM, Daniel Fuchs > >>> wrote: > >>>> Hi Christoph, > >>>> > >>>> Is there anything funny with the place jtreg is installed? > >>>> like: > >>>> - path contains whitespaces > >>>> - path is accessible through links or mount points... > >>>> > >>>> It seems clear that the issue here is that testng classes are > >>>> missing some permissions, so I was wondering whether that could > >>>> be caused by the actual path to testng.jar not matching the > >>>> path injected in the policy file. > >>>> > >>>> I'm using jtreg 4.2 fcs b03, and have no issues with the jaxp tests: > >>>> > >>>> $ cd jaxp/tests > >>>> $ rm -r JT* > >>>> $ jtreg -verbose:summary -ignore:quiet -jdk > >>>> ../../build/macosx-x86_64-normal-server-release/images/jdk javax/ > >>>> > >>>> => the only test that fails is > >>>> javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh, but that's > >>>> expected > >>>> (it's in the ProblemList.txt). > >>>> > >>>> The other thing to take care of, is not to run two jtreg process > >>>> concurrently if they point to the same JT* directories. If you do > >>>> that then you might experience weird failures with permissions > >>>> issues (it seems to mess the policy files). > >>>> > >>>> best regards, > >>>> > >>>> -- daniel > >>>> > >>>> > >>>> On 22/11/16 10:52, Langer, Christoph wrote: > >>>>> > >>>>> Yes, please find it here: > >>>>> http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > >>>>>> Sent: Dienstag, 22. November 2016 11:03 > >>>>>> To: Langer, Christoph > >>>>>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; > >>>>>> jtreg- > >>>>>> use at openjdk.java.net > >>>>>> Subject: Re: Issues running JAXP jtreg tests > >>>>>> ("java.lang.RuntimePermission" > >>>>>> "accessDeclaredMembers") > >>>>>> > >>>>>> > >>>>>>> On 22 Nov 2016, at 09:43, Langer, Christoph > >>>>>>> > >>>>>> > >>>>>> wrote: > >>>>>>> > >>>>>>> > >>>>>>> Hi Chris, > >>>>>>> > >>>>>>> thanks for this hint. However, we've already seen this change and > >>>>>>> rebuilt > >>>>>> > >>>>>> jtreg with the latest jtreg repo. But it doesn't change a thing. > >>>>>>> > >>>>>>> > >>>>>>> Also, the download from https://adopt- > >>>>>> > >>>>>> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ > >>>>>> where I > >>>>>> would > >>>>>> suppose latest jtreg sources were used, don't help. > >>>>>>> > >>>>>>> > >>>>>>> Am I missing something? > >>>>>> > >>>>>> > >>>>>> Is it possible to post, or upload to cr.o.j.n, the jtr of the failing > >>>>>> test? > >>>>>> > >>>>>> -Chris. > >>>>>> > >>>>>>> Best regards > >>>>>>> Christoph > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > >>>>>>>> Sent: Dienstag, 22. November 2016 10:08 > >>>>>>>> To: Langer, Christoph > >>>>>>>> Cc: core-libs-dev at openjdk.java.net; > >>>>>>>> code-tools-dev at openjdk.java.net; > >>>>>>>> jtreg- > >>>>>>>> use at openjdk.java.net > >>>>>>>> Subject: Re: Issues running JAXP jtreg tests > >>>>>>>> ("java.lang.RuntimePermission" > >>>>>>>> "accessDeclaredMembers") > >>>>>>>> > >>>>>>>> Hi Christoph, > >>>>>>>> > >>>>>>>> Can you please ensure that your build of jtreg contains the fix for > >>>>>>>> 7901792 > >>>>>> > >>>>>> [1]. > >>>>>>>> > >>>>>>>> 7901792 grants /lib/testng.jar all permissions. > >>>>>>>> > >>>>>>>> -Chris. > >>>>>>>> > >>>>>>>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 > >>>>>>>> > >>>>>>>>> On 22 Nov 2016, at 08:38, Langer, Christoph > >>>>>>>>> > >>>>>>>> > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> I'm currently struggling while running jtreg tests for the jaxp > >>>>>>>>> depot. > >>>>>>>>> > >>>>>>>>> There are several tests that fail with the same symptom. I > >>>>>>>>> always get > >>>>>>>> > >>>>>>>> exceptions like: > >>>>>>>>> > >>>>>>>>> java.security.AccessControlException: access denied > >>>>>>>> > >>>>>>>> ("java.lang.RuntimePermission" "accessDeclaredMembers") > >>>>>>>>> > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > java.base/java.security.AccessControlContext.checkPermission(AccessControlCo > >>>>>> > >>>>>>>> > >>>>>>>> ntext.java:471) > >>>>>>>>> > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > java.base/java.security.AccessController.checkPermission(AccessController.java > >>>>>> > >>>>>>>> > >>>>>>>> :894) > >>>>>>>>> > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 > >>>>>> > >>>>>>>> > >>>>>>>> 48) > >>>>>>>>> > >>>>>>>>> at > >>>>>>>>> java.base/java.lang.Class.checkMemberAccess(Class.java:2595) > >>>>>>>>> at > >>>>>>>>> java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) > >>>>>>>>> at > >>>>>> > >>>>>> org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) > >>>>>>>>> > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > >>>>>>>> > org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) > >>>>>>>> > >>>>>>>>> > >>>>>>>>> at > >>>>>> > >>>>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:323) > >>>>>>>>> > >>>>>>>>> at > >>>>>> > >>>>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:259) > >>>>>>>>> > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > org.testng.internal.Parameters.handleParameters(Parameters.java:419) > >>>>>>>> > >>>>>>>>> > >>>>>>>>> at > >>>>>>>>> org.testng.internal.Invoker.handleParameters(Invoker.java:1274) > >>>>>>>>> at > >>>>>>>>> org.testng.internal.Invoker.createParameters(Invoker.java:989) > >>>>>>>>> at > >>>>>>>>> org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > >>>>>> > org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. > >>>>>> > >>>>>>>> > >>>>>>>> java:129) > >>>>>>>>> > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) > >>>>>>>>> > >>>>>>>>> at org.testng.TestRunner.privateRun(TestRunner.java:782) > >>>>>>>>> at org.testng.TestRunner.run(TestRunner.java:632) > >>>>>>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) > >>>>>>>>> at > >>>>>>>>> org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) > >>>>>>>>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) > >>>>>>>>> at org.testng.SuiteRunner.run(SuiteRunner.java:268) > >>>>>>>>> at > >>>>>>>>> > org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > >>>>>>>>> at > >>>>>>>>> org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > >>>>>>>>> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244) > >>>>>>>>> at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) > >>>>>>>>> at org.testng.TestNG.run(TestNG.java:1064) > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: > >>>>>> > >>>>>>>> > >>>>>>>> 224) > >>>>>>>>> > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: > >>>>>> > >>>>>>>> > >>>>>>>> 188) > >>>>>>>>> > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > >>>>>>>> > >>>>>>>> Method) > >>>>>>>>> > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod > >>>>>> > >>>>>>>> > >>>>>>>> AccessorImpl.java:62) > >>>>>>>>> > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin > >>>>>> > >>>>>>>> > >>>>>>>> gMethodAccessorImpl.java:43) > >>>>>>>>> > >>>>>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:537) > >>>>>>>>> at > >>>>>>>> > >>>>>>>> > >>>>>> > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j > >>>>>> > >>>>>>>> > >>>>>>>> ava:110) > >>>>>>>>> > >>>>>>>>> at java.base/java.lang.Thread.run(Thread.java:844) > >>>>>>>>> > >>>>>>>>> For instance the test > >>>>>>>> > >>>>>>>> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like > >>>>>>>> this. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> It's calling "testng -DrunSecMngr=true" and obviously some > >>>>>>>>> important > >>>>>>>> > >>>>>>>> permission for testing is missing with that. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I'm using most current jtreg (with testng-6.9.10.jar) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks for any help. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Best regards > >>>>>>>>> Christoph > >>>>>>> > >>>>>>> > >>>>> > >>>> > >> > > From daniel.fuchs at oracle.com Tue Nov 22 13:31:47 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 22 Nov 2016 13:31:47 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> Message-ID: On 22/11/16 13:01, Langer, Christoph wrote: > Hi, > > we are running jtreg with something like -jdk:/images/jdk. So would that be the exploded version or not? Yes - that's the image. Hmm... The failures I see with the exploded build are different than what you have anyway. > FWIW: I think all test that fail don't have void test methods but the test methods expect input parameters and hence a tag @Test(dataProvider = "...") exists. Good observation. > Can it be that we are using a testng framework that is "too new" and maybe contains something which makes it not work in the jaxp scenario? When I call jtreg -version it reports: TestNG: version 6.9.5 This seems different to what you are using. Can you try with https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/jtreg-4.2-b03.tar.gz without altering the version of testng? I had no problem running the tests with that version of testng (except if I use the exploded build). Maybe the listener that the test uses to set up the security manager is invoked in a different way (earlier?) with the 6.9.10 version? best regards, -- daniel > > Best, > Christoph > >> -----Original Message----- >> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com] >> Sent: Dienstag, 22. November 2016 13:42 >> To: Volker Simonis ; Langer, Christoph >> ; Langer, Christoph >> Cc: Chris Hegarty ; code-tools- >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- >> use at openjdk.java.net >> Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" >> "accessDeclaredMembers") >> >> Hi guys, >> >> Are you running the tests with the exploded jdk or with the image? >> >> I'm seeing failures with the exploded jdk. >> >> That could explain the difference with permission checks. >> >> best regards, >> >> -- daniel >> >> >> On 22/11/16 12:32, Daniel Fuchs wrote: >>> Hi Volker, >>> >>> On 22/11/16 12:25, Chris Hegarty wrote: >>>> Volker, >>>> >>>> Just to add, jtreg has support in its tags to start the test VM with a >>>> security manager and a specified policy. In the case of the test failure >>>> you are seeing, the built-in jtreg support is not being used. Instead, >>>> the test is executing with a test-specific system property that is being >>>> used to trigger the programatic setting of a security manager with a >>>> generated policy. I think this explains why you are not seeing any >>>> policy file in the JTwork directory. >>>> >>>> What is odd is that the stack trace you are seeing appears to be >>>> before the test?s main entry point, so I would not expect to the >>>> security manager to be active at this point ( since no test code >>>> has run ). My previous comment regarding 7901792 is not relevant >>>> since it relates to tests executing with a security manager set >>>> through jtreg tags. >>> >>> I agree with Chris - I believe CODETOOLS-7901792 was a red herring. >>> I'm going to try the jtreg you pointed at and see if there's any >>> difference (I'm using jtreg 4.2 fcs b03). >>> >>>> Is there anything in the environment that could trigger the VM >>>> to start up with a security manager enabled? >>> >>> This is a good question. >>> >>> best regards, >>> >>> -- daniel >>> >>>> >>>> -Chris. >>>> >>>>> On 22 Nov 2016, at 12:13, Volker Simonis >>>>> wrote: >>>>> >>>>> Hi Daniel, >>>>> >>>>> thanks for your support - this problem really drives us crazy! >>>>> >>>>> What version of jtreg are you using? >>>>> If you are using a central one which was configured and build by >>>>> Oracle, could you please also try with the one from >>>>> https://adopt- >> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ >>>>> >>>>> ? >>>>> >>>>> Where can we find the generated policy files? It seems they get >>>>> deleted during test post-run cleanup phase (at least I could not find >>>>> any of them under JTwork). Is there a way to get a more detailed trace >>>>> on how JTreg executes testng and to leave all the generated files in >>>>> place after the test? >>>>> >>>>> I'm currently running the following JAXP test and get the same error >>>>> as described by Christoph: >>>>> >>>>> /tmp/jtreg/bin/jtreg -verbose:summary -jdk >>>>> /output-jdk9-hs-dbg/images/jdk/ >>>>> /OpenJDK/jdk9- >> hs/jaxp/test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.jav >> a >>>>> >>>>> >>>>> What I don't really understand is how this is supposed to work at all, >>>>> because every JAXP test which runs with "-DrunSecMngr=true" will >>>>> execute the following code from JAXPPolicyManager: >>>>> >>>>> /* >>>>> * Install a SecurityManager along with a default Policy to allow >>>>> testNG to >>>>> * run when there is a security manager. >>>>> */ >>>>> private JAXPPolicyManager() { >>>>> // Backing up policy and security manager for restore >>>>> policyBackup = Policy.getPolicy(); >>>>> smBackup = System.getSecurityManager(); >>>>> >>>>> // Set customized policy >>>>> setDefaultPermissions(); >>>>> Policy.setPolicy(policy); >>>>> System.setSecurityManager(new SecurityManager()); >>>>> } >>>>> >>>>> Won't this code override the settings from the policy file which was >>>>> potentially installed by jtreg for testng? >>>>> >>>>> The setDefaultPermissions() sets some special permissions for testng, >>>>> but not "accessDeclaredMembers": >>>>> >>>>> private void setDefaultPermissions() { >>>>> //Permissions to set security manager and policy >>>>> addPermission(new SecurityPermission("getPolicy")); >>>>> addPermission(new SecurityPermission("setPolicy")); >>>>> addPermission(new RuntimePermission("setSecurityManager")); >>>>> //Properties that jtreg and TestNG require >>>>> addPermission(new >>>>> PropertyPermission("testng.show.stack.frames", "read")); >>>>> addPermission(new PropertyPermission("test.src", "read")); >>>>> addPermission(new PropertyPermission("test.classes", "read")); >>>>> addPermission(new >>>>> PropertyPermission("dataproviderthreadcount", "read")); >>>>> addPermission(new PropertyPermission("experimental", "read")); >>>>> } >>>>> >>>>> If I add the line: >>>>> >>>>> addPermission(new RuntimePermission("accessDeclaredMembers")); >>>>> >>>>> to setDefaultPermissions(), the test will succeed. >>>>> >>>>> I saw that an early version of "JDK-8067170: Enable security manager >>>>> on JAXP unit tests" contained that extra permission, but you objected >>>>> (http://mail.openjdk.java.net/pipermail/core-libs-dev/2016- >> July/042520.html) >>>>> >>>>> and it was removed in the final version. >>>>> >>>>> Any more hints? >>>>> >>>>> Thanks, >>>>> Volker >>>>> >>>>> >>>>> On Tue, Nov 22, 2016 at 12:24 PM, Daniel Fuchs >>>>> wrote: >>>>>> Hi Christoph, >>>>>> >>>>>> Is there anything funny with the place jtreg is installed? >>>>>> like: >>>>>> - path contains whitespaces >>>>>> - path is accessible through links or mount points... >>>>>> >>>>>> It seems clear that the issue here is that testng classes are >>>>>> missing some permissions, so I was wondering whether that could >>>>>> be caused by the actual path to testng.jar not matching the >>>>>> path injected in the policy file. >>>>>> >>>>>> I'm using jtreg 4.2 fcs b03, and have no issues with the jaxp tests: >>>>>> >>>>>> $ cd jaxp/tests >>>>>> $ rm -r JT* >>>>>> $ jtreg -verbose:summary -ignore:quiet -jdk >>>>>> ../../build/macosx-x86_64-normal-server-release/images/jdk javax/ >>>>>> >>>>>> => the only test that fails is >>>>>> javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh, but that's >>>>>> expected >>>>>> (it's in the ProblemList.txt). >>>>>> >>>>>> The other thing to take care of, is not to run two jtreg process >>>>>> concurrently if they point to the same JT* directories. If you do >>>>>> that then you might experience weird failures with permissions >>>>>> issues (it seems to mess the policy files). >>>>>> >>>>>> best regards, >>>>>> >>>>>> -- daniel >>>>>> >>>>>> >>>>>> On 22/11/16 10:52, Langer, Christoph wrote: >>>>>>> >>>>>>> Yes, please find it here: >>>>>>> http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>>>>>> Sent: Dienstag, 22. November 2016 11:03 >>>>>>>> To: Langer, Christoph >>>>>>>> Cc: core-libs-dev at openjdk.java.net; code-tools-dev at openjdk.java.net; >>>>>>>> jtreg- >>>>>>>> use at openjdk.java.net >>>>>>>> Subject: Re: Issues running JAXP jtreg tests >>>>>>>> ("java.lang.RuntimePermission" >>>>>>>> "accessDeclaredMembers") >>>>>>>> >>>>>>>> >>>>>>>>> On 22 Nov 2016, at 09:43, Langer, Christoph >>>>>>>>> >>>>>>>> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Chris, >>>>>>>>> >>>>>>>>> thanks for this hint. However, we've already seen this change and >>>>>>>>> rebuilt >>>>>>>> >>>>>>>> jtreg with the latest jtreg repo. But it doesn't change a thing. >>>>>>>>> >>>>>>>>> >>>>>>>>> Also, the download from https://adopt- >>>>>>>> >>>>>>>> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ >>>>>>>> where I >>>>>>>> would >>>>>>>> suppose latest jtreg sources were used, don't help. >>>>>>>>> >>>>>>>>> >>>>>>>>> Am I missing something? >>>>>>>> >>>>>>>> >>>>>>>> Is it possible to post, or upload to cr.o.j.n, the jtr of the failing >>>>>>>> test? >>>>>>>> >>>>>>>> -Chris. >>>>>>>> >>>>>>>>> Best regards >>>>>>>>> Christoph >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>>>>>>>> Sent: Dienstag, 22. November 2016 10:08 >>>>>>>>>> To: Langer, Christoph >>>>>>>>>> Cc: core-libs-dev at openjdk.java.net; >>>>>>>>>> code-tools-dev at openjdk.java.net; >>>>>>>>>> jtreg- >>>>>>>>>> use at openjdk.java.net >>>>>>>>>> Subject: Re: Issues running JAXP jtreg tests >>>>>>>>>> ("java.lang.RuntimePermission" >>>>>>>>>> "accessDeclaredMembers") >>>>>>>>>> >>>>>>>>>> Hi Christoph, >>>>>>>>>> >>>>>>>>>> Can you please ensure that your build of jtreg contains the fix for >>>>>>>>>> 7901792 >>>>>>>> >>>>>>>> [1]. >>>>>>>>>> >>>>>>>>>> 7901792 grants /lib/testng.jar all permissions. >>>>>>>>>> >>>>>>>>>> -Chris. >>>>>>>>>> >>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 >>>>>>>>>> >>>>>>>>>>> On 22 Nov 2016, at 08:38, Langer, Christoph >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I'm currently struggling while running jtreg tests for the jaxp >>>>>>>>>>> depot. >>>>>>>>>>> >>>>>>>>>>> There are several tests that fail with the same symptom. I >>>>>>>>>>> always get >>>>>>>>>> >>>>>>>>>> exceptions like: >>>>>>>>>>> >>>>>>>>>>> java.security.AccessControlException: access denied >>>>>>>>>> >>>>>>>>>> ("java.lang.RuntimePermission" "accessDeclaredMembers") >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >> java.base/java.security.AccessControlContext.checkPermission(AccessControlCo >>>>>>>> >>>>>>>>>> >>>>>>>>>> ntext.java:471) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >> java.base/java.security.AccessController.checkPermission(AccessController.java >>>>>>>> >>>>>>>>>> >>>>>>>>>> :894) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 >>>>>>>> >>>>>>>>>> >>>>>>>>>> 48) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> java.base/java.lang.Class.checkMemberAccess(Class.java:2595) >>>>>>>>>>> at >>>>>>>>>>> java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) >>>>>>>>>>> at >>>>>>>> >>>>>>>> org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >> org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>> >>>>>>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:323) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>> >>>>>>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:259) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >> org.testng.internal.Parameters.handleParameters(Parameters.java:419) >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> org.testng.internal.Invoker.handleParameters(Invoker.java:1274) >>>>>>>>>>> at >>>>>>>>>>> org.testng.internal.Invoker.createParameters(Invoker.java:989) >>>>>>>>>>> at >>>>>>>>>>> org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>> >> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. >>>>>>>> >>>>>>>>>> >>>>>>>>>> java:129) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) >>>>>>>>>>> >>>>>>>>>>> at org.testng.TestRunner.privateRun(TestRunner.java:782) >>>>>>>>>>> at org.testng.TestRunner.run(TestRunner.java:632) >>>>>>>>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) >>>>>>>>>>> at >>>>>>>>>>> org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) >>>>>>>>>>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) >>>>>>>>>>> at org.testng.SuiteRunner.run(SuiteRunner.java:268) >>>>>>>>>>> at >>>>>>>>>>> >> org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) >>>>>>>>>>> at >>>>>>>>>>> org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) >>>>>>>>>>> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244) >>>>>>>>>>> at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) >>>>>>>>>>> at org.testng.TestNG.run(TestNG.java:1064) >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>>>>> >>>>>>>>>> >>>>>>>>>> 224) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>>>>> >>>>>>>>>> >>>>>>>>>> 188) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>>>>> >>>>>>>>>> Method) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod >>>>>>>> >>>>>>>>>> >>>>>>>>>> AccessorImpl.java:62) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin >>>>>>>> >>>>>>>>>> >>>>>>>>>> gMethodAccessorImpl.java:43) >>>>>>>>>>> >>>>>>>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:537) >>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>> >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j >>>>>>>> >>>>>>>>>> >>>>>>>>>> ava:110) >>>>>>>>>>> >>>>>>>>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>>>>>>>> >>>>>>>>>>> For instance the test >>>>>>>>>> >>>>>>>>>> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like >>>>>>>>>> this. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> It's calling "testng -DrunSecMngr=true" and obviously some >>>>>>>>>>> important >>>>>>>>>> >>>>>>>>>> permission for testing is missing with that. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'm using most current jtreg (with testng-6.9.10.jar) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks for any help. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best regards >>>>>>>>>>> Christoph >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >>> > From daniel.fuchs at oracle.com Tue Nov 22 13:34:29 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 22 Nov 2016 13:34:29 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> Message-ID: <2f394e9e-ac3e-5d6f-880b-2a84b55e8a2f@oracle.com> On 22/11/16 13:31, Daniel Fuchs wrote: > On 22/11/16 13:01, Langer, Christoph wrote: >> Hi, >> >> we are running jtreg with something like -jdk:> directory>/images/jdk. So would that be the exploded version or not? > > Yes - that's the image. Hmm... The failures I see with the exploded > build are different than what you have anyway. I mean 'yes that's the image and not the exploded build' The exploded build would be: -jdk:/jdk (sorry for not being clear) -- daniel From daniel.fuchs at oracle.com Tue Nov 22 14:31:26 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 22 Nov 2016 14:31:26 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> Message-ID: <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> Hi, The issue seems to be caused by changes in testng - but maybe that needs to be fixed in the JAXP test base. I could reproduce the issue by running the jaxp tests, after unsetting JT_HOME and running with https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/jtreg-4.2-b03.tar.gz which has testng 6.9.11. When I dowloaded http://mvnrepository.com/artifact/org.testng/testng/6.9.5 and installed it in the jtreg install dir, the issue disappeared. best regards, -- daniel On 22/11/16 13:31, Daniel Fuchs wrote: >> Can it be that we are using a testng framework that is "too new" and >> maybe contains something which makes it not work in the jaxp scenario? > > When I call jtreg -version it reports: > TestNG: version 6.9.5 > > This seems different to what you are using. > Can you try with > https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/jtreg-4.2-b03.tar.gz > > without altering the version of testng? > > I had no problem running the tests with that version > of testng (except if I use the exploded build). > > Maybe the listener that the test uses to set up the security > manager is invoked in a different way (earlier?) with the > 6.9.10 version? From volker.simonis at gmail.com Tue Nov 22 14:31:58 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 22 Nov 2016 15:31:58 +0100 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> Message-ID: On Tue, Nov 22, 2016 at 2:31 PM, Daniel Fuchs wrote: > On 22/11/16 13:01, Langer, Christoph wrote: >> >> Hi, >> >> we are running jtreg with something like -jdk:> directory>/images/jdk. So would that be the exploded version or not? > > > Yes - that's the image. Hmm... The failures I see with the exploded > build are different than what you have anyway. > >> FWIW: I think all test that fail don't have void test methods but the test >> methods expect input parameters and hence a tag @Test(dataProvider = "...") >> exists. > > > Good observation. > >> Can it be that we are using a testng framework that is "too new" and maybe >> contains something which makes it not work in the jaxp scenario? > > > When I call jtreg -version it reports: > TestNG: version 6.9.5 > > This seems different to what you are using. > Can you try with > https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/jtreg-4.2-b03.tar.gz > without altering the version of testng? > > I had no problem running the tests with that version > of testng (except if I use the exploded build). > Sorry, but I can't believe that :) Are you really sure you used exact that version for testing? I'm just asking because I get the same failure with that version as well: /tmp/jtreg/bin/jtreg -version jtreg, version 4.2 dev b03 Installed in /tmp/jtreg/lib/jtreg.jar Running on platform version 1.8.0-internal from /net/usr.work/openjdk/nb/linuxx86_64/last_known_good/output-jdk8/images/j2sdk-image/jre. Built with 1.8.0_60 on 11/21/2016 01:47 PM. Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved. Use is subject to license terms. JCov 2.0-1 TestNG (testng.jar): version 6.9.11 TestNG (jcommander.jar): version unknown /tmp/jtreg/bin/jtreg -verbose:summary -jdk /output-jdk9-hs-dbg/images/jdk/ /OpenJDK/jdk9-hs/jaxp/test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.java FAILED: javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.java Test results: failed: 1 cat JTwork/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.jtr ... javatestVersion=4.6 jtregVersion=jtreg 4.2 dev b03 #section:testng ----------messages:(4/240)---------- command: testng -DrunSecMngr=true catalog.CatalogReferCircularityTest reason: User specified action: run testng/othervm -DrunSecMngr=true catalog.CatalogReferCircularityTest Mode: othervm [/othervm specified] elapsed time (seconds): 4.407 ----------configuration:(0/0)---------- ----------System.out:(46/2950)---------- [TestNG] Running: javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.java test catalog.CatalogReferCircularityTest.testReferCircularity(): skip java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessDeclaredMembers") at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:471) at java.base/java.security.AccessController.checkPermission(AccessController.java:894) at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:548) at java.base/java.lang.Class.checkMemberAccess(Class.java:2595) at java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) at org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) at org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) at org.testng.internal.Parameters.findDataProvider(Parameters.java:323) at org.testng.internal.Parameters.findDataProvider(Parameters.java:259) at org.testng.internal.Parameters.handleParameters(Parameters.java:419) at org.testng.internal.Invoker.handleParameters(Invoker.java:1243) at org.testng.internal.Invoker.createParameters(Invoker.java:992) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1082) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1225) at org.testng.TestNG.runSuitesLocally(TestNG.java:1150) at org.testng.TestNG.runSuites(TestNG.java:1075) at org.testng.TestNG.run(TestNG.java:1047) at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:220) at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:184) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:537) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) > Maybe the listener that the test uses to set up the security > manager is invoked in a different way (earlier?) with the > 6.9.10 version? > I'm pretty sure now that the error is related to the testng version! I've rebuild our local jtreg with testng 9.5 (the same one you're using and the version which is recommended on the "Building jtreg" page at http://openjdk.java.net/jtreg/build.html. Unfortunately, that's not so easy, because testng-6.9.5.jar from maven-central is badly compiled to contain Java 8 classes (i.e. classes with major version 52). But this breaks the jtreg build because it generates (and expects) Java 7 classes. If I set JDK17HOME to point to a Java 8 jdk, the build succeeds and the resulting jtreg (with testng-6.9.5.jar) successfully executes the test mentioned before. Unfortunately we can't use such a version of jtreg with Java 7 anymore :( After I've verified that testng-6.9.5.jar is indeed working, I've also checked with the latest testng-6.9.13.6.jar from maven-central and it still breaks the tests. So somwhere between testng 9.5 and 9.10 testng was changed in a way which breaks some of the testng/jtreg tests. I'm currently investigating if this is a general testng/jdk9 problem or a problem which can be fixed or worked-around in jtreg. @Daniel: can I please kindly ask you to retry your tests with https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/jtreg-4.2-b03.tar.gz and make sure you are really using that version. If you really succeed to successfully execute javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.jtr with that version I would be pretty surprised (and speechless :) Thanks, Volker > best regards, > > -- daniel > > >> >> Best, >> Christoph >> >>> -----Original Message----- >>> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com] >>> Sent: Dienstag, 22. November 2016 13:42 >>> To: Volker Simonis ; Langer, Christoph >>> ; Langer, Christoph >>> Cc: Chris Hegarty ; code-tools- >>> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- >>> use at openjdk.java.net >>> Subject: Re: Issues running JAXP jtreg tests >>> ("java.lang.RuntimePermission" >>> "accessDeclaredMembers") >>> >>> Hi guys, >>> >>> Are you running the tests with the exploded jdk or with the image? >>> >>> I'm seeing failures with the exploded jdk. >>> >>> That could explain the difference with permission checks. >>> >>> best regards, >>> >>> -- daniel >>> >>> >>> On 22/11/16 12:32, Daniel Fuchs wrote: >>>> >>>> Hi Volker, >>>> >>>> On 22/11/16 12:25, Chris Hegarty wrote: >>>>> >>>>> Volker, >>>>> >>>>> Just to add, jtreg has support in its tags to start the test VM with a >>>>> security manager and a specified policy. In the case of the test >>>>> failure >>>>> you are seeing, the built-in jtreg support is not being used. Instead, >>>>> the test is executing with a test-specific system property that is >>>>> being >>>>> used to trigger the programatic setting of a security manager with a >>>>> generated policy. I think this explains why you are not seeing any >>>>> policy file in the JTwork directory. >>>>> >>>>> What is odd is that the stack trace you are seeing appears to be >>>>> before the test?s main entry point, so I would not expect to the >>>>> security manager to be active at this point ( since no test code >>>>> has run ). My previous comment regarding 7901792 is not relevant >>>>> since it relates to tests executing with a security manager set >>>>> through jtreg tags. >>>> >>>> >>>> I agree with Chris - I believe CODETOOLS-7901792 was a red herring. >>>> I'm going to try the jtreg you pointed at and see if there's any >>>> difference (I'm using jtreg 4.2 fcs b03). >>>> >>>>> Is there anything in the environment that could trigger the VM >>>>> to start up with a security manager enabled? >>>> >>>> >>>> This is a good question. >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>>> >>>>> -Chris. >>>>> >>>>>> On 22 Nov 2016, at 12:13, Volker Simonis >>>>>> wrote: >>>>>> >>>>>> Hi Daniel, >>>>>> >>>>>> thanks for your support - this problem really drives us crazy! >>>>>> >>>>>> What version of jtreg are you using? >>>>>> If you are using a central one which was configured and build by >>>>>> Oracle, could you please also try with the one from >>>>>> https://adopt- >>> >>> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ >>>>>> >>>>>> >>>>>> ? >>>>>> >>>>>> Where can we find the generated policy files? It seems they get >>>>>> deleted during test post-run cleanup phase (at least I could not find >>>>>> any of them under JTwork). Is there a way to get a more detailed trace >>>>>> on how JTreg executes testng and to leave all the generated files in >>>>>> place after the test? >>>>>> >>>>>> I'm currently running the following JAXP test and get the same error >>>>>> as described by Christoph: >>>>>> >>>>>> /tmp/jtreg/bin/jtreg -verbose:summary -jdk >>>>>> /output-jdk9-hs-dbg/images/jdk/ >>>>>> /OpenJDK/jdk9- >>> >>> >>> hs/jaxp/test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.jav >>> a >>>>>> >>>>>> >>>>>> >>>>>> What I don't really understand is how this is supposed to work at all, >>>>>> because every JAXP test which runs with "-DrunSecMngr=true" will >>>>>> execute the following code from JAXPPolicyManager: >>>>>> >>>>>> /* >>>>>> * Install a SecurityManager along with a default Policy to allow >>>>>> testNG to >>>>>> * run when there is a security manager. >>>>>> */ >>>>>> private JAXPPolicyManager() { >>>>>> // Backing up policy and security manager for restore >>>>>> policyBackup = Policy.getPolicy(); >>>>>> smBackup = System.getSecurityManager(); >>>>>> >>>>>> // Set customized policy >>>>>> setDefaultPermissions(); >>>>>> Policy.setPolicy(policy); >>>>>> System.setSecurityManager(new SecurityManager()); >>>>>> } >>>>>> >>>>>> Won't this code override the settings from the policy file which was >>>>>> potentially installed by jtreg for testng? >>>>>> >>>>>> The setDefaultPermissions() sets some special permissions for testng, >>>>>> but not "accessDeclaredMembers": >>>>>> >>>>>> private void setDefaultPermissions() { >>>>>> //Permissions to set security manager and policy >>>>>> addPermission(new SecurityPermission("getPolicy")); >>>>>> addPermission(new SecurityPermission("setPolicy")); >>>>>> addPermission(new RuntimePermission("setSecurityManager")); >>>>>> //Properties that jtreg and TestNG require >>>>>> addPermission(new >>>>>> PropertyPermission("testng.show.stack.frames", "read")); >>>>>> addPermission(new PropertyPermission("test.src", "read")); >>>>>> addPermission(new PropertyPermission("test.classes", "read")); >>>>>> addPermission(new >>>>>> PropertyPermission("dataproviderthreadcount", "read")); >>>>>> addPermission(new PropertyPermission("experimental", "read")); >>>>>> } >>>>>> >>>>>> If I add the line: >>>>>> >>>>>> addPermission(new RuntimePermission("accessDeclaredMembers")); >>>>>> >>>>>> to setDefaultPermissions(), the test will succeed. >>>>>> >>>>>> I saw that an early version of "JDK-8067170: Enable security manager >>>>>> on JAXP unit tests" contained that extra permission, but you objected >>>>>> (http://mail.openjdk.java.net/pipermail/core-libs-dev/2016- >>> >>> July/042520.html) >>>>>> >>>>>> >>>>>> and it was removed in the final version. >>>>>> >>>>>> Any more hints? >>>>>> >>>>>> Thanks, >>>>>> Volker >>>>>> >>>>>> >>>>>> On Tue, Nov 22, 2016 at 12:24 PM, Daniel Fuchs >>>>>> wrote: >>>>>>> >>>>>>> Hi Christoph, >>>>>>> >>>>>>> Is there anything funny with the place jtreg is installed? >>>>>>> like: >>>>>>> - path contains whitespaces >>>>>>> - path is accessible through links or mount points... >>>>>>> >>>>>>> It seems clear that the issue here is that testng classes are >>>>>>> missing some permissions, so I was wondering whether that could >>>>>>> be caused by the actual path to testng.jar not matching the >>>>>>> path injected in the policy file. >>>>>>> >>>>>>> I'm using jtreg 4.2 fcs b03, and have no issues with the jaxp tests: >>>>>>> >>>>>>> $ cd jaxp/tests >>>>>>> $ rm -r JT* >>>>>>> $ jtreg -verbose:summary -ignore:quiet -jdk >>>>>>> ../../build/macosx-x86_64-normal-server-release/images/jdk javax/ >>>>>>> >>>>>>> => the only test that fails is >>>>>>> javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh, but that's >>>>>>> expected >>>>>>> (it's in the ProblemList.txt). >>>>>>> >>>>>>> The other thing to take care of, is not to run two jtreg process >>>>>>> concurrently if they point to the same JT* directories. If you do >>>>>>> that then you might experience weird failures with permissions >>>>>>> issues (it seems to mess the policy files). >>>>>>> >>>>>>> best regards, >>>>>>> >>>>>>> -- daniel >>>>>>> >>>>>>> >>>>>>> On 22/11/16 10:52, Langer, Christoph wrote: >>>>>>>> >>>>>>>> >>>>>>>> Yes, please find it here: >>>>>>>> http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>>>>>>> Sent: Dienstag, 22. November 2016 11:03 >>>>>>>>> To: Langer, Christoph >>>>>>>>> Cc: core-libs-dev at openjdk.java.net; >>>>>>>>> code-tools-dev at openjdk.java.net; >>>>>>>>> jtreg- >>>>>>>>> use at openjdk.java.net >>>>>>>>> Subject: Re: Issues running JAXP jtreg tests >>>>>>>>> ("java.lang.RuntimePermission" >>>>>>>>> "accessDeclaredMembers") >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 22 Nov 2016, at 09:43, Langer, Christoph >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Chris, >>>>>>>>>> >>>>>>>>>> thanks for this hint. However, we've already seen this change and >>>>>>>>>> rebuilt >>>>>>>>> >>>>>>>>> >>>>>>>>> jtreg with the latest jtreg repo. But it doesn't change a thing. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Also, the download from https://adopt- >>>>>>>>> >>>>>>>>> >>>>>>>>> openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ >>>>>>>>> where I >>>>>>>>> would >>>>>>>>> suppose latest jtreg sources were used, don't help. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Am I missing something? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Is it possible to post, or upload to cr.o.j.n, the jtr of the >>>>>>>>> failing >>>>>>>>> test? >>>>>>>>> >>>>>>>>> -Chris. >>>>>>>>> >>>>>>>>>> Best regards >>>>>>>>>> Christoph >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>>>>>>>>> Sent: Dienstag, 22. November 2016 10:08 >>>>>>>>>>> To: Langer, Christoph >>>>>>>>>>> Cc: core-libs-dev at openjdk.java.net; >>>>>>>>>>> code-tools-dev at openjdk.java.net; >>>>>>>>>>> jtreg- >>>>>>>>>>> use at openjdk.java.net >>>>>>>>>>> Subject: Re: Issues running JAXP jtreg tests >>>>>>>>>>> ("java.lang.RuntimePermission" >>>>>>>>>>> "accessDeclaredMembers") >>>>>>>>>>> >>>>>>>>>>> Hi Christoph, >>>>>>>>>>> >>>>>>>>>>> Can you please ensure that your build of jtreg contains the fix >>>>>>>>>>> for >>>>>>>>>>> 7901792 >>>>>>>>> >>>>>>>>> >>>>>>>>> [1]. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 7901792 grants /lib/testng.jar all permissions. >>>>>>>>>>> >>>>>>>>>>> -Chris. >>>>>>>>>>> >>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792 >>>>>>>>>>> >>>>>>>>>>>> On 22 Nov 2016, at 08:38, Langer, Christoph >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I'm currently struggling while running jtreg tests for the jaxp >>>>>>>>>>>> depot. >>>>>>>>>>>> >>>>>>>>>>>> There are several tests that fail with the same symptom. I >>>>>>>>>>>> always get >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> exceptions like: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> java.security.AccessControlException: access denied >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ("java.lang.RuntimePermission" "accessDeclaredMembers") >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>> >>> java.base/java.security.AccessControlContext.checkPermission(AccessControlCo >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ntext.java:471) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>> >>> java.base/java.security.AccessController.checkPermission(AccessController.java >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> :894) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>> >>> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5 >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 48) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>>> java.base/java.lang.Class.checkMemberAccess(Class.java:2595) >>>>>>>>>>>> at >>>>>>>>>>>> java.base/java.lang.Class.getDeclaredMethods(Class.java:2162) >>>>>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>> org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:323) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.testng.internal.Parameters.findDataProvider(Parameters.java:259) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>> org.testng.internal.Parameters.handleParameters(Parameters.java:419) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>>> org.testng.internal.Invoker.handleParameters(Invoker.java:1274) >>>>>>>>>>>> at >>>>>>>>>>>> org.testng.internal.Invoker.createParameters(Invoker.java:989) >>>>>>>>>>>> at >>>>>>>>>>>> org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079) >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> java:129) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at org.testng.TestRunner.privateRun(TestRunner.java:782) >>>>>>>>>>>> at org.testng.TestRunner.run(TestRunner.java:632) >>>>>>>>>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) >>>>>>>>>>>> at >>>>>>>>>>>> org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) >>>>>>>>>>>> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) >>>>>>>>>>>> at org.testng.SuiteRunner.run(SuiteRunner.java:268) >>>>>>>>>>>> at >>>>>>>>>>>> >>> org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>>> org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) >>>>>>>>>>>> at >>>>>>>>>>>> org.testng.TestNG.runSuitesSequentially(TestNG.java:1244) >>>>>>>>>>>> at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) >>>>>>>>>>>> at org.testng.TestNG.run(TestNG.java:1064) >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>> >>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 224) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>> >>> com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java: >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 188) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Method) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>> >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> AccessorImpl.java:62) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>> >>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> gMethodAccessorImpl.java:43) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>>> java.base/java.lang.reflect.Method.invoke(Method.java:537) >>>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ava:110) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>>>>>>>>> >>>>>>>>>>>> For instance the test >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails >>>>>>>>>>> like >>>>>>>>>>> this. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> It's calling "testng -DrunSecMngr=true" and obviously some >>>>>>>>>>>> important >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> permission for testing is missing with that. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I'm using most current jtreg (with testng-6.9.10.jar) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks for any help. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Best regards >>>>>>>>>>>> Christoph >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >> > From christoph.langer at sap.com Tue Nov 22 14:43:22 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 22 Nov 2016 14:43:22 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> Message-ID: <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> Hi Daniel, yes - that looks like what we observe, see Volker's mail. It seems to work with testing 6.9.5 but not with 6.9.10 or 6.9.11. So for my jaxp testing I can use 6.9.5, I'm so happy :) But, as for fixing with the new testng, will you look into this? Shall I open a bug? Thanks Christoph > -----Original Message----- > From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com] > Sent: Dienstag, 22. November 2016 15:31 > To: Langer, Christoph ; Volker Simonis > > Cc: code-tools-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- > use at openjdk.java.net > Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > "accessDeclaredMembers") > > Hi, > > The issue seems to be caused by changes in testng - but maybe that > needs to be fixed in the JAXP test base. > > I could reproduce the issue by running the jaxp tests, after > unsetting JT_HOME and running with > https://adopt- > openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/jtreg-4.2- > b03.tar.gz > which has testng 6.9.11. > > When I dowloaded > http://mvnrepository.com/artifact/org.testng/testng/6.9.5 > and installed it in the jtreg install dir, the issue disappeared. > > best regards, > > -- daniel > From joe.darcy at oracle.com Tue Nov 22 14:43:36 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 22 Nov 2016 06:43:36 -0800 Subject: RFR JDK-8170170 Problem list ExternalEditorTest.java on all platforms In-Reply-To: <037601d2449f$4e5be5e0$eb13b1a0$@oracle.com> References: <037601d2449f$4e5be5e0$eb13b1a0$@oracle.com> Message-ID: <311927b1-a9c5-87b8-50dc-6e89e64c8c7c@oracle.com> Hello, Yes, given the failures seen on non-windows platforms too, this test is failing often enough to be universally problem listed. Thanks, -Joe On 11/22/2016 1:03 AM, Frank Yuan wrote: > Hi All > > > > This is a problem list update in langtools repo: > > diff -r f4b6b78a1200 test/ProblemList.txt > > --- a/test/ProblemList.txt Mon Nov 21 12:28:56 2016 -0800 > > +++ b/test/ProblemList.txt Tue Nov 22 16:34:24 2016 +0800 > > @@ -38,7 +38,7 @@ > > jdk/jshell/EditorPadTest.java 8161276 windows-all Test set-up cannot press > buttons > > jdk/jshell/ToolBasicTest.java 8139873 generic-all JShell tests failing > > -jdk/jshell/ExternalEditorTest.java 8170108 windows-all > > +jdk/jshell/ExternalEditorTest.java 8169828 generic-all > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170170 > > > > Anyone would like to have a look? > > > > Thanks > > Frank > From daniel.fuchs at oracle.com Tue Nov 22 14:44:00 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 22 Nov 2016 14:44:00 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> Message-ID: Hi Volker, Our emails crossed each others :-) On 22/11/16 14:31, Volker Simonis wrote: > @Daniel: can I please kindly ask you to retry your tests with > https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/jtreg-4.2-b03.tar.gz > and make sure you are really using that version. If you really succeed > to successfully execute > javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.jtr with > that version I would be pretty surprised (and speechless :) I arrived at the same conclusion. I finally noticed that I had JT_HOME set, which meant that whatever jtreg script I invoked it still linked back to my own install which had 6.9.5. best regards, -- daniel From daniel.fuchs at oracle.com Tue Nov 22 14:47:15 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 22 Nov 2016 14:47:15 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> Message-ID: On 22/11/16 14:43, Langer, Christoph wrote: > But, as for fixing with the new testng, will you look into this? Shall I open a bug? I am unsure on how to fix this actually. The new testng must attempt to load the data provider after having invoked the listener, while the old testng probably did the opposite. Let me try some experiments... best regards, -- daniel From christoph.langer at sap.com Tue Nov 22 14:51:14 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 22 Nov 2016 14:51:14 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> Message-ID: <7b9c0ca9a73c4d03920b87eea1ecab4f@DEWDFE13DE03.global.corp.sap> In that case, if we can't change testng, maybe the jaxp SecurityManager can allow testng to access the declared members without granting this to the testee code? > -----Original Message----- > From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com] > Sent: Dienstag, 22. November 2016 15:47 > To: Langer, Christoph > Cc: code-tools-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- > use at openjdk.java.net; Volker Simonis > Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > "accessDeclaredMembers") > > On 22/11/16 14:43, Langer, Christoph wrote: > > But, as for fixing with the new testng, will you look into this? Shall I open a > bug? > > I am unsure on how to fix this actually. > > The new testng must attempt to load the data provider > after having invoked the listener, while the old testng > probably did the opposite. > > Let me try some experiments... > > best regards, > > -- daniel From daniel.fuchs at oracle.com Tue Nov 22 15:58:59 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 22 Nov 2016 15:58:59 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: <7b9c0ca9a73c4d03920b87eea1ecab4f@DEWDFE13DE03.global.corp.sap> References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> <7b9c0ca9a73c4d03920b87eea1ecab4f@DEWDFE13DE03.global.corp.sap> Message-ID: <604c06b2-9475-029b-4558-ac164980fc80@oracle.com> On 22/11/16 14:51, Langer, Christoph wrote: > In that case, if we can't change testng, maybe the jaxp SecurityManager can allow testng to access the declared members without granting this to the testee code? That's what I was prototyping. The patch below seem to fix the issue - but it's a bit ugly. (note I just tested it with XSLTFunctionsTest - you need to rm -r JT* after applying to the jaxp repo) It might be less ugly if we had a system property set by jtreg to point at /lib - as we could use that to predict the code source location - but I don't think we do. -- daniel diff --git a/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java b/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java --- a/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java +++ b/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java @@ -23,6 +23,7 @@ package jaxp.library; +import java.net.URL; import java.security.CodeSource; import java.security.Permission; import java.security.PermissionCollection; @@ -34,6 +35,7 @@ import java.util.HashMap; import java.util.Map; import java.util.PropertyPermission; +import java.util.Set; import java.util.StringJoiner; @@ -163,6 +165,8 @@ * JAXP concrete classes. */ class TestPolicy extends Policy { + private final static Set TEST_JARS = + Set.of("jtreg.jar", "javatest.jar", "testng.jar"); private final PermissionCollection permissions = new Permissions(); private ThreadLocal> transientPermissions = new ThreadLocal<>(); @@ -221,9 +225,30 @@ if (permissions.implies(perm)) return true; - else + else { + boolean before = allowAll(); + String path = null; + try { + CodeSource cs = (domain == null) ? null : domain.getCodeSource(); + URL loc = (cs == null) ? null : cs.getLocation(); + path = (loc == null) ? null : loc.getPath(); + } finally { + setAllowAll(before); + } + if (path != null && TEST_JARS.stream() + .filter(path::endsWith) + .findAny() + .isPresent()) { + return true; + } else { return tmpImplies(perm); } + } + } + + + /* * Add a temporary permission in current thread context. This won't impact From daniel.fuchs at oracle.com Tue Nov 22 16:24:17 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 22 Nov 2016 16:24:17 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> Message-ID: Hi Christoph, I have logged https://bugs.openjdk.java.net/browse/JDK-8170192 best regards, -- daniel On 22/11/16 14:47, Daniel Fuchs wrote: > On 22/11/16 14:43, Langer, Christoph wrote: >> But, as for fixing with the new testng, will you look into this? Shall >> I open a bug? From andrey.x.nazarov at oracle.com Tue Nov 22 16:29:16 2016 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Tue, 22 Nov 2016 19:29:16 +0300 Subject: [9] RFR: 8170120: Several new jimage testcases should be excluded due to their failures In-Reply-To: <0d57289f-6d88-4c32-981d-f2a4fe97c656@default> References: <0d57289f-6d88-4c32-981d-f2a4fe97c656@default> Message-ID: Hi, Looks OK to me. ?Andrey > On 22 Nov 2016, at 15:51, Denis Kononenko wrote: > > > Hi, > > Could someone please review this small fix. > > Recently several failing test cases were delivered into jdk9-dev by my mistake (https://bugs.openjdk.java.net/browse/JDK-8167240). I've just renamed these test cases to temporarily avoid their execution. They should be renamed back when appropriate fixes for 4 product bugs are delivered. > Also I've fixed testcase JImageVerifyTest.testVerifyNotExistingImage, it contained a regrettable error and duplicated another test case (testVerifyImageNotSpecified). > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170120 > WEBREV: http://cr.openjdk.java.net/~dkononenko/8170120/webrev.00 > > > Now the tests have 100% pass rate. > > JImageListTest: > > Invoking testList > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListHelp > jimage [list, -h] > jimage [list, --help] > Invoking testListVerbose > jimage [list, --verbose, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeAllWithGlob > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, **, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeWithGlob > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, /java.base/java/util/zip/**, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeNoMatchWithGlob > jimage [list, --include, not_matching, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeAllWithExplicitGlob > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, glob:**, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeAllWithRegex > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, regex:.*, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeWithRegex > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, regex:/java.base/java/text/.*, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeNoMatchWithRegex > jimage [list, --include, regex:not_matching, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeMultiplePatterns > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, glob:/java.base/java/time/**,regex:/java.base/java/util/zip/.*, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListNotExistingImage > jimage [list, ./not_existing_image] > Invoking testListWithUnknownOption > jimage [list, --unknown] > STDERR: > STATUS:Passed. > > > JImageExtractTest: > > Invoking testExtract > jimage [extract, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testExtractHelp > jimage [extract, --help] > jimage [extract, --help] > Invoking testExtractToDir > jimage [extract, --dir, ./JImageExtractTest3092688479608335903, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testExtractNotExistingImage > jimage [extract, ./not_existing_image] > Invoking testExtractToUnspecifiedDir > jimage [extract, --dir, --, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testExtractToNotExistingDir > jimage [extract, --dir, ./JImageExtractTest9794403129293432977, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testExtractFromDir > jimage [extract, home/dnk/projects/oracle/jdk-9/lib] > Invoking testExtractToDirBySymlink > jimage [extract, --dir, ./symlink, /home/dnk/projects/oracle/jdk-9/lib/modules] > STDERR: > STATUS:Passed. > > > JImageVerifyTest: > > Invoking testVerify > jimage [verify, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testVerifyHelp > jimage [verify, -h] > jimage [verify, --help] > Invoking testVerifyNotExistingImage > jimage [verify, ./not_existing_image] > Invoking testVerifyWithUnknownOption > jimage [verify, --unknown] > STDERR: > STATUS:Passed. > > Also I need a sponsor to push the change into jdk9-dev. > > Thank you, > Denis. > > From james.laskey at oracle.com Tue Nov 22 16:49:58 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 22 Nov 2016 12:49:58 -0400 Subject: [9] RFR: 8170120: Several new jimage testcases should be excluded due to their failures In-Reply-To: <0d57289f-6d88-4c32-981d-f2a4fe97c656@default> References: <0d57289f-6d88-4c32-981d-f2a4fe97c656@default> Message-ID: <9940A44B-7FA3-4260-BA60-0F9B9837811E@oracle.com> +1 > On Nov 22, 2016, at 8:51 AM, Denis Kononenko wrote: > > > Hi, > > Could someone please review this small fix. > > Recently several failing test cases were delivered into jdk9-dev by my mistake (https://bugs.openjdk.java.net/browse/JDK-8167240). I've just renamed these test cases to temporarily avoid their execution. They should be renamed back when appropriate fixes for 4 product bugs are delivered. > Also I've fixed testcase JImageVerifyTest.testVerifyNotExistingImage, it contained a regrettable error and duplicated another test case (testVerifyImageNotSpecified). > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170120 > WEBREV: http://cr.openjdk.java.net/~dkononenko/8170120/webrev.00 > > > Now the tests have 100% pass rate. > > JImageListTest: > > Invoking testList > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListHelp > jimage [list, -h] > jimage [list, --help] > Invoking testListVerbose > jimage [list, --verbose, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeAllWithGlob > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, **, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeWithGlob > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, /java.base/java/util/zip/**, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeNoMatchWithGlob > jimage [list, --include, not_matching, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeAllWithExplicitGlob > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, glob:**, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeAllWithRegex > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, regex:.*, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeWithRegex > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, regex:/java.base/java/text/.*, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeNoMatchWithRegex > jimage [list, --include, regex:not_matching, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListIncludeMultiplePatterns > jimage [list, /home/dnk/projects/oracle/jdk-9/lib/modules] > jimage [list, --include, glob:/java.base/java/time/**,regex:/java.base/java/util/zip/.*, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testListNotExistingImage > jimage [list, ./not_existing_image] > Invoking testListWithUnknownOption > jimage [list, --unknown] > STDERR: > STATUS:Passed. > > > JImageExtractTest: > > Invoking testExtract > jimage [extract, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testExtractHelp > jimage [extract, --help] > jimage [extract, --help] > Invoking testExtractToDir > jimage [extract, --dir, ./JImageExtractTest3092688479608335903, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testExtractNotExistingImage > jimage [extract, ./not_existing_image] > Invoking testExtractToUnspecifiedDir > jimage [extract, --dir, --, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testExtractToNotExistingDir > jimage [extract, --dir, ./JImageExtractTest9794403129293432977, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testExtractFromDir > jimage [extract, home/dnk/projects/oracle/jdk-9/lib] > Invoking testExtractToDirBySymlink > jimage [extract, --dir, ./symlink, /home/dnk/projects/oracle/jdk-9/lib/modules] > STDERR: > STATUS:Passed. > > > JImageVerifyTest: > > Invoking testVerify > jimage [verify, /home/dnk/projects/oracle/jdk-9/lib/modules] > Invoking testVerifyHelp > jimage [verify, -h] > jimage [verify, --help] > Invoking testVerifyNotExistingImage > jimage [verify, ./not_existing_image] > Invoking testVerifyWithUnknownOption > jimage [verify, --unknown] > STDERR: > STATUS:Passed. > > Also I need a sponsor to push the change into jdk9-dev. > > Thank you, > Denis. > > From paul.sandoz at oracle.com Tue Nov 22 17:26:18 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 22 Nov 2016 09:26:18 -0800 Subject: 8072784: Better spliterator implementation for BitSet.stream() In-Reply-To: References: <1271248255.20161121205903@gmail.com> <84F5CDB7-DB60-4AC9-85C5-67F18EBEA49C@oracle.com> Message-ID: <45EE81A4-072A-45B2-9B08-FB926177428B@oracle.com> > On 21 Nov 2016, at 20:00, Tagir Valeev wrote: > > Hello! > >> Hi Tagir, >> >> In the original issue i was pondering using SIZED for smaller bit sets and non-SIZED for larger bit sets, since we stride over the longs themselves when calculating the size (should be intrinsic to count the set bits, at least on x86). Supporting both is fairly simple, but you are correct not reporting SIZED would simplify things further and it may not matter in practice. >> >> Can you log an issue? I will follow up with some performance analysis. > > Sure, here it is: > https://bugs.openjdk.java.net/browse/JDK-8170159 > Thanks! > Probably it would be optimal not to call cardinality until it's > actually queried. Unfortunately current stream implementation always > queries getExactSizeIfKnown() (passing it into sink.begin()) even if > it's not actually used (which is most of the cases). > The expectation being that if a spliterator reports SIZED then the exact size it can be calculated efficiently, which is not necessarily the case for BitStream. For sequential streams i think you have a point, but for parallel streams the estimated size will also be used for the splitting threshold. (A spliterator cannot report both an estimated size and an exact size.) Paul. From huizhe.wang at oracle.com Tue Nov 22 19:08:26 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 22 Nov 2016 11:08:26 -0800 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: <604c06b2-9475-029b-4558-ac164980fc80@oracle.com> References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> <7b9c0ca9a73c4d03920b87eea1ecab4f@DEWDFE13DE03.global.corp.sap> <604c06b2-9475-029b-4558-ac164980fc80@oracle.com> Message-ID: <583497AA.9040402@oracle.com> Daniel, you're awesome! This could have potentially been a frustration to anyone with a newer testng, as Christoph and Volker have experienced. This issue really needs to be fixed immediately :-) Joe On 11/22/16, 7:58 AM, Daniel Fuchs wrote: > On 22/11/16 14:51, Langer, Christoph wrote: >> In that case, if we can't change testng, maybe the jaxp >> SecurityManager can allow testng to access the declared members >> without granting this to the testee code? > > That's what I was prototyping. > The patch below seem to fix the issue - but it's a bit ugly. > (note I just tested it with XSLTFunctionsTest - you need to > rm -r JT* after applying to the jaxp repo) > > It might be less ugly if we had a system property set > by jtreg to point at /lib - as we could use that > to predict the code source location - but I don't think > we do. > > -- daniel > > diff --git > a/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java > b/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java > --- a/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java > +++ b/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java > @@ -23,6 +23,7 @@ > package jaxp.library; > > > +import java.net.URL; > import java.security.CodeSource; > import java.security.Permission; > import java.security.PermissionCollection; > @@ -34,6 +35,7 @@ > import java.util.HashMap; > import java.util.Map; > import java.util.PropertyPermission; > +import java.util.Set; > import java.util.StringJoiner; > > > @@ -163,6 +165,8 @@ > * JAXP concrete classes. > */ > class TestPolicy extends Policy { > + private final static Set TEST_JARS = > + Set.of("jtreg.jar", "javatest.jar", "testng.jar"); > private final PermissionCollection permissions = new Permissions(); > > private ThreadLocal> > transientPermissions = new ThreadLocal<>(); > @@ -221,9 +225,30 @@ > > if (permissions.implies(perm)) > return true; > - else > + else { > + boolean before = allowAll(); > + String path = null; > + try { > + CodeSource cs = (domain == null) ? null : > domain.getCodeSource(); > + URL loc = (cs == null) ? null : cs.getLocation(); > + path = (loc == null) ? null : loc.getPath(); > + } finally { > + setAllowAll(before); > + } > + if (path != null && TEST_JARS.stream() > + .filter(path::endsWith) > + .findAny() > + .isPresent()) { > + return true; > + } else { > return tmpImplies(perm); > } > + } > + } > + > + > + > > /* > * Add a temporary permission in current thread context. This > won't impact > From huizhe.wang at oracle.com Tue Nov 22 19:11:27 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 22 Nov 2016 11:11:27 -0800 Subject: RFR: 8169631: [JAXP] XALAN: transformation of XML via namespace-unaware SAX input yields a different result than namespace-unaware DOM input In-Reply-To: <582F90D6.1040308@oracle.com> References: <313759790392479fa80a10542ab664ec@dewdfe13de07.global.corp.sap> <582A7170.7030100@oracle.com> <4be5158237814eeb9352fe8fe344e47c@dewdfe13de07.global.corp.sap> <582E8944.7090906@oracle.com> <582F90D6.1040308@oracle.com> Message-ID: <5834985F.4060503@oracle.com> Hi Christoph, Once you're able to run all tests, feel free to push the changeset. Frank has fixed the Smoke test. Thanks, Joe On 11/18/16, 3:37 PM, Joe Wang wrote: > Hi Christoph, > > Thanks for explaining the customer's dilemma with regard to their > legacy process. > > The testcase I sent you was extracted from an internal SQE smoke test. > I agree with your analysis, the 'golden' file which has been in there > for over 10 years turns out to be wrong and needs to be updated. > > To fix this issue, we need to get that test fixed, and the check-in of > your patch and that of the test need needs to happen simultaneously. > Would you mind wanting for me to go through an internal process to get > a patch ready, then we can check in almost at the same time? > > Best, > Joe > > On 11/18/16, 2:51 PM, Langer, Christoph wrote: >> Hi Joe, >> >> thanks for the feedback. >> >> I've now understood the testcase that you've sent over and the reason >> that it is reporting failure after my fix is that the output of its >> transform operation is rather correct now. And before it was wrong. :) >> The test is comparing the actual result to a "golden" result file in >> the end and both of these were not looking healthy so far. The reason >> is that your test is using a namespace unaware SAX Parser as input. >> With the current JDK XALAN, you could already modify your smoketest >> to use a namespace aware parser. >> >> E.g. replace lines >> >> 82 // Use the JAXP way to get an XMLReader >> 83 XMLReader reader = >> SAXParserFactory.newInstance().newSAXParser().getXMLReader(); >> >> with >> >> 82 // Use the JAXP way to get an XMLReader >> 83 SAXParserFactory spf = SAXParserFactory.newInstance(); >> 84 spf.setNamespaceAware(true); >> 85 XMLReader reader = spf.newSAXParser().getXMLReader(); >> >> ...and you would already get correct results that also DOM input or >> Stream Input would yield. >> >> So, are there other concerns/issues with this fix? Do you want me to >> include a transformation operation like the one that your SmokeTest >> does to TransformerTest which would illustrate the problem with >> namespace unaware SAX input data? >> >> Best regards >> Christoph >> >>> -----Original Message----- >>> From: Joe Wang [mailto:huizhe.wang at oracle.com] >>> Sent: Freitag, 18. November 2016 05:53 >>> To: Langer, Christoph >>> Cc: core-libs-dev at openjdk.java.net >>> Subject: Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via >>> namespace-unaware SAX input yields a different result than namespace- >>> unaware DOM input >>> >>> >>> >>> On 11/14/16, 11:43 PM, Langer, Christoph wrote: >>>> Hi Joe, >>>> >>>> thanks for looking. >>>> >>>> Can you let me know which smoke test is failing? I didn't see >>>> issues so far - I >>> was merely running the jtreg unittests for transformer. >>> >>> I sent the test to your mailbox. >>>> I stepped back from replacing Vector with ArrayList for >>>> m_prefixMappings >>> because the code is using methods indexOf() with a start index and >>> setSize() for >>> which ArrayList has no direct matchings. One could, for sure, add >>> some other >>> coding, e.g. use ArrayList's subList() method for the index based >>> search - but I >>> wouldn't want to run the risk of adding a regression here just >>> because I >>> modified the code and did not well test it. But if you insist, I >>> could have another >>> look. >>> >>> Ok, that's fine. subList would do, but setSize may need a bit more >>> work. >>> >>> Best, >>> Joe >>>> Best regards >>>> Christoph >>>> >>>>> -----Original Message----- >>>>> From: Joe Wang [mailto:huizhe.wang at oracle.com] >>>>> Sent: Dienstag, 15. November 2016 03:23 >>>>> To: Langer, Christoph >>>>> Cc: core-libs-dev at openjdk.java.net >>>>> Subject: Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via >>>>> namespace-unaware SAX input yields a different result than namespace- >>>>> unaware DOM input >>>>> >>>>> Hi Christoph, >>>>> >>>>> Not all tests have finished yet, but there's at least one failure >>>>> in the >>>>> smoke test. I'll get to the details when I have time. >>>>> >>>>> Any reason why m_prefixMappings can not be replaced with ArrayList? >>>>> >>>>> Thanks, >>>>> Joe >>>>> >>>>> On 11/14/16, 6:10 AM, Langer, Christoph wrote: >>>>>> Hi, >>>>>> >>>>>> please review this fix for bug 8169631. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8169631 >>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169631.0/ >>>>>> >>>>>> When XALAN is handling namespace unaware input, it behaves >>>>>> differently >>>>> while using SAX input compared to DOM input. >>>>>> With both input source types, the class >>>>> com.sun.org.apache.xml.internal.dtm.ref.sax2dtm.SAX2DTM2 converts SAX >>>>> input into a DTM representation for processing by the XALAN >>>>> transformer. >>> Its >>>>> method startElement takes URI, localname and qName as attribute. >>>>> In case >>> of >>>>> missing feature namespaces, startElement and localname can be empty. >>>>> However, the function uses the localname value for the call to >>>>> m_expandedNameTable.getExpandedTypeID() and further processing. In >>>>> the >>>>> case where only qName has data, this leads to issues. >>>>>> When using DOM input, the class >>>>> com.sun.org.apache.xalan.internal.xsltc.trax.DOM2SAX converts the DOM >>> input >>>>> into SAX input. In the case of empty localname, it fills localname >>>>> with qname >>>>> data. See method getLocalName() [1], called by parse() [2]. >>>>>> When directly using SAX input, the SAX parser calls the >>>>>> startElement() >>>>> function on XALAN's handler with empty uri and localname - which >>>>> seems >>>>> correct, as per the spec. >>>>>> Both paths end up in SAX2DTM2's startElement(). So I suggest to >>>>>> change >>> this >>>>> method to handle the case when uri and localname are empty and >>>>> then set >>>>> qname as localname. Maybe one should even change DOM2SAX's >>>>> getLocalName handling to not fill localname with qname in case it >>>>> is empty >>>>> after SAX2DTM was changed.. >>>>>> Generally, JavaDoc for SAXSource says that "Attempting to >>>>>> transform an >>> input >>>>> source that is not generated with a namespace-aware parser may >>>>> result in >>>>> errors." But why not fix some of these :) >>>>>> Furthermore I did some cleanups in the code. >>>>>> >>>>>> Thanks and best regards >>>>>> Christoph >>>>>> >>>>>> [1] >>> http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/shar >>> >>> e/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l139 >>> >>>>>> [2] >>> http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/shar >>> >>> e/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l279 >>> >>>>>> [3] >>> https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/sax/SAXSource >>> >>>>> .html From paul.sandoz at oracle.com Tue Nov 22 19:15:32 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 22 Nov 2016 11:15:32 -0800 Subject: RFR 8169808 Stream returning methods should specify if they are late binding In-Reply-To: References: <2332D5F4-986E-4936-8665-933E64E5E6DE@oracle.com> Message-ID: Hi Tagir, Yes, it applies to all implementations. I think the risk of incompatibility is low for 9. Based on analysis on grepcode most CharSequence implementations don?t override the stream returning methods, those few that do defer to some other sequence. Paul. > On 21 Nov 2016, at 19:44, Tagir Valeev wrote: > > Hello! > > >> diff -r a11577c64a1d src/java.base/share/classes/java/lang/CharSequence.java >> --- a/src/java.base/share/classes/java/lang/CharSequence.java Mon Nov 21 10:50:01 2016 -0800 >> +++ b/src/java.base/share/classes/java/lang/CharSequence.java Mon Nov 21 12:17:08 2016 -0800 >> @@ -121,8 +121,11 @@ >> * href="{@docRoot}/java/lang/Character.html#unicode">surrogate code >> * point is passed through uninterpreted. >> * >> - *

      If the sequence is mutated while the stream is being read, the >> - * result is undefined. >> + *

      The stream binds to this sequence when the terminal stream operation >> + * commences. If the sequence is modified during that operation then the >> + * result is undefined. (Specifically, for mutable sequences the >> + * spliterator for the stream is >> + * late-binding.) > > As this an interface method with default implementation, I think, it should be > clear whether this states a method contract for all implementors or an > implementation detail of > the default implementation. Here it's not in the @implNote section, so > I assume that the new statement > tightens the specification for all possible implementors (probably > making valid Java-8 code invalid in Java-9 > if somebody reimplemented chars() for custom CharSequence in > non-late-binding manner). > Is this spec change intended? > > With best regards, > Tagir Valeev. From volker.simonis at gmail.com Tue Nov 22 19:24:41 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 22 Nov 2016 20:24:41 +0100 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> Message-ID: Hi Daniel, thanks for your patch! I've meanwhile tried to better understand the root cause of the problem. I don't think that the invocation order of the data provider the listener have changed. If you look at the the two version 6.9.5 and 6.9.13 of testng, the org.testng.TestRunner.run() methods look exactly the same in both 6.9.5 [1] and 6.9.13 [2]: public void run() { beforeRun(); try { XmlTest test= getTest(); if(test.isJUnit()) { privateRunJUnit(test); } else { privateRun(test); } } finally { afterRun(); } I think the problem is in org.testng.internal.ClassHelper.getAvailableMethods() where we testng only collected the methods until (i.e. excluding) java.lang.Object in 6.9.5 [3] but including java.lang.Object in 6.9.13 [4]: 6.9.5 ===== public static Set getAvailableMethods(Class clazz) { Set methods = Sets.newHashSet(); methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); Class parent = clazz.getSuperclass(); while (Object.class != parent) { methods.addAll(extractMethods(clazz, parent, methods)); parent = parent.getSuperclass(); } 6.9.13 ===== public static Set getAvailableMethods(Class clazz) { Set methods = Sets.newHashSet(); methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); Class parent = clazz.getSuperclass(); while (null != parent) { methods.addAll(extractMethods(clazz, parent, methods)); parent = parent.getSuperclass(); } But java.lang.Object has a different class loader (null) compared to the test class (which is loaded by the application class loader), which leads to the AccessControlException with 6.9.13. As far as I can see, this was changed in testng 6.9.10 [5] to fix https://github.com/cbeust/testng/issues/876 This behavior may potentially also affect other tests which are running with a security manger so I'm not sure you fix will help for all of them. And I also wonder why this hasn't been detected by other who run testng with a security manager (but maybe nobody is doing that :) Regards, Volker [1] https://github.com/cbeust/testng/blob/testng-6.9.5/src/main/java/org/testng/TestRunner.java [2] https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/TestRunner.java [3] https://github.com/cbeust/testng/blob/testng-6.9.5/src/main/java/org/testng/internal/ClassHelper.java [4] https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/internal/ClassHelper.java [5] https://github.com/cbeust/testng/pull/886/commits/fefedec34706e40ff2bf780bff7716fca29daaab On Tue, Nov 22, 2016 at 5:24 PM, Daniel Fuchs wrote: > Hi Christoph, > > I have logged https://bugs.openjdk.java.net/browse/JDK-8170192 > > best regards, > > -- daniel > > > On 22/11/16 14:47, Daniel Fuchs wrote: >> >> On 22/11/16 14:43, Langer, Christoph wrote: >>> >>> But, as for fixing with the new testng, will you look into this? Shall >>> I open a bug? > > From volker.simonis at gmail.com Tue Nov 22 19:27:43 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 22 Nov 2016 20:27:43 +0100 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: <583497AA.9040402@oracle.com> References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> <7b9c0ca9a73c4d03920b87eea1ecab4f@DEWDFE13DE03.global.corp.sap> <604c06b2-9475-029b-4558-ac164980fc80@oracle.com> <583497AA.9040402@oracle.com> Message-ID: On Tue, Nov 22, 2016 at 8:08 PM, Joe Wang wrote: > Daniel, you're awesome! This could have potentially been a frustration to > anyone with a newer testng, as Christoph and Volker have experienced. This > issue really needs to be fixed immediately :-) > And Oracle should try to use the same tools versions as the community :) As mentioned earlier in this thread, nobody can currently build jtreg with testng 6.9.5 as described on the jtreg page :( > Joe > > > On 11/22/16, 7:58 AM, Daniel Fuchs wrote: >> >> On 22/11/16 14:51, Langer, Christoph wrote: >>> >>> In that case, if we can't change testng, maybe the jaxp SecurityManager >>> can allow testng to access the declared members without granting this to the >>> testee code? >> >> >> That's what I was prototyping. >> The patch below seem to fix the issue - but it's a bit ugly. >> (note I just tested it with XSLTFunctionsTest - you need to >> rm -r JT* after applying to the jaxp repo) >> >> It might be less ugly if we had a system property set >> by jtreg to point at /lib - as we could use that >> to predict the code source location - but I don't think >> we do. >> >> -- daniel >> >> diff --git a/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java >> b/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java >> --- a/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java >> +++ b/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java >> @@ -23,6 +23,7 @@ >> package jaxp.library; >> >> >> +import java.net.URL; >> import java.security.CodeSource; >> import java.security.Permission; >> import java.security.PermissionCollection; >> @@ -34,6 +35,7 @@ >> import java.util.HashMap; >> import java.util.Map; >> import java.util.PropertyPermission; >> +import java.util.Set; >> import java.util.StringJoiner; >> >> >> @@ -163,6 +165,8 @@ >> * JAXP concrete classes. >> */ >> class TestPolicy extends Policy { >> + private final static Set TEST_JARS = >> + Set.of("jtreg.jar", "javatest.jar", "testng.jar"); >> private final PermissionCollection permissions = new Permissions(); >> >> private ThreadLocal> transientPermissions = >> new ThreadLocal<>(); >> @@ -221,9 +225,30 @@ >> >> if (permissions.implies(perm)) >> return true; >> - else >> + else { >> + boolean before = allowAll(); >> + String path = null; >> + try { >> + CodeSource cs = (domain == null) ? null : >> domain.getCodeSource(); >> + URL loc = (cs == null) ? null : cs.getLocation(); >> + path = (loc == null) ? null : loc.getPath(); >> + } finally { >> + setAllowAll(before); >> + } >> + if (path != null && TEST_JARS.stream() >> + .filter(path::endsWith) >> + .findAny() >> + .isPresent()) { >> + return true; >> + } else { >> return tmpImplies(perm); >> } >> + } >> + } >> + >> + >> + >> >> /* >> * Add a temporary permission in current thread context. This won't >> impact >> > From christoph.langer at sap.com Tue Nov 22 19:50:30 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 22 Nov 2016 19:50:30 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> Message-ID: <2df3195f1faf474dbd8593c2af8e50bf@DEWDFE13DE03.global.corp.sap> Thanks a lot Volker and Daniel for the big support to analyze and fix this. It seems to me that the proposed fix (http://cr.openjdk.java.net/~dfuchs/webrev_8170192/webrev.00/ ) looks like the best that can be done at the moment. I agree that it would be nicer if jtreg would leave the jtreg lib path as java property to be able to elevate all of its contents. But the current proposal with a set of TEST_JARS of jtreg, javatest and testng is probably sufficient for jaxp testing. The best thing to find out about other issues with the new version of testng would certainly be if Oracle's internal version of jtreg be updated to use the latest testng :-) Best regards Christoph > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Dienstag, 22. November 2016 20:25 > To: Daniel Fuchs > Cc: Langer, Christoph ; code-tools- > dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- > use at openjdk.java.net > Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > "accessDeclaredMembers") > > Hi Daniel, > > thanks for your patch! > > I've meanwhile tried to better understand the root cause of the problem. > > I don't think that the invocation order of the data provider the > listener have changed. If you look at the the two version 6.9.5 and > 6.9.13 of testng, the org.testng.TestRunner.run() methods look exactly > the same in both 6.9.5 [1] and 6.9.13 [2]: > > public void run() { > beforeRun(); > > try { > XmlTest test= getTest(); > if(test.isJUnit()) { > privateRunJUnit(test); > } > else { > privateRun(test); > } > } > finally { > afterRun(); > } > > I think the problem is in > org.testng.internal.ClassHelper.getAvailableMethods() where we testng > only collected the methods until (i.e. excluding) java.lang.Object in > 6.9.5 [3] but including java.lang.Object in 6.9.13 [4]: > > 6.9.5 > ===== > public static Set getAvailableMethods(Class clazz) { > Set methods = Sets.newHashSet(); > methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); > > Class parent = clazz.getSuperclass(); > while (Object.class != parent) { > methods.addAll(extractMethods(clazz, parent, methods)); > parent = parent.getSuperclass(); > } > > 6.9.13 > ===== > public static Set getAvailableMethods(Class clazz) { > Set methods = Sets.newHashSet(); > methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); > > Class parent = clazz.getSuperclass(); > while (null != parent) { > methods.addAll(extractMethods(clazz, parent, methods)); > parent = parent.getSuperclass(); > } > > But java.lang.Object has a different class loader (null) compared to > the test class (which is loaded by the application class loader), > which leads to the AccessControlException with 6.9.13. > > As far as I can see, this was changed in testng 6.9.10 [5] to fix > https://github.com/cbeust/testng/issues/876 > > This behavior may potentially also affect other tests which are > running with a security manger so I'm not sure you fix will help for > all of them. And I also wonder why this hasn't been detected by other > who run testng with a security manager (but maybe nobody is doing that > :) > > Regards, > Volker > > [1] https://github.com/cbeust/testng/blob/testng- > 6.9.5/src/main/java/org/testng/TestRunner.java > [2] > https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/TestRu > nner.java > [3] https://github.com/cbeust/testng/blob/testng- > 6.9.5/src/main/java/org/testng/internal/ClassHelper.java > [4] > https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/interna > l/ClassHelper.java > [5] > https://github.com/cbeust/testng/pull/886/commits/fefedec34706e40ff2bf780b > ff7716fca29daaab > > > On Tue, Nov 22, 2016 at 5:24 PM, Daniel Fuchs > wrote: > > Hi Christoph, > > > > I have logged https://bugs.openjdk.java.net/browse/JDK-8170192 > > > > best regards, > > > > -- daniel > > > > > > On 22/11/16 14:47, Daniel Fuchs wrote: > >> > >> On 22/11/16 14:43, Langer, Christoph wrote: > >>> > >>> But, as for fixing with the new testng, will you look into this? Shall > >>> I open a bug? > > > > From roger.riggs at oracle.com Tue Nov 22 21:23:05 2016 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 22 Nov 2016 16:23:05 -0500 Subject: RFR 9: 8169416: SSLSessionImpl finalize overhead Message-ID: <5711d4dc-cfe8-c901-1623-0866163e0824@oracle.com> Please review this change to remove an ineffective finalizer for SSLSessions. The finalizer removes bindings from the SSLSession of a table that is also freed when the SSLSession is being freed. There is no point in removing them explicitly. It only delays freeing memory and increases the overhead due to the tracking of finalizable objects. Details are in the issue. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-ssl-finalize-8169416 Issue: https://bugs.openjdk.java.net/browse/JDK-8169416 Thanks, Roger From christoph.langer at sap.com Tue Nov 22 21:26:42 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 22 Nov 2016 21:26:42 +0000 Subject: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE In-Reply-To: <582F8D4E.6020902@oracle.com> References: <582EA144.2000601@oracle.com> <667b95e296fb48809485a685394c5730@DEWDFE13DE03.global.corp.sap> <582F4FBD.3030208@oracle.com> <9fe8c952061c4cf490ab3419fadf70f2@DEWDFE13DE03.global.corp.sap> <582F8D4E.6020902@oracle.com> Message-ID: Hi Joe, as my jtreg issues are solved now, I'm finalizing the patches. For this one I've updated the test method: http://cr.openjdk.java.net/~clanger/webrevs/8169772.2/ Could you please quickly check if my new test method "testBug8169772()" looks as you want it? I've added some more detailed comments for the method. The point is that without the fix you'd encounter an NPE. Or should there be some special assertion around it? If it's ok for you, I'd push tomorrow. Thanks & Best regards Christoph From: Joe Wang [mailto:huizhe.wang at oracle.com] Sent: Samstag, 19. November 2016 00:23 To: Langer, Christoph Cc: core-libs-dev at openjdk.java.net Subject: Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE On 11/18/16, 12:17 PM, Langer, Christoph wrote: Hi Joe, Yep, I'll conduct the testing before pushing. With the "Expected Result", you mean some comment for the test method, right? Yes, some comment for the test method would do. But I see that you've added assertions? That would be even better. Comments help in this case since without the patch, the process would have thrown an NPE. Once a bug is fixed, SQE will take the new test and verify the fix. Knowing the success/fail (before and after fix) conditions is helpful for them. Thanks, Joe Thanks Christoph From: Joe Wang [mailto:huizhe.wang at oracle.com] Sent: Freitag, 18. November 2016 20:00 To: Langer, Christoph Cc: core-libs-dev at openjdk.java.net Subject: Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE Looks good, Christoph. I assume you'll do an all-test run (all in jaxp/test) before pushing. No need for further review, but it'd be nice to add an "Expected result" for the new test testBug8169772, with/without the fix (e.g. NPE). Best regards, Joe On 11/18/16, 4:38 AM, Langer, Christoph wrote: Hi Joe, thanks for the feedback. I've created a new version of the webrev working in your suggestions, adding some further formatting cleanups in the files and I also moved a small refactoring in TransformerTest.java to this changeset. http://cr.openjdk.java.net/~clanger/webrevs/8169772.1/ >From my end this one is ready for pushing - waiting for your final go. Best regards Christoph From: Joe Wang [mailto:huizhe.wang at oracle.com] Sent: Freitag, 18. November 2016 07:36 To: Langer, Christoph Cc: core-libs-dev at openjdk.java.net Subject: Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE Looks fine. License header: in general, don't change / add Year if there's no material change, removing the legacy $Id field in EmptySerializer.java for example, does not constitute a change to the code, so just keep the original year (see below). The initial years for the classes: EmptySerializer.java 2012 SerializerBase.java 2012 ToSAXHandler.java none (meaning if you make changes to this class, just add 2016) ToStream.java 2006 ToUnknownStream.java 2007 XSLOutputAttributes.java none (so keep the original "DO NOT REMOVE OR ALTER!" block) Thanks, Joe On 11/16/16, 6:22 AM, Langer, Christoph wrote: Hi, please review another XALAN fix. The Serializer should be able to handle text nodes with null input. There has already been some discussion here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044567.html Bug: https://bugs.openjdk.java.net/browse/JDK-8169772 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169772.0/ The actual fix is in ToUnknownStream.java, method "public void characters(String chars) throws SAXException". I don't know if one should even directly return after chars being null or of size() 0. The rest of this change is cleanups and a test case. Thanks for reviewing. Best regards Christoph From Roger.Riggs at Oracle.com Tue Nov 22 21:41:54 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 22 Nov 2016 16:41:54 -0500 Subject: RFR 9: 8169416: SSLSessionImpl finalize overhead In-Reply-To: <5711d4dc-cfe8-c901-1623-0866163e0824@oracle.com> References: <5711d4dc-cfe8-c901-1623-0866163e0824@oracle.com> Message-ID: <5e1e84bf-4f10-1f23-5d36-55d441c1dad1@Oracle.com> Adding security-dev... Please review this change to remove an ineffective finalizer for SSLSessions. The finalizer removes bindings from the SSLSession of a table that is also freed when the SSLSession is being freed. There is no point in removing them explicitly. It only delays freeing memory and increases the overhead due to the tracking of finalizable objects. Details are in the issue. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-ssl-finalize-8169416 Issue: https://bugs.openjdk.java.net/browse/JDK-8169416 Thanks, Roger > From brian.burkhalter at oracle.com Tue Nov 22 21:45:44 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 22 Nov 2016 13:45:44 -0800 Subject: RFR 9: 8169416: SSLSessionImpl finalize overhead In-Reply-To: <5711d4dc-cfe8-c901-1623-0866163e0824@oracle.com> References: <5711d4dc-cfe8-c901-1623-0866163e0824@oracle.com> Message-ID: Hi Roger, I think this looks OK. Brian On Nov 22, 2016, at 1:23 PM, Roger Riggs wrote: > Please review this change to remove an ineffective finalizer for SSLSessions. > The finalizer removes bindings from the SSLSession of a table that is also > freed when the SSLSession is being freed. There is no point in removing them explicitly. > It only delays freeing memory and increases the overhead due to the tracking > of finalizable objects. Details are in the issue. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-ssl-finalize-8169416 > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8169416 > > Thanks, Roger From huizhe.wang at oracle.com Tue Nov 22 22:01:47 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 22 Nov 2016 14:01:47 -0800 Subject: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE In-Reply-To: References: <582EA144.2000601@oracle.com> <667b95e296fb48809485a685394c5730@DEWDFE13DE03.global.corp.sap> <582F4FBD.3030208@oracle.com> <9fe8c952061c4cf490ab3419fadf70f2@DEWDFE13DE03.global.corp.sap> <582F8D4E.6020902@oracle.com> Message-ID: <5834C04B.4090705@oracle.com> Hi Christoph, That looks good to me. Best, Joe On 11/22/16, 1:26 PM, Langer, Christoph wrote: > > Hi Joe, > > as my jtreg issues are solved now, I'm finalizing the patches. > > For this one I've updated the test method: > http://cr.openjdk.java.net/~clanger/webrevs/8169772.2/ > > > Could you please quickly check if my new test method > "testBug8169772()" looks as you want it? I've added some more detailed > comments for the method. The point is that without the fix you'd > encounter an NPE. Or should there be some special assertion around it? > > If it's ok for you, I'd push tomorrow. > > Thanks & Best regards > > Christoph > > *From:*Joe Wang [mailto:huizhe.wang at oracle.com] > *Sent:* Samstag, 19. November 2016 00:23 > *To:* Langer, Christoph > *Cc:* core-libs-dev at openjdk.java.net > *Subject:* Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with > null valued text node causes NPE > > > > On 11/18/16, 12:17 PM, Langer, Christoph wrote: > > Hi Joe, > > Yep, I'll conduct the testing before pushing. > > With the "Expected Result", you mean some comment for the test > method, right? > > > Yes, some comment for the test method would do. But I see that you've > added assertions? That would be even better. Comments help in this > case since without the patch, the process would have thrown an NPE. > > Once a bug is fixed, SQE will take the new test and verify the fix. > Knowing the success/fail (before and after fix) conditions is helpful > for them. > > Thanks, > Joe > > > Thanks > > Christoph > > *From:*Joe Wang [mailto:huizhe.wang at oracle.com] > *Sent:* Freitag, 18. November 2016 20:00 > *To:* Langer, Christoph > > *Cc:* core-libs-dev at openjdk.java.net > > *Subject:* Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM > with null valued text node causes NPE > > Looks good, Christoph. > > I assume you'll do an all-test run (all in jaxp/test) before > pushing. No need for further review, but it'd be nice to add an > "Expected result" for the new test testBug8169772, with/without > the fix (e.g. NPE). > > Best regards, > Joe > > On 11/18/16, 4:38 AM, Langer, Christoph wrote: > > Hi Joe, > > thanks for the feedback. > > I've created a new version of the webrev working in your > suggestions, adding some further formatting cleanups in the > files and I also moved a small refactoring in > TransformerTest.java to this changeset. > > http://cr.openjdk.java.net/~clanger/webrevs/8169772.1/ > > > From my end this one is ready for pushing -- waiting for your > final go. > > Best regards > > Christoph > > *From:*Joe Wang [mailto:huizhe.wang at oracle.com] > *Sent:* Freitag, 18. November 2016 07:36 > *To:* Langer, Christoph > > *Cc:* core-libs-dev at openjdk.java.net > > *Subject:* Re: RFR: 8169772: [JAXP] XALAN: Transformation of > DOM with null valued text node causes NPE > > Looks fine. > > License header: in general, don't change / add Year if there's > no material change, removing the legacy $Id field in > EmptySerializer.java for example, does not constitute a change > to the code, so just keep the original year (see below). > > The initial years for the classes: > EmptySerializer.java 2012 > SerializerBase.java 2012 > ToSAXHandler.java none (meaning if you make > changes to this class, just add 2016) > ToStream.java 2006 > ToUnknownStream.java 2007 > XSLOutputAttributes.java none (so keep the > original "DO NOT REMOVE OR ALTER!" block) > > Thanks, > Joe > > On 11/16/16, 6:22 AM, Langer, Christoph wrote: > > Hi, > > > > please review another XALAN fix. > > > > The Serializer should be able to handle text nodes with null input. There has already been some discussion here:http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044567.html > > > > Bug:https://bugs.openjdk.java.net/browse/JDK-8169772 > > Webrev:http://cr.openjdk.java.net/~clanger/webrevs/8169772.0/ > > > > The actual fix is in ToUnknownStream.java, method "public void characters(String chars) throws SAXException". I don't know if one should even directly return after chars being null or of size() 0. The rest of this change is cleanups and a test case. > > > > Thanks for reviewing. > > > > Best regards > > Christoph > > > From martinrb at google.com Tue Nov 22 23:14:59 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 22 Nov 2016 15:14:59 -0800 Subject: RFR 8169808 Stream returning methods should specify if they are late binding In-Reply-To: References: <2332D5F4-986E-4936-8665-933E64E5E6DE@oracle.com> Message-ID: Hmmm.... I've finally read the Spliterator spec. I now accept that late-binding by definition does not apply to CONCURRENT sources. Iteration is in any case a little weird for concurrent collections, but I think the fundamental principle, beyond the weak consistency guarantees, is to always return elements as long as any are available, at least until the first time there are none AND that fact has been returned to the user. So existing concurrent implementations should act in "late-binding style", because it's the best behavior for users. In some cases (ConcurrentLinkedQueue ?) it may even be best to keep on returning new elements even after; e.g. if tryAdvance fails, then a new element becomes available, another tryAdvance may succeed. Maybe in jdk 10. On Mon, Nov 21, 2016 at 3:23 PM, Paul Sandoz wrote: > > > On 21 Nov 2016, at 14:19, Martin Buchholz wrote: > > > > > > > > On Mon, Nov 21, 2016 at 1:06 PM, Paul Sandoz > wrote: > > > > > The CONCURRENT Spliterators in j.u.c. do not document late-binding, > but probably they should, given the implementation effort we've already > done to make it so. > > > > > > > Late-binding really only applies to spliterators not reporting IMMUTABLE > or CONCURRENT. What did you have in mind? > > > > > > j.u.c. Spliterators like in ConcurrentLinkedDeque ... > > > > https://bugs.openjdk.java.net/browse/JDK-8169739? > focusedCommentId=14022987&page=com.atlassian.jira. > plugin.system.issuetabpanels:comment-tabpanel#comment-14022987 > > > > ... have extra complexity to support the idea that they are never surely > exhausted when created, even if the collection happens to have no elements > at that point. I was hoping you would have opinions on that (I gave up on > making that change). > > > > Ah, i missed that, sorry. (I believe writing an @ in a > comment will notify more explicitly in email.) > > At the moment late-binding and CONCURRENT are mutually exclusive (see the > full definition below). > > On the specification of Spliterator.CONCURRENT there is this api note: > > * @apiNote Most concurrent collections maintain a consistency policy > * guaranteeing accuracy with respect to elements present at the point of > * Spliterator construction, but possibly not reflecting subsequent > * additions or removals. > > In this case i think you could specify a "consistency policy" that if > LinkedBlockingDeque is empty on spliterator construction then the > spliterator covers no elements and does not reflect subsequent additions or > removals. But as you say it would be a change in current behaviour and > unless there is a sufficient improvement it would not be worth the change. > > > > We make an effort to provide this behavior, but we don't promise it to > our users! > > > > Interesting case. > > > > Let's look at the definition: > > """A late-binding Spliterator binds to the source of elements at the > point of first traversal ...""" > > That applies equally well to concurrent and non-concurrent spliterators! > > Why don't we specify late-binding for those concurrent spliterators that > in fact implement it, or abandon implementing it? > > > > Here is the complete definition, which is currently focused on mutable > non-concurrent sources: > > *

      A Spliterator that does not report {@code > IMMUTABLE} or > * {@code CONCURRENT} is expected to have a documented policy concerning: > * when the spliterator binds to the element source; and detection > of > * structural interference of the element source detected after > binding. A > * late-binding Spliterator binds to the source of elements at the > * point of first traversal, first split, or first query for estimated size, > * rather than at the time the Spliterator is created. A Spliterator that > is > * not late-binding binds to the source of elements at the point of > * construction or first invocation of any method. Modifications made to > the > * source prior to binding are reflected when the Spliterator is traversed. > * After binding a Spliterator should, on a best-effort basis, throw > * {@link ConcurrentModificationException} if structural interference is > * detected. Spliterators that do this are called fail-fast. The > * bulk traversal method ({@link #forEachRemaining forEachRemaining()}) of a > * Spliterator may optimize traversal and check for structural interference > * after all elements have been traversed, rather than checking per-element > and > * failing immediately. > > Paul. > > > From paul.sandoz at oracle.com Tue Nov 22 23:54:29 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 22 Nov 2016 15:54:29 -0800 Subject: RFR 8169808 Stream returning methods should specify if they are late binding In-Reply-To: References: <2332D5F4-986E-4936-8665-933E64E5E6DE@oracle.com> Message-ID: <8E6DDA66-3BFA-470E-BD49-E91A2F1ADA0B@oracle.com> > On 22 Nov 2016, at 15:14, Martin Buchholz wrote: > > Hmmm.... I've finally read the Spliterator spec. I now accept that late-binding by definition does not apply to CONCURRENT sources. Iteration is in any case a little weird for concurrent collections, but I think the fundamental principle, beyond the weak consistency guarantees, is to always return elements as long as any are available, at least until the first time there are none AND that fact has been returned to the user. So existing concurrent implementations should act in "late-binding style", because it's the best behavior for users. Agreed. > In some cases (ConcurrentLinkedQueue ?) it may even be best to keep on returning new elements even after; e.g. if tryAdvance fails, then a new element becomes available, another tryAdvance may succeed. Maybe in jdk 10. > I suppose there is a solution in such cases, but you might not like it: get new instance of the spliterator or iterator. Spliterator.tryAdvance is specified to give such wiggle room, perhaps unintentionally or foreseeing such a use case? I suspect the former, testing wise we have interpreted returning false as always returning false on subsequent calls, and so do the Iterators wrapping Spliterators. Paul. > On Mon, Nov 21, 2016 at 3:23 PM, Paul Sandoz > wrote: > > > On 21 Nov 2016, at 14:19, Martin Buchholz > wrote: > > > > > > > > On Mon, Nov 21, 2016 at 1:06 PM, Paul Sandoz > wrote: > > > > > The CONCURRENT Spliterators in j.u.c. do not document late-binding, but probably they should, given the implementation effort we've already done to make it so. > > > > > > > Late-binding really only applies to spliterators not reporting IMMUTABLE or CONCURRENT. What did you have in mind? > > > > > > j.u.c. Spliterators like in ConcurrentLinkedDeque ... > > > > https://bugs.openjdk.java.net/browse/JDK-8169739?focusedCommentId=14022987&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14022987 > > > > ... have extra complexity to support the idea that they are never surely exhausted when created, even if the collection happens to have no elements at that point. I was hoping you would have opinions on that (I gave up on making that change). > > > > Ah, i missed that, sorry. (I believe writing an @ in a comment will notify more explicitly in email.) > > At the moment late-binding and CONCURRENT are mutually exclusive (see the full definition below). > > On the specification of Spliterator.CONCURRENT there is this api note: > > * @apiNote Most concurrent collections maintain a consistency policy > * guaranteeing accuracy with respect to elements present at the point of > * Spliterator construction, but possibly not reflecting subsequent > * additions or removals. > > In this case i think you could specify a "consistency policy" that if LinkedBlockingDeque is empty on spliterator construction then the spliterator covers no elements and does not reflect subsequent additions or removals. But as you say it would be a change in current behaviour and unless there is a sufficient improvement it would not be worth the change. > > > > We make an effort to provide this behavior, but we don't promise it to our users! > > > > Interesting case. > > > > Let's look at the definition: > > """A late-binding Spliterator binds to the source of elements at the point of first traversal ...""" > > That applies equally well to concurrent and non-concurrent spliterators! > > Why don't we specify late-binding for those concurrent spliterators that in fact implement it, or abandon implementing it? > > > > Here is the complete definition, which is currently focused on mutable non-concurrent sources: > > *

      A Spliterator that does not report {@code IMMUTABLE} or > * {@code CONCURRENT} is expected to have a documented policy concerning: > * when the spliterator binds to the element source; and detection of > * structural interference of the element source detected after binding. A > * late-binding Spliterator binds to the source of elements at the > * point of first traversal, first split, or first query for estimated size, > * rather than at the time the Spliterator is created. A Spliterator that is > * not late-binding binds to the source of elements at the point of > * construction or first invocation of any method. Modifications made to the > * source prior to binding are reflected when the Spliterator is traversed. > * After binding a Spliterator should, on a best-effort basis, throw > * {@link ConcurrentModificationException} if structural interference is > * detected. Spliterators that do this are called fail-fast. The > * bulk traversal method ({@link #forEachRemaining forEachRemaining()}) of a > * Spliterator may optimize traversal and check for structural interference > * after all elements have been traversed, rather than checking per-element and > * failing immediately. > > Paul. > > > From Xuelei.Fan at Oracle.Com Wed Nov 23 00:21:32 2016 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Wed, 23 Nov 2016 08:21:32 +0800 Subject: RFR 9: 8169416: SSLSessionImpl finalize overhead In-Reply-To: <5e1e84bf-4f10-1f23-5d36-55d441c1dad1@Oracle.com> References: <5711d4dc-cfe8-c901-1623-0866163e0824@oracle.com> <5e1e84bf-4f10-1f23-5d36-55d441c1dad1@Oracle.com> Message-ID: <414AD697-091E-4F82-B17F-9B101D39858B@Oracle.Com> Looks fine to me. Thanks, Xuelei > On 23 Nov 2016, at 5:41 AM, Roger Riggs wrote: > > Adding security-dev... > > Please review this change to remove an ineffective finalizer for SSLSessions. > The finalizer removes bindings from the SSLSession of a table that is also > freed when the SSLSession is being freed. There is no point in removing them explicitly. > It only delays freeing memory and increases the overhead due to the tracking > of finalizable objects. Details are in the issue. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-ssl-finalize-8169416 > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8169416 > > Thanks, Roger >> > From martinrb at google.com Wed Nov 23 00:24:05 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 22 Nov 2016 16:24:05 -0800 Subject: RFR 8169808 Stream returning methods should specify if they are late binding In-Reply-To: References: <2332D5F4-986E-4936-8665-933E64E5E6DE@oracle.com> Message-ID: On Mon, Nov 21, 2016 at 1:06 PM, Paul Sandoz wrote: > > See the SpliteratorLateBindingFailFastTest. That could be refactored out > as it?s conflating two concepts and is too collection/map focused. > Here's my own attempt, for the pending jsr166 integration: --- src/test/tck/Collection8Test.java 22 Nov 2016 01:08:14 -0000 1.29 +++ src/test/tck/Collection8Test.java 23 Nov 2016 00:20:43 -0000 @@ -606,6 +606,39 @@ assertNull(future.get(0L, MILLISECONDS)); } + /** + * Spliterators are either IMMUTABLE or truly late-binding or, if + * concurrent, use the same "late-binding style" of returning + * elements added between creation and first use. + */ + public void testLateBinding() throws Throwable { + if (!testImplementationDetails) return; + // Immutable (snapshot) spliterators are exempt + if (impl.emptyCollection().spliterator() + .hasCharacteristics(Spliterator.IMMUTABLE)) + return; + final Object one = impl.makeElement(1); + { + final Collection c = impl.emptyCollection(); + final Spliterator split = c.spliterator(); + c.add(one); + assertTrue(split.tryAdvance(e -> { assertSame(e, one); })); + assertFalse(split.tryAdvance(e -> { throw new AssertionError(); })); + assertTrue(c.contains(one)); + } + { + final AtomicLong count = new AtomicLong(0); + final Collection c = impl.emptyCollection(); + final Spliterator split = c.spliterator(); + c.add(one); + split.forEachRemaining( + e -> { assertSame(e, one); count.getAndIncrement(); }); + assertEquals(1L, count.get()); + assertFalse(split.tryAdvance(e -> { throw new AssertionError(); })); + assertTrue(c.contains(one)); + } + } + From martinrb at google.com Wed Nov 23 01:21:40 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 22 Nov 2016 17:21:40 -0800 Subject: RFR 8169808 Stream returning methods should specify if they are late binding In-Reply-To: References: <2332D5F4-986E-4936-8665-933E64E5E6DE@oracle.com> Message-ID: On Tue, Nov 22, 2016 at 4:24 PM, Martin Buchholz wrote: > > > On Mon, Nov 21, 2016 at 1:06 PM, Paul Sandoz > wrote: > >> >> See the SpliteratorLateBindingFailFastTest. That could be refactored out >> as it?s conflating two concepts and is too collection/map focused. > > I took a look at that test, and saw that ArrayDeque doesn't get tested there because it's less predictable at throwing CME. ArrayDeque expends fewer resources on catching concurrent modification than classes with a modCount, and that's my own preference as well. From martinrb at google.com Wed Nov 23 01:33:02 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 22 Nov 2016 17:33:02 -0800 Subject: RFR 8169808 Stream returning methods should specify if they are late binding In-Reply-To: References: <2332D5F4-986E-4936-8665-933E64E5E6DE@oracle.com> Message-ID: PriorityBlockingQueue has a late-binding-style, snapshot spliterator that does not report IMMUTABLE. It *is* immutable ... after the first access! Should we add IMMUTABLE? From felix.yang at oracle.com Wed Nov 23 03:38:39 2016 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 23 Nov 2016 11:38:39 +0800 Subject: RFR 8170249/9, Problem list jdk/jshell/ToolFormatTest.java and jdk/jshell/ReplaceTest.java until 8170216 is fixed Message-ID: Hi there, please review the change to problem following tests on Soalris Sparcv9. They have been observed to be failing quite frequently on Solaris Sparcv9 Thanks, Felix diff -r 318dd5fce0ee test/ProblemList.txt --- a/test/ProblemList.txt Tue Nov 22 16:31:03 2016 -0800 +++ b/test/ProblemList.txt Tue Nov 22 19:20:36 2016 -0800 @@ -39,6 +39,8 @@ jdk/jshell/EditorPadTest.java 8161276 windows-all Test set-up cannot press buttons jdk/jshell/ToolBasicTest.java 8139873 generic-all JShell tests failing jdk/jshell/ExternalEditorTest.java 8170108 generic-all +jdk/jshell/ToolFormatTest.java 8170216 solaris-sparcv9 +jdk/jshell/ReplaceTest.java 8170216 solaris-sparcv9 ########################################################################### # From joe.darcy at oracle.com Wed Nov 23 04:05:18 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 22 Nov 2016 20:05:18 -0800 Subject: RFR 8170249/9, Problem list jdk/jshell/ToolFormatTest.java and jdk/jshell/ReplaceTest.java until 8170216 is fixed In-Reply-To: References: Message-ID: <67ee5fd1-4979-157c-4caf-9127b812943f@oracle.com> +1 Thanks, -Joe On 11/22/2016 7:38 PM, Felix Yang wrote: > Hi there, > > please review the change to problem following tests on Soalris > Sparcv9. They have been observed to be failing quite frequently on > Solaris Sparcv9 > > Thanks, > > Felix > > > diff -r 318dd5fce0ee test/ProblemList.txt > --- a/test/ProblemList.txt Tue Nov 22 16:31:03 2016 -0800 > +++ b/test/ProblemList.txt Tue Nov 22 19:20:36 2016 -0800 > @@ -39,6 +39,8 @@ > jdk/jshell/EditorPadTest.java 8161276 windows-all Test set-up > cannot press buttons > jdk/jshell/ToolBasicTest.java 8139873 generic-all JShell tests > failing > jdk/jshell/ExternalEditorTest.java 8170108 generic-all > +jdk/jshell/ToolFormatTest.java 8170216 solaris-sparcv9 > +jdk/jshell/ReplaceTest.java 8170216 solaris-sparcv9 > > ########################################################################### > > # > From frank.yuan at oracle.com Wed Nov 23 04:41:10 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Wed, 23 Nov 2016 12:41:10 +0800 Subject: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions to jtreg, javatest, and testng jars Message-ID: <02f901d24543$d2b37f70$781a7e50$@oracle.com> Hi All Would you like to review http://cr.openjdk.java.net/~fyuan/8170192/webrev.00/? Bug: https://bugs.openjdk.java.net/browse/JDK-8170192 This patch is fully same as Daniel provided except a few lines of additional cleaning, thanks to Daniel for providing the patch! Thanks Frank From felix.yang at oracle.com Wed Nov 23 05:15:06 2016 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 23 Nov 2016 13:15:06 +0800 Subject: RFR 8170248, Problem list javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java Message-ID: Hi, this test fails frequently on Linux platforms. I suggest to exclude it until JDK-8169737 is fixed. Thanks, Felix diff -r 67d3235a317f test/ProblemList.txt --- a/test/ProblemList.txt Wed Nov 23 10:12:01 2016 +0800 +++ b/test/ProblemList.txt Tue Nov 22 20:44:56 2016 -0800 @@ -305,5 +305,6 @@ # jdk_other com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8141370 linux-i586,macosx-all +javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 8170248 linux-all ############################################################################ From felix.yang at oracle.com Wed Nov 23 05:17:39 2016 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 23 Nov 2016 13:17:39 +0800 Subject: RFR 8170248, Problem list javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java In-Reply-To: References: Message-ID: <7d9e23d5-2787-17ae-0159-e04d15d5f1ff@oracle.com> Excuse me, On 2016/11/23 13:15, Felix Yang wrote: > Hi, > > this test fails frequently on Linux platforms. I suggest to exclude > it until JDK-8169737 is fixed. > > Thanks, > > Felix > > > Corrected diff: diff -r 67d3235a317f test/ProblemList.txt --- a/test/ProblemList.txt Wed Nov 23 10:12:01 2016 +0800 +++ b/test/ProblemList.txt Tue Nov 22 21:04:46 2016 -0800 @@ -305,5 +305,6 @@ # jdk_other com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8141370 linux-i586,macosx-all +javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 8169737 linux-all ############################################################################ From frank.yuan at oracle.com Wed Nov 23 05:26:05 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Wed, 23 Nov 2016 13:26:05 +0800 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: <2df3195f1faf474dbd8593c2af8e50bf@DEWDFE13DE03.global.corp.sap> References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> <2df3195f1faf474dbd! 8593c2af8e50bf@DEWDFE13 DE03.global.corp.sap> Message-ID: <030901d2454a$18c955b0$4a5c0110$@oracle.com> Hi Christoph and Volker I have been launching jdk and langtools tests with the new jtreg, will update to you once I get the result. Hope jaxp test is special because most of tests should control the Security Manager setting inside the test methods. Thanks Frank > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Langer, Christoph > Sent: Wednesday, November 23, 2016 3:51 AM > Subject: RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") > > Thanks a lot Volker and Daniel for the big support to analyze and fix this. > > It seems to me that the proposed fix > (http://cr.openjdk.java.net/~dfuchs/webrev_8170192/webrev.00/ ) looks like > the best that can be done at the moment. I agree that it would be nicer if > jtreg would leave the jtreg lib path as java property to be able to elevate > all of its contents. But the current proposal with a set of TEST_JARS of > jtreg, javatest and testng is probably sufficient for jaxp testing. > > The best thing to find out about other issues with the new version of testng > would certainly be if Oracle's internal version of jtreg be updated to use > the latest testng :-) > > Best regards > Christoph > > > > > -----Original Message----- > > From: Volker Simonis [mailto:volker.simonis at gmail.com] > > Sent: Dienstag, 22. November 2016 20:25 > > To: Daniel Fuchs > > Cc: Langer, Christoph ; code-tools- > > dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- > > use at openjdk.java.net > > Subject: Re: Issues running JAXP jtreg tests > > ("java.lang.RuntimePermission" > > "accessDeclaredMembers") > > > > Hi Daniel, > > > > thanks for your patch! > > > > I've meanwhile tried to better understand the root cause of the problem. > > > > I don't think that the invocation order of the data provider the > > listener have changed. If you look at the the two version 6.9.5 and > > 6.9.13 of testng, the org.testng.TestRunner.run() methods look exactly > > the same in both 6.9.5 [1] and 6.9.13 [2]: > > > > public void run() { > > beforeRun(); > > > > try { > > XmlTest test= getTest(); > > if(test.isJUnit()) { > > privateRunJUnit(test); > > } > > else { > > privateRun(test); > > } > > } > > finally { > > afterRun(); > > } > > > > I think the problem is in > > org.testng.internal.ClassHelper.getAvailableMethods() where we testng > > only collected the methods until (i.e. excluding) java.lang.Object in > > 6.9.5 [3] but including java.lang.Object in 6.9.13 [4]: > > > > 6.9.5 > > ===== > > public static Set getAvailableMethods(Class clazz) { > > Set methods = Sets.newHashSet(); > > methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); > > > > Class parent = clazz.getSuperclass(); > > while (Object.class != parent) { > > methods.addAll(extractMethods(clazz, parent, methods)); > > parent = parent.getSuperclass(); > > } > > > > 6.9.13 > > ===== > > public static Set getAvailableMethods(Class clazz) { > > Set methods = Sets.newHashSet(); > > methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); > > > > Class parent = clazz.getSuperclass(); > > while (null != parent) { > > methods.addAll(extractMethods(clazz, parent, methods)); > > parent = parent.getSuperclass(); > > } > > > > But java.lang.Object has a different class loader (null) compared to > > the test class (which is loaded by the application class loader), > > which leads to the AccessControlException with 6.9.13. > > > > As far as I can see, this was changed in testng 6.9.10 [5] to fix > > https://github.com/cbeust/testng/issues/876 > > > > This behavior may potentially also affect other tests which are > > running with a security manger so I'm not sure you fix will help for > > all of them. And I also wonder why this hasn't been detected by other > > who run testng with a security manager (but maybe nobody is doing that > > :) > > > > Regards, > > Volker > > > > [1] https://github.com/cbeust/testng/blob/testng- > > 6.9.5/src/main/java/org/testng/TestRunner.java > > [2] > > https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/TestRu > > nner.java > > [3] https://github.com/cbeust/testng/blob/testng- > > 6.9.5/src/main/java/org/testng/internal/ClassHelper.java > > [4] > > https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/interna > > l/ClassHelper.java > > [5] > > https://github.com/cbeust/testng/pull/886/commits/fefedec34706e40ff2bf780b > > ff7716fca29daaab > > > > > > On Tue, Nov 22, 2016 at 5:24 PM, Daniel Fuchs > > wrote: > > > Hi Christoph, > > > > > > I have logged https://bugs.openjdk.java.net/browse/JDK-8170192 > > > > > > best regards, > > > > > > -- daniel > > > > > > > > > On 22/11/16 14:47, Daniel Fuchs wrote: > > >> > > >> On 22/11/16 14:43, Langer, Christoph wrote: > > >>> > > >>> But, as for fixing with the new testng, will you look into this? Shall > > >>> I open a bug? > > > > > > From sha.jiang at oracle.com Wed Nov 23 05:49:13 2016 From: sha.jiang at oracle.com (John Jiang) Date: Wed, 23 Nov 2016 13:49:13 +0800 Subject: RFR[9] JDK-8158916: ProblemList.txt update for com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java In-Reply-To: <212fd806-b85d-cf3b-2065-4766ec773753@oracle.com> References: <59dc7e57-3d05-6395-abdc-a0677b487fbb@oracle.com> <0988590c-7530-8470-3b74-56a2a8c3e744@oracle.com> <7e02a877-a014-a8a6-d69e-40320aae53ae@oracle.com> <212fd806-b85d-cf3b-2065-4766ec773753@oracle.com> Message-ID: <08b1838e-4541-57b3-36ca-0f0cb98ab578@oracle.com> Hi Daniel, I'll push the below patch: diff -r 5cd2aa3f3e9b test/ProblemList.txt --- a/test/ProblemList.txt Tue Nov 22 10:45:48 2016 -0800 +++ b/test/ProblemList.txt Tue Nov 22 21:34:47 2016 -0800 @@ -305,6 +305,6 @@ # jdk_other -com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8141370 linux-i586,macosx-all +com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8169942 linux-i586,macosx-all,windows-x64 ############################################################################ Best regards, John Jiang On 2016/11/18 18:03, Daniel Fuchs wrote: > Hi John, > > Looks good to me. Should windows-amd64 also be listed? > It appears the test also failing there (JDK-8152654) > > best regards, > > -- daniel > > On 18/11/16 06:02, John Jiang wrote: >> Hi, >> Track this test issue with a new JBS bug JDK-8169942. >> Please take a look at the updated webrew: >> http://cr.openjdk.java.net/~jjiang/8158916/webrev.01/, or the below, >> >> --- old/test/ProblemList.txt 2016-11-17 21:29:12.112822913 -0800 >> +++ new/test/ProblemList.txt 2016-11-17 21:29:11.964822915 -0800 >> @@ -298,6 +298,6 @@ >> >> # jdk_other >> >> -com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8141370 >> linux-i586,macosx-all >> +com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8169942 >> linux-i586,macosx-all >> >> ############################################################################ >> >> >> >> Best regards, >> John Jiang >> >> >> On 2016/11/8 18:53, Daniel Fuchs wrote: >>> Hi John, >>> >>> On 08/11/16 01:30, John Jiang wrote: >>>> Hi Daniel, >>>> Thanks for your comments. >>>> >>>> On 2016/11/7 19:21, Daniel Fuchs wrote: >>>>> Hi John, >>>>> >>>>> Maybe you should reach out to Rob who fixed JDK-8141370 to >>>>> make sure this is the right thing to do. >>>> just cc Rob Mckenna >>>> >>>>> >>>>> It seems the exclusion on problematic platforms [1] was deliberate: >>>>> >>>>>> Basically I've separated the failing subtest out into its own >>>>>> file and >>>>>> excluded it on the (intermittently) failing platforms. >>>> I see. But it should use an open issue. >>>> I would like to open a new issue to track this issue. But I don't get >>>> the exact failure log on DeadSSLLdapTimeoutTest.java, though the >>>> failure >>>> may still be related to SSLHandshakeException. >>>> When this test was born, it was in the ProblemList, so I suppose it >>>> has >>>> no chance to be executed by our automatic testing systems. >>> >>> I see. I agree it's better to have an open bug in the ProblemList. >>> But I am concerned if that bug is something that we never intend to >>> fix because the test is not appropriate for those platforms. >>> >>> best regards, >>> >>> -- daniel >>> >>>> >>>> Best regards, >>>> John Jiang >>>> >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>>> >>>>> [1] >>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037385.html >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 07/11/16 02:37, John Jiang wrote: >>>>>> Hi, >>>>>> com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java is associated to >>>>>> 8141370 >>>>>> in ProblemList, though issue JDK-8141370 has been resolved. >>>>>> In fact, the fix for JDK-8141370 extracted some codes from >>>>>> com/sun/jndi/ldap/LdapTimeoutTest.java to create >>>>>> com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java, and put the new >>>>>> test to >>>>>> ProblemList. >>>>>> It would be better to remove this item from ProblemList. If >>>>>> com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java still fails >>>>>> intermittently, we can put it back to ProblemList with the exact >>>>>> failure >>>>>> logs. >>>>>> >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8158916 >>>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8158916/webrev.00/ >>>>>> >>>>>> Best regards, >>>>>> John Jiang >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From christoph.langer at sap.com Wed Nov 23 07:40:57 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 23 Nov 2016 07:40:57 +0000 Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") In-Reply-To: <030901d2454a$18c955b0$4a5c0110$@oracle.com> References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap> <31232031-06F6-40E4-B0D2-7EB765D0B25E@oracle.com> <32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com> <45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap> <3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com> <26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap> <2df3195f1faf474dbd! 8593c2af8e50bf@DEWDFE13 DE03.global.corp.sap> <030901d2454a$18c955b0$4a5c0110$@oracle.com> Message-ID: <762c837a843e4b99bffae8e3f3e6d4b0@DEWDFE13DE03.global.corp.sap> Thanks, Frank. we run scheduled jtreg tests for jdk every night so we should have encountered issues if there were some. But langtools could be interesting, I don't think those run automatically for OpenJDK in our environment. Best regards Christoph > -----Original Message----- > From: Frank Yuan [mailto:frank.yuan at oracle.com] > Sent: Mittwoch, 23. November 2016 06:26 > To: Langer, Christoph ; 'Volker Simonis' > ; 'Daniel Fuchs' > Cc: code-tools-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- > use at openjdk.java.net > Subject: RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > "accessDeclaredMembers") > > Hi Christoph and Volker > > I have been launching jdk and langtools tests with the new jtreg, will update to > you once I get the result. > Hope jaxp test is special because most of tests should control the Security > Manager setting inside the test methods. > > Thanks > Frank > > > > > -----Original Message----- > > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf Of Langer, Christoph > > Sent: Wednesday, November 23, 2016 3:51 AM > > Subject: RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > "accessDeclaredMembers") > > > > Thanks a lot Volker and Daniel for the big support to analyze and fix this. > > > > It seems to me that the proposed fix > > (http://cr.openjdk.java.net/~dfuchs/webrev_8170192/webrev.00/ ) looks like > > the best that can be done at the moment. I agree that it would be nicer if > > jtreg would leave the jtreg lib path as java property to be able to elevate > > all of its contents. But the current proposal with a set of TEST_JARS of > > jtreg, javatest and testng is probably sufficient for jaxp testing. > > > > The best thing to find out about other issues with the new version of testng > > would certainly be if Oracle's internal version of jtreg be updated to use > > the latest testng :-) > > > > Best regards > > Christoph > > > > > > > > > -----Original Message----- > > > From: Volker Simonis [mailto:volker.simonis at gmail.com] > > > Sent: Dienstag, 22. November 2016 20:25 > > > To: Daniel Fuchs > > > Cc: Langer, Christoph ; code-tools- > > > dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- > > > use at openjdk.java.net > > > Subject: Re: Issues running JAXP jtreg tests > > > ("java.lang.RuntimePermission" > > > "accessDeclaredMembers") > > > > > > Hi Daniel, > > > > > > thanks for your patch! > > > > > > I've meanwhile tried to better understand the root cause of the problem. > > > > > > I don't think that the invocation order of the data provider the > > > listener have changed. If you look at the the two version 6.9.5 and > > > 6.9.13 of testng, the org.testng.TestRunner.run() methods look exactly > > > the same in both 6.9.5 [1] and 6.9.13 [2]: > > > > > > public void run() { > > > beforeRun(); > > > > > > try { > > > XmlTest test= getTest(); > > > if(test.isJUnit()) { > > > privateRunJUnit(test); > > > } > > > else { > > > privateRun(test); > > > } > > > } > > > finally { > > > afterRun(); > > > } > > > > > > I think the problem is in > > > org.testng.internal.ClassHelper.getAvailableMethods() where we testng > > > only collected the methods until (i.e. excluding) java.lang.Object in > > > 6.9.5 [3] but including java.lang.Object in 6.9.13 [4]: > > > > > > 6.9.5 > > > ===== > > > public static Set getAvailableMethods(Class clazz) { > > > Set methods = Sets.newHashSet(); > > > methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); > > > > > > Class parent = clazz.getSuperclass(); > > > while (Object.class != parent) { > > > methods.addAll(extractMethods(clazz, parent, methods)); > > > parent = parent.getSuperclass(); > > > } > > > > > > 6.9.13 > > > ===== > > > public static Set getAvailableMethods(Class clazz) { > > > Set methods = Sets.newHashSet(); > > > methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); > > > > > > Class parent = clazz.getSuperclass(); > > > while (null != parent) { > > > methods.addAll(extractMethods(clazz, parent, methods)); > > > parent = parent.getSuperclass(); > > > } > > > > > > But java.lang.Object has a different class loader (null) compared to > > > the test class (which is loaded by the application class loader), > > > which leads to the AccessControlException with 6.9.13. > > > > > > As far as I can see, this was changed in testng 6.9.10 [5] to fix > > > https://github.com/cbeust/testng/issues/876 > > > > > > This behavior may potentially also affect other tests which are > > > running with a security manger so I'm not sure you fix will help for > > > all of them. And I also wonder why this hasn't been detected by other > > > who run testng with a security manager (but maybe nobody is doing that > > > :) > > > > > > Regards, > > > Volker > > > > > > [1] https://github.com/cbeust/testng/blob/testng- > > > 6.9.5/src/main/java/org/testng/TestRunner.java > > > [2] > > > > https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/TestRu > > > nner.java > > > [3] https://github.com/cbeust/testng/blob/testng- > > > 6.9.5/src/main/java/org/testng/internal/ClassHelper.java > > > [4] > > > > https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/interna > > > l/ClassHelper.java > > > [5] > > > > https://github.com/cbeust/testng/pull/886/commits/fefedec34706e40ff2bf780b > > > ff7716fca29daaab > > > > > > > > > On Tue, Nov 22, 2016 at 5:24 PM, Daniel Fuchs > > > wrote: > > > > Hi Christoph, > > > > > > > > I have logged https://bugs.openjdk.java.net/browse/JDK-8170192 > > > > > > > > best regards, > > > > > > > > -- daniel > > > > > > > > > > > > On 22/11/16 14:47, Daniel Fuchs wrote: > > > >> > > > >> On 22/11/16 14:43, Langer, Christoph wrote: > > > >>> > > > >>> But, as for fixing with the new testng, will you look into this? Shall > > > >>> I open a bug? > > > > > > > > From christoph.langer at sap.com Wed Nov 23 07:48:27 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 23 Nov 2016 07:48:27 +0000 Subject: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions to jtreg, javatest, and testng jars In-Reply-To: <02f901d24543$d2b37f70$781a7e50$@oracle.com> References: <02f901d24543$d2b37f70$781a7e50$@oracle.com> Message-ID: <6d4303350e6f44aaa5016abd0bc4a8ec@DEWDFE13DE03.global.corp.sap> Hi Frank, to me this looks fine. Maybe a small cosmetical thing: Around lines 212 and 240 you could remove the additional empty lines to have one blank line between methods as in the rest of the file. Note that I'm not a reviewer. Best regards Christoph From: Frank Yuan [mailto:frank.yuan at oracle.com] Sent: Mittwoch, 23. November 2016 05:41 To: core-libs-dev at openjdk.java.net; 'Daniel Fuchs' ; Langer, Christoph ; 'Volker Simonis' ; 'Joe Wang' Cc: code-tools-dev at openjdk.java.net; jtreg-use at openjdk.java.net Subject: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions to jtreg, javatest, and testng jars Hi All Would you like to review http://cr.openjdk.java.net/~fyuan/8170192/webrev.00/? Bug: https://bugs.openjdk.java.net/browse/JDK-8170192 This patch is fully same as Daniel provided except a few lines of additional cleaning, thanks to Daniel for providing the patch! Thanks Frank From christoph.langer at sap.com Wed Nov 23 08:03:29 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 23 Nov 2016 08:03:29 +0000 Subject: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE In-Reply-To: <5834C04B.4090705@oracle.com> References: <582EA144.2000601@oracle.com> <667b95e296fb48809485a685394c5730@DEWDFE13DE03.global.corp.sap> <582F4FBD.3030208@oracle.com> <9fe8c952061c4cf490ab3419fadf70f2@DEWDFE13DE03.global.corp.sap> <582F8D4E.6020902@oracle.com> <5834C04B.4090705@oracle.com> Message-ID: Hi Joe, tests went well and I pushed: http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/31ac7aab52da Thanks Christoph From: Joe Wang [mailto:huizhe.wang at oracle.com] Sent: Dienstag, 22. November 2016 23:02 To: Langer, Christoph Cc: core-libs-dev at openjdk.java.net Subject: Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE Hi Christoph, That looks good to me. Best, Joe On 11/22/16, 1:26 PM, Langer, Christoph wrote: Hi Joe, as my jtreg issues are solved now, I'm finalizing the patches. For this one I've updated the test method: http://cr.openjdk.java.net/~clanger/webrevs/8169772.2/ Could you please quickly check if my new test method "testBug8169772()" looks as you want it? I've added some more detailed comments for the method. The point is that without the fix you'd encounter an NPE. Or should there be some special assertion around it? If it's ok for you, I'd push tomorrow. Thanks & Best regards Christoph From: Joe Wang [mailto:huizhe.wang at oracle.com] Sent: Samstag, 19. November 2016 00:23 To: Langer, Christoph Cc: core-libs-dev at openjdk.java.net Subject: Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE On 11/18/16, 12:17 PM, Langer, Christoph wrote: Hi Joe, Yep, I'll conduct the testing before pushing. With the "Expected Result", you mean some comment for the test method, right? Yes, some comment for the test method would do. But I see that you've added assertions? That would be even better. Comments help in this case since without the patch, the process would have thrown an NPE. Once a bug is fixed, SQE will take the new test and verify the fix. Knowing the success/fail (before and after fix) conditions is helpful for them. Thanks, Joe Thanks Christoph From: Joe Wang [mailto:huizhe.wang at oracle.com] Sent: Freitag, 18. November 2016 20:00 To: Langer, Christoph Cc: core-libs-dev at openjdk.java.net Subject: Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE Looks good, Christoph. I assume you'll do an all-test run (all in jaxp/test) before pushing. No need for further review, but it'd be nice to add an "Expected result" for the new test testBug8169772, with/without the fix (e.g. NPE). Best regards, Joe On 11/18/16, 4:38 AM, Langer, Christoph wrote: Hi Joe, thanks for the feedback. I've created a new version of the webrev working in your suggestions, adding some further formatting cleanups in the files and I also moved a small refactoring in TransformerTest.java to this changeset. http://cr.openjdk.java.net/~clanger/webrevs/8169772.1/ >From my end this one is ready for pushing - waiting for your final go. Best regards Christoph From: Joe Wang [mailto:huizhe.wang at oracle.com] Sent: Freitag, 18. November 2016 07:36 To: Langer, Christoph Cc: core-libs-dev at openjdk.java.net Subject: Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE Looks fine. License header: in general, don't change / add Year if there's no material change, removing the legacy $Id field in EmptySerializer.java for example, does not constitute a change to the code, so just keep the original year (see below). The initial years for the classes: EmptySerializer.java 2012 SerializerBase.java 2012 ToSAXHandler.java none (meaning if you make changes to this class, just add 2016) ToStream.java 2006 ToUnknownStream.java 2007 XSLOutputAttributes.java none (so keep the original "DO NOT REMOVE OR ALTER!" block) Thanks, Joe On 11/16/16, 6:22 AM, Langer, Christoph wrote: Hi, please review another XALAN fix. The Serializer should be able to handle text nodes with null input. There has already been some discussion here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044567.html Bug: https://bugs.openjdk.java.net/browse/JDK-8169772 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169772.0/ The actual fix is in ToUnknownStream.java, method "public void characters(String chars) throws SAXException". I don't know if one should even directly return after chars being null or of size() 0. The rest of this change is cleanups and a test case. Thanks for reviewing. Best regards Christoph From frank.yuan at oracle.com Wed Nov 23 08:31:50 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Wed, 23 Nov 2016 16:31:50 +0800 Subject: Did the tests fail due to TestNG dataprovider parameter type check? Message-ID: <036a01d24564$0bc56e20$23504a60$@oracle.com> Hi Jon I run the whole jdk regression tests with jtreg-4.2-b03 [1], and then found lots of tests in different test groups failed with the error message like following: test test.java.time.format.TestNumberPrinter.test_pad_ALWAYS(): failure org.testng.internal.reflect.MethodMatcherException: Data provider mismatch Method: test_pad_ALWAYS([Parameter{index=0, type=int, declaredAnnotations=[]}, Parameter{index=1, type=int, declaredAnnotations=[]}, Parameter{index=2, type=long, declaredAnnotations=[]}, Parameter{index=3, type=java.lang.String, declaredAnnotations=[]}]) Arguments: [(java.lang.Integer)1,(java.lang.Integer)1,(java.lang.Integer)-10,null] at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1225) at org.testng.TestNG.runSuitesLocally(TestNG.java:1150) at org.testng.TestNG.runSuites(TestNG.java:1075) at org.testng.TestNG.run(TestNG.java:1047) at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:220) at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:184) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:537) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) This test methd signature is: public void test_pad_ALWAYS(int minPad, int maxPad, long value, String result) The provider return the following data Object[][] provider_pad() { return new Object[][] { {1, 1, -10, null}, {1, 1, -9, "9"}, {1, 1, -1, "1"}, ... However, I got message "Cannot find class java/lang/reflect/JTRegModuleHelper.class to init patch directory" when I run jtreg, although I didn't find any code related to testng dataprovider in jtreg source, I would double confirm with you if this is a definite issue or anything I made incorrectly? To Christoph Except above issue, I didn't find any other issue in jdk and langtools repo so far. [1] https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/jtreg-4.2-b03.tar.gz Thanks Frank > -----Original Message----- > From: Langer, Christoph [mailto:christoph.langer at sap.com] > Sent: Wednesday, November 23, 2016 3:41 PM > To: Frank Yuan > Cc: code-tools-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg-use at openjdk.java.net; 'Volker Simonis'; 'Daniel Fuchs' > Subject: RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") > > Thanks, Frank. > > we run scheduled jtreg tests for jdk every night so we should have encountered issues if there were some. But langtools could be interesting, I > don't think those run automatically for OpenJDK in our environment. > > Best regards > Christoph > > > -----Original Message----- > > From: Frank Yuan [mailto:frank.yuan at oracle.com] > > Sent: Mittwoch, 23. November 2016 06:26 > > To: Langer, Christoph ; 'Volker Simonis' > > ; 'Daniel Fuchs' > > Cc: code-tools-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- > > use at openjdk.java.net > > Subject: RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > > "accessDeclaredMembers") > > > > Hi Christoph and Volker > > > > I have been launching jdk and langtools tests with the new jtreg, will update to > > you once I get the result. > > Hope jaxp test is special because most of tests should control the Security > > Manager setting inside the test methods. > > > > Thanks > > Frank > > > > > > > > > -----Original Message----- > > > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > > Behalf Of Langer, Christoph > > > Sent: Wednesday, November 23, 2016 3:51 AM > > > Subject: RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" > > "accessDeclaredMembers") > > > > > > Thanks a lot Volker and Daniel for the big support to analyze and fix this. > > > > > > It seems to me that the proposed fix > > > (http://cr.openjdk.java.net/~dfuchs/webrev_8170192/webrev.00/ ) looks like > > > the best that can be done at the moment. I agree that it would be nicer if > > > jtreg would leave the jtreg lib path as java property to be able to elevate > > > all of its contents. But the current proposal with a set of TEST_JARS of > > > jtreg, javatest and testng is probably sufficient for jaxp testing. > > > > > > The best thing to find out about other issues with the new version of testng > > > would certainly be if Oracle's internal version of jtreg be updated to use > > > the latest testng :-) > > > > > > Best regards > > > Christoph > > > > > > > > > > > > > -----Original Message----- > > > > From: Volker Simonis [mailto:volker.simonis at gmail.com] > > > > Sent: Dienstag, 22. November 2016 20:25 > > > > To: Daniel Fuchs > > > > Cc: Langer, Christoph ; code-tools- > > > > dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- > > > > use at openjdk.java.net > > > > Subject: Re: Issues running JAXP jtreg tests > > > > ("java.lang.RuntimePermission" > > > > "accessDeclaredMembers") > > > > > > > > Hi Daniel, > > > > > > > > thanks for your patch! > > > > > > > > I've meanwhile tried to better understand the root cause of the problem. > > > > > > > > I don't think that the invocation order of the data provider the > > > > listener have changed. If you look at the the two version 6.9.5 and > > > > 6.9.13 of testng, the org.testng.TestRunner.run() methods look exactly > > > > the same in both 6.9.5 [1] and 6.9.13 [2]: > > > > > > > > public void run() { > > > > beforeRun(); > > > > > > > > try { > > > > XmlTest test= getTest(); > > > > if(test.isJUnit()) { > > > > privateRunJUnit(test); > > > > } > > > > else { > > > > privateRun(test); > > > > } > > > > } > > > > finally { > > > > afterRun(); > > > > } > > > > > > > > I think the problem is in > > > > org.testng.internal.ClassHelper.getAvailableMethods() where we testng > > > > only collected the methods until (i.e. excluding) java.lang.Object in > > > > 6.9.5 [3] but including java.lang.Object in 6.9.13 [4]: > > > > > > > > 6.9.5 > > > > ===== > > > > public static Set getAvailableMethods(Class clazz) { > > > > Set methods = Sets.newHashSet(); > > > > methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); > > > > > > > > Class parent = clazz.getSuperclass(); > > > > while (Object.class != parent) { > > > > methods.addAll(extractMethods(clazz, parent, methods)); > > > > parent = parent.getSuperclass(); > > > > } > > > > > > > > 6.9.13 > > > > ===== > > > > public static Set getAvailableMethods(Class clazz) { > > > > Set methods = Sets.newHashSet(); > > > > methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); > > > > > > > > Class parent = clazz.getSuperclass(); > > > > while (null != parent) { > > > > methods.addAll(extractMethods(clazz, parent, methods)); > > > > parent = parent.getSuperclass(); > > > > } > > > > > > > > But java.lang.Object has a different class loader (null) compared to > > > > the test class (which is loaded by the application class loader), > > > > which leads to the AccessControlException with 6.9.13. > > > > > > > > As far as I can see, this was changed in testng 6.9.10 [5] to fix > > > > https://github.com/cbeust/testng/issues/876 > > > > > > > > This behavior may potentially also affect other tests which are > > > > running with a security manger so I'm not sure you fix will help for > > > > all of them. And I also wonder why this hasn't been detected by other > > > > who run testng with a security manager (but maybe nobody is doing that > > > > :) > > > > > > > > Regards, > > > > Volker > > > > > > > > [1] https://github.com/cbeust/testng/blob/testng- > > > > 6.9.5/src/main/java/org/testng/TestRunner.java > > > > [2] > > > > > > https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/TestRu > > > > nner.java > > > > [3] https://github.com/cbeust/testng/blob/testng- > > > > 6.9.5/src/main/java/org/testng/internal/ClassHelper.java > > > > [4] > > > > > > https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/interna > > > > l/ClassHelper.java > > > > [5] > > > > > > https://github.com/cbeust/testng/pull/886/commits/fefedec34706e40ff2bf780b > > > > ff7716fca29daaab > > > > > > > > > > > > On Tue, Nov 22, 2016 at 5:24 PM, Daniel Fuchs > > > > wrote: > > > > > Hi Christoph, > > > > > > > > > > I have logged https://bugs.openjdk.java.net/browse/JDK-8170192 > > > > > > > > > > best regards, > > > > > > > > > > -- daniel > > > > > > > > > > > > > > > On 22/11/16 14:47, Daniel Fuchs wrote: > > > > >> > > > > >> On 22/11/16 14:43, Langer, Christoph wrote: > > > > >>> > > > > >>> But, as for fixing with the new testng, will you look into this? Shall > > > > >>> I open a bug? > > > > > > > > > > From zoltan.majo at oracle.com Wed Nov 23 08:54:43 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 23 Nov 2016 09:54:43 +0100 Subject: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package In-Reply-To: References: <167f4359-dda8-f024-7c9a-2081d00967fe@oracle.com> <585bb2a3-80d4-2c38-73d6-a26c8c38a204@gmail.com> <01e58d88-64e7-2bf8-cb55-93b148a0584f@oracle.com> <1695A59F-98AB-4821-9E20-AD3FE155EFAE@oracle.com> <0D45991D-20E0-4835-9EFA-C3DCCBA24059@oracle.com> Message-ID: Hi, Mandy and I have agreed in a personal discussion that Mandy will take this issue and target it for a future issue. So I retract this RFR. Thank you, everybody, for the discussions and help! Best regards, Zoltan From huaming.li at oracle.com Wed Nov 23 09:49:06 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 23 Nov 2016 17:49:06 +0800 Subject: RFR of JDK-8019538: TEST_BUG: java/rmi/activation/rmidViaInheritedChannel tests may fail Message-ID: <73753d7c-9d58-8632-da37-10e12e13e400@oracle.com> Would you please review the fix for below bug? bug: https://bugs.openjdk.java.net/browse/JDK-8019538 webrev: http://cr.openjdk.java.net/~mli/8019538/webrev.00/ There are 4 issues in the bug, 2 in RmidViaInheritedChannel.java: "port in use" in registry, "port in use" in rmid start. 2 InheritedChannelNotServerSocket.java: "port in use" in registry, "port in use" in rmid start. This patch fixes 2 issues in RmidViaInheritedChannel, and only "port in use" in registry in InheritedChannelNotServerSocket. The "port in use" in rmid in InheritedChannelNotServerSocket is little bit hard, as it intends to test rmid when inherited channel not work. Currently the only solution in my mind is to retry when rmid fails with "port in use", but as we discussed earlier, it's not a good solution as it might impact other programs or tests, and it's not efficient. So I hope to push the fix for the other issues first to improve the stability of RMI tests, and keep studying if there are other better solutions for the "port in use" in rmid in InheritedChannelNotServerSocket. Thank you -Hamlin From patrick at reini.net Wed Nov 23 09:52:44 2016 From: patrick at reini.net (Patrick Reinhart) Date: Wed, 23 Nov 2016 10:52:44 +0100 Subject: RFR: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors In-Reply-To: <95e4229aebf14680b20f5757ec725304@reini.net> References: <95e4229aebf14680b20f5757ec725304@reini.net> Message-ID: <31e02e3b48d118af5d4e8a2d1d5cfb73@reini.net> Are there any obligations to add those constructors? -Patrick On 2016-11-18 10:19, Patrick Reinhart wrote: > I was looking at the existing JDK 9 issues for some simple ones I > could solve and found this one. I wanted to know if it makes sense to > add additional constructors here? > > Now you need to do this: > ------------------------ > try { > new PrintWriter(file, "UTF-8"); > } catch (UnsupportedEncodingException e) { > // Ignore, this is required to be supported by the JVM. > } > > The same applies also to the String constructor... > > > > Instead the following behaviour is requested: > --------------------------------------------- > new PrintWriter(file, StandardCharsets.UTF_8)); > > > > On the other hand then the next request will be to add constructors > also to specify autoflush and so on... > > -Patrick From scolebourne at joda.org Wed Nov 23 11:04:41 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 23 Nov 2016 11:04:41 +0000 Subject: RFR: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors In-Reply-To: <31e02e3b48d118af5d4e8a2d1d5cfb73@reini.net> References: <95e4229aebf14680b20f5757ec725304@reini.net> <31e02e3b48d118af5d4e8a2d1d5cfb73@reini.net> Message-ID: These are the current constructors: PrintWriter(Writer) PrintWriter(Writer, boolean) PrintWriter(OutputStream) PrintWriter(OutputStream, boolean) PrintWriter(String) PrintWriter(String, String) PrintWriter(File) PrintWriter(File, String) These are the annoying missing ones (not all of the possible combinations): PrintWriter(OutputStream, Charset) PrintWriter(OutputStream, Charset, boolean) PrintWriter(String, Charset) PrintWriter(String, Charset, boolean) PrintWriter(File, Charset) PrintWriter(File, Charset, boolean) there are other missing Charset methods on FileWriter. Perhaps a method withAutoFlush(boolean) could reduce the number of constructors? And perhaps the String filename is an anachronism? Thus, adding these three methods might be enough: PrintWriter(OutputStream, Charset) PrintWriter(File, Charset) withAutoFlush(boolean) Stephen On 23 November 2016 at 09:52, Patrick Reinhart wrote: > Are there any obligations to add those constructors? > > -Patrick > > On 2016-11-18 10:19, Patrick Reinhart wrote: > >> I was looking at the existing JDK 9 issues for some simple ones I >> could solve and found this one. I wanted to know if it makes sense to >> add additional constructors here? >> >> Now you need to do this: >> ------------------------ >> try { >> new PrintWriter(file, "UTF-8"); >> } catch (UnsupportedEncodingException e) { >> // Ignore, this is required to be supported by the JVM. >> } >> >> The same applies also to the String constructor... >> >> >> >> Instead the following behaviour is requested: >> --------------------------------------------- >> new PrintWriter(file, StandardCharsets.UTF_8)); >> >> >> >> On the other hand then the next request will be to add constructors >> also to specify autoflush and so on... >> >> -Patrick From brunoaiss at gmail.com Wed Nov 23 12:13:40 2016 From: brunoaiss at gmail.com (Brunoais) Date: Wed, 23 Nov 2016 12:13:40 +0000 Subject: Request/discussion: BufferedReader reading using async API while providing sync API In-Reply-To: References: <077bf6e8-14ae-5588-b1a4-03fb4333c15b@gmail.com> <48cd729d-7922-3de5-3983-cc7486b5a9d3@gmail.com> <4bf67d65-7b2d-59a7-cd4a-19d84a062799@gmail.com> <10318b41-0383-d68a-3145-bdc57ae78450@gmail.com> <7f977d1d-3aa7-ec2e-6df5-51e8ac6473e5@gmail.com> <6fe864bb-bc46-59fd-a7db-c9328e9ea71f@gmail.com> Message-ID: <51ddcf18-7135-8fe0-c82d-0b20ea97400c@gmail.com> Hey! Is this forgotten? On 03/11/2016 14:35, Brunoais wrote: > Any information you can give on this? > > > On 29/10/2016 19:10, Brunoais wrote: >> Here's my try on going async. >> >> On my tests on my local windows 10 machine (I don't have access to >> the linux one without a VM ATM) , now with 1GB file, I noticed: >> >> ~2s of speed improvement from BufferedInputStream to >> BufferedNonBlockStream when BufferedNonBlockStream is at its most >> advantageous state (with CPU work between reads). Otherwise, it has >> ~0.3s speed improvement; maybe less. >> >> ~0.8s of speed improvement from BufferedNonBlockStream to >> BufferedAsyncStream when BufferedNonBlockStream/BufferedAsyncStream >> is at its most advantageous state. Otherwise, ~0 speed improvement. >> >> I noticed: Until you process as fast as you read, both >> BufferedNonBlockStream and BufferedAsyncStream gain advantage towards >> BufferedInputStream. From the point as you take longer to process >> than to I/O, BufferedNonBlockStream and BufferedAsyncStream tend to >> keep the advantage. >> >> If the file is in cache, BufferedInputStream takes ~1.6-1.9s to read >> the file, BufferedNonBlockStream takes a steady ~2.05-2.1s to read >> the file and BufferedAsyncStream ~1.2s. >> >> BufferedNonBlockStream and BufferedAsyncStream win more when given >> more buffer memory than BufferedInputStream but only until a certain >> limit. On my hardware, the best speed I got was with 655360B for the >> new ones. Any more than that was not producing any visible results. I >> guess it is due to the speed data was processing for the test. >> >> On 28/10/2016 09:16, Brunoais wrote: >>> I'll try going back to a previous version I worked on which used the >>> java7's AsynchronousFileChannel and work from there. My small >>> research shows it can also work with AsynchronousFileChannel mostly >>> without changes. >>> >>> For now, 1 question: >>> Is Thread.sleep() a possible way of dealing the block requirements >>> of read()? Do I need to use LockSupport.park() or something like that? >>> >>> I'll call back here when it is done. >>> >>> >>> On 27/10/2016 22:09, David Holmes wrote: >>>> You might try discussing on net-dev rather than core-libs-dev, to >>>> get additional historical info related to the io and nio file APIs. >>>> >>>> David >>>> >>>> On 28/10/2016 5:08 AM, Brunoais wrote: >>>>> You are right. Even in windows it does not set the flags for async >>>>> reads. It seems like it is windows itself that does the decision to >>>>> buffer the contents based on its own heuristics. >>>>> >>>>> But... Why? Why won't it be? Why is there no API for it? How am I >>>>> getting 100% HDD use and faster times when I fake work to delay >>>>> getting >>>>> more data and I only have a fluctuating 60-90% (always going up and >>>>> down) when I use an InputStream? >>>>> Is it related to how both classes cache and how frequently and how >>>>> much >>>>> each one asks for data? >>>>> >>>>> I really would prefer not having to read the source code because it >>>>> takes a real long time T.T. >>>>> >>>>> I end up reinstating... And wondering... >>>>> >>>>> Why doesn't java provide a single-threaded non-block API for file >>>>> reads >>>>> for all OS that support it? I simply cannot find that information no >>>>> matter how much I search on google, bing, duck duck go... Can any >>>>> of you >>>>> point me to whomever knows? >>>>> >>>>> On 27/10/2016 14:11, Vitaly Davidovich wrote: >>>>>> I don't know about Windows specifically, but generally file systems >>>>>> across major OS's will implement readahead in their IO scheduler >>>>>> when >>>>>> they detect sequential scans. >>>>>> >>>>>> On Linux, you can also strace your test to confirm which syscalls >>>>>> are >>>>>> emitted (you should be seeing plain read()'s there, with >>>>>> FileInputStream and FileChannel). >>>>>> >>>>>> On Thu, Oct 27, 2016 at 9:06 AM, Brunoais >>>>> > wrote: >>>>>> >>>>>> Thanks for the heads up. >>>>>> >>>>>> I'll try that later. These tests are still useful then. >>>>>> Meanwhile, >>>>>> I'll end up also checking how FileChannel queries the OS on >>>>>> windows. I'm getting 100% HDD reads... Could it be that the OS >>>>>> reads the file ahead on its own?... Anyway, I'll look into it. >>>>>> Thanks for the heads up. >>>>>> >>>>>> >>>>>> On 27/10/2016 13:53, Vitaly Davidovich wrote: >>>>>>> >>>>>>> >>>>>>> On Thu, Oct 27, 2016 at 8:34 AM, Brunoais >>>>>> > wrote: >>>>>>> >>>>>>> Oh... I see. In that case, it means something is terribly >>>>>>> wrong. It can be my initial tests, though. >>>>>>> >>>>>>> I'm testing on both linux and windows and I'm getting >>>>>>> performance gains from using the FileChannel compared to >>>>>>> using FileInputStream... The tests also make sense based on >>>>>>> my predictions O_O... >>>>>>> >>>>>>> FileInputStream requires copying native buffers holding the >>>>>>> read >>>>>>> data to the java byte[]. If you're using direct ByteBuffer for >>>>>>> FileChannel, that whole memcpy is skipped. Try comparing >>>>>>> FileChannel with HeapByteBuffer instead. >>>>>>> >>>>>>> >>>>>>> On 27/10/2016 11:47, Vitaly Davidovich wrote: >>>>>>>> >>>>>>>> >>>>>>>> On Thursday, October 27, 2016, Brunoais >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>> Did you read the C code? >>>>>>>> >>>>>>>> I looked at the Linux code in the JDK. >>>>>>>> >>>>>>>> Have you got any idea how many functions Windows or >>>>>>>> Linux (nearly all flavors) have for the read operation >>>>>>>> towards a file? >>>>>>>> >>>>>>>> I do. >>>>>>>> >>>>>>>> >>>>>>>> I have already done that homework myself. I may not >>>>>>>> have >>>>>>>> read JVM's source code but I know well that there's >>>>>>>> functions on both Windows and Linux that provide such >>>>>>>> interface I mentioned although they require a slightly >>>>>>>> different treatment (and different constants). >>>>>>>> >>>>>>>> You should read the JDK (native) source code instead of >>>>>>>> guessing/assuming. On Linux, it doesn't use aio >>>>>>>> facilities >>>>>>>> for files. The kernel io scheduler may issue readahead >>>>>>>> behind the scenes, but there's no nonblocking file io >>>>>>>> that's >>>>>>>> at the heart of your premise. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 27/10/2016 00:06, Vitaly Davidovich wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wednesday, October 26, 2016, Brunoais >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> It is actually based on the premise that: >>>>>>>> >>>>>>>> 1. The first call to >>>>>>>> ReadableByteChannel.read(ByteBuffer) sets the OS >>>>>>>> buffer size to fill in as the same size as >>>>>>>> ByteBuffer. >>>>>>>> >>>>>>>> Why do you say that? AFAICT, it issues a read >>>>>>>> syscall and that will block if the data isn't in >>>>>>>> page cache. >>>>>>>> >>>>>>>> 2. The consecutive calls to >>>>>>>> ReadableByteChannel.read(ByteBuffer) >>>>>>>> orders >>>>>>>> the JVM to order the OS to execute memcpy() >>>>>>>> to copy from its memory >>>>>>>> to the shared memory created at ByteBuffer >>>>>>>> instantiation (in >>>>>>>> java 8) >>>>>>>> using Unsafe and then for the JVM to update >>>>>>>> the ByteBuffer fields. >>>>>>>> >>>>>>>> I think subsequent reads just invoke the same read >>>>>>>> syscall, passing the current file offset >>>>>>>> maintained >>>>>>>> by the file channel instance. >>>>>>>> >>>>>>>> 3. The call will not block waiting for I/O and >>>>>>>> it won't take longer >>>>>>>> than the JNI interface if no new data >>>>>>>> exists. >>>>>>>> However, it will >>>>>>>> block >>>>>>>> waiting for the OS to execute memcpy() >>>>>>>> to the >>>>>>>> shared memory. >>>>>>>> >>>>>>>> So why do you think it won't block? >>>>>>>> >>>>>>>> >>>>>>>> Is my premise wrong? >>>>>>>> >>>>>>>> If I read correctly, if I don't use a >>>>>>>> DirectBuffer, there would be >>>>>>>> even another intermediate buffer to copy >>>>>>>> data to >>>>>>>> before giving it >>>>>>>> to the "user" which would be useless. >>>>>>>> >>>>>>>> If you use a HeapByteBuffer, then there's an extra >>>>>>>> copy from the native buffer to the Java buffer. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 26/10/2016 11:57, Pavel Rappo wrote: >>>>>>>> >>>>>>>> I believe I see where you coming from. >>>>>>>> Please correct me if >>>>>>>> I'm wrong. >>>>>>>> >>>>>>>> Your implementation is based on the >>>>>>>> premise >>>>>>>> that a call to >>>>>>>> ReadableByteChannel.read() >>>>>>>> _initiates_ the operation and returns >>>>>>>> immediately. The OS then >>>>>>>> continues to fill >>>>>>>> the buffer while there's a free space >>>>>>>> in the >>>>>>>> buffer and the >>>>>>>> channel hasn't encountered EOF. >>>>>>>> >>>>>>>> Is that right? >>>>>>>> >>>>>>>> On 25 Oct 2016, at 22:16, Brunoais >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Thank you for your time. I'll try to >>>>>>>> explain it. I hope I >>>>>>>> can clear it up. >>>>>>>> First of it, I made a meaning mistake >>>>>>>> between asynchronous >>>>>>>> and non-blocking. This implementation >>>>>>>> uses a non-blocking >>>>>>>> algorithm internally while providing a >>>>>>>> blocking-like >>>>>>>> algorithm on the surface. It is >>>>>>>> single-threaded and not >>>>>>>> multi-threaded where one thread >>>>>>>> fetches >>>>>>>> data and blocks >>>>>>>> waiting and the other accumulates >>>>>>>> it and >>>>>>>> provides to >>>>>>>> whichever wants it. >>>>>>>> >>>>>>>> Second of it, I had made a mistake of >>>>>>>> going after >>>>>>>> BufferedReader instead of going after >>>>>>>> BufferedInputStream. >>>>>>>> If you want me to go after >>>>>>>> BufferedReader it's ok but I >>>>>>>> only thought that going after >>>>>>>> BufferedInputStream would be >>>>>>>> more generically useful than >>>>>>>> BufferedReaderwhen I started >>>>>>>> the poc. >>>>>>>> >>>>>>>> On to my code: >>>>>>>> Short answers: >>>>>>>> ? The sleep(int) exists >>>>>>>> because >>>>>>>> I don't know how >>>>>>>> to wait until more data exists in the >>>>>>>> buffer which is part >>>>>>>> of read()'s contract. >>>>>>>> ? The ByteBuffer gives a >>>>>>>> buffer >>>>>>>> that is filled by >>>>>>>> the OS (what I believe Channels do) >>>>>>>> instead of getting >>>>>>>> data only by demand (what I >>>>>>>> believe Streams do). >>>>>>>> Full answers: >>>>>>>> The blockingFill(boolean) method is a >>>>>>>> method for a busy >>>>>>>> wait for a fill which is used >>>>>>>> exclusively by the read() >>>>>>>> method. All other methods use the >>>>>>>> version that does not >>>>>>>> sleep (fill(boolean)). >>>>>>>> blockingFill(boolean)'s existance like that is >>>>>>>> only >>>>>>>> because the read() method must not >>>>>>>> return unless either: >>>>>>>> >>>>>>>> ? The stream ended. >>>>>>>> ? The next byte is ready for >>>>>>>> reading. >>>>>>>> Additionally, statistically, that >>>>>>>> while >>>>>>>> loop will rarely >>>>>>>> evaluate to true as reads are in >>>>>>>> chunks >>>>>>>> so readPos will be >>>>>>>> behind writePos most of the time. >>>>>>>> I have no idea if an interrupt will >>>>>>>> ever >>>>>>>> happen, to be >>>>>>>> honest. The main reasons why I'm >>>>>>>> using a >>>>>>>> sleep is because >>>>>>>> I didn't want a hog onto the CPU in a >>>>>>>> full thread usage >>>>>>>> busy wait and because I didn't find >>>>>>>> any >>>>>>>> way of doing a >>>>>>>> thread sleep in order to wake up later >>>>>>>> when the buffer >>>>>>>> managed by native code has more data. >>>>>>>> The Non-blocking part is managed by >>>>>>>> the >>>>>>>> buffer the OS >>>>>>>> keeps filling most if not all the >>>>>>>> time. >>>>>>>> That buffer is the >>>>>>>> field >>>>>>>> >>>>>>>> ByteBuffer readBuffer >>>>>>>> That's the gaining part against the >>>>>>>> plain old Buffered >>>>>>>> classes. >>>>>>>> >>>>>>>> >>>>>>>> Did that make sense to you? Feel >>>>>>>> free to >>>>>>>> ask anything else >>>>>>>> you need. >>>>>>>> >>>>>>>> On 25/10/2016 20:52, Pavel Rappo >>>>>>>> wrote: >>>>>>>> >>>>>>>> I've skimmed through the code and >>>>>>>> I'm not sure I can >>>>>>>> see any asynchronicity >>>>>>>> (you were pointing at the lack >>>>>>>> of it >>>>>>>> in BufferedReader). >>>>>>>> And the mechanics of this is very >>>>>>>> puzzling to me, to >>>>>>>> be honest: >>>>>>>> void blockingFill(boolean >>>>>>>> forced) throws >>>>>>>> IOException { >>>>>>>> fill(forced); >>>>>>>> while (readPos == >>>>>>>> writePos) { >>>>>>>> try { >>>>>>>> Thread.sleep(100); >>>>>>>> } catch >>>>>>>> (InterruptedException e) { >>>>>>>> // An interrupt may mean more data is >>>>>>>> available >>>>>>>> } >>>>>>>> fill(forced); >>>>>>>> } >>>>>>>> } >>>>>>>> I thought you were suggesting that >>>>>>>> we should utilize >>>>>>>> the tools which OS provides >>>>>>>> more efficiently. Instead we have >>>>>>>> something that looks >>>>>>>> very similarly to a >>>>>>>> "busy loop" and... also who and >>>>>>>> when >>>>>>>> is supposed to >>>>>>>> interrupt Thread.sleep()? >>>>>>>> Sorry, I'm not following. Could >>>>>>>> you >>>>>>>> please explain how >>>>>>>> this is supposed to work? >>>>>>>> >>>>>>>> On 24 Oct 2016, at 15:59, >>>>>>>> Brunoais >>>>>>>> >>>>>>>> wrote: >>>>>>>> Attached and sending! >>>>>>>> On 24/10/2016 13:48, Pavel >>>>>>>> Rappo >>>>>>>> wrote: >>>>>>>> >>>>>>>> Could you please send a >>>>>>>> new >>>>>>>> email on this list >>>>>>>> with the source >>>>>>>> attached as a >>>>>>>> text file? >>>>>>>> >>>>>>>> On 23 Oct 2016, at >>>>>>>> 19:14, Brunoais >>>>>>>> >>>>>>>> wrote: >>>>>>>> Here's my poc/prototype: >>>>>>>> >>>>>>>> http://pastebin.com/WRpYWDJF >>>>>>>> >>>>>>>> I've implemented the >>>>>>>> bare minimum of the >>>>>>>> class that follows the same contract of >>>>>>>> BufferedReader while signaling all issues >>>>>>>> I think it may have or >>>>>>>> has in comments. >>>>>>>> I also wrote some >>>>>>>> javadoc to help guiding >>>>>>>> through the class. >>>>>>>> I could have used more >>>>>>>> fields from >>>>>>>> BufferedReader but the names were so >>>>>>>> minimalistic that were confusing me. I >>>>>>>> intent to change them before sending this >>>>>>>> to openJDK. >>>>>>>> One of the major >>>>>>>> problems this has is long >>>>>>>> overflowing. It is major because it is >>>>>>>> hidden, it will be extremely rare and it >>>>>>>> takes a really long time to reproduce. >>>>>>>> There are different ways of dealing with >>>>>>>> it. From just >>>>>>>> documenting to actually >>>>>>>> making code that works with it. >>>>>>>> I built a simple test >>>>>>>> code for it to have >>>>>>>> some ideas about >>>>>>>> performance and correctness. >>>>>>>> >>>>>>>> http://pastebin.com/eh6LFgwT >>>>>>>> >>>>>>>> This doesn't do a >>>>>>>> through test if it is >>>>>>>> actually working correctly but I see no >>>>>>>> reason for it not working correctly after >>>>>>>> fixing the 2 bugs that test found. >>>>>>>> I'll also leave here >>>>>>>> some conclusions >>>>>>>> about speed and resource consumption I found. >>>>>>>> I made tests with >>>>>>>> default buffer sizes, >>>>>>>> 5000B 15_000B and 500_000B. I noticed >>>>>>>> that, with my hardware, with the 1 530 000 >>>>>>>> 000B file, I was >>>>>>>> getting >>>>>>>> around: >>>>>>>> In all buffers and >>>>>>>> fake >>>>>>>> work: 10~15s speed >>>>>>>> improvement ( from 90% HDD speed to 100% >>>>>>>> HDD speed) >>>>>>>> In all buffers and no >>>>>>>> fake work: 1~2s >>>>>>>> speed improvement ( from 90% HDD speed to >>>>>>>> 100% HDD speed) >>>>>>>> Changing the buffer size was giving >>>>>>>> different reading speeds but both were >>>>>>>> quite equal in how much they would change >>>>>>>> when changing the >>>>>>>> buffer >>>>>>>> size. >>>>>>>> Finally, I could always confirm that I/O >>>>>>>> was always the slowest >>>>>>>> thing while this >>>>>>>> code was running. >>>>>>>> For the ones wondering >>>>>>>> about the file >>>>>>>> size; it is both to avoid OS cache and to >>>>>>>> make the reading at >>>>>>>> the >>>>>>>> main use-case >>>>>>>> these objects are for (large streams of >>>>>>>> bytes). >>>>>>>> @Pavel, are you open for discussion now >>>>>>>> ;)? Need anything >>>>>>>> else? >>>>>>>> On 21/10/2016 19:21, >>>>>>>> Pavel Rappo wrote: >>>>>>>> >>>>>>>> Just to append to my previous email. >>>>>>>> BufferedReader wraps any Reader out there. >>>>>>>> Not specifically FileReader. While >>>>>>>> you're talking about the case of effective >>>>>>>> reading from a file. >>>>>>>> I guess there's one existing >>>>>>>> possibility to provide exactly what >>>>>>>> you need (as I >>>>>>>> understand it) under this method: >>>>>>>> /** >>>>>>>> * Opens a file for reading, >>>>>>>> returning a {@code BufferedReader} to >>>>>>>> read text >>>>>>>> * from the file in an efficient >>>>>>>> manner... >>>>>>>> ... >>>>>>>> */ >>>>>>>> >>>>>>>> java.nio.file.Files#newBufferedReader(java.nio.file.Path) >>>>>>>> It can return _anything_ as long as it >>>>>>>> is a BufferedReader. We can do it, but it >>>>>>>> needs to be investigated not only for >>>>>>>> your favorite OS but for other OSes as >>>>>>>> well. Feel free to prototype this and >>>>>>>> we can discuss it on the list later. >>>>>>>> Thanks, >>>>>>>> -Pavel >>>>>>>> >>>>>>>> On 21 Oct 2016, at 18:56, Brunoais >>>>>>>> >>>>>>>> wrote: >>>>>>>> Pavel is right. >>>>>>>> In reality, I was expecting such >>>>>>>> BufferedReader to use only a >>>>>>>> single buffer and have that Buffer >>>>>>>> being filled asynchronously, not >>>>>>>> in a different Thread. >>>>>>>> Additionally, I don't have the >>>>>>>> intention of having a larger >>>>>>>> buffer than before unless stated >>>>>>>> through the API (the constructor). >>>>>>>> In my idea, internally, it is >>>>>>>> supposed to use >>>>>>>> java.nio.channels.AsynchronousFileChannel >>>>>>>> or equivalent. >>>>>>>> It does not prevent having two >>>>>>>> buffers and I do not intent to >>>>>>>> change BufferedReader itself. I'd >>>>>>>> do an BufferedAsyncReader of sorts >>>>>>>> (any name suggestion is welcome as >>>>>>>> I'm an awful namer). >>>>>>>> On 21/10/2016 18:38, Roger Riggs >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Pavel, >>>>>>>> I think Brunoais asking for a >>>>>>>> double buffering scheme in >>>>>>>> which the implementation of >>>>>>>> BufferReader fills (a second >>>>>>>> buffer) in parallel with the >>>>>>>> application reading from the >>>>>>>> 1st buffer >>>>>>>> and managing the swaps and >>>>>>>> async reads transparently. >>>>>>>> It would not change the API >>>>>>>> but would change the >>>>>>>> interactions between the >>>>>>>> buffered reader >>>>>>>> and the underlying stream. It >>>>>>>> would also increase memory >>>>>>>> requirements and processing >>>>>>>> by introducing or using a >>>>>>>> separate thread and the >>>>>>>> necessary synchronization. >>>>>>>> Though I think the formal >>>>>>>> interface semantics could be >>>>>>>> maintained, I have doubts >>>>>>>> about compatibility and its >>>>>>>> unintended consequences on >>>>>>>> existing subclasses, >>>>>>>> applications and libraries. >>>>>>>> $.02, Roger >>>>>>>> On 10/21/16 1:22 PM, Pavel >>>>>>>> Rappo wrote: >>>>>>>> >>>>>>>> Off the top of my head, I >>>>>>>> would say it's not >>>>>>>> possible to change the >>>>>>>> design of an >>>>>>>> _extensible_ type that has >>>>>>>> been out there for 20 or >>>>>>>> so years. All these I/O >>>>>>>> streams from java.io >>>>>>>> were >>>>>>>> designed for simple >>>>>>>> synchronous use case. >>>>>>>> It's not that their design >>>>>>>> is flawed in some way, >>>>>>>> it's that they doesn't seem to >>>>>>>> suit your needs. Have you >>>>>>>> considered using >>>>>>>> java.nio.channels.AsynchronousFileChannel >>>>>>>> in your applications? >>>>>>>> -Pavel >>>>>>>> >>>>>>>> On 21 Oct 2016, at >>>>>>>> 17:08, Brunoais >>>>>>>> >>>>>>>> wrote: >>>>>>>> Any feedback on this? >>>>>>>> I'm really interested >>>>>>>> in implementing such >>>>>>>> BufferedReader/BufferedStreamReader >>>>>>>> to allow speeding up >>>>>>>> my applications >>>>>>>> without having to >>>>>>>> think in an >>>>>>>> asynchronous way or >>>>>>>> multi-threading while >>>>>>>> programming with it. >>>>>>>> That's why I'm asking >>>>>>>> this here. >>>>>>>> On 13/10/2016 14:45, >>>>>>>> Brunoais wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> I looked at >>>>>>>> BufferedReader >>>>>>>> source code for >>>>>>>> java 9 long with >>>>>>>> the source code of >>>>>>>> the >>>>>>>> channels/streams >>>>>>>> used. I noticed >>>>>>>> that, like in java >>>>>>>> 7, BufferedReader >>>>>>>> does not use an >>>>>>>> Async API to load >>>>>>>> data from files, >>>>>>>> instead, the data >>>>>>>> loading is all >>>>>>>> done synchronously >>>>>>>> even when the OS >>>>>>>> allows requesting >>>>>>>> a file to be read >>>>>>>> and getting a >>>>>>>> warning later when >>>>>>>> the file is >>>>>>>> effectively read. >>>>>>>> Why Is >>>>>>>> BufferedReader not >>>>>>>> async while >>>>>>>> providing a sync API? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- Sent from my phone >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- Sent from my phone >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From patrick at reini.net Wed Nov 23 12:23:50 2016 From: patrick at reini.net (Patrick Reinhart) Date: Wed, 23 Nov 2016 13:23:50 +0100 Subject: RFR: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors In-Reply-To: References: <95e4229aebf14680b20f5757ec725304@reini.net> <31e02e3b48d118af5d4e8a2d1d5cfb73@reini.net> Message-ID: <9caca326f3c7ca1b637d6aa4f385a1bd@reini.net> Hi Stephen, On 2016-11-23 12:04, Stephen Colebourne wrote: > Perhaps a method withAutoFlush(boolean) could reduce the number of To make that work, we would have to make the boolean field "autoFlush" writeable. Also the auto flush behaviour could be changed at any time. I would then prefer to only have something like a one-way-street as this: withAutoFlush() intentionally no argument to only change it to enabled. > constructors? And perhaps the String filename is an anachronism? > > Thus, adding these three methods might be enough: > > PrintWriter(OutputStream, Charset) > PrintWriter(File, Charset) > withAutoFlush(boolean) > > Stephen > I would think, this would be a good change. -Patrick From scolebourne at joda.org Wed Nov 23 12:37:02 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 23 Nov 2016 12:37:02 +0000 Subject: RFR 8160036: Java API doc for method minusMonths in LocalDateTime class needs correction In-Reply-To: References: <58206E94.3000504@oracle.com> Message-ID: +1 Stephen On 7 November 2016 at 21:23, Roger Riggs wrote: > Looks good, > > Thanks, Roger > > > > On 11/7/2016 7:27 AM, Bhanu Gopularam wrote: >> >> Thanks Nadeesh. Here is the updated webrev: >> >> http://cr.openjdk.java.net/~bgopularam/8160036/webrev.01 >> >> Thanks, >> Bhanu >> >> -----Original Message----- >> From: nadeesh tv >> Sent: Monday, November 07, 2016 5:38 PM >> To: core-libs-dev at openjdk.java.net >> Subject: Re: RFR 8160036: Java API doc for method minusMonths in >> LocalDateTime class needs correction >> >> Hi Bhanu, >> Same issues with OffsetDateTime minusWeeks and minusDays >> >> Thanks and Regards, >> Nadeesh >> >> On 11/7/2016 5:31 PM, Bhanu Gopularam wrote: >>> >>> Hi all, >>> >>> Could you please review fix for following issue? >>> >>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8160036 >>> >>> Solution: Corrected documentation for couple of methods in LocalDateTime >>> and OffsetDateTime classes >>> >>> Webrev: http://cr.openjdk.java.net/~bgopularam/8160036/webrev.00 >>> >>> Thanks, >>> Bhanu > > From patrick at reini.net Wed Nov 23 13:09:22 2016 From: patrick at reini.net (Patrick Reinhart) Date: Wed, 23 Nov 2016 14:09:22 +0100 Subject: RFR: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors In-Reply-To: <9caca326f3c7ca1b637d6aa4f385a1bd@reini.net> References: <95e4229aebf14680b20f5757ec725304@reini.net> <31e02e3b48d118af5d4e8a2d1d5cfb73@reini.net> <9caca326f3c7ca1b637d6aa4f385a1bd@reini.net> Message-ID: <8d29b80ac6eecd357ba1fa102a84833e@reini.net> Added those new public constructors: PrintWriter(OutputStream, Charset) PrintWriter(File, Charset) withAutoFlush() Also added a new private constructor: PrintWriter(OutputStream, Charset, boolean) and rewired the OutputStream constructor calls to this private constructor. Here's the webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8167648/webrev.00 -Patrick From jbluettduncan at gmail.com Wed Nov 23 13:35:08 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Wed, 23 Nov 2016 13:35:08 +0000 Subject: RFR: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors In-Reply-To: <8d29b80ac6eecd357ba1fa102a84833e@reini.net> References: <95e4229aebf14680b20f5757ec725304@reini.net> <31e02e3b48d118af5d4e8a2d1d5cfb73@reini.net> <9caca326f3c7ca1b637d6aa4f385a1bd@reini.net> <8d29b80ac6eecd357ba1fa102a84833e@reini.net> Message-ID: Hi Patrick, Have you considered making `withAutoFlush()` return the `PrintWriter` itself, allowing fluent code snippets like the following? ``` PrintWriter writer = new PrintWriter(new File("path/to/file.txt"), StandardCharsets.UTF_8).withAutoFlush(); ``` Kind regards, Jonathan On 23 November 2016 at 13:09, Patrick Reinhart wrote: > Added those new public constructors: > > PrintWriter(OutputStream, Charset) > PrintWriter(File, Charset) > withAutoFlush() > > Also added a new private constructor: > > PrintWriter(OutputStream, Charset, boolean) > > and rewired the OutputStream constructor calls to this private constructor. > > > Here's the webrev: > > http://cr.openjdk.java.net/~reinhapa/reviews/8167648/webrev.00 > > > -Patrick > From scolebourne at joda.org Wed Nov 23 13:45:30 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 23 Nov 2016 13:45:30 +0000 Subject: RFR: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors In-Reply-To: References: <95e4229aebf14680b20f5757ec725304@reini.net> <31e02e3b48d118af5d4e8a2d1d5cfb73@reini.net> <9caca326f3c7ca1b637d6aa4f385a1bd@reini.net> <8d29b80ac6eecd357ba1fa102a84833e@reini.net> Message-ID: Returning the writer was my intention. I also intended it to return a new instance, to avoid changing the variable from final to non-final. Stephen On 23 November 2016 at 13:35, Jonathan Bluett-Duncan wrote: > Hi Patrick, > > Have you considered making `withAutoFlush()` return the `PrintWriter` > itself, allowing fluent code snippets like the following? > > ``` > PrintWriter writer = new PrintWriter(new File("path/to/file.txt"), > StandardCharsets.UTF_8).withAutoFlush(); > ``` > > Kind regards, > Jonathan > > On 23 November 2016 at 13:09, Patrick Reinhart wrote: >> >> Added those new public constructors: >> >> PrintWriter(OutputStream, Charset) >> PrintWriter(File, Charset) >> withAutoFlush() >> >> Also added a new private constructor: >> >> PrintWriter(OutputStream, Charset, boolean) >> >> and rewired the OutputStream constructor calls to this private >> constructor. >> >> >> Here's the webrev: >> >> http://cr.openjdk.java.net/~reinhapa/reviews/8167648/webrev.00 >> >> >> -Patrick > > From patrick at reini.net Wed Nov 23 13:45:59 2016 From: patrick at reini.net (Patrick Reinhart) Date: Wed, 23 Nov 2016 14:45:59 +0100 Subject: RFR: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors In-Reply-To: References: <95e4229aebf14680b20f5757ec725304@reini.net> <31e02e3b48d118af5d4e8a2d1d5cfb73@reini.net> <9caca326f3c7ca1b637d6aa4f385a1bd@reini.net> <8d29b80ac6eecd357ba1fa102a84833e@reini.net> Message-ID: On 2016-11-23 14:35, Jonathan Bluett-Duncan wrote: > Hi Patrick, > > Have you considered making `withAutoFlush()` return the `PrintWriter` > itself, allowing fluent code snippets like the following? > > ``` > PrintWriter writer = new PrintWriter(new File("path/to/file.txt"), > StandardCharsets.UTF_8).withAutoFlush(); > ``` > Good point. I taught about it, but it somehow got lost on the way of re-wiring the constructors... :-) Just updated the webrev -Patrick From daniel.fuchs at oracle.com Wed Nov 23 13:49:20 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 23 Nov 2016 13:49:20 +0000 Subject: RFR[9] JDK-8158916: ProblemList.txt update for com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java In-Reply-To: <08b1838e-4541-57b3-36ca-0f0cb98ab578@oracle.com> References: <59dc7e57-3d05-6395-abdc-a0677b487fbb@oracle.com> <0988590c-7530-8470-3b74-56a2a8c3e744@oracle.com> <7e02a877-a014-a8a6-d69e-40320aae53ae@oracle.com> <212fd806-b85d-cf3b-2065-4766ec773753@oracle.com> <08b1838e-4541-57b3-36ca-0f0cb98ab578@oracle.com> Message-ID: <06da0afd-2c38-0965-cac6-3631386b023d@oracle.com> Looks good! On 23/11/16 05:49, John Jiang wrote: > Hi Daniel, > I'll push the below patch: > diff -r 5cd2aa3f3e9b test/ProblemList.txt > --- a/test/ProblemList.txt Tue Nov 22 10:45:48 2016 -0800 > +++ b/test/ProblemList.txt Tue Nov 22 21:34:47 2016 -0800 > @@ -305,6 +305,6 @@ > > # jdk_other > > -com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8141370 > linux-i586,macosx-all > +com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8169942 > linux-i586,macosx-all,windows-x64 > > ############################################################################ > > > Best regards, > John Jiang > > On 2016/11/18 18:03, Daniel Fuchs wrote: >> Hi John, >> >> Looks good to me. Should windows-amd64 also be listed? >> It appears the test also failing there (JDK-8152654) >> >> best regards, >> >> -- daniel >> >> On 18/11/16 06:02, John Jiang wrote: >>> Hi, >>> Track this test issue with a new JBS bug JDK-8169942. >>> Please take a look at the updated webrew: >>> http://cr.openjdk.java.net/~jjiang/8158916/webrev.01/, or the below, >>> >>> --- old/test/ProblemList.txt 2016-11-17 21:29:12.112822913 -0800 >>> +++ new/test/ProblemList.txt 2016-11-17 21:29:11.964822915 -0800 >>> @@ -298,6 +298,6 @@ >>> >>> # jdk_other >>> >>> -com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8141370 >>> linux-i586,macosx-all >>> +com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8169942 >>> linux-i586,macosx-all >>> >>> ############################################################################ >>> >>> >>> >>> Best regards, >>> John Jiang >>> >>> >>> On 2016/11/8 18:53, Daniel Fuchs wrote: >>>> Hi John, >>>> >>>> On 08/11/16 01:30, John Jiang wrote: >>>>> Hi Daniel, >>>>> Thanks for your comments. >>>>> >>>>> On 2016/11/7 19:21, Daniel Fuchs wrote: >>>>>> Hi John, >>>>>> >>>>>> Maybe you should reach out to Rob who fixed JDK-8141370 to >>>>>> make sure this is the right thing to do. >>>>> just cc Rob Mckenna >>>>> >>>>>> >>>>>> It seems the exclusion on problematic platforms [1] was deliberate: >>>>>> >>>>>>> Basically I've separated the failing subtest out into its own >>>>>>> file and >>>>>>> excluded it on the (intermittently) failing platforms. >>>>> I see. But it should use an open issue. >>>>> I would like to open a new issue to track this issue. But I don't get >>>>> the exact failure log on DeadSSLLdapTimeoutTest.java, though the >>>>> failure >>>>> may still be related to SSLHandshakeException. >>>>> When this test was born, it was in the ProblemList, so I suppose it >>>>> has >>>>> no chance to be executed by our automatic testing systems. >>>> >>>> I see. I agree it's better to have an open bug in the ProblemList. >>>> But I am concerned if that bug is something that we never intend to >>>> fix because the test is not appropriate for those platforms. >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>>> >>>>> Best regards, >>>>> John Jiang >>>>> >>>>>> >>>>>> best regards, >>>>>> >>>>>> -- daniel >>>>>> >>>>>> [1] >>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037385.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 07/11/16 02:37, John Jiang wrote: >>>>>>> Hi, >>>>>>> com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java is associated to >>>>>>> 8141370 >>>>>>> in ProblemList, though issue JDK-8141370 has been resolved. >>>>>>> In fact, the fix for JDK-8141370 extracted some codes from >>>>>>> com/sun/jndi/ldap/LdapTimeoutTest.java to create >>>>>>> com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java, and put the new >>>>>>> test to >>>>>>> ProblemList. >>>>>>> It would be better to remove this item from ProblemList. If >>>>>>> com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java still fails >>>>>>> intermittently, we can put it back to ProblemList with the exact >>>>>>> failure >>>>>>> logs. >>>>>>> >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8158916 >>>>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8158916/webrev.00/ >>>>>>> >>>>>>> Best regards, >>>>>>> John Jiang >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > From daniel.fuchs at oracle.com Wed Nov 23 13:59:20 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 23 Nov 2016 13:59:20 +0000 Subject: Did the tests fail due to TestNG dataprovider parameter type check? In-Reply-To: <036a01d24564$0bc56e20$23504a60$@oracle.com> References: <036a01d24564$0bc56e20$23504a60$@oracle.com> Message-ID: <637303db-c014-4f19-6e38-3182c17aae34@oracle.com> Hi Frank, I ran only the tests under jaxp/tests/javax - and one test was failing (DurationTest) with a similar error (something about a mismatch between Integer & Long in data provider). This looked to be completely unrelated to the permission changes, so I thought it would be better to investigate it as a separate issue. The failure in the Duration test looked simpler - so it might be a good place to look at to try and figure out what is going on. best regards, -- daniel On 23/11/16 08:31, Frank Yuan wrote: > Hi Jon > > I run the whole jdk regression tests with jtreg-4.2-b03 [1], and then found lots of tests in different test groups failed with the error message like following: > test test.java.time.format.TestNumberPrinter.test_pad_ALWAYS(): failure > org.testng.internal.reflect.MethodMatcherException: > Data provider mismatch > Method: test_pad_ALWAYS([Parameter{index=0, type=int, declaredAnnotations=[]}, Parameter{index=1, type=int, declaredAnnotations=[]}, Parameter{index=2, type=long, declaredAnnotations=[]}, Parameter{index=3, type=java.lang.String, declaredAnnotations=[]}]) > Arguments: [(java.lang.Integer)1,(java.lang.Integer)1,(java.lang.Integer)-10,null] > at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) > at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) > at org.testng.TestRunner.privateRun(TestRunner.java:778) > at org.testng.TestRunner.run(TestRunner.java:632) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) > at org.testng.SuiteRunner.run(SuiteRunner.java:268) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1225) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1150) > at org.testng.TestNG.runSuites(TestNG.java:1075) > at org.testng.TestNG.run(TestNG.java:1047) > at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:220) > at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:184) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:537) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) > at java.base/java.lang.Thread.run(Thread.java:844) > > > This test methd signature is: > public void test_pad_ALWAYS(int minPad, int maxPad, long value, String result) > > The provider return the following data > Object[][] provider_pad() { > return new Object[][] { > {1, 1, -10, null}, > {1, 1, -9, "9"}, > {1, 1, -1, "1"}, > ... > > However, I got message "Cannot find class java/lang/reflect/JTRegModuleHelper.class to init patch directory" when I run jtreg, although I didn't find any code related to testng dataprovider in jtreg source, I would double confirm with you if this is a definite issue or anything I made incorrectly? > > To Christoph > > Except above issue, I didn't find any other issue in jdk and langtools repo so far. > > > [1] https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/jtreg-4.2-b03.tar.gz > > > Thanks > Frank > >> -----Original Message----- >> From: Langer, Christoph [mailto:christoph.langer at sap.com] >> Sent: Wednesday, November 23, 2016 3:41 PM >> To: Frank Yuan >> Cc: code-tools-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg-use at openjdk.java.net; 'Volker Simonis'; 'Daniel Fuchs' >> Subject: RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers") >> >> Thanks, Frank. >> >> we run scheduled jtreg tests for jdk every night so we should have encountered issues if there were some. But langtools could be interesting, I >> don't think those run automatically for OpenJDK in our environment. >> >> Best regards >> Christoph >> >>> -----Original Message----- >>> From: Frank Yuan [mailto:frank.yuan at oracle.com] >>> Sent: Mittwoch, 23. November 2016 06:26 >>> To: Langer, Christoph ; 'Volker Simonis' >>> ; 'Daniel Fuchs' >>> Cc: code-tools-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- >>> use at openjdk.java.net >>> Subject: RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" >>> "accessDeclaredMembers") >>> >>> Hi Christoph and Volker >>> >>> I have been launching jdk and langtools tests with the new jtreg, will update to >>> you once I get the result. >>> Hope jaxp test is special because most of tests should control the Security >>> Manager setting inside the test methods. >>> >>> Thanks >>> Frank >>> >>> >>> >>>> -----Original Message----- >>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On >>> Behalf Of Langer, Christoph >>>> Sent: Wednesday, November 23, 2016 3:51 AM >>>> Subject: RE: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" >>> "accessDeclaredMembers") >>>> >>>> Thanks a lot Volker and Daniel for the big support to analyze and fix this. >>>> >>>> It seems to me that the proposed fix >>>> (http://cr.openjdk.java.net/~dfuchs/webrev_8170192/webrev.00/ ) looks like >>>> the best that can be done at the moment. I agree that it would be nicer if >>>> jtreg would leave the jtreg lib path as java property to be able to elevate >>>> all of its contents. But the current proposal with a set of TEST_JARS of >>>> jtreg, javatest and testng is probably sufficient for jaxp testing. >>>> >>>> The best thing to find out about other issues with the new version of testng >>>> would certainly be if Oracle's internal version of jtreg be updated to use >>>> the latest testng :-) >>>> >>>> Best regards >>>> Christoph >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Volker Simonis [mailto:volker.simonis at gmail.com] >>>>> Sent: Dienstag, 22. November 2016 20:25 >>>>> To: Daniel Fuchs >>>>> Cc: Langer, Christoph ; code-tools- >>>>> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jtreg- >>>>> use at openjdk.java.net >>>>> Subject: Re: Issues running JAXP jtreg tests >>>>> ("java.lang.RuntimePermission" >>>>> "accessDeclaredMembers") >>>>> >>>>> Hi Daniel, >>>>> >>>>> thanks for your patch! >>>>> >>>>> I've meanwhile tried to better understand the root cause of the problem. >>>>> >>>>> I don't think that the invocation order of the data provider the >>>>> listener have changed. If you look at the the two version 6.9.5 and >>>>> 6.9.13 of testng, the org.testng.TestRunner.run() methods look exactly >>>>> the same in both 6.9.5 [1] and 6.9.13 [2]: >>>>> >>>>> public void run() { >>>>> beforeRun(); >>>>> >>>>> try { >>>>> XmlTest test= getTest(); >>>>> if(test.isJUnit()) { >>>>> privateRunJUnit(test); >>>>> } >>>>> else { >>>>> privateRun(test); >>>>> } >>>>> } >>>>> finally { >>>>> afterRun(); >>>>> } >>>>> >>>>> I think the problem is in >>>>> org.testng.internal.ClassHelper.getAvailableMethods() where we testng >>>>> only collected the methods until (i.e. excluding) java.lang.Object in >>>>> 6.9.5 [3] but including java.lang.Object in 6.9.13 [4]: >>>>> >>>>> 6.9.5 >>>>> ===== >>>>> public static Set getAvailableMethods(Class clazz) { >>>>> Set methods = Sets.newHashSet(); >>>>> methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); >>>>> >>>>> Class parent = clazz.getSuperclass(); >>>>> while (Object.class != parent) { >>>>> methods.addAll(extractMethods(clazz, parent, methods)); >>>>> parent = parent.getSuperclass(); >>>>> } >>>>> >>>>> 6.9.13 >>>>> ===== >>>>> public static Set getAvailableMethods(Class clazz) { >>>>> Set methods = Sets.newHashSet(); >>>>> methods.addAll(Arrays.asList(clazz.getDeclaredMethods())); >>>>> >>>>> Class parent = clazz.getSuperclass(); >>>>> while (null != parent) { >>>>> methods.addAll(extractMethods(clazz, parent, methods)); >>>>> parent = parent.getSuperclass(); >>>>> } >>>>> >>>>> But java.lang.Object has a different class loader (null) compared to >>>>> the test class (which is loaded by the application class loader), >>>>> which leads to the AccessControlException with 6.9.13. >>>>> >>>>> As far as I can see, this was changed in testng 6.9.10 [5] to fix >>>>> https://github.com/cbeust/testng/issues/876 >>>>> >>>>> This behavior may potentially also affect other tests which are >>>>> running with a security manger so I'm not sure you fix will help for >>>>> all of them. And I also wonder why this hasn't been detected by other >>>>> who run testng with a security manager (but maybe nobody is doing that >>>>> :) >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> [1] https://github.com/cbeust/testng/blob/testng- >>>>> 6.9.5/src/main/java/org/testng/TestRunner.java >>>>> [2] >>>>> >>> https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/TestRu >>>>> nner.java >>>>> [3] https://github.com/cbeust/testng/blob/testng- >>>>> 6.9.5/src/main/java/org/testng/internal/ClassHelper.java >>>>> [4] >>>>> >>> https://github.com/cbeust/testng/blob/6.9.13/src/main/java/org/testng/interna >>>>> l/ClassHelper.java >>>>> [5] >>>>> >>> https://github.com/cbeust/testng/pull/886/commits/fefedec34706e40ff2bf780b >>>>> ff7716fca29daaab >>>>> >>>>> >>>>> On Tue, Nov 22, 2016 at 5:24 PM, Daniel Fuchs >>>>> wrote: >>>>>> Hi Christoph, >>>>>> >>>>>> I have logged https://bugs.openjdk.java.net/browse/JDK-8170192 >>>>>> >>>>>> best regards, >>>>>> >>>>>> -- daniel >>>>>> >>>>>> >>>>>> On 22/11/16 14:47, Daniel Fuchs wrote: >>>>>>> >>>>>>> On 22/11/16 14:43, Langer, Christoph wrote: >>>>>>>> >>>>>>>> But, as for fixing with the new testng, will you look into this? Shall >>>>>>>> I open a bug? >>>>>> >>>>>> > > From daniel.fuchs at oracle.com Wed Nov 23 14:00:13 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 23 Nov 2016 14:00:13 +0000 Subject: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions to jtreg, javatest, and testng jars In-Reply-To: <02f901d24543$d2b37f70$781a7e50$@oracle.com> References: <02f901d24543$d2b37f70$781a7e50$@oracle.com> Message-ID: <5107a701-1cea-5017-2afb-c4a2031c4058@oracle.com> Hi Frank, Thanks for taking this on. Looks good to me. -- daniel On 23/11/16 04:41, Frank Yuan wrote: > Hi All > > > > Would you like to review > http://cr.openjdk.java.net/~fyuan/8170192/webrev.00/? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170192 > > > > This patch is fully same as Daniel provided except a few lines of > additional cleaning, thanks to Daniel for providing the patch! > > > > Thanks > > Frank > > > From volker.simonis at gmail.com Wed Nov 23 14:05:33 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 23 Nov 2016 15:05:33 +0100 Subject: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <583394C5.3030206@linux.vnet.ibm.com> References: <583394C5.3030206@linux.vnet.ibm.com> Message-ID: Hi Gustavo, thanks a lot for tracking this down! The change looks good and I a can sponsor it once you get another review from the build group and the FC Extension Request was approved. In general I'd advise to sign the OCTLA [1] to get access to the Java SE TCK [2] as this contains quite a lot of additional conformance tests which can be quite valuable for changes like this. Regards, Volker [1] http://openjdk.java.net/legal/octla-java-se-8.pdf [2] http://openjdk.java.net/groups/conformance/JckAccess/ On Tue, Nov 22, 2016 at 1:43 AM, Gustavo Romero wrote: > Hi, > > Could the following change be reviewed, please? > > webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/ > webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/jdk/ > bug: https://bugs.openjdk.java.net/browse/JDK-8170153 > > It enables fdlibm optimization on Linux PPC64 LE & BE and hence speeds up the > StrictMath methods (in some cases up to 3x) on that platform. > > On PPC64 fdlibm optimization can be done without precision issues if > floating-point expression contraction is disable, i.e. if the compiler does not > use floating-point multiply-add (FMA). For further details please refer to gcc > bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 > > No regression was observed on Math and StrictMath tests: > > Passed: java/lang/Math/AbsPositiveZero.java > Passed: java/lang/Math/Atan2Tests.java > Passed: java/lang/Math/CeilAndFloorTests.java > Passed: java/lang/Math/CubeRootTests.java > Passed: java/lang/Math/DivModTests.java > Passed: java/lang/Math/ExactArithTests.java > Passed: java/lang/Math/Expm1Tests.java > Passed: java/lang/Math/FusedMultiplyAddTests.java > Passed: java/lang/Math/HyperbolicTests.java > Passed: java/lang/Math/HypotTests.java > Passed: java/lang/Math/IeeeRecommendedTests.java > Passed: java/lang/Math/Log10Tests.java > Passed: java/lang/Math/Log1pTests.java > Passed: java/lang/Math/MinMax.java > Passed: java/lang/Math/MultiplicationTests.java > Passed: java/lang/Math/PowTests.java > Passed: java/lang/Math/Rint.java > Passed: java/lang/Math/RoundTests.java > Passed: java/lang/Math/SinCosCornerCasesTests.java > Passed: java/lang/Math/TanTests.java > Passed: java/lang/Math/WorstCaseTests.java > Test results: passed: 21 > > Passed: java/lang/StrictMath/CubeRootTests.java > Passed: java/lang/StrictMath/ExactArithTests.java > Passed: java/lang/StrictMath/Expm1Tests.java > Passed: java/lang/StrictMath/HyperbolicTests.java > Passed: java/lang/StrictMath/HypotTests.java > Passed: java/lang/StrictMath/Log10Tests.java > Passed: java/lang/StrictMath/Log1pTests.java > Passed: java/lang/StrictMath/PowTests.java > Test results: passed: 8 > > and also on the following hotspot tests: > > Passed: compiler/intrinsics/mathexact/sanity/AddExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/AddExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/DecrementExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/IncrementExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/IncrementExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/MultiplyExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/MultiplyExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/NegateExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/NegateExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/SubtractExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/SubtractExactLongTest.java > Passed: compiler/intrinsics/mathexact/AddExactICondTest.java > Passed: compiler/intrinsics/mathexact/AddExactIConstantTest.java > Passed: compiler/intrinsics/mathexact/AddExactILoadTest.java > Passed: compiler/intrinsics/mathexact/AddExactILoopDependentTest.java > Passed: compiler/intrinsics/mathexact/AddExactINonConstantTest.java > Passed: compiler/intrinsics/mathexact/AddExactIRepeatTest.java > Passed: compiler/intrinsics/mathexact/AddExactLConstantTest.java > Passed: compiler/intrinsics/mathexact/AddExactLNonConstantTest.java > Passed: compiler/intrinsics/mathexact/CompareTest.java > Passed: compiler/intrinsics/mathexact/DecExactITest.java > Passed: compiler/intrinsics/mathexact/DecExactLTest.java > Passed: compiler/intrinsics/mathexact/GVNTest.java > Passed: compiler/intrinsics/mathexact/IncExactITest.java > Passed: compiler/intrinsics/mathexact/IncExactLTest.java > Passed: compiler/intrinsics/mathexact/MulExactICondTest.java > Passed: compiler/intrinsics/mathexact/MulExactIConstantTest.java > Passed: compiler/intrinsics/mathexact/MulExactILoadTest.java > Passed: compiler/intrinsics/mathexact/MulExactILoopDependentTest.java > Passed: compiler/intrinsics/mathexact/MulExactINonConstantTest.java > Passed: compiler/intrinsics/mathexact/MulExactIRepeatTest.java > Passed: compiler/intrinsics/mathexact/MulExactLConstantTest.java > Passed: compiler/intrinsics/mathexact/MulExactLNonConstantTest.java > Passed: compiler/intrinsics/mathexact/NegExactIConstantTest.java > Passed: compiler/intrinsics/mathexact/NegExactILoadTest.java > Passed: compiler/intrinsics/mathexact/NegExactILoopDependentTest.java > Passed: compiler/intrinsics/mathexact/NegExactINonConstantTest.java > Passed: compiler/intrinsics/mathexact/NegExactLConstantTest.java > Passed: compiler/intrinsics/mathexact/NegExactLNonConstantTest.java > Passed: compiler/intrinsics/mathexact/NestedMathExactTest.java > Passed: compiler/intrinsics/mathexact/SplitThruPhiTest.java > Passed: compiler/intrinsics/mathexact/SubExactICondTest.java > Passed: compiler/intrinsics/mathexact/SubExactIConstantTest.java > Passed: compiler/intrinsics/mathexact/SubExactILoadTest.java > Passed: compiler/intrinsics/mathexact/SubExactILoopDependentTest.java > Passed: compiler/intrinsics/mathexact/SubExactINonConstantTest.java > Passed: compiler/intrinsics/mathexact/SubExactIRepeatTest.java > Passed: compiler/intrinsics/mathexact/SubExactLConstantTest.java > Passed: compiler/intrinsics/mathexact/SubExactLNonConstantTest.java > Test results: passed: 50 > > Thank you. > > > Regards, > Gustavo > From dl at cs.oswego.edu Wed Nov 23 14:14:30 2016 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 23 Nov 2016 09:14:30 -0500 Subject: RFR 8169808 Stream returning methods should specify if they are late binding In-Reply-To: References: <2332D5F4-986E-4936-8665-933E64E5E6DE@oracle.com> Message-ID: <373316af-30f5-4901-be14-a64537ea2d5a@cs.oswego.edu> On 11/22/2016 08:33 PM, Martin Buchholz wrote: > PriorityBlockingQueue has a late-binding-style, snapshot spliterator > that does not report IMMUTABLE. It *is* immutable ... after the first > access! Should we add IMMUTABLE? Probably not. This might overly constrain future improvements; for example, someday replacing with some linked structure. Arguably, if so, we could just change the reported characteristics, but that could be surprising to users, and possibly lead to subtle user bugs. -Doug From erik.joelsson at oracle.com Wed Nov 23 14:29:52 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Nov 2016 15:29:52 +0100 Subject: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <583394C5.3030206@linux.vnet.ibm.com> References: <583394C5.3030206@linux.vnet.ibm.com> Message-ID: <9327e543-f35b-b88f-2831-a51e265b6a30@oracle.com> Build changes look ok. In CoreLibraries.gmk, I think it would have been ok to keep the conditional checking (OPENJDK_TARGET_CPU_ARCH, ppc), but this certainly works too. /Erik On 2016-11-22 01:43, Gustavo Romero wrote: > Hi, > > Could the following change be reviewed, please? > > webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/ > webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/jdk/ > bug: https://bugs.openjdk.java.net/browse/JDK-8170153 > > It enables fdlibm optimization on Linux PPC64 LE & BE and hence speeds up the > StrictMath methods (in some cases up to 3x) on that platform. > > On PPC64 fdlibm optimization can be done without precision issues if > floating-point expression contraction is disable, i.e. if the compiler does not > use floating-point multiply-add (FMA). For further details please refer to gcc > bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 > > No regression was observed on Math and StrictMath tests: > > Passed: java/lang/Math/AbsPositiveZero.java > Passed: java/lang/Math/Atan2Tests.java > Passed: java/lang/Math/CeilAndFloorTests.java > Passed: java/lang/Math/CubeRootTests.java > Passed: java/lang/Math/DivModTests.java > Passed: java/lang/Math/ExactArithTests.java > Passed: java/lang/Math/Expm1Tests.java > Passed: java/lang/Math/FusedMultiplyAddTests.java > Passed: java/lang/Math/HyperbolicTests.java > Passed: java/lang/Math/HypotTests.java > Passed: java/lang/Math/IeeeRecommendedTests.java > Passed: java/lang/Math/Log10Tests.java > Passed: java/lang/Math/Log1pTests.java > Passed: java/lang/Math/MinMax.java > Passed: java/lang/Math/MultiplicationTests.java > Passed: java/lang/Math/PowTests.java > Passed: java/lang/Math/Rint.java > Passed: java/lang/Math/RoundTests.java > Passed: java/lang/Math/SinCosCornerCasesTests.java > Passed: java/lang/Math/TanTests.java > Passed: java/lang/Math/WorstCaseTests.java > Test results: passed: 21 > > Passed: java/lang/StrictMath/CubeRootTests.java > Passed: java/lang/StrictMath/ExactArithTests.java > Passed: java/lang/StrictMath/Expm1Tests.java > Passed: java/lang/StrictMath/HyperbolicTests.java > Passed: java/lang/StrictMath/HypotTests.java > Passed: java/lang/StrictMath/Log10Tests.java > Passed: java/lang/StrictMath/Log1pTests.java > Passed: java/lang/StrictMath/PowTests.java > Test results: passed: 8 > > and also on the following hotspot tests: > > Passed: compiler/intrinsics/mathexact/sanity/AddExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/AddExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/DecrementExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/IncrementExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/IncrementExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/MultiplyExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/MultiplyExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/NegateExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/NegateExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/SubtractExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/SubtractExactLongTest.java > Passed: compiler/intrinsics/mathexact/AddExactICondTest.java > Passed: compiler/intrinsics/mathexact/AddExactIConstantTest.java > Passed: compiler/intrinsics/mathexact/AddExactILoadTest.java > Passed: compiler/intrinsics/mathexact/AddExactILoopDependentTest.java > Passed: compiler/intrinsics/mathexact/AddExactINonConstantTest.java > Passed: compiler/intrinsics/mathexact/AddExactIRepeatTest.java > Passed: compiler/intrinsics/mathexact/AddExactLConstantTest.java > Passed: compiler/intrinsics/mathexact/AddExactLNonConstantTest.java > Passed: compiler/intrinsics/mathexact/CompareTest.java > Passed: compiler/intrinsics/mathexact/DecExactITest.java > Passed: compiler/intrinsics/mathexact/DecExactLTest.java > Passed: compiler/intrinsics/mathexact/GVNTest.java > Passed: compiler/intrinsics/mathexact/IncExactITest.java > Passed: compiler/intrinsics/mathexact/IncExactLTest.java > Passed: compiler/intrinsics/mathexact/MulExactICondTest.java > Passed: compiler/intrinsics/mathexact/MulExactIConstantTest.java > Passed: compiler/intrinsics/mathexact/MulExactILoadTest.java > Passed: compiler/intrinsics/mathexact/MulExactILoopDependentTest.java > Passed: compiler/intrinsics/mathexact/MulExactINonConstantTest.java > Passed: compiler/intrinsics/mathexact/MulExactIRepeatTest.java > Passed: compiler/intrinsics/mathexact/MulExactLConstantTest.java > Passed: compiler/intrinsics/mathexact/MulExactLNonConstantTest.java > Passed: compiler/intrinsics/mathexact/NegExactIConstantTest.java > Passed: compiler/intrinsics/mathexact/NegExactILoadTest.java > Passed: compiler/intrinsics/mathexact/NegExactILoopDependentTest.java > Passed: compiler/intrinsics/mathexact/NegExactINonConstantTest.java > Passed: compiler/intrinsics/mathexact/NegExactLConstantTest.java > Passed: compiler/intrinsics/mathexact/NegExactLNonConstantTest.java > Passed: compiler/intrinsics/mathexact/NestedMathExactTest.java > Passed: compiler/intrinsics/mathexact/SplitThruPhiTest.java > Passed: compiler/intrinsics/mathexact/SubExactICondTest.java > Passed: compiler/intrinsics/mathexact/SubExactIConstantTest.java > Passed: compiler/intrinsics/mathexact/SubExactILoadTest.java > Passed: compiler/intrinsics/mathexact/SubExactILoopDependentTest.java > Passed: compiler/intrinsics/mathexact/SubExactINonConstantTest.java > Passed: compiler/intrinsics/mathexact/SubExactIRepeatTest.java > Passed: compiler/intrinsics/mathexact/SubExactLConstantTest.java > Passed: compiler/intrinsics/mathexact/SubExactLNonConstantTest.java > Test results: passed: 50 > > Thank you. > > > Regards, > Gustavo > From martinrb at google.com Wed Nov 23 15:05:10 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 23 Nov 2016 07:05:10 -0800 Subject: RFR 8169808 Stream returning methods should specify if they are late binding In-Reply-To: <373316af-30f5-4901-be14-a64537ea2d5a@cs.oswego.edu> References: <2332D5F4-986E-4936-8665-933E64E5E6DE@oracle.com> <373316af-30f5-4901-be14-a64537ea2d5a@cs.oswego.edu> Message-ID: Right now, PBQ's spliterator is in violation of """A Spliterator that does not report IMMUTABLE or CONCURRENT is expected to have a documented policy concerning: when the spliterator binds to the element source;""" so I think we only get a choice between IMMUTABLE and CONCURRENT. I propose: --- src/main/java/util/concurrent/PriorityBlockingQueue.java 23 Nov 2016 14:51:10 -0000 1.116 +++ src/main/java/util/concurrent/PriorityBlockingQueue.java 23 Nov 2016 15:01:29 -0000 @@ -962,3 +962,6 @@ public int characteristics() { - return Spliterator.NONNULL | Spliterator.SIZED | Spliterator.SUBSIZED; + return (Spliterator.IMMUTABLE | + Spliterator.NONNULL | + Spliterator.SIZED | + Spliterator.SUBSIZED); } On Wed, Nov 23, 2016 at 6:14 AM, Doug Lea

      wrote: > On 11/22/2016 08:33 PM, Martin Buchholz wrote: > >> PriorityBlockingQueue has a late-binding-style, snapshot spliterator >> that does not report IMMUTABLE. It *is* immutable ... after the first >> access! Should we add IMMUTABLE? >> > > Probably not. > This might overly constrain future improvements; for example, someday > replacing with some linked structure. > Arguably, if so, we could just change the reported characteristics, > but that could be surprising to users, and possibly lead to subtle user > bugs. > > -Doug > > From gromero at linux.vnet.ibm.com Wed Nov 23 15:28:05 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 23 Nov 2016 13:28:05 -0200 Subject: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <583394C5.3030206@linux.vnet.ibm.com> Message-ID: <5835B585.5040807@linux.vnet.ibm.com> Hi Volker, On 23-11-2016 12:05, Volker Simonis wrote: > thanks a lot for tracking this down! Happy to contribute :) > The change looks good and I a can sponsor it once you get another > review from the build group and the FC Extension Request was approved. Thanks a lot for sponsoring it! > In general I'd advise to sign the OCTLA [1] to get access to the Java > SE TCK [2] as this contains quite a lot of additional conformance > tests which can be quite valuable for changes like this. > > Regards, > Volker > > [1] http://openjdk.java.net/legal/octla-java-se-8.pdf > [2] http://openjdk.java.net/groups/conformance/JckAccess/ Right. I'll check the documentation and find a way to get access to the TCK. Best regards, Gustavo From gromero at linux.vnet.ibm.com Wed Nov 23 15:29:51 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 23 Nov 2016 13:29:51 -0200 Subject: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <8d52c2bcc0c0473e8e79d3f794ca81f3@dewdfe13de06.global.corp.sap> References: <583394C5.3030206@linux.vnet.ibm.com> <8d52c2bcc0c0473e8e79d3f794ca81f3@dewdfe13de06.global.corp.sap> Message-ID: <5835B5EF.7070006@linux.vnet.ibm.com> Hi Martin, On 23-11-2016 12:38, Doerr, Martin wrote: > Hi Gustavo, > > thanks for providing the webrevs. > > I have ran the StrictMath jck tests which fail when building with -O3 and without -ffp-contract=off: > FailedTests: > api/java_lang/StrictMath/desc.html#acos javasoft.sqe.tests.api.java.lang.StrictMath.acos_test > api/java_lang/StrictMath/desc.html#asin javasoft.sqe.tests.api.java.lang.StrictMath.asin_test > api/java_lang/StrictMath/desc.html#atan javasoft.sqe.tests.api.java.lang.StrictMath.atan_test > api/java_lang/StrictMath/desc.html#atan2 javasoft.sqe.tests.api.java.lang.StrictMath.atan2_test > api/java_lang/StrictMath/desc.html#cos javasoft.sqe.tests.api.java.lang.StrictMath.cos_test > api/java_lang/StrictMath/desc.html#exp javasoft.sqe.tests.api.java.lang.StrictMath.exp_test > api/java_lang/StrictMath/desc.html#log javasoft.sqe.tests.api.java.lang.StrictMath.log_test > api/java_lang/StrictMath/desc.html#sin javasoft.sqe.tests.api.java.lang.StrictMath.sin_test > api/java_lang/StrictMath/desc.html#tan javasoft.sqe.tests.api.java.lang.StrictMath.tan_test > api/java_lang/StrictMath/index.html#expm1 javasoft.sqe.tests.api.java.lang.StrictMath.expm1Tests -TestCaseID ALL > api/java_lang/StrictMath/index.html#log10 javasoft.sqe.tests.api.java.lang.StrictMath.log10Tests -TestCaseID ALL > api/java_lang/StrictMath/index.html#log1p javasoft.sqe.tests.api.java.lang.StrictMath.log1pTests -TestCaseID ALL > > All of them have passed when building with -O3 and -ffp-contract=off (on linuxppc64le). Thank you very much for running the additional StrictMath jck tests against the change! Best regards, Gustavo From gromero at linux.vnet.ibm.com Wed Nov 23 15:33:43 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 23 Nov 2016 13:33:43 -0200 Subject: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <9327e543-f35b-b88f-2831-a51e265b6a30@oracle.com> References: <583394C5.3030206@linux.vnet.ibm.com> <9327e543-f35b-b88f-2831-a51e265b6a30@oracle.com> Message-ID: <5835B6D7.4020101@linux.vnet.ibm.com> Hi Erik, On 23-11-2016 12:29, Erik Joelsson wrote: > Build changes look ok. > > In CoreLibraries.gmk, I think it would have been ok to keep the conditional checking (OPENJDK_TARGET_CPU_ARCH, ppc), but this certainly works too. Thanks a lot for reviewing the change. Regards, Gustavo From Roger.Riggs at Oracle.com Wed Nov 23 15:43:25 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 23 Nov 2016 10:43:25 -0500 Subject: RFR 9: 8169645 : ObjectInputFilter.Config spec is ambiguous regarding overriding the filter via System properties Message-ID: <0a874321-916d-83e8-09fc-1035930d94ab@Oracle.com> Please review a clarification of the serialization filtering configuration of pattern based filters requested and reviewed by the JCK team. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-filter-config-8169645/ Thanks, Roger From dl at cs.oswego.edu Wed Nov 23 15:50:36 2016 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 23 Nov 2016 10:50:36 -0500 Subject: RFR 8169808 Stream returning methods should specify if they are late binding In-Reply-To: References: <2332D5F4-986E-4936-8665-933E64E5E6DE@oracle.com> <373316af-30f5-4901-be14-a64537ea2d5a@cs.oswego.edu> Message-ID: <35f50fe8-d8b8-e5fa-ccfa-674f0cdbe364@cs.oswego.edu> On 11/23/2016 10:05 AM, Martin Buchholz wrote: > Right now, PBQ's spliterator is in violation of > > """A Spliterator that does not report IMMUTABLE or CONCURRENT is > expected to have a documented policy concerning: when the spliterator > binds to the element source;""" > > so I think we only get a choice between IMMUTABLE and CONCURRENT. I > propose: Well, OK. Hopefully no user program will hardwire which choice is made, in case the implementation changes. -Doug > > --- src/main/java/util/concurrent/PriorityBlockingQueue.java23 Nov 2016 > 14:51:10 -00001.116 > +++ src/main/java/util/concurrent/PriorityBlockingQueue.java23 Nov 2016 > 15:01:29 -0000 > @@ -962,3 +962,6 @@ > public int characteristics() { > - return Spliterator.NONNULL | Spliterator.SIZED | > Spliterator.SUBSIZED; > + return (Spliterator.IMMUTABLE | > + Spliterator.NONNULL | > + Spliterator.SIZED | > + Spliterator.SUBSIZED); > } > > > > On Wed, Nov 23, 2016 at 6:14 AM, Doug Lea
      > wrote: > > On 11/22/2016 08:33 PM, Martin Buchholz wrote: > > PriorityBlockingQueue has a late-binding-style, snapshot spliterator > that does not report IMMUTABLE. It *is* immutable ... after the > first > access! Should we add IMMUTABLE? > > > Probably not. > This might overly constrain future improvements; for example, someday > replacing with some linked structure. > Arguably, if so, we could just change the reported characteristics, > but that could be surprising to users, and possibly lead to subtle > user bugs. > > -Doug > > From joe.darcy at oracle.com Wed Nov 23 16:10:14 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 23 Nov 2016 08:10:14 -0800 Subject: JDK 9 RFR of JDK-8169479: java.lang.reflect.Constructor class has wrong api documentation Message-ID: Hello, Please review the changes to address JDK-8169479: java.lang.reflect.Constructor class has wrong api documentation http://cr.openjdk.java.net/~darcy/8169479.0/ Patch inline below. There are a few issues reported in the bug: * The Constructor.toString method fails to state it prints out "throws" information. The implementation already does this and the analogous methods Constructor.toGenericString, Method.toString, etc. explicitly mention throws information already. * The specification of Executable.getDeclaringClass can be overridden to be more precise in the Constructor and Method subclasses. * In Constructor.toGenericString, "return type" is used where "class name" is meant. Thanks, -Joe --- old/src/java.base/share/classes/java/lang/reflect/Constructor.java 2016-11-23 07:33:00.095083685 -0800 +++ new/src/java.base/share/classes/java/lang/reflect/Constructor.java 2016-11-23 07:32:59.927083679 -0800 @@ -200,7 +200,8 @@ } /** - * {@inheritDoc} + * Returns the {@code Class} object representing the class that + * declares the constructor represented by this object. */ @Override public Class getDeclaringClass() { @@ -321,6 +322,11 @@ * public java.util.Hashtable(int,float) * } * + *

      If the constructor is declared to throw exceptions, the + * parameter list is followed by a space, followed by the word + * "{@code throws}" followed by a comma-separated list of the + * thrown exception types. + * *

      The only possible modifiers for constructors are the access * modifiers {@code public}, {@code protected} or * {@code private}. Only one of these may appear, or none if the @@ -357,13 +363,13 @@ * "Type...". * * A space is used to separate access modifiers from one another - * and from the type parameters or return type. If there are no + * and from the type parameters or class name. If there are no * type parameters, the type parameter list is elided; if the type * parameter list is present, a space separates the list from the * class name. If the constructor is declared to throw * exceptions, the parameter list is followed by a space, followed * by the word "{@code throws}" followed by a - * comma-separated list of the thrown exception types. + * comma-separated list of the generic thrown exception types. * *

      The only possible modifiers for constructors are the access * modifiers {@code public}, {@code protected} or --- old/src/java.base/share/classes/java/lang/reflect/Method.java 2016-11-23 07:33:00.495083699 -0800 +++ new/src/java.base/share/classes/java/lang/reflect/Method.java 2016-11-23 07:33:00.343083694 -0800 @@ -211,7 +211,8 @@ } /** - * {@inheritDoc} + * Returns the {@code Class} object representing the class or interface + * that declares the method represented by this object. */ @Override public Class getDeclaringClass() { @@ -372,7 +373,7 @@ * the method name, followed by a parenthesized, comma-separated * list of the method's formal parameter types. If the method * throws checked exceptions, the parameter list is followed by a - * space, followed by the word throws followed by a + * space, followed by the word "{@code throws}" followed by a * comma-separated list of the thrown exception types. * For example: * 

      @@ -428,8 +429,8 @@
       * parameter list is present, a space separates the list from the
       * class name.  If the method is declared to throw exceptions, the
       * parameter list is followed by a space, followed by the word
-     * throws followed by a comma-separated list of the generic thrown
-     * exception types.
+     * "{@code throws}" followed by a comma-separated list of the generic
+     * thrown exception types.
       *
       * 
      The access modifiers are placed in canonical order as
       * specified by "The Java Language Specification".  This is


From brian.burkhalter at oracle.com  Wed Nov 23 16:46:08 2016
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 23 Nov 2016 08:46:08 -0800
Subject: RFR 9: 8169645 : ObjectInputFilter.Config spec is ambiguous
	regarding overriding the filter via System properties
In-Reply-To: <0a874321-916d-83e8-09fc-1035930d94ab@Oracle.com>
References: <0a874321-916d-83e8-09fc-1035930d94ab@Oracle.com>
Message-ID: <26C2A27F-237D-4AD8-9D99-8824B35A1D1C@oracle.com>

Hi Roger,

This seems sufficiently clear.

Brian

On Nov 23, 2016, at 7:43 AM, Roger Riggs  wrote:

> Please review a clarification of the serialization filtering configuration of pattern based filters
> requested and reviewed by the JCK team.
> 
> Webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-filter-config-8169645/
> 
> Thanks, Roger
> 


From paul.sandoz at oracle.com  Wed Nov 23 17:25:36 2016
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 23 Nov 2016 09:25:36 -0800
Subject: JDK 9 RFR of JDK-8169479: java.lang.reflect.Constructor class has
	wrong api documentation
In-Reply-To: 
References: 
Message-ID: 

+1

Paul.

> On 23 Nov 2016, at 08:10, joe darcy  wrote:
> 
> Hello,
> 
> Please review the changes to address
> 
>    JDK-8169479: java.lang.reflect.Constructor class has wrong api documentation
>    http://cr.openjdk.java.net/~darcy/8169479.0/
> 
> Patch inline below. There are a few issues reported in the bug:
> 
> * The Constructor.toString method fails to state it prints out "throws" information. The implementation already does this and the analogous methods Constructor.toGenericString, Method.toString, etc. explicitly mention throws information already.
> 
> * The specification of Executable.getDeclaringClass can be overridden to be more precise in the Constructor and Method subclasses.
> 
> * In Constructor.toGenericString, "return type" is used where "class name" is meant.
> 
> Thanks,
> 
> -Joe

From brian.burkhalter at oracle.com  Wed Nov 23 17:27:35 2016
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 23 Nov 2016 09:27:35 -0800
Subject: JDK 9 RFR of JDK-8169479: java.lang.reflect.Constructor class has
	wrong api documentation
In-Reply-To: 
References: 
	
Message-ID: <0F7CA02A-FF3F-42FE-8997-523B5B89E78D@oracle.com>

+1

Brian

On Nov 23, 2016, at 9:25 AM, Paul Sandoz  wrote:

> +1
> 
> Paul.
> 
>> On 23 Nov 2016, at 08:10, joe darcy  wrote:
>> 
>> Hello,
>> 
>> Please review the changes to address
>> 
>>   JDK-8169479: java.lang.reflect.Constructor class has wrong api documentation
>>   http://cr.openjdk.java.net/~darcy/8169479.0/
>> 
>> Patch inline below. There are a few issues reported in the bug:
>> 
>> * The Constructor.toString method fails to state it prints out "throws" information. The implementation already does this and the analogous methods Constructor.toGenericString, Method.toString, etc. explicitly mention throws information already.
>> 
>> * The specification of Executable.getDeclaringClass can be overridden to be more precise in the Constructor and Method subclasses.
>> 
>> * In Constructor.toGenericString, "return type" is used where "class name" is meant.
>> 
>> Thanks,
>> 
>> -Joe


From huizhe.wang at oracle.com  Wed Nov 23 17:47:39 2016
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 23 Nov 2016 09:47:39 -0800
Subject: RFR JDK-8170192 [JAXP] [TESTBUG]
	test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java
	should grant permissions to jtreg, javatest, and testng jars
In-Reply-To: <5107a701-1cea-5017-2afb-c4a2031c4058@oracle.com>
References: <02f901d24543$d2b37f70$781a7e50$@oracle.com>
	<5107a701-1cea-5017-2afb-c4a2031c4058@oracle.com>
Message-ID: <5835D63B.2090609@oracle.com>

+1. Thanks Frank!

-Joe

On 11/23/16, 6:00 AM, Daniel Fuchs wrote:
> Hi Frank,
>
> Thanks for taking this on.
> Looks good to me.
>
> -- daniel
>
> On 23/11/16 04:41, Frank Yuan wrote:
>> Hi All
>>
>>
>>
>> Would you like to review
>> http://cr.openjdk.java.net/~fyuan/8170192/webrev.00/?
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170192
>>
>>
>>
>> This patch is fully same as Daniel provided except a few lines of
>> additional cleaning, thanks to Daniel for providing the patch!
>>
>>
>>
>> Thanks
>>
>> Frank
>>
>>
>>
>

From paul.sandoz at oracle.com  Wed Nov 23 18:07:19 2016
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 23 Nov 2016 10:07:19 -0800
Subject: RFR 8169808 Stream returning methods should specify if they are
	late binding
In-Reply-To: <35f50fe8-d8b8-e5fa-ccfa-674f0cdbe364@cs.oswego.edu>
References: <2332D5F4-986E-4936-8665-933E64E5E6DE@oracle.com>
	
	
	
	
	
	<373316af-30f5-4901-be14-a64537ea2d5a@cs.oswego.edu>
	
	<35f50fe8-d8b8-e5fa-ccfa-674f0cdbe364@cs.oswego.edu>
Message-ID: 


> On 23 Nov 2016, at 07:50, Doug Lea 
       wrote:
> 
> On 11/23/2016 10:05 AM, Martin Buchholz wrote:
>> Right now, PBQ's spliterator is in violation of
>> 
>> """A Spliterator that does not report IMMUTABLE or CONCURRENT is
>> expected to have a documented policy concerning: when the spliterator
>> binds to the element source;"""
>> 
>> so I think we only get a choice between IMMUTABLE and CONCURRENT.  I
>> propose:
> 
> Well, OK. Hopefully no user program will hardwire which
> choice is made, in case the implementation changes.
> 

I think we boxed ourselves into the corner when we specified that the PBQ.spliterator reports SIZED. Although the spliterator is specified to be weakly consistent, it cannot reflect any modifications subsequent to first size query, traversal or split.

Paul.

From paul.sandoz at oracle.com  Wed Nov 23 18:43:48 2016
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 23 Nov 2016 10:43:48 -0800
Subject: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove
In-Reply-To: 
References: 
Message-ID: <77A06B57-049C-494F-B4F2-FE302DF7554D@oracle.com>

Stuart and I refined the text to mention a concurrent modification policy (e.g. fail-fast or weakly consistent) of any overriding class.

Paul.


diff -r c7b932897909 src/java.base/share/classes/java/lang/Iterable.java
--- a/src/java.base/share/classes/java/lang/Iterable.java	Wed Nov 23 10:35:44 2016 -0800
+++ b/src/java.base/share/classes/java/lang/Iterable.java	Wed Nov 23 10:40:53 2016 -0800
@@ -53,10 +53,13 @@
     /**
      * Performs the given action for each element of the {@code Iterable}
      * until all elements have been processed or the action throws an
-     * exception.  Unless otherwise specified by the implementing class,
-     * actions are performed in the order of iteration (if an iteration order
-     * is specified).  Exceptions thrown by the action are relayed to the
+     * exception.  Actions are performed in the order of iteration, if that
+     * order is specified.  Exceptions thrown by the action are relayed to the
      * caller.
+     * 
      
+     * The behavior of this method is unspecified if the action performs
+     * side-effects that modify the underlying source of elements, unless an
+     * overriding class has specified a concurrent modification policy.
      *
      * @implSpec
      * 
      The default implementation behaves as if:
diff -r c7b932897909 src/java.base/share/classes/java/util/Iterator.java
--- a/src/java.base/share/classes/java/util/Iterator.java	Wed Nov 23 10:35:44 2016 -0800
+++ b/src/java.base/share/classes/java/util/Iterator.java	Wed Nov 23 10:40:53 2016 -0800
@@ -76,10 +76,15 @@
     /**
      * Removes from the underlying collection the last element returned
      * by this iterator (optional operation).  This method can be called
-     * only once per call to {@link #next}.  The behavior of an iterator
-     * is unspecified if the underlying collection is modified while the
-     * iteration is in progress in any way other than by calling this
-     * method.
+     * only once per call to {@link #next}.
+     * 
      
+     * The behavior of an iterator is unspecified if the underlying collection
+     * is modified while the iteration is in progress in any way other than by
+     * calling this method, unless an overriding class has specified a
+     * concurrent modification policy.
+     * 
      
+     * The behavior of an iterator is unspecified if this method is called
+     * after a call to the {@link #forEachRemaining forEachRemaining} method.
      *
      * @implSpec
      * The default implementation throws an instance of
@@ -102,6 +107,13 @@
      * have been processed or the action throws an exception.  Actions are
      * performed in the order of iteration, if that order is specified.
      * Exceptions thrown by the action are relayed to the caller.
+     * 
      
+     * The behavior of an iterator is unspecified if the action modifies the
+     * collection in any way (even by calling the {@link #remove remove} method),
+     * unless an overriding class has specified a concurrent modification policy.
+     * 
      
+     * Subsequent behavior of an iterator is unspecified if the action throws an
+     * exception.
      *
      * @implSpec
      * 
      The default implementation behaves as if:

From jonathan.gibbons at oracle.com  Wed Nov 23 20:26:09 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 23 Nov 2016 12:26:09 -0800
Subject: RFR JDK-8170192 [JAXP] [TESTBUG]
	test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java
	should grant permissions to jtreg, javatest, and testng jars
In-Reply-To: <02f901d24543$d2b37f70$781a7e50$@oracle.com>
References: <02f901d24543$d2b37f70$781a7e50$@oracle.com>
Message-ID: <5835FB61.8090707@oracle.com>

Frank,

More recent builds of testng.jar, such as the builds available on 
Maven,  have separated out the jcommander component so that two jar 
files are required: testng.jar and jcommander.jar.

You should consider taking jcommander.jar into account.  This will be 
more important/noticeable to folk outside Oracle who build their own 
copy of jtreg to use.

-- Jon

On 11/22/2016 08:41 PM, Frank Yuan wrote:
>
> Hi All
>
> Would you like to review 
> http://cr.openjdk.java.net/~fyuan/8170192/webrev.00/ 
> ?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170192
>
> This patch is fully same as Daniel provided except a few lines of 
> additional cleaning, thanks to Daniel for providing the patch!
>
> Thanks
>
> Frank
>


From jonathan.gibbons at oracle.com  Wed Nov 23 20:47:32 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 23 Nov 2016 12:47:32 -0800
Subject: Issues running JAXP jtreg tests ("java.lang.RuntimePermission"
	"accessDeclaredMembers")
In-Reply-To: <2df3195f1faf474dbd8593c2af8e50bf@DEWDFE13DE03.global.corp.sap>
References: <639787f8bc2e4a1e8baeed463f971d48@DEWDFE13DE03.global.corp.sap>								<32b3d0b6-74b9-1f96-13e2-039d5e350c7a@oracle.com>	<45c659a9f1e34c79bdbc6dea1a83e02a@DEWDFE13DE03.global.corp.sap>		<3a1b3a00-5358-a4da-f9a5-c48bd8842f3f@oracle.com>	<26b14bd4927a4b5387f4fddbaa0d2c06@DEWDFE13DE03.global.corp.sap>			
	<2df3195f1faf474dbd8593c2af8e50bf@DEWDFE13DE03.global.corp.sap>
Message-ID: <58360064.1070104@oracle.com>



On 11/22/2016 11:50 AM, Langer, Christoph wrote:
>   I agree that it would be nicer if jtreg would leave the jtreg lib path as java property to be able to elevate all of its contents. But the current proposal with a set of TEST_JARS of jtreg, javatest and testng is probably sufficient for jaxp testing.

https://bugs.openjdk.java.net/browse/CODETOOLS-7901844

-- Jon

From patrick at reini.net  Wed Nov 23 20:53:44 2016
From: patrick at reini.net (Patrick Reinhart)
Date: Wed, 23 Nov 2016 21:53:44 +0100
Subject: RFR: JDK-8167648: java.io.PrintWriter should have
	PrintWriter((String|File), Charset) constructors
In-Reply-To: 
References: <95e4229aebf14680b20f5757ec725304@reini.net>
	<31e02e3b48d118af5d4e8a2d1d5cfb73@reini.net>
	
	<9caca326f3c7ca1b637d6aa4f385a1bd@reini.net>
	<8d29b80ac6eecd357ba1fa102a84833e@reini.net>
	
	
Message-ID: 

Hi Stephen,

I changed the webrev accordingly:

http://cr.openjdk.java.net/~reinhapa/reviews/8167648/webrev.00

-Patrick

> Am 23.11.2016 um 14:45 schrieb Stephen Colebourne :
> 
> Returning the writer was my intention. I also intended it to return a
> new instance, to avoid changing the variable from final to non-final.
> Stephen
> 


From paul.sandoz at oracle.com  Wed Nov 23 22:39:42 2016
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 23 Nov 2016 14:39:42 -0800
Subject: RFR 8170155: StringBuffer and StringBuilder stream methods are not
	late-binding
Message-ID: 

Hi,

Please review:

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8170155-string-buffer-builder-late-binding/webrev/

This patch:

1) updates the StringBuilder/StringBuffer.chars()/codePoints() so they are late binding.

2) refactors the spliterator late binding and fail fast tests, separating them out, and to the former additional tests are added for CharSequence implementations and BitSet.

The code in AbstractStringBuilder has the following bounds check call to checkOffset:

1558         return StreamSupport.intStream(
1559                 () -> {
1560                     byte[] val = this.value; int count = this.count;
1561                     checkOffset(count, val.length >> coder);
1562                     return coder == LATIN1
1563                            ? new StringLatin1.CharsSpliterator(val, 0, count, 0)
1564                            : new StringUTF16.CharsSpliterator(val, 0, count, 0);
1565                 },
1566                 Spliterator.ORDERED | Spliterator.SIZED | Spliterator.SUBSIZED,
1567                 false);

(Separately checkOffset could be replaced with the internal Preconditions.checkIndex.)

On initial inspection that should be a no-op, but talking to Sherman we believe it is required for UTF-16 access, since the intrinsics do not perform bounds checks, so they need to be guarded (for conformance purposes if a no-op).

If so i propose the following to make this clearer:

return StreamSupport.intStream(
        () -> {
            byte[] val = this.value; int count = this.count;
            if (coder == LATIN1) {
                return new StringLatin1.CharsSpliterator(val, 0, count, 0);
            } else {
                // Perform an explicit bounds check since HotSpot
                // intrinsics to access UTF-16 characters in the byte[]
                // array will not perform bounds checks
                checkOffset(count, val.length >> coder);
                return new StringUTF16.CharsSpliterator(val, 0, count, 0);
            }
        },
        Spliterator.ORDERED | Spliterator.SIZED | Spliterator.SUBSIZED,
        false);

Paul.

From xueming.shen at oracle.com  Wed Nov 23 23:56:32 2016
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 23 Nov 2016 15:56:32 -0800
Subject: RFR 8170155: StringBuffer and StringBuilder stream methods are
	not late-binding
In-Reply-To: 
References: 
Message-ID: <58362CB0.6050109@oracle.com>

On 11/23/2016 02:39 PM, Paul Sandoz wrote:
> Hi,
>
> Please review:
>
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8170155-string-buffer-builder-late-binding/webrev/
>
> This patch:
>
> 1) updates the StringBuilder/StringBuffer.chars()/codePoints() so they are late binding.
>
> 2) refactors the spliterator late binding and fail fast tests, separating them out, and to the former additional tests are added for CharSequence implementations and BitSet.
>
> The code in AbstractStringBuilder has the following bounds check call to checkOffset:
>
> 1558         return StreamSupport.intStream(
> 1559                 () ->  {
> 1560                     byte[] val = this.value; int count = this.count;
> 1561                     checkOffset(count, val.length>>  coder);
> 1562                     return coder == LATIN1
> 1563                            ? new StringLatin1.CharsSpliterator(val, 0, count, 0)
> 1564                            : new StringUTF16.CharsSpliterator(val, 0, count, 0);
> 1565                 },
> 1566                 Spliterator.ORDERED | Spliterator.SIZED | Spliterator.SUBSIZED,
> 1567                 false);
>
> (Separately checkOffset could be replaced with the internal Preconditions.checkIndex.)
>
> On initial inspection that should be a no-op, but talking to Sherman we believe it is required for UTF-16 access, since the intrinsics do not perform bounds checks, so they need to be guarded (for conformance purposes if a no-op).

One of the purposes of having StringUTF16.putChar() (other than the charAt())
is to avoid the expensive boundary check on each/every char access. I'm forwarding
the email to Tobias to make sure it's still the case on hotspot side.

I'm not sure if it is still desired to do the same boundary check in case of LATIN1
for the benefit of consistency.  Assume there might be concurrent access/operation
between val = this.value and count = this.count; (for StringBuilder) for example,
the this.value got doubled and the this.count got increased. One will end up with
StringIndexOutOfBoundsException() from checkOffset, but the other will be ioobe
from vm?

Sherman


> If so i propose the following to make this clearer:
>
> return StreamSupport.intStream(
>          () ->  {
>              byte[] val = this.value; int count = this.count;
>              if (coder == LATIN1) {
>                  return new StringLatin1.CharsSpliterator(val, 0, count, 0);
>              } else {
>                  // Perform an explicit bounds check since HotSpot
>                  // intrinsics to access UTF-16 characters in the byte[]
>                  // array will not perform bounds checks
>                  checkOffset(count, val.length>>  coder);
>                  return new StringUTF16.CharsSpliterator(val, 0, count, 0);
>              }
>          },
>          Spliterator.ORDERED | Spliterator.SIZED | Spliterator.SUBSIZED,
>          false);
>
> Paul.


From frank.yuan at oracle.com  Thu Nov 24 02:29:24 2016
From: frank.yuan at oracle.com (Frank Yuan)
Date: Thu, 24 Nov 2016 10:29:24 +0800
Subject: RFR JDK-8170192 [JAXP] [TESTBUG]
	test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java
	should grant permissions to jtreg, javatest, and testng jars
In-Reply-To: <5835FB61.8090707@oracle.com>
References: <02f901d24543$d2b37f70$781a7e50$@oracle.com>
	<5835FB61.8090707@oracle.com>
Message-ID: <013b01d245fa$95b17020$c1145060$@oracle.com>

Hi Jon

 

Thank you for your advice!

 

Please check the update http://cr.openjdk.java.net/~fyuan/8170192/webrev.01/ , which contains jcommander.jar and removes the extra
blank lines following Christoph's suggestion.

 

Frank

 

From: Jonathan Gibbons [mailto:jonathan.gibbons at oracle.com] 
Sent: Thursday, November 24, 2016 4:26 AM
Subject: Re: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions
to jtreg, javatest, and testng jars

 

Frank,

More recent builds of testng.jar, such as the builds available on Maven,  have separated out the jcommander component so that two
jar files are required: testng.jar and jcommander.jar.

You should consider taking jcommander.jar into account.  This will be more important/noticeable to folk outside Oracle who build
their own copy of jtreg to use.

-- Jon

On 11/22/2016 08:41 PM, Frank Yuan wrote:

Hi All

 

Would you like to review http://cr.openjdk.java.net/~fyuan/8170192/webrev.00/
 ?

Bug: https://bugs.openjdk.java.net/browse/JDK-8170192

 

This patch is fully same as Daniel provided except a few lines of additional cleaning, thanks to Daniel for providing the patch!

 

Thanks

Frank

 

 


From shilpi.rastogi at oracle.com  Thu Nov 24 06:11:49 2016
From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com)
Date: Thu, 24 Nov 2016 11:41:49 +0530
Subject: RFR[9]: 8133719 java.lang.InternalError in
	java.lang.invoke.MethodHandleImpl$BindCaller.bindCaller
Message-ID: <68323143-287d-7782-9230-f5198bad14d3@oracle.com>

Hi All,

Please review fix for

https://bugs.openjdk.java.net/browse/JDK-8133719
http://cr.openjdk.java.net/~srastogi/8133719/webrev.01/


Thanks,
Shilpi


From daniel.fuchs at oracle.com  Thu Nov 24 10:22:54 2016
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 24 Nov 2016 10:22:54 +0000
Subject: RFR JDK-8170192 [JAXP] [TESTBUG]
	test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should
	grant permissions to jtreg, javatest, and testng jars
In-Reply-To: <013b01d245fa$95b17020$c1145060$@oracle.com>
References: <02f901d24543$d2b37f70$781a7e50$@oracle.com>
	<5835FB61.8090707@oracle.com>
	<013b01d245fa$95b17020$c1145060$@oracle.com>
Message-ID: <3573f887-9e8f-2b09-3ef8-f644794ebe3c@oracle.com>

Hi Frank,

Looks good to me.
Thanks for the advice Jon!

best regards,

-- daniel

On 24/11/16 02:29, Frank Yuan wrote:
> Hi Jon
>
>
>
> Thank you for your advice!
>
>
>
> Please check the update
> http://cr.openjdk.java.net/~fyuan/8170192/webrev.01/ , which contains
> jcommander.jar and removes the extra blank lines following Christoph?s
> suggestion.
>
>
>
> Frank
>
>
>
> *From:*Jonathan Gibbons [mailto:jonathan.gibbons at oracle.com]
> *Sent:* Thursday, November 24, 2016 4:26 AM
> *Subject:* Re: RFR JDK-8170192 [JAXP] [TESTBUG]
> test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should
> grant permissions to jtreg, javatest, and testng jars
>
>
>
> Frank,
>
> More recent builds of testng.jar, such as the builds available on
> Maven,  have separated out the jcommander component so that two jar
> files are required: testng.jar and jcommander.jar.
>
> You should consider taking jcommander.jar into account.  This will be
> more important/noticeable to folk outside Oracle who build their own
> copy of jtreg to use.
>
> -- Jon
>
> On 11/22/2016 08:41 PM, Frank Yuan wrote:
>
>     Hi All
>
>
>
>     Would you like to review
>     http://cr.openjdk.java.net/~fyuan/8170192/webrev.00/
>     ?
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8170192
>
>
>
>     This patch is fully same as Daniel provided except a few lines of
>     additional cleaning, thanks to Daniel for providing the patch!
>
>
>
>     Thanks
>
>     Frank
>
>
>
>
>


From lance.andersen at oracle.com  Thu Nov 24 12:58:22 2016
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 24 Nov 2016 07:58:22 -0500
Subject: RFR JDK-8170192 [JAXP] [TESTBUG]
	test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java
	should grant permissions to jtreg, javatest, and testng jars
In-Reply-To: <013b01d245fa$95b17020$c1145060$@oracle.com>
References: <02f901d24543$d2b37f70$781a7e50$@oracle.com>
	<5835FB61.8090707@oracle.com>
	<013b01d245fa$95b17020$c1145060$@oracle.com>
Message-ID: <5F4F601B-8AF1-4A1C-BDB7-88C96F19998B@oracle.com>

Looks good Frank

Best
Lance
> On Nov 23, 2016, at 9:29 PM, Frank Yuan  wrote:
> 
> Hi Jon
> 
> 
> 
> Thank you for your advice!
> 
> 
> 
> Please check the update http://cr.openjdk.java.net/~fyuan/8170192/webrev.01/ , which contains jcommander.jar and removes the extra
> blank lines following Christoph's suggestion.
> 
> 
> 
> Frank
> 
> 
> 
> From: Jonathan Gibbons [mailto:jonathan.gibbons at oracle.com] 
> Sent: Thursday, November 24, 2016 4:26 AM
> Subject: Re: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions
> to jtreg, javatest, and testng jars
> 
> 
> 
> Frank,
> 
> More recent builds of testng.jar, such as the builds available on Maven,  have separated out the jcommander component so that two
> jar files are required: testng.jar and jcommander.jar.
> 
> You should consider taking jcommander.jar into account.  This will be more important/noticeable to folk outside Oracle who build
> their own copy of jtreg to use.
> 
> -- Jon
> 
> On 11/22/2016 08:41 PM, Frank Yuan wrote:
> 
> Hi All
> 
> 
> 
> Would you like to review http://cr.openjdk.java.net/~fyuan/8170192/webrev.00/
>  ?
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170192
> 
> 
> 
> This patch is fully same as Daniel provided except a few lines of additional cleaning, thanks to Daniel for providing the patch!
> 
> 
> 
> Thanks
> 
> Frank
> 
> 
> 
> 
> 

 
  
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com 




From patrick at reini.net  Thu Nov 24 20:13:01 2016
From: patrick at reini.net (Patrick Reinhart)
Date: Thu, 24 Nov 2016 21:13:01 +0100
Subject: RFR: JDK-8167648: java.io.PrintWriter should have
	PrintWriter((String|File), Charset) constructors
In-Reply-To: 
References: <95e4229aebf14680b20f5757ec725304@reini.net>
	<31e02e3b48d118af5d4e8a2d1d5cfb73@reini.net>
	
	<9caca326f3c7ca1b637d6aa4f385a1bd@reini.net>
	<8d29b80ac6eecd357ba1fa102a84833e@reini.net>
	
	
	
Message-ID: <249C369B-D7D9-4879-A6B1-1A1BCE6951F4@reini.net>

Any sponsor for this?

> Am 23.11.2016 um 21:53 schrieb Patrick Reinhart :
> 
> Hi Stephen,
> 
> I changed the webrev accordingly:
> 
> http://cr.openjdk.java.net/~reinhapa/reviews/8167648/webrev.00
> 
> -Patrick
> 
>> Am 23.11.2016 um 14:45 schrieb Stephen Colebourne :
>> 
>> Returning the writer was my intention. I also intended it to return a
>> new instance, to avoid changing the variable from final to non-final.
>> Stephen
>> 
> 


From martin.doerr at sap.com  Wed Nov 23 14:38:09 2016
From: martin.doerr at sap.com (Doerr, Martin)
Date: Wed, 23 Nov 2016 14:38:09 +0000
Subject: RFR(s) 8170153: PPC64: Poor StrictMath performance due to
	non-optimized compilation
In-Reply-To: 
References: <583394C5.3030206@linux.vnet.ibm.com>
	
Message-ID: <8d52c2bcc0c0473e8e79d3f794ca81f3@dewdfe13de06.global.corp.sap>

Hi Gustavo,

thanks for providing the webrevs.

I have ran the StrictMath jck tests which fail when building with -O3 and without -ffp-contract=off:
FailedTests:
api/java_lang/StrictMath/desc.html#acos javasoft.sqe.tests.api.java.lang.StrictMath.acos_test
api/java_lang/StrictMath/desc.html#asin javasoft.sqe.tests.api.java.lang.StrictMath.asin_test
api/java_lang/StrictMath/desc.html#atan javasoft.sqe.tests.api.java.lang.StrictMath.atan_test
api/java_lang/StrictMath/desc.html#atan2 javasoft.sqe.tests.api.java.lang.StrictMath.atan2_test
api/java_lang/StrictMath/desc.html#cos javasoft.sqe.tests.api.java.lang.StrictMath.cos_test
api/java_lang/StrictMath/desc.html#exp javasoft.sqe.tests.api.java.lang.StrictMath.exp_test
api/java_lang/StrictMath/desc.html#log javasoft.sqe.tests.api.java.lang.StrictMath.log_test
api/java_lang/StrictMath/desc.html#sin javasoft.sqe.tests.api.java.lang.StrictMath.sin_test
api/java_lang/StrictMath/desc.html#tan javasoft.sqe.tests.api.java.lang.StrictMath.tan_test
api/java_lang/StrictMath/index.html#expm1 javasoft.sqe.tests.api.java.lang.StrictMath.expm1Tests -TestCaseID ALL
api/java_lang/StrictMath/index.html#log10 javasoft.sqe.tests.api.java.lang.StrictMath.log10Tests -TestCaseID ALL
api/java_lang/StrictMath/index.html#log1p javasoft.sqe.tests.api.java.lang.StrictMath.log1pTests -TestCaseID ALL

All of them have passed when building with -O3 and -ffp-contract=off (on linuxppc64le).

So thumbs up from my side.

Thanks and best regards,
Martin



-----Original Message-----
From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis
Sent: Mittwoch, 23. November 2016 15:06
To: Gustavo Romero 
Cc: build-dev ; ppc-aix-port-dev at openjdk.java.net; Java Core Libs ; hotspot-dev at openjdk.java.net
Subject: Re: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi Gustavo,

thanks a lot for tracking this down!

The change looks good and I a can sponsor it once you get another review from the build group and the FC Extension Request was approved.

In general I'd advise to sign the OCTLA [1] to get access to the Java SE TCK [2] as this contains quite a lot of additional conformance tests which can be quite valuable for changes like this.

Regards,
Volker

[1] http://openjdk.java.net/legal/octla-java-se-8.pdf
[2] http://openjdk.java.net/groups/conformance/JckAccess/


On Tue, Nov 22, 2016 at 1:43 AM, Gustavo Romero  wrote:
> Hi,
>
> Could the following change be reviewed, please?
>
> webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/
> webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/jdk/
> bug:        https://bugs.openjdk.java.net/browse/JDK-8170153
>
> It enables fdlibm optimization on Linux PPC64 LE & BE and hence speeds 
> up the StrictMath methods (in some cases up to 3x) on that platform.
>
> On PPC64 fdlibm optimization can be done without precision issues if 
> floating-point expression contraction is disable, i.e. if the compiler 
> does not use floating-point multiply-add (FMA). For further details 
> please refer to gcc
> bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386
>
> No regression was observed on Math and StrictMath tests:
>
> Passed: java/lang/Math/AbsPositiveZero.java
> Passed: java/lang/Math/Atan2Tests.java
> Passed: java/lang/Math/CeilAndFloorTests.java
> Passed: java/lang/Math/CubeRootTests.java
> Passed: java/lang/Math/DivModTests.java
> Passed: java/lang/Math/ExactArithTests.java
> Passed: java/lang/Math/Expm1Tests.java
> Passed: java/lang/Math/FusedMultiplyAddTests.java
> Passed: java/lang/Math/HyperbolicTests.java
> Passed: java/lang/Math/HypotTests.java
> Passed: java/lang/Math/IeeeRecommendedTests.java
> Passed: java/lang/Math/Log10Tests.java
> Passed: java/lang/Math/Log1pTests.java
> Passed: java/lang/Math/MinMax.java
> Passed: java/lang/Math/MultiplicationTests.java
> Passed: java/lang/Math/PowTests.java
> Passed: java/lang/Math/Rint.java
> Passed: java/lang/Math/RoundTests.java
> Passed: java/lang/Math/SinCosCornerCasesTests.java
> Passed: java/lang/Math/TanTests.java
> Passed: java/lang/Math/WorstCaseTests.java
> Test results: passed: 21
>
> Passed: java/lang/StrictMath/CubeRootTests.java
> Passed: java/lang/StrictMath/ExactArithTests.java
> Passed: java/lang/StrictMath/Expm1Tests.java
> Passed: java/lang/StrictMath/HyperbolicTests.java
> Passed: java/lang/StrictMath/HypotTests.java
> Passed: java/lang/StrictMath/Log10Tests.java
> Passed: java/lang/StrictMath/Log1pTests.java
> Passed: java/lang/StrictMath/PowTests.java
> Test results: passed: 8
>
> and also on the following hotspot tests:
>
> Passed: compiler/intrinsics/mathexact/sanity/AddExactIntTest.java
> Passed: compiler/intrinsics/mathexact/sanity/AddExactLongTest.java
> Passed: 
> compiler/intrinsics/mathexact/sanity/DecrementExactIntTest.java
> Passed: 
> compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java
> Passed: 
> compiler/intrinsics/mathexact/sanity/IncrementExactIntTest.java
> Passed: 
> compiler/intrinsics/mathexact/sanity/IncrementExactLongTest.java
> Passed: compiler/intrinsics/mathexact/sanity/MultiplyExactIntTest.java
> Passed: 
> compiler/intrinsics/mathexact/sanity/MultiplyExactLongTest.java
> Passed: compiler/intrinsics/mathexact/sanity/NegateExactIntTest.java
> Passed: compiler/intrinsics/mathexact/sanity/NegateExactLongTest.java
> Passed: compiler/intrinsics/mathexact/sanity/SubtractExactIntTest.java
> Passed: 
> compiler/intrinsics/mathexact/sanity/SubtractExactLongTest.java
> Passed: compiler/intrinsics/mathexact/AddExactICondTest.java
> Passed: compiler/intrinsics/mathexact/AddExactIConstantTest.java
> Passed: compiler/intrinsics/mathexact/AddExactILoadTest.java
> Passed: compiler/intrinsics/mathexact/AddExactILoopDependentTest.java
> Passed: compiler/intrinsics/mathexact/AddExactINonConstantTest.java
> Passed: compiler/intrinsics/mathexact/AddExactIRepeatTest.java
> Passed: compiler/intrinsics/mathexact/AddExactLConstantTest.java
> Passed: compiler/intrinsics/mathexact/AddExactLNonConstantTest.java
> Passed: compiler/intrinsics/mathexact/CompareTest.java
> Passed: compiler/intrinsics/mathexact/DecExactITest.java
> Passed: compiler/intrinsics/mathexact/DecExactLTest.java
> Passed: compiler/intrinsics/mathexact/GVNTest.java
> Passed: compiler/intrinsics/mathexact/IncExactITest.java
> Passed: compiler/intrinsics/mathexact/IncExactLTest.java
> Passed: compiler/intrinsics/mathexact/MulExactICondTest.java
> Passed: compiler/intrinsics/mathexact/MulExactIConstantTest.java
> Passed: compiler/intrinsics/mathexact/MulExactILoadTest.java
> Passed: compiler/intrinsics/mathexact/MulExactILoopDependentTest.java
> Passed: compiler/intrinsics/mathexact/MulExactINonConstantTest.java
> Passed: compiler/intrinsics/mathexact/MulExactIRepeatTest.java
> Passed: compiler/intrinsics/mathexact/MulExactLConstantTest.java
> Passed: compiler/intrinsics/mathexact/MulExactLNonConstantTest.java
> Passed: compiler/intrinsics/mathexact/NegExactIConstantTest.java
> Passed: compiler/intrinsics/mathexact/NegExactILoadTest.java
> Passed: compiler/intrinsics/mathexact/NegExactILoopDependentTest.java
> Passed: compiler/intrinsics/mathexact/NegExactINonConstantTest.java
> Passed: compiler/intrinsics/mathexact/NegExactLConstantTest.java
> Passed: compiler/intrinsics/mathexact/NegExactLNonConstantTest.java
> Passed: compiler/intrinsics/mathexact/NestedMathExactTest.java
> Passed: compiler/intrinsics/mathexact/SplitThruPhiTest.java
> Passed: compiler/intrinsics/mathexact/SubExactICondTest.java
> Passed: compiler/intrinsics/mathexact/SubExactIConstantTest.java
> Passed: compiler/intrinsics/mathexact/SubExactILoadTest.java
> Passed: compiler/intrinsics/mathexact/SubExactILoopDependentTest.java
> Passed: compiler/intrinsics/mathexact/SubExactINonConstantTest.java
> Passed: compiler/intrinsics/mathexact/SubExactIRepeatTest.java
> Passed: compiler/intrinsics/mathexact/SubExactLConstantTest.java
> Passed: compiler/intrinsics/mathexact/SubExactLNonConstantTest.java
> Test results: passed: 50
>
> Thank you.
>
>
> Regards,
> Gustavo
>

From tobias.hartmann at oracle.com  Fri Nov 25 10:47:06 2016
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 25 Nov 2016 11:47:06 +0100
Subject: RFR 8170155: StringBuffer and StringBuilder stream methods are
	not late-binding
In-Reply-To: <58362CB0.6050109@oracle.com>
References: 
	<58362CB0.6050109@oracle.com>
Message-ID: <583816AA.6080101@oracle.com>

Hi,

On 24.11.2016 00:56, Xueming Shen wrote:
> On 11/23/2016 02:39 PM, Paul Sandoz wrote:
>> Hi,
>>
>> Please review:
>>
>>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8170155-string-buffer-builder-late-binding/webrev/
>>
>> This patch:
>>
>> 1) updates the StringBuilder/StringBuffer.chars()/codePoints() so they are late binding.
>>
>> 2) refactors the spliterator late binding and fail fast tests, separating them out, and to the former additional tests are added for CharSequence implementations and BitSet.
>>
>> The code in AbstractStringBuilder has the following bounds check call to checkOffset:
>>
>> 1558         return StreamSupport.intStream(
>> 1559                 () ->  {
>> 1560                     byte[] val = this.value; int count = this.count;
>> 1561                     checkOffset(count, val.length>>  coder);
>> 1562                     return coder == LATIN1
>> 1563                            ? new StringLatin1.CharsSpliterator(val, 0, count, 0)
>> 1564                            : new StringUTF16.CharsSpliterator(val, 0, count, 0);
>> 1565                 },
>> 1566                 Spliterator.ORDERED | Spliterator.SIZED | Spliterator.SUBSIZED,
>> 1567                 false);
>>
>> (Separately checkOffset could be replaced with the internal Preconditions.checkIndex.)

Yes, if possible, bound checks should be replaced by the intrinsified Preconditions.check() (see https://bugs.openjdk.java.net/browse/JDK-8042997).

>> On initial inspection that should be a no-op, but talking to Sherman we believe it is required for UTF-16 access, since the intrinsics do not perform bounds checks, so they need to be guarded (for conformance purposes if a no-op).

If an out of bounds access is possible when using StringUTF16.putChar/getChar(), the check in the Java code is required because the intrinsic does not implement any bound checks (see below).

> One of the purposes of having StringUTF16.putChar() (other than the charAt())
> is to avoid the expensive boundary check on each/every char access. I'm forwarding
> the email to Tobias to make sure it's still the case on hotspot side.

Yes, this is still correct. For performance reasons, the intrinsic for StringUTF16.putChar/getChar() has no boundary checks (see LibraryCallKit::inline_string_char_access()). It should *only* be used without a bounds check in the Java code if the index is guaranteed to be always in bounds.

> I'm not sure if it is still desired to do the same boundary check in case of LATIN1
> for the benefit of consistency.  Assume there might be concurrent access/operation
> between val = this.value and count = this.count; (for StringBuilder) for example,
> the this.value got doubled and the this.count got increased. One will end up with
> StringIndexOutOfBoundsException() from checkOffset, but the other will be ioobe
> from vm?

You mean when hitting a check in an intrinsic compared to when hitting a check in the Java wrapper?

Actually, bound checks should always be done in the Java wrapper method that calls the (unchecked) intrinsic. In general, the unchecked intrinsic should not be called directly. StringUTF16.putChar/getChar() is an exception because there are places where we we need to omit the check for performance reasons.

I'm planning to revisit this with JDK-8156534 in JDK 10.

Best regards,
Tobias

> 
> Sherman
> 
> 
>> If so i propose the following to make this clearer:
>>
>> return StreamSupport.intStream(
>>          () ->  {
>>              byte[] val = this.value; int count = this.count;
>>              if (coder == LATIN1) {
>>                  return new StringLatin1.CharsSpliterator(val, 0, count, 0);
>>              } else {
>>                  // Perform an explicit bounds check since HotSpot
>>                  // intrinsics to access UTF-16 characters in the byte[]
>>                  // array will not perform bounds checks
>>                  checkOffset(count, val.length>>  coder);
>>                  return new StringUTF16.CharsSpliterator(val, 0, count, 0);
>>              }
>>          },
>>          Spliterator.ORDERED | Spliterator.SIZED | Spliterator.SUBSIZED,
>>          false);
>>
>> Paul.
> 

From christoph.langer at sap.com  Fri Nov 25 12:25:24 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 25 Nov 2016 12:25:24 +0000
Subject: RFR: 8169631: [JAXP] XALAN: transformation of XML via
	namespace-unaware SAX input yields a different result than
	namespace-unaware DOM input
In-Reply-To: <5834985F.4060503@oracle.com>
References: <313759790392479fa80a10542ab664ec@dewdfe13de07.global.corp.sap>
	<582A7170.7030100@oracle.com>
	<4be5158237814eeb9352fe8fe344e47c@dewdfe13de07.global.corp.sap>
	<582E8944.7090906@oracle.com>
	
	<582F90D6.1040308@oracle.com> <5834985F.4060503@oracle.com>
Message-ID: <4ff8d067fd88496ba536c65610ee54cb@DEWDFE13DE03.global.corp.sap>

Hi Joe,

when trying to finish this up, I had a closer look again.

I found out that it's necessary to look at attributes as well and handle the case where namespace prefixes are used.

Here is a new version of the changeset that passes all jaxp jtreg tests:
http://cr.openjdk.java.net/~clanger/webrevs/8169631.1/

Now I would also throw out prefixes in localName if we don't have namespace support - for both, elements and attributes (in SAX2DTM2.startElement()).

I also removed some qname handling in DOM2SAX as it is not needed with my changes to SAX2DTM2 anymore.

The test case was adopted.

Thanks & best regards
Christoph

> -----Original Message-----
> From: Joe Wang [mailto:huizhe.wang at oracle.com]
> Sent: Dienstag, 22. November 2016 20:11
> To: Langer, Christoph 
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via
> namespace-unaware SAX input yields a different result than namespace-
> unaware DOM input
> 
> Hi Christoph,
> 
> Once you're able to run all tests, feel free to push the changeset.
> Frank has fixed the Smoke test.
> 
> Thanks,
> Joe
> 
> On 11/18/16, 3:37 PM, Joe Wang wrote:
> > Hi Christoph,
> >
> > Thanks for explaining the customer's dilemma with regard to their
> > legacy process.
> >
> > The testcase I sent you was extracted from an internal SQE smoke test.
> > I agree with your analysis, the 'golden' file which has been in there
> > for over 10 years turns out to be wrong and needs to be updated.
> >
> > To fix this issue, we need to get that test fixed, and the check-in of
> > your patch and that of the test need needs to happen simultaneously.
> > Would you mind wanting for me to go through an internal process to get
> > a patch ready, then we can check in almost at the same time?
> >
> > Best,
> > Joe
> >
> > On 11/18/16, 2:51 PM, Langer, Christoph wrote:
> >> Hi Joe,
> >>
> >> thanks for the feedback.
> >>
> >> I've now understood the testcase that you've sent over and the reason
> >> that it is reporting failure after my fix is that the output of its
> >> transform operation is rather correct now. And before it was wrong. :)
> >> The test is comparing the actual result to a "golden" result file in
> >> the end and both of these were not looking healthy so far. The reason
> >> is that your test is using a namespace unaware SAX Parser as input.
> >> With the current JDK XALAN, you could already modify your smoketest
> >> to use a namespace aware parser.
> >>
> >> E.g. replace lines
> >>
> >> 82        // Use the JAXP way to get an XMLReader
> >> 83        XMLReader reader =
> >> SAXParserFactory.newInstance().newSAXParser().getXMLReader();
> >>
> >> with
> >>
> >> 82        // Use the JAXP way to get an XMLReader
> >> 83        SAXParserFactory spf = SAXParserFactory.newInstance();
> >> 84        spf.setNamespaceAware(true);
> >> 85        XMLReader reader = spf.newSAXParser().getXMLReader();
> >>
> >> ...and you would already get correct results that also DOM input or
> >> Stream Input would yield.
> >>
> >> So, are there other concerns/issues with this fix? Do you want me to
> >> include a transformation operation like the one that your SmokeTest
> >> does to TransformerTest which would illustrate the problem with
> >> namespace unaware SAX input data?
> >>
> >> Best regards
> >> Christoph
> >>
> >>> -----Original Message-----
> >>> From: Joe Wang [mailto:huizhe.wang at oracle.com]
> >>> Sent: Freitag, 18. November 2016 05:53
> >>> To: Langer, Christoph
> >>> Cc: core-libs-dev at openjdk.java.net
> >>> Subject: Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via
> >>> namespace-unaware SAX input yields a different result than namespace-
> >>> unaware DOM input
> >>>
> >>>
> >>>
> >>> On 11/14/16, 11:43 PM, Langer, Christoph wrote:
> >>>> Hi Joe,
> >>>>
> >>>> thanks for looking.
> >>>>
> >>>> Can you let me know which smoke test is failing? I didn't see
> >>>> issues so far - I
> >>> was merely running the jtreg unittests for transformer.
> >>>
> >>> I sent the test to your mailbox.
> >>>> I stepped back from replacing Vector with ArrayList for
> >>>> m_prefixMappings
> >>> because the code is using methods indexOf() with a start index and
> >>> setSize() for
> >>> which ArrayList has no direct matchings. One could, for sure, add
> >>> some other
> >>> coding, e.g. use ArrayList's subList() method for the index based
> >>> search - but I
> >>> wouldn't want to run the risk of adding a regression here just
> >>> because I
> >>> modified the code and did not well test it. But if you insist, I
> >>> could have another
> >>> look.
> >>>
> >>> Ok, that's fine. subList would do, but setSize may need a bit more
> >>> work.
> >>>
> >>> Best,
> >>> Joe
> >>>> Best regards
> >>>> Christoph
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Joe Wang [mailto:huizhe.wang at oracle.com]
> >>>>> Sent: Dienstag, 15. November 2016 03:23
> >>>>> To: Langer, Christoph
> >>>>> Cc: core-libs-dev at openjdk.java.net
> >>>>> Subject: Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via
> >>>>> namespace-unaware SAX input yields a different result than namespace-
> >>>>> unaware DOM input
> >>>>>
> >>>>> Hi Christoph,
> >>>>>
> >>>>> Not all tests have finished yet, but there's at least one failure
> >>>>> in the
> >>>>> smoke test. I'll get to the details when I have time.
> >>>>>
> >>>>> Any reason why m_prefixMappings can not be replaced with ArrayList?
> >>>>>
> >>>>> Thanks,
> >>>>> Joe
> >>>>>
> >>>>> On 11/14/16, 6:10 AM, Langer, Christoph wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> please review this fix for bug 8169631.
> >>>>>>
> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8169631
> >>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169631.0/
> >>>>>>
> >>>>>> When XALAN is handling namespace unaware input, it behaves
> >>>>>> differently
> >>>>> while using SAX input compared to DOM input.
> >>>>>> With both input source types, the class
> >>>>> com.sun.org.apache.xml.internal.dtm.ref.sax2dtm.SAX2DTM2 converts
> SAX
> >>>>> input into a DTM representation for processing by the XALAN
> >>>>> transformer.
> >>> Its
> >>>>> method startElement takes URI, localname and qName as attribute.
> >>>>> In case
> >>> of
> >>>>> missing feature namespaces, startElement and localname can be empty.
> >>>>> However, the function uses the localname value for the call to
> >>>>> m_expandedNameTable.getExpandedTypeID() and further processing. In
> >>>>> the
> >>>>> case where only qName has data, this leads to issues.
> >>>>>> When using DOM input, the class
> >>>>> com.sun.org.apache.xalan.internal.xsltc.trax.DOM2SAX converts the
> DOM
> >>> input
> >>>>> into SAX input. In the case of empty localname, it fills localname
> >>>>> with qname
> >>>>> data. See method getLocalName() [1], called by parse() [2].
> >>>>>> When directly using SAX input, the SAX parser calls the
> >>>>>> startElement()
> >>>>> function on XALAN's handler with empty uri and localname - which
> >>>>> seems
> >>>>> correct, as per the spec.
> >>>>>> Both paths end up in SAX2DTM2's startElement(). So I suggest to
> >>>>>> change
> >>> this
> >>>>> method to handle the case when uri and localname are empty and
> >>>>> then set
> >>>>> qname as localname. Maybe one should even change DOM2SAX's
> >>>>> getLocalName handling to not fill localname with qname in case it
> >>>>> is empty
> >>>>> after SAX2DTM was changed..
> >>>>>> Generally, JavaDoc for SAXSource says that "Attempting to
> >>>>>> transform an
> >>> input
> >>>>> source that is not generated with a namespace-aware parser may
> >>>>> result in
> >>>>> errors." But why not fix some of these :)
> >>>>>> Furthermore I did some cleanups in the code.
> >>>>>>
> >>>>>> Thanks and best regards
> >>>>>> Christoph
> >>>>>>
> >>>>>> [1]
> >>>
> http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/shar
> >>>
> >>>
> e/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l139
> >>>
> >>>>>> [2]
> >>>
> http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/shar
> >>>
> >>>
> e/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l279
> >>>
> >>>>>> [3]
> >>>
> https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/sax/SAXSource
> >>>
> >>>>> .html

From volker.simonis at gmail.com  Fri Nov 25 13:32:37 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 25 Nov 2016 14:32:37 +0100
Subject: RFR(s) 8170153: PPC64: Poor StrictMath performance due to
	non-optimized compilation
In-Reply-To: <5835B6D7.4020101@linux.vnet.ibm.com>
References: <583394C5.3030206@linux.vnet.ibm.com>
	<9327e543-f35b-b88f-2831-a51e265b6a30@oracle.com>
	<5835B6D7.4020101@linux.vnet.ibm.com>
Message-ID: 

Hi Gustavo,

we've realized that we have exactly the same problem on Linux/s390 so
I hope you don't mind that I've updated the bug and the webrev to also
include the fix for Linux/s390:

http://cr.openjdk.java.net/~simonis/webrevs/2016/8170153.top/
http://cr.openjdk.java.net/~simonis/webrevs/2016/8170153.jdk/
https://bugs.openjdk.java.net/browse/JDK-8170153

The top-level change stays the same (I've only added the current
reviewers) and for the jdk change I've just added Linux/s390 as
another platform which can compile fdlibm with HIGH optimization.

Thanks,
Volker

On Wed, Nov 23, 2016 at 4:33 PM, Gustavo Romero
 wrote:
> Hi Erik,
>
> On 23-11-2016 12:29, Erik Joelsson wrote:
>> Build changes look ok.
>>
>> In CoreLibraries.gmk, I think it would have been ok to keep the conditional checking (OPENJDK_TARGET_CPU_ARCH, ppc), but this certainly works too.
>
> Thanks a lot for reviewing the change.
>
>
> Regards,
> Gustavo
>

From erik.joelsson at oracle.com  Fri Nov 25 14:06:27 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 25 Nov 2016 15:06:27 +0100
Subject: RFR(s) 8170153: PPC64: Poor StrictMath performance due to
	non-optimized compilation
In-Reply-To: 
References: <583394C5.3030206@linux.vnet.ibm.com>
	<9327e543-f35b-b88f-2831-a51e265b6a30@oracle.com>
	<5835B6D7.4020101@linux.vnet.ibm.com>
	
Message-ID: <98b7942d-837e-0166-93de-9ea256bb1ecf@oracle.com>

Looks good.

/Erik


On 2016-11-25 14:32, Volker Simonis wrote:
> Hi Gustavo,
>
> we've realized that we have exactly the same problem on Linux/s390 so
> I hope you don't mind that I've updated the bug and the webrev to also
> include the fix for Linux/s390:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2016/8170153.top/
> http://cr.openjdk.java.net/~simonis/webrevs/2016/8170153.jdk/
> https://bugs.openjdk.java.net/browse/JDK-8170153
>
> The top-level change stays the same (I've only added the current
> reviewers) and for the jdk change I've just added Linux/s390 as
> another platform which can compile fdlibm with HIGH optimization.
>
> Thanks,
> Volker
>
> On Wed, Nov 23, 2016 at 4:33 PM, Gustavo Romero
>  wrote:
>> Hi Erik,
>>
>> On 23-11-2016 12:29, Erik Joelsson wrote:
>>> Build changes look ok.
>>>
>>> In CoreLibraries.gmk, I think it would have been ok to keep the conditional checking (OPENJDK_TARGET_CPU_ARCH, ppc), but this certainly works too.
>> Thanks a lot for reviewing the change.
>>
>>
>> Regards,
>> Gustavo
>>


From weijun.wang at oracle.com  Sat Nov 26 08:54:50 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Sat, 26 Nov 2016 16:54:50 +0800
Subject: RFR 8170364: FilePermission path modified during merge
Message-ID: <2D9EFE53-ECE6-49E2-9D83-17055360EAA4@oracle.com>

Please take a review at

   http://cr.openjdk.java.net/~weijun/8170364/webrev.00/

The compatibility layer introduced in the new FilePermission implementation requires one FilePermission to imply another with either a relative path or an absolute path. This is solved with a private field npath2 inside. When this field is set, the permission's name is modified a little (JDK-8168127) so that when adding to a FilePermissionCollection, it is not confused with one without the field. Unfortunately, this modified name is reused in the merge to create a new "merged" FilePermission which contains a malformed path now.

This fix creates a new non-public method to create this "merged" FilePermission.

I checked other places and seems the name is not used to create a new FilePermission.

Thanks
Max


From Alan.Bateman at oracle.com  Sun Nov 27 10:12:30 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 27 Nov 2016 10:12:30 +0000
Subject: RFR 8170364: FilePermission path modified during merge
In-Reply-To: <2D9EFE53-ECE6-49E2-9D83-17055360EAA4@oracle.com>
References: <2D9EFE53-ECE6-49E2-9D83-17055360EAA4@oracle.com>
Message-ID: 

On 26/11/2016 08:54, Wang Weijun wrote:

> Please take a review at
>
>     http://cr.openjdk.java.net/~weijun/8170364/webrev.00/
>
> The compatibility layer introduced in the new FilePermission implementation requires one FilePermission to imply another with either a relative path or an absolute path. This is solved with a private field npath2 inside. When this field is set, the permission's name is modified a little (JDK-8168127) so that when adding to a FilePermissionCollection, it is not confused with one without the field. Unfortunately, this modified name is reused in the merge to create a new "merged" FilePermission which contains a malformed path now.
>
> This fix creates a new non-public method to create this "merged" FilePermission.
>
> I checked other places and seems the name is not used to create a new FilePermission.
>
Ideally FilePermission (and all permissions) would have final fields, I 
hope that can be fixed some day. In the mean-time then having 
withNewActions create a new FilePermission and then mutate it looks a 
bit ugly, can't you just introduce a new non-public constructor to 
create it with the effective mask?

In passing then maybe the comment at L1063-1065 can be re-examined and 
it looks to be stale (the specific bootstrapping issue mentioned was 
fixed in 2015).

The test is one specific scenario and I wonder if you've considered 
beefing this up to other scenarios and other targets so that it's more 
broadly testing the merging scenarios.

-Alan



From weijun.wang at oracle.com  Sun Nov 27 11:13:52 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Sun, 27 Nov 2016 19:13:52 +0800
Subject: RFR 8170364: FilePermission path modified during merge
In-Reply-To: 
References: <2D9EFE53-ECE6-49E2-9D83-17055360EAA4@oracle.com>
	
Message-ID: <6CF04250-1585-4FD4-81F7-E630121DEB84@oracle.com>


> On Nov 27, 2016, at 6:12 PM, Alan Bateman  wrote:
> 
> On 26/11/2016 08:54, Wang Weijun wrote:
> 
>> Please take a review at
>> 
>>    http://cr.openjdk.java.net/~weijun/8170364/webrev.00/
>> 
>> The compatibility layer introduced in the new FilePermission implementation requires one FilePermission to imply another with either a relative path or an absolute path. This is solved with a private field npath2 inside. When this field is set, the permission's name is modified a little (JDK-8168127) so that when adding to a FilePermissionCollection, it is not confused with one without the field. Unfortunately, this modified name is reused in the merge to create a new "merged" FilePermission which contains a malformed path now.
>> 
>> This fix creates a new non-public method to create this "merged" FilePermission.
>> 
>> I checked other places and seems the name is not used to create a new FilePermission.
>> 
> Ideally FilePermission (and all permissions) would have final fields, I hope that can be fixed some day. 

Me too, but we have that huge init() method now.

> In the mean-time then having withNewActions create a new FilePermission and then mutate it looks a bit ugly, can't you just introduce a new non-public constructor to create it with the effective mask?

The private "clone" constructor is now used in 3 places, all with a mutation right after (lines 267, 280, 993). I've taken care that only newly created objects are mutated this way. Creating 3 new constructors looks like too many duplicated codes.

> 
> In passing then maybe the comment at L1063-1065 can be re-examined and it looks to be stale (the specific bootstrapping issue mentioned was fixed in 2015).

I can try.

> 
> The test is one specific scenario and I wonder if you've considered beefing this up to other scenarios and other targets so that it's more broadly testing the merging scenarios.

I can add 2 more lines on checking the absolute path, and maybe with delete, execute and readlink (1+1+1+1, 2+2, 3+1 etc). The merge is only about the name and any name is the same, so it seems unnecessary to try other names.

Thanks
Max


> 
> -Alan
> 
> 


From weijun.wang at oracle.com  Mon Nov 28 00:01:07 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Mon, 28 Nov 2016 08:01:07 +0800
Subject: RFR 8170364: FilePermission path modified during merge
In-Reply-To: <6CF04250-1585-4FD4-81F7-E630121DEB84@oracle.com>
References: <2D9EFE53-ECE6-49E2-9D83-17055360EAA4@oracle.com>
	
	<6CF04250-1585-4FD4-81F7-E630121DEB84@oracle.com>
Message-ID: <99F23B3A-AF21-4604-B9C2-B335279FF983@oracle.com>


> On Nov 27, 2016, at 7:13 PM, Wang Weijun  wrote:
> 
>> 
>> On Nov 27, 2016, at 6:12 PM, Alan Bateman  wrote:
>> 
>> On 26/11/2016 08:54, Wang Weijun wrote:
>> 
>>> Please take a review at
>>> 
>>>   http://cr.openjdk.java.net/~weijun/8170364/webrev.00/
>>> 
>>> The compatibility layer introduced in the new FilePermission implementation requires one FilePermission to imply another with either a relative path or an absolute path. This is solved with a private field npath2 inside. When this field is set, the permission's name is modified a little (JDK-8168127) so that when adding to a FilePermissionCollection, it is not confused with one without the field. Unfortunately, this modified name is reused in the merge to create a new "merged" FilePermission which contains a malformed path now.
>>> 
>>> This fix creates a new non-public method to create this "merged" FilePermission.
>>> 
>>> I checked other places and seems the name is not used to create a new FilePermission.
>>> 
>> Ideally FilePermission (and all permissions) would have final fields, I hope that can be fixed some day. 
> 
> Me too, but we have that huge init() method now.
> 
>> In the mean-time then having withNewActions create a new FilePermission and then mutate it looks a bit ugly, can't you just introduce a new non-public constructor to create it with the effective mask?
> 
> The private "clone" constructor is now used in 3 places, all with a mutation right after (lines 267, 280, 993). I've taken care that only newly created objects are mutated this way. Creating 3 new constructors looks like too many duplicated codes.

Do you still have a strong opinion?

> 
>> 
>> In passing then maybe the comment at L1063-1065 can be re-examined and it looks to be stale (the specific bootstrapping issue mentioned was fixed in 2015).
> 
> I can try.

Changed to lambda. Tests on -testset core most pass. java/lang/invoke/lambda/LogGeneratedClassesTest.java still fails but it already failed before my change.

> 
>> 
>> The test is one specific scenario and I wonder if you've considered beefing this up to other scenarios and other targets so that it's more broadly testing the merging scenarios.
> 
> I can add 2 more lines on checking the absolute path, and maybe with delete, execute and readlink (1+1+1+1, 2+2, 3+1 etc). The merge is only about the name and any name is the same, so it seems unnecessary to try other names.

Test enhanced. Permissions are granted in "read", "write", "delete", "execute", or "read,write", "delete,execute", or "read,write,delete", "execute", or "read,write,delete,execute", and 2^4-1 combinations of actions for both "x" and "/abs/x" checked.

If you are OK with the above, I'll post an updated webrev.

Thanks
Max

> 
> Thanks
> Max
> 
> 
>> 
>> -Alan


From weijun.wang at oracle.com  Mon Nov 28 08:40:04 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Mon, 28 Nov 2016 16:40:04 +0800
Subject: RFR 8170364: FilePermission path modified during merge
In-Reply-To: <99F23B3A-AF21-4604-B9C2-B335279FF983@oracle.com>
References: <2D9EFE53-ECE6-49E2-9D83-17055360EAA4@oracle.com>
	
	<6CF04250-1585-4FD4-81F7-E630121DEB84@oracle.com>
	<99F23B3A-AF21-4604-B9C2-B335279FF983@oracle.com>
Message-ID: <075F53F1-ED08-4AB4-9B1D-D82A5358A01D@oracle.com>

Hi Alan

Updated webrev at

   http://cr.openjdk.java.net/~weijun/8170364/webrev.01

Changes since webrev.00:

- a private constructor that can clones 4 fields and modifies 5 others

- using lambda

- test enhancement

Thanks
Max


From ramanand.patil at oracle.com  Mon Nov 28 09:24:25 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Mon, 28 Nov 2016 01:24:25 -0800 (PST)
Subject: RFR: 8169191: (tz) Support tzdata2016j
Message-ID: <31739ca3-0ad5-418e-963b-be01ac2ef6c4@default>

Hi all,
Please review the latest TZDATA integration (tzdata2016j) to JDK9.
Bug: https://bugs.openjdk.java.net/browse/JDK-8170316
Webrev: http://cr.openjdk.java.net/~rpatil/8170316/webrev.00/

All the TimeZone related tests are passed after integration.

Regards,
Ramanand.

From christoph.dreis at freenet.de  Mon Nov 28 12:57:49 2016
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Mon, 28 Nov 2016 13:57:49 +0100
Subject: [NEW BUG]: Reduce allocations in
	sun.reflect.annotation.AnnotationInvocationHandler.invoke()
Message-ID: <019201d24977$06540070$12fc0150$@freenet.de>

Hey,

 

I'm new to the OpenJDK and not sure (yet) how the procedure especially for
new bugs/enhancement is. So I apologise upfront if I made any mistakes.

 

I'm working mostly with the Spring-Framework/Spring-Boot in my current
projects. In these frameworks a lot of dynamic proxying can happen.
Recently, I noticed that the JDK in versions 8 up to the current snapshots
produces some allocations coming from
sun.reflect.annotation.AnnotationInvocationHandler.invoke() we could avoid
in the majority of cases. Only the check for equality needs the actual
parameter types - all other cases only need the parameter count which JDK 8
luckily provides with Method.getParameterCount().

 

What about changing the current behaviour to something like my attached
proposal? I'd be happy if someone is willing to sponsor this change. Again -
if I made any mistakes here, please let me know for the next time.

 

Cheers,

Christoph Dreis

 

================================

Reduce allocations in
sun.reflect.annotation.AnnotationInvocationHandler.invoke()

 

diff -r ba70dcd8de76 -r 86bbc5442c1d
src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandl
er.java

---
a/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHan
dler.java     Fri Nov 11 13:11:27 2016 +0000

+++
b/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHan
dler.java  Mon Nov 14 19:04:33 2016 +0100

@@ -57,13 +57,13 @@

     public Object invoke(Object proxy, Method method, Object[] args) {

         String member = method.getName();

-        Class[] paramTypes = method.getParameterTypes();

+        int parameterCount = method.getParameterCount();

         // Handle Object and Annotation methods

-        if (member.equals("equals") && paramTypes.length == 1 &&

-            paramTypes[0] == Object.class)

+        if (member.equals("equals") && parameterCount == 1 &&

+            method.getParameterTypes()[0] == Object.class)

             return equalsImpl(proxy, args[0]);

-        if (paramTypes.length != 0)

+        if (parameterCount != 0)

             throw new AssertionError("Too many parameters for an annotation
method");

         switch(member) {

 

 


From gromero at linux.vnet.ibm.com  Mon Nov 28 13:24:40 2016
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Mon, 28 Nov 2016 11:24:40 -0200
Subject: RFR(s) 8170153: PPC64: Poor StrictMath performance due to
	non-optimized compilation
In-Reply-To: 
References: <583394C5.3030206@linux.vnet.ibm.com>
	<9327e543-f35b-b88f-2831-a51e265b6a30@oracle.com>
	<5835B6D7.4020101@linux.vnet.ibm.com>
	
Message-ID: <583C3018.5080109@linux.vnet.ibm.com>

Hi Volker,

Sorry for not replying earlier, it was day-off on Friday here...

On 25-11-2016 11:32, Volker Simonis wrote:
> Hi Gustavo,
> 
> we've realized that we have exactly the same problem on Linux/s390 so
> I hope you don't mind that I've updated the bug and the webrev to also
> include the fix for Linux/s390:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2016/8170153.top/
> http://cr.openjdk.java.net/~simonis/webrevs/2016/8170153.jdk/
> https://bugs.openjdk.java.net/browse/JDK-8170153
> 
> The top-level change stays the same (I've only added the current
> reviewers) and for the jdk change I've just added Linux/s390 as
> another platform which can compile fdlibm with HIGH optimization.

Actually, it's really cool to know that an analysis on PPC64 contributed
also to the s390 arch! :)

Thanks for providing the updated webrevs.


Regards,
Gustavo


From claes.redestad at oracle.com  Mon Nov 28 13:35:24 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 28 Nov 2016 14:35:24 +0100
Subject: [NEW BUG]: Reduce allocations in
	sun.reflect.annotation.AnnotationInvocationHandler.invoke()
In-Reply-To: <019201d24977$06540070$12fc0150$@freenet.de>
References: <019201d24977$06540070$12fc0150$@freenet.de>
Message-ID: 

Hi,

for general guidelines on contributing: 
http://openjdk.java.net/contribute/ [1]

As for the patch I think it looks good, but out of curiosity I wonder if
you have any numbers on how much allocations you see in these methods and
how much this patch helps? A non-escaping clone like this should typically
be possible for the JIT to escape entirely, but if that's not happening I
don't see why we should be opposed to a simple optimization like this.

Once changes suggested by Peter Levart is pushed[2] we could improve this
further by using LangReflectAccess.getExecutableSharedParameterTypes, which
will get direct access to the array and thus help the slow case too (if that
matters).

Is it perhaps worth changing ordering around while we're at it?

   if (parameterCount == 1 && member.equals("equals") && ...

Thanks!

/Claes

[1] Someone correct me if I'm wrong, but I've heard somewhere that for a
trivial patch contribution like this signing an OCA is not strictly 
necessary.
Regardless, providing the patch attached or inline is enough to allow us to
sponsor it for you.

[2]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-October/043932.html
http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.07/

On 2016-11-28 13:57, Christoph Dreis wrote:
> Hey,
>
>   
>
> I'm new to the OpenJDK and not sure (yet) how the procedure especially for
> new bugs/enhancement is. So I apologise upfront if I made any mistakes.
>
>   
>
> I'm working mostly with the Spring-Framework/Spring-Boot in my current
> projects. In these frameworks a lot of dynamic proxying can happen.
> Recently, I noticed that the JDK in versions 8 up to the current snapshots
> produces some allocations coming from
> sun.reflect.annotation.AnnotationInvocationHandler.invoke() we could avoid
> in the majority of cases. Only the check for equality needs the actual
> parameter types - all other cases only need the parameter count which JDK 8
> luckily provides with Method.getParameterCount().
>
>   
>
> What about changing the current behaviour to something like my attached
> proposal? I'd be happy if someone is willing to sponsor this change. Again -
> if I made any mistakes here, please let me know for the next time.
>
>   
>
> Cheers,
>
> Christoph Dreis
>
>   
>
> ================================
>
> Reduce allocations in
> sun.reflect.annotation.AnnotationInvocationHandler.invoke()
>
>   
>
> diff -r ba70dcd8de76 -r 86bbc5442c1d
> src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandl
> er.java
>
> ---
> a/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHan
> dler.java     Fri Nov 11 13:11:27 2016 +0000
>
> +++
> b/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHan
> dler.java  Mon Nov 14 19:04:33 2016 +0100
>
> @@ -57,13 +57,13 @@
>
>       public Object invoke(Object proxy, Method method, Object[] args) {
>
>           String member = method.getName();
>
> -        Class[] paramTypes = method.getParameterTypes();
>
> +        int parameterCount = method.getParameterCount();
>
>           // Handle Object and Annotation methods
>
> -        if (member.equals("equals") && paramTypes.length == 1 &&
>
> -            paramTypes[0] == Object.class)
>
> +        if (member.equals("equals") && parameterCount == 1 &&
>
> +            method.getParameterTypes()[0] == Object.class)
>
>               return equalsImpl(proxy, args[0]);
>
> -        if (paramTypes.length != 0)
>
> +        if (parameterCount != 0)
>
>               throw new AssertionError("Too many parameters for an annotation
> method");
>
>           switch(member) {
>
>   
>
>   
>


From christoph.dreis at freenet.de  Mon Nov 28 13:46:23 2016
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Mon, 28 Nov 2016 14:46:23 +0100
Subject: [NEW BUG]: Reduce allocations in
	sun.reflect.annotation.AnnotationInvocationHandler.invoke()
Message-ID: <019e01d2497d$cf2517e0$6d6f47a0$@freenet.de>

Hi,

 

Thank you for the quick response. I've signed the OCA already according to
the contribution guidelines - I just wasn't sure where to put such a trivial
enhancement.

 

In a 10 minute profile I had around 600MB of allocations for cloning the
types, so roughly 1MB/s. If you need the screenshot, I can post it tomorrow.

 

Anything you need from me in order to proceed?

 

Cheers,

Christoph

 

 


From Alan.Bateman at oracle.com  Mon Nov 28 14:17:05 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 28 Nov 2016 14:17:05 +0000
Subject: RFR 8170364: FilePermission path modified during merge
In-Reply-To: <075F53F1-ED08-4AB4-9B1D-D82A5358A01D@oracle.com>
References: <2D9EFE53-ECE6-49E2-9D83-17055360EAA4@oracle.com>
	
	<6CF04250-1585-4FD4-81F7-E630121DEB84@oracle.com>
	<99F23B3A-AF21-4604-B9C2-B335279FF983@oracle.com>
	<075F53F1-ED08-4AB4-9B1D-D82A5358A01D@oracle.com>
Message-ID: <2a8a0922-a967-68b4-6e8d-166ccabcc628@oracle.com>



On 28/11/2016 08:40, Wang Weijun wrote:
> Hi Alan
>
> Updated webrev at
>
>     http://cr.openjdk.java.net/~weijun/8170364/webrev.01
>
> Changes since webrev.00:
>
> - a private constructor that can clones 4 fields and modifies 5 others
>
> - using lambda
>
> - test enhancement
>
This looks much better. A minor nit but the for readability purposes 
then it would be easy to read if the parameters to the constructor were 
all aligned rather than groups of two.

-Alan

From claes.redestad at oracle.com  Mon Nov 28 14:20:53 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 28 Nov 2016 15:20:53 +0100
Subject: [NEW BUG]: Reduce allocations in
	sun.reflect.annotation.AnnotationInvocationHandler.invoke()
In-Reply-To: <019e01d2497d$cf2517e0$6d6f47a0$@freenet.de>
References: <019e01d2497d$cf2517e0$6d6f47a0$@freenet.de>
Message-ID: <88adaaee-7dbd-c6a9-f018-4ec41f076c63@oracle.com>

Hi,

doing a bit of digging it appears a similar improvement - along with a
lot of other things - was suggested and filed a few years back:

https://bugs.openjdk.java.net/browse/JDK-8029019

Peter, this enhancement is currently assigned to you, but I guess
you're not actively working on it. Any objection if I create a subtask
to deal with the observed performance issue in
AnnotationInvocationHandler.invoke - or do you want to revisit the
enhancement in full?

Thanks!

/Claes

On 2016-11-28 14:46, Christoph Dreis wrote:
> Hi,
>
>   
>
> Thank you for the quick response. I've signed the OCA already according to
> the contribution guidelines - I just wasn't sure where to put such a trivial
> enhancement.
>
>   
>
> In a 10 minute profile I had around 600MB of allocations for cloning the
> types, so roughly 1MB/s. If you need the screenshot, I can post it tomorrow.
>
>   
>
> Anything you need from me in order to proceed?
>
>   
>
> Cheers,
>
> Christoph
>
>   
>
>   
>


From christoph.dreis at freenet.de  Mon Nov 28 14:35:41 2016
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Mon, 28 Nov 2016 15:35:41 +0100
Subject: [NEW BUG]: Reduce allocations in
	sun.reflect.annotation.AnnotationInvocationHandler.invoke()
Message-ID: <01a401d24984$b1fcc850$15f658f0$@freenet.de>

> doing a bit of digging it appears a similar improvement - along with a
> lot of other things - was suggested and filed a few years back:

> https://bugs.openjdk.java.net/browse/JDK-8029019

Really sorry for missing that! 


From claes.redestad at oracle.com  Mon Nov 28 14:44:19 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 28 Nov 2016 15:44:19 +0100
Subject: [NEW BUG]: Reduce allocations in
	sun.reflect.annotation.AnnotationInvocationHandler.invoke()
In-Reply-To: <01a401d24984$b1fcc850$15f658f0$@freenet.de>
References: <01a401d24984$b1fcc850$15f658f0$@freenet.de>
Message-ID: <5fa34815-f0e9-d08b-1dce-f16794911a3a@oracle.com>



On 2016-11-28 15:35, Christoph Dreis wrote:
>> doing a bit of digging it appears a similar improvement - along with a
>> lot of other things - was suggested and filed a few years back:
>> https://bugs.openjdk.java.net/browse/JDK-8029019
> Really sorry for missing that!
>

Nothing to be sorry about: you brought attention to a performance
issue that has been pointed out before and was at apparent risk of being
lost to time, instead informing us that it should probably be fixed one way
or another.

Thanks!

/Claes

From gromero at linux.vnet.ibm.com  Mon Nov 28 16:28:00 2016
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Mon, 28 Nov 2016 14:28:00 -0200
Subject: RFR(s) PPC64/s390x/aarch64: Poor StrictMath performance due to
	non-optimized compilation
Message-ID: <583C5B10.8040204@linux.vnet.ibm.com>

Hi all,

I'm re-sending due to JDK title update to include s390x and aarch64 archs.

Could the following webrev be reviewed, please?

webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/
webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/
bug:        https://bugs.openjdk.java.net/browse/JDK-8170153

Thank you.


Regards,
Gustavo


From erik.joelsson at oracle.com  Mon Nov 28 16:55:00 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 28 Nov 2016 17:55:00 +0100
Subject: RFR(s) PPC64/s390x/aarch64: Poor StrictMath performance due to
	non-optimized compilation
In-Reply-To: <583C5B10.8040204@linux.vnet.ibm.com>
References: <583C5B10.8040204@linux.vnet.ibm.com>
Message-ID: <1b332dd2-aa9f-e24b-faaf-b95eacd11dac@oracle.com>

Looks good.

/Erik


On 2016-11-28 17:28, Gustavo Romero wrote:
> Hi all,
>
> I'm re-sending due to JDK title update to include s390x and aarch64 archs.
>
> Could the following webrev be reviewed, please?
>
> webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/
> webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/
> bug:        https://bugs.openjdk.java.net/browse/JDK-8170153
>
> Thank you.
>
>
> Regards,
> Gustavo
>


From huizhe.wang at oracle.com  Mon Nov 28 19:05:33 2016
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 28 Nov 2016 11:05:33 -0800
Subject: RFR: 8169631: [JAXP] XALAN: transformation of XML via
	namespace-unaware
	SAX input yields a different result than namespace-unaware DOM input
In-Reply-To: <4ff8d067fd88496ba536c65610ee54cb@DEWDFE13DE03.global.corp.sap>
References: <313759790392479fa80a10542ab664ec@dewdfe13de07.global.corp.sap>
	<582A7170.7030100@oracle.com>
	<4be5158237814eeb9352fe8fe344e47c@dewdfe13de07.global.corp.sap>
	<582E8944.7090906@oracle.com>
	
	<582F90D6.1040308@oracle.com> <5834985F.4060503@oracle.com>
	<4ff8d067fd88496ba536c65610ee54cb@DEWDFE13DE03.global.corp.sap>
Message-ID: <583C7FFD.4000601@oracle.com>

Hi Christoph,

The changes look good. I also run the other tests (smoke test and etc.), 
and they all passed.

Best,
Joe

On 11/25/16, 4:25 AM, Langer, Christoph wrote:
> Hi Joe,
>
> when trying to finish this up, I had a closer look again.
>
> I found out that it's necessary to look at attributes as well and handle the case where namespace prefixes are used.
>
> Here is a new version of the changeset that passes all jaxp jtreg tests:
> http://cr.openjdk.java.net/~clanger/webrevs/8169631.1/
>
> Now I would also throw out prefixes in localName if we don't have namespace support - for both, elements and attributes (in SAX2DTM2.startElement()).
>
> I also removed some qname handling in DOM2SAX as it is not needed with my changes to SAX2DTM2 anymore.
>
> The test case was adopted.
>
> Thanks&  best regards
> Christoph
>
>> -----Original Message-----
>> From: Joe Wang [mailto:huizhe.wang at oracle.com]
>> Sent: Dienstag, 22. November 2016 20:11
>> To: Langer, Christoph
>> Cc: core-libs-dev at openjdk.java.net
>> Subject: Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via
>> namespace-unaware SAX input yields a different result than namespace-
>> unaware DOM input
>>
>> Hi Christoph,
>>
>> Once you're able to run all tests, feel free to push the changeset.
>> Frank has fixed the Smoke test.
>>
>> Thanks,
>> Joe
>>
>> On 11/18/16, 3:37 PM, Joe Wang wrote:
>>> Hi Christoph,
>>>
>>> Thanks for explaining the customer's dilemma with regard to their
>>> legacy process.
>>>
>>> The testcase I sent you was extracted from an internal SQE smoke test.
>>> I agree with your analysis, the 'golden' file which has been in there
>>> for over 10 years turns out to be wrong and needs to be updated.
>>>
>>> To fix this issue, we need to get that test fixed, and the check-in of
>>> your patch and that of the test need needs to happen simultaneously.
>>> Would you mind wanting for me to go through an internal process to get
>>> a patch ready, then we can check in almost at the same time?
>>>
>>> Best,
>>> Joe
>>>
>>> On 11/18/16, 2:51 PM, Langer, Christoph wrote:
>>>> Hi Joe,
>>>>
>>>> thanks for the feedback.
>>>>
>>>> I've now understood the testcase that you've sent over and the reason
>>>> that it is reporting failure after my fix is that the output of its
>>>> transform operation is rather correct now. And before it was wrong. :)
>>>> The test is comparing the actual result to a "golden" result file in
>>>> the end and both of these were not looking healthy so far. The reason
>>>> is that your test is using a namespace unaware SAX Parser as input.
>>>> With the current JDK XALAN, you could already modify your smoketest
>>>> to use a namespace aware parser.
>>>>
>>>> E.g. replace lines
>>>>
>>>> 82        // Use the JAXP way to get an XMLReader
>>>> 83        XMLReader reader =
>>>> SAXParserFactory.newInstance().newSAXParser().getXMLReader();
>>>>
>>>> with
>>>>
>>>> 82        // Use the JAXP way to get an XMLReader
>>>> 83        SAXParserFactory spf = SAXParserFactory.newInstance();
>>>> 84        spf.setNamespaceAware(true);
>>>> 85        XMLReader reader = spf.newSAXParser().getXMLReader();
>>>>
>>>> ...and you would already get correct results that also DOM input or
>>>> Stream Input would yield.
>>>>
>>>> So, are there other concerns/issues with this fix? Do you want me to
>>>> include a transformation operation like the one that your SmokeTest
>>>> does to TransformerTest which would illustrate the problem with
>>>> namespace unaware SAX input data?
>>>>
>>>> Best regards
>>>> Christoph
>>>>
>>>>> -----Original Message-----
>>>>> From: Joe Wang [mailto:huizhe.wang at oracle.com]
>>>>> Sent: Freitag, 18. November 2016 05:53
>>>>> To: Langer, Christoph
>>>>> Cc: core-libs-dev at openjdk.java.net
>>>>> Subject: Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via
>>>>> namespace-unaware SAX input yields a different result than namespace-
>>>>> unaware DOM input
>>>>>
>>>>>
>>>>>
>>>>> On 11/14/16, 11:43 PM, Langer, Christoph wrote:
>>>>>> Hi Joe,
>>>>>>
>>>>>> thanks for looking.
>>>>>>
>>>>>> Can you let me know which smoke test is failing? I didn't see
>>>>>> issues so far - I
>>>>> was merely running the jtreg unittests for transformer.
>>>>>
>>>>> I sent the test to your mailbox.
>>>>>> I stepped back from replacing Vector with ArrayList for
>>>>>> m_prefixMappings
>>>>> because the code is using methods indexOf() with a start index and
>>>>> setSize() for
>>>>> which ArrayList has no direct matchings. One could, for sure, add
>>>>> some other
>>>>> coding, e.g. use ArrayList's subList() method for the index based
>>>>> search - but I
>>>>> wouldn't want to run the risk of adding a regression here just
>>>>> because I
>>>>> modified the code and did not well test it. But if you insist, I
>>>>> could have another
>>>>> look.
>>>>>
>>>>> Ok, that's fine. subList would do, but setSize may need a bit more
>>>>> work.
>>>>>
>>>>> Best,
>>>>> Joe
>>>>>> Best regards
>>>>>> Christoph
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Joe Wang [mailto:huizhe.wang at oracle.com]
>>>>>>> Sent: Dienstag, 15. November 2016 03:23
>>>>>>> To: Langer, Christoph
>>>>>>> Cc: core-libs-dev at openjdk.java.net
>>>>>>> Subject: Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via
>>>>>>> namespace-unaware SAX input yields a different result than namespace-
>>>>>>> unaware DOM input
>>>>>>>
>>>>>>> Hi Christoph,
>>>>>>>
>>>>>>> Not all tests have finished yet, but there's at least one failure
>>>>>>> in the
>>>>>>> smoke test. I'll get to the details when I have time.
>>>>>>>
>>>>>>> Any reason why m_prefixMappings can not be replaced with ArrayList?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Joe
>>>>>>>
>>>>>>> On 11/14/16, 6:10 AM, Langer, Christoph wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> please review this fix for bug 8169631.
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8169631
>>>>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169631.0/
>>>>>>>>
>>>>>>>> When XALAN is handling namespace unaware input, it behaves
>>>>>>>> differently
>>>>>>> while using SAX input compared to DOM input.
>>>>>>>> With both input source types, the class
>>>>>>> com.sun.org.apache.xml.internal.dtm.ref.sax2dtm.SAX2DTM2 converts
>> SAX
>>>>>>> input into a DTM representation for processing by the XALAN
>>>>>>> transformer.
>>>>> Its
>>>>>>> method startElement takes URI, localname and qName as attribute.
>>>>>>> In case
>>>>> of
>>>>>>> missing feature namespaces, startElement and localname can be empty.
>>>>>>> However, the function uses the localname value for the call to
>>>>>>> m_expandedNameTable.getExpandedTypeID() and further processing. In
>>>>>>> the
>>>>>>> case where only qName has data, this leads to issues.
>>>>>>>> When using DOM input, the class
>>>>>>> com.sun.org.apache.xalan.internal.xsltc.trax.DOM2SAX converts the
>> DOM
>>>>> input
>>>>>>> into SAX input. In the case of empty localname, it fills localname
>>>>>>> with qname
>>>>>>> data. See method getLocalName() [1], called by parse() [2].
>>>>>>>> When directly using SAX input, the SAX parser calls the
>>>>>>>> startElement()
>>>>>>> function on XALAN's handler with empty uri and localname - which
>>>>>>> seems
>>>>>>> correct, as per the spec.
>>>>>>>> Both paths end up in SAX2DTM2's startElement(). So I suggest to
>>>>>>>> change
>>>>> this
>>>>>>> method to handle the case when uri and localname are empty and
>>>>>>> then set
>>>>>>> qname as localname. Maybe one should even change DOM2SAX's
>>>>>>> getLocalName handling to not fill localname with qname in case it
>>>>>>> is empty
>>>>>>> after SAX2DTM was changed..
>>>>>>>> Generally, JavaDoc for SAXSource says that "Attempting to
>>>>>>>> transform an
>>>>> input
>>>>>>> source that is not generated with a namespace-aware parser may
>>>>>>> result in
>>>>>>> errors." But why not fix some of these :)
>>>>>>>> Furthermore I did some cleanups in the code.
>>>>>>>>
>>>>>>>> Thanks and best regards
>>>>>>>> Christoph
>>>>>>>>
>>>>>>>> [1]
>> http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/shar
>>>>>
>> e/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l139
>>>>>>>> [2]
>> http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/shar
>>>>>
>> e/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l279
>>>>>>>> [3]
>> https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/sax/SAXSource
>>>>>>> .html

From paul.sandoz at oracle.com  Mon Nov 28 19:27:06 2016
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 28 Nov 2016 11:27:06 -0800
Subject: RFR 8170155: StringBuffer and StringBuilder stream methods are
	not late-binding
In-Reply-To: <583816AA.6080101@oracle.com>
References: 
	<58362CB0.6050109@oracle.com> <583816AA.6080101@oracle.com>
Message-ID: <4504A2AF-A44C-4853-8308-6FB52060FBD7@oracle.com>


> On 25 Nov 2016, at 02:47, Tobias Hartmann  wrote:
> 
>> I'm not sure if it is still desired to do the same boundary check in case of LATIN1
>> for the benefit of consistency.  Assume there might be concurrent access/operation
>> between val = this.value and count = this.count; (for StringBuilder) for example,
>> the this.value got doubled and the this.count got increased. One will end up with
>> StringIndexOutOfBoundsException() from checkOffset, but the other will be ioobe
>> from vm?
> 
> You mean when hitting a check in an intrinsic compared to when hitting a check in the Java wrapper?
> 

Not quite. There is a spliterator implementation for each coder, in the case of the LATIN1 coder there are no associated intrinsics. I think it?s ok just to perform the explicit bounds check for the UTF16 coder, since for the LATIN1 bounds checks will be performed by baloads.

However, i think there is bug. The coder could change from LATIN1 to UTF16, while holding a reference to a byte[] value as LATIN1.

For StringBuilder i could fix that by atomically reading the value/count/coder, but there is still an issue with StringBuffer. Thus, in the UTF16 coder spliterator we need to perform the explicit bounds before *every* StringUTF16.getChar().

Webrev updated:

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8170155-string-buffer-builder-late-binding/webrev/

Paul.

> Actually, bound checks should always be done in the Java wrapper method that calls the (unchecked) intrinsic. In general, the unchecked intrinsic should not be called directly. StringUTF16.putChar/getChar() is an exception because there are places where we we need to omit the check for performance reasons.
> 
> I'm planning to revisit this with JDK-8156534 in JDK 10.
> 
> Best regards,
> Tobias
> 
>> 
>> Sherman
>> 
>> 
>>> If so i propose the following to make this clearer:
>>> 
>>> return StreamSupport.intStream(
>>>         () ->  {
>>>             byte[] val = this.value; int count = this.count;
>>>             if (coder == LATIN1) {
>>>                 return new StringLatin1.CharsSpliterator(val, 0, count, 0);
>>>             } else {
>>>                 // Perform an explicit bounds check since HotSpot
>>>                 // intrinsics to access UTF-16 characters in the byte[]
>>>                 // array will not perform bounds checks
>>>                 checkOffset(count, val.length>>  coder);
>>>                 return new StringUTF16.CharsSpliterator(val, 0, count, 0);
>>>             }
>>>         },
>>>         Spliterator.ORDERED | Spliterator.SIZED | Spliterator.SUBSIZED,
>>>         false);
>>> 
>>> Paul.
>> 


From martinrb at google.com  Mon Nov 28 19:28:30 2016
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 28 Nov 2016 11:28:30 -0800
Subject:  RFR: 8169191: (tz) Support tzdata2016j
In-Reply-To: <31739ca3-0ad5-418e-963b-be01ac2ef6c4@default>
References: <31739ca3-0ad5-418e-963b-be01ac2ef6c4@default>
Message-ID: 

Thanks as always for keeping the tzdata pipeline moving!
Looks good to me.

On Mon, Nov 28, 2016 at 1:24 AM, Ramanand Patil 
wrote:

> Hi all,
> Please review the latest TZDATA integration (tzdata2016j) to JDK9.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170316
> Webrev: http://cr.openjdk.java.net/~rpatil/8170316/webrev.00/
>
> All the TimeZone related tests are passed after integration.
>
> Regards,
> Ramanand.
>

From Roger.Riggs at Oracle.com  Mon Nov 28 21:50:55 2016
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 28 Nov 2016 16:50:55 -0500
Subject: RFR 8170248, Problem list
	javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java
In-Reply-To: <7d9e23d5-2787-17ae-0159-e04d15d5f1ff@oracle.com>
References: 
	<7d9e23d5-2787-17ae-0159-e04d15d5f1ff@oracle.com>
Message-ID: 

Hi Felix,

The change looks fine, if you still want to put it on the ProblemList.

Roger


On 11/23/2016 12:17 AM, Felix Yang wrote:
> Excuse me,
>
> On 2016/11/23 13:15, Felix Yang wrote:
>> Hi,
>>
>>    this test fails frequently on Linux platforms. I suggest to 
>> exclude it until JDK-8169737 is fixed.
>>
>> Thanks,
>>
>> Felix
>>
>>
>>
> Corrected diff:
>
> diff -r 67d3235a317f test/ProblemList.txt
> --- a/test/ProblemList.txt      Wed Nov 23 10:12:01 2016 +0800
> +++ b/test/ProblemList.txt      Tue Nov 22 21:04:46 2016 -0800
> @@ -305,5 +305,6 @@
>  # jdk_other
>
>  com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8141370 
> linux-i586,macosx-all
> +javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 
> 8169737 linux-all
>
>  ############################################################################ 
>
>


From paul.sandoz at oracle.com  Mon Nov 28 22:30:01 2016
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 28 Nov 2016 14:30:01 -0800
Subject: RFR[9]: 8133719 java.lang.InternalError in
	java.lang.invoke.MethodHandleImpl$BindCaller.bindCaller
In-Reply-To: <68323143-287d-7782-9230-f5198bad14d3@oracle.com>
References: <68323143-287d-7782-9230-f5198bad14d3@oracle.com>
Message-ID: <66C68B3C-72A6-4D8D-958F-AAEF5BE29BF9@oracle.com>


> On 23 Nov 2016, at 22:11, shilpi.rastogi at oracle.com wrote:
> 
> Hi All,
> 
> Please review fix for
> 
> https://bugs.openjdk.java.net/browse/JDK-8133719
> http://cr.openjdk.java.net/~srastogi/8133719/webrev.01/
> 

+1

Paul.

From weijun.wang at oracle.com  Tue Nov 29 06:46:40 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Tue, 29 Nov 2016 14:46:40 +0800
Subject: RFR 8170408: LogGeneratedClassesTest.java fails with recent changes
Message-ID: 

http://cr.openjdk.java.net/~weijun/8170408/webrev.00/

A lambda inside JDK is dumped, we should not count it in this test.

Thanks
Max


From huaming.li at oracle.com  Tue Nov 29 07:01:22 2016
From: huaming.li at oracle.com (Hamlin Li)
Date: Tue, 29 Nov 2016 15:01:22 +0800
Subject: RFR of JDK-8019538: TEST_BUG:
	java/rmi/activation/rmidViaInheritedChannel tests may fail
In-Reply-To: <73753d7c-9d58-8632-da37-10e12e13e400@oracle.com>
References: <73753d7c-9d58-8632-da37-10e12e13e400@oracle.com>
Message-ID: <9455fd2f-7435-c097-261e-460bca612472@oracle.com>

Is some one available to review the patch?

Thank you
-Hamlin

On 2016/11/23 17:49, Hamlin Li wrote:
> Would you please review the fix for below bug?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8019538
> webrev: http://cr.openjdk.java.net/~mli/8019538/webrev.00/
>
> There are 4 issues in the bug,
> 2 in RmidViaInheritedChannel.java:  "port in use" in registry, "port 
> in use" in rmid start.
> 2 InheritedChannelNotServerSocket.java: "port in use" in registry, 
> "port in use" in rmid start.
>
> This patch fixes 2 issues in RmidViaInheritedChannel, and only "port 
> in use" in registry in InheritedChannelNotServerSocket.
> The "port in use" in rmid in InheritedChannelNotServerSocket is little 
> bit hard, as it intends to test rmid when inherited channel not work. 
> Currently the only solution in my mind is to retry when rmid fails 
> with "port in use", but as we discussed earlier, it's not a good 
> solution as it might impact other programs or tests, and it's not 
> efficient.
> So I hope to push the fix for the other issues first to improve the 
> stability of RMI tests, and keep studying if there are other better 
> solutions for the "port in use" in rmid in 
> InheritedChannelNotServerSocket.
>
> Thank you
> -Hamlin


From huaming.li at oracle.com  Tue Nov 29 09:23:31 2016
From: huaming.li at oracle.com (Hamlin Li)
Date: Tue, 29 Nov 2016 17:23:31 +0800
Subject: RFR of JDK-8049316: TEST_BUG: java/nio/channels/Selector/Wakeup.java
	fails in same binary run b19
Message-ID: <55b7c230-6f1a-57fd-847b-6ee79728f67c@oracle.com>

Would you please review the below patch?

bug: https://bugs.openjdk.java.net/browse/JDK-8049316
webrev: http://cr.openjdk.java.net/~mli/8049316/webrev.00/

Root cause:
1. it depends on sleeping time to check failure, which is not reliable 
in some extreme situation
2. it mix several tests together with a loop in Sleeper

Solution:
1. synchronize between threads.
2. isolate tests.

Thank you
Hamlin

From volker.simonis at gmail.com  Tue Nov 29 09:41:10 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 29 Nov 2016 10:41:10 +0100
Subject: RFR(s) PPC64/s390x/aarch64: Poor StrictMath performance due to
	non-optimized compilation
In-Reply-To: <583C5B10.8040204@linux.vnet.ibm.com>
References: <583C5B10.8040204@linux.vnet.ibm.com>
Message-ID: 

Thanks Gustavo,

the change looks good.

So now we're just waiting for another review from somebody of the aarch64 folks.
Once we have that and the fc-request is approved I'll push the changes.

Regards,
Volker


On Mon, Nov 28, 2016 at 5:28 PM, Gustavo Romero
 wrote:
> Hi all,
>
> I'm re-sending due to JDK title update to include s390x and aarch64 archs.
>
> Could the following webrev be reviewed, please?
>
> webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/
> webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/
> bug:        https://bugs.openjdk.java.net/browse/JDK-8170153
>
> Thank you.
>
>
> Regards,
> Gustavo
>

From mkanat at google.com  Tue Nov 29 10:48:23 2016
From: mkanat at google.com (Max Kanat-Alexander)
Date: Tue, 29 Nov 2016 05:48:23 -0500
Subject: [PATCH] SignatureParser performance problems due to excessive
	StringBuilder usage
Message-ID: 

Currently, any heavy use of sun.reflect.generics.parser.SignatureParser
leads to many calls to Arrays.copyOf, due to using StringBuilder inside of
SignatureParser to build up a string a character at a time. This showed up
as a top CPU-usage culprit in profiling of a large number of tests,
particularly those which use reflection-heavy dependency injection systems
such as Guice.

To determine the size to pre-size the StringBuilder in this patch, I made
AbstractStringBuilder.expandCapacity print out the original capacity and
new capacity every time it did a resize. I measured the outputs that
happened during a heavy real-world user of SignatureParser, and took
particular measurements at different StringBuilder sizes:

    16: Reallocs: 907310 Total Alloc Counting Only Realloc: 84324048
Estimated Total Alloc: 84310608 Copy Bytes: 27249937 Reallocs from initial
size: 517883
    32: Reallocs: 497220 Total Alloc Counting Only Realloc: 68184799
Estimated Total Alloc: 75412799 Copy Bytes: 22138274 Reallocs from initial
size: 291168
    40: Reallocs: 331045 Total Alloc Counting Only Realloc: 54170531
Estimated Total Alloc: 69096811 Copy Bytes: 17560068 Reallocs from initial
size: 143886
    48: Reallocs: 222232 Total Alloc Counting Only Realloc: 42141244
Estimated Total Alloc: 65213692 Copy Bytes: 13637722 Reallocs from initial
size: 36367
    56: Reallocs: 196595 Total Alloc Counting Only Realloc: 39246690
Estimated Total Alloc: 67601618 Copy Bytes: 12698496 Reallocs from initial
size: 10705
    64: Reallocs: 185941 Total Alloc Counting Only Realloc: 38031623
Estimated Total Alloc: 71112263 Copy Bytes: 12304703 Reallocs from initial
size: 158

As you can see, 48 gives us the lowest total memory allocation as well as
significantly reducing the number of times we reallocate arrays. With
higher values it becomes significantly non-linear in improvement and we
start to allocate more memory overall, so 48 seemed like the right number
to pick.

There is no bug which exactly matches this problem.
https://bugs.openjdk.java.net/browse/JDK-8035424 is close, but describes a
different root cause for performance issues--one which I did not actually
see as occupying significant CPU time in profiles.

This is my first OpenJDK contribution, so I can't file a bug myself.

There is no test included as this is entirely a performance problem. This
patch should be entirely behavior-preserving.

# HG changeset patch
# User mkanat
# Date 1480414839 28800
#      Tue Nov 29 02:20:39 2016 -0800
# Node ID 514fca7d9aa19b074eb32ee8ac700c796b4d9444
# Parent  7901a13a051ce1630477ef9f8a17c5af6c515e69
Optimize SignatureParser's use of StringBuilder.

diff --git a/src/java.base/share/classes/sun/reflect/generics/parser/SignatureParser.java
b/src/java.base/share/classes/sun/reflect/generics/parser/SignatureParser.java
--- a/src/java.base/share/classes/sun/reflect/generics/parser/SignatureParser.java
+++ b/src/java.base/share/classes/sun/reflect/generics/parser/SignatureParser.java
@@ -70,6 +70,11 @@
     private static final char EOI = ':';
     private static final boolean DEBUG = false;

+    // StringBuilder does a lot of array copies if we don't pre-size
+    // it when parsing a full class name. This value was determined
+    // empirically by measurements of real-world code.
+    public static final int CLASS_NAME_SB_SIZE = 48;
+
     // private constructor - enforces use of static factory
     private SignatureParser(){}

@@ -251,9 +256,19 @@
         return FormalTypeParameter.make(id, bs);
     }

-    private String parseIdentifier(){
+    private String parseIdentifier() {
         StringBuilder result = new StringBuilder();
-        while (!Character.isWhitespace(current())) {
+        parseIdentifierInto(result);
+        return result.toString();
+    }
+
+    // This is separate from parseIdentifier for performance reasons.
+    // For a caller who already has a StringBuilder, it's much faster to
+    // re-use the existing builder, because it results in far fewer internal
+    // array copies inside of StringBuilder.
+    private void parseIdentifierInto(StringBuilder result) {
+        int startIndex = index;
+        parseLoop: while (!Character.isWhitespace(current())) {
             char c = current();
             switch(c) {
             case ';':
@@ -263,16 +278,14 @@
             case ':':
             case '>':
             case '<':
-                return result.toString();
-            default:{
-                result.append(c);
+                break parseLoop;
+            default:
                 advance();
             }
+        }
+        result.append(input, startIndex, index - startIndex);
+    }

-            }
-        }
-        return result.toString();
-    }
     /**
      * FieldTypeSignature:
      *     ClassTypeSignature
@@ -325,18 +338,16 @@
         // Parse both any optional leading PackageSpecifier as well as
         // the following SimpleClassTypeSignature.

-        String id = parseIdentifier();
+        StringBuilder idBuild = new StringBuilder(CLASS_NAME_SB_SIZE);
+        parseIdentifierInto(idBuild);

-        if (current() == '/') { // package name
-            StringBuilder idBuild = new StringBuilder(id);
+        while (current() == '/') { // package name
+            advance();
+            idBuild.append('.');
+            parseIdentifierInto(idBuild);
+        }

-            while(current() == '/') {
-                advance();
-                idBuild.append(".");
-                idBuild.append(parseIdentifier());
-            }
-            id = idBuild.toString();
-        }
+        String id = idBuild.toString();

         switch (current()) {
         case ';':

From daniel.fuchs at oracle.com  Tue Nov 29 11:22:43 2016
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 29 Nov 2016 11:22:43 +0000
Subject: RFR 8170408: LogGeneratedClassesTest.java fails with recent
	changes
In-Reply-To: 
References: 
Message-ID: <1ccdb622-9661-5b9b-c2f9-a8b608c26a5d@oracle.com>

Hi Max,

On 29/11/16 06:46, Wang Weijun wrote:
> http://cr.openjdk.java.net/~weijun/8170408/webrev.00/
>
> A lambda inside JDK is dumped, we should not count it in this test.

Looks good to me. An alternative might be to only look
at the files under dump/com/example (I remember modifying
LogGeneratedClassesTest::testLoggingException for exactly
that same kind of reasons).

best regards,

-- daniel

>
> Thanks
> Max
>


From claes.redestad at oracle.com  Tue Nov 29 12:08:02 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 29 Nov 2016 13:08:02 +0100
Subject: [PATCH] SignatureParser performance problems due to excessive
	StringBuilder usage
In-Reply-To: 
References: 
Message-ID: 

Hi and welcome!

I've filed https://bugs.openjdk.java.net/browse/JDK-8170467 to track
this.

Introducing a parseIdentifierInto to avoid repeated creation of
StringBuilder/String pairs seems like a no-brainer (my guess is
this is the largest allocation reduction here?), and although I have a
bit of a knee-jerk reaction against the magic number for the
pre-sized builder it doesn't seem like an outrageous default for
package.Class specifiers in the current ecosystem.

Noting that there's no nested StringBuilder use in this code "pooling"
them would be trivial (a single ThreadLocal which we
setLength(0) after toString() would do), which could reduce allocations
further at the cost of a very slight retained footprint increase and
some loss of cache locality. It'd be interesting to see numbers on this,
but I won't insist. :-)

Nit: the use of break-to-label in a non-nested while-loop seems
awkward to me.

/Claes

On 2016-11-29 11:48, Max Kanat-Alexander wrote:
> Currently, any heavy use of sun.reflect.generics.parser.SignatureParser
> leads to many calls to Arrays.copyOf, due to using StringBuilder inside of
> SignatureParser to build up a string a character at a time. This showed up
> as a top CPU-usage culprit in profiling of a large number of tests,
> particularly those which use reflection-heavy dependency injection systems
> such as Guice.
>
> To determine the size to pre-size the StringBuilder in this patch, I made
> AbstractStringBuilder.expandCapacity print out the original capacity and
> new capacity every time it did a resize. I measured the outputs that
> happened during a heavy real-world user of SignatureParser, and took
> particular measurements at different StringBuilder sizes:
>
>      16: Reallocs: 907310 Total Alloc Counting Only Realloc: 84324048
> Estimated Total Alloc: 84310608 Copy Bytes: 27249937 Reallocs from initial
> size: 517883
>      32: Reallocs: 497220 Total Alloc Counting Only Realloc: 68184799
> Estimated Total Alloc: 75412799 Copy Bytes: 22138274 Reallocs from initial
> size: 291168
>      40: Reallocs: 331045 Total Alloc Counting Only Realloc: 54170531
> Estimated Total Alloc: 69096811 Copy Bytes: 17560068 Reallocs from initial
> size: 143886
>      48: Reallocs: 222232 Total Alloc Counting Only Realloc: 42141244
> Estimated Total Alloc: 65213692 Copy Bytes: 13637722 Reallocs from initial
> size: 36367
>      56: Reallocs: 196595 Total Alloc Counting Only Realloc: 39246690
> Estimated Total Alloc: 67601618 Copy Bytes: 12698496 Reallocs from initial
> size: 10705
>      64: Reallocs: 185941 Total Alloc Counting Only Realloc: 38031623
> Estimated Total Alloc: 71112263 Copy Bytes: 12304703 Reallocs from initial
> size: 158
>
> As you can see, 48 gives us the lowest total memory allocation as well as
> significantly reducing the number of times we reallocate arrays. With
> higher values it becomes significantly non-linear in improvement and we
> start to allocate more memory overall, so 48 seemed like the right number
> to pick.
>
> There is no bug which exactly matches this problem.
> https://bugs.openjdk.java.net/browse/JDK-8035424 is close, but describes a
> different root cause for performance issues--one which I did not actually
> see as occupying significant CPU time in profiles.
>
> This is my first OpenJDK contribution, so I can't file a bug myself.
>
> There is no test included as this is entirely a performance problem. This
> patch should be entirely behavior-preserving.
>
> # HG changeset patch
> # User mkanat
> # Date 1480414839 28800
> #      Tue Nov 29 02:20:39 2016 -0800
> # Node ID 514fca7d9aa19b074eb32ee8ac700c796b4d9444
> # Parent  7901a13a051ce1630477ef9f8a17c5af6c515e69
> Optimize SignatureParser's use of StringBuilder.
>
> diff --git a/src/java.base/share/classes/sun/reflect/generics/parser/SignatureParser.java
> b/src/java.base/share/classes/sun/reflect/generics/parser/SignatureParser.java
> --- a/src/java.base/share/classes/sun/reflect/generics/parser/SignatureParser.java
> +++ b/src/java.base/share/classes/sun/reflect/generics/parser/SignatureParser.java
> @@ -70,6 +70,11 @@
>       private static final char EOI = ':';
>       private static final boolean DEBUG = false;
>
> +    // StringBuilder does a lot of array copies if we don't pre-size
> +    // it when parsing a full class name. This value was determined
> +    // empirically by measurements of real-world code.
> +    public static final int CLASS_NAME_SB_SIZE = 48;
> +
>       // private constructor - enforces use of static factory
>       private SignatureParser(){}
>
> @@ -251,9 +256,19 @@
>           return FormalTypeParameter.make(id, bs);
>       }
>
> -    private String parseIdentifier(){
> +    private String parseIdentifier() {
>           StringBuilder result = new StringBuilder();
> -        while (!Character.isWhitespace(current())) {
> +        parseIdentifierInto(result);
> +        return result.toString();
> +    }
> +
> +    // This is separate from parseIdentifier for performance reasons.
> +    // For a caller who already has a StringBuilder, it's much faster to
> +    // re-use the existing builder, because it results in far fewer internal
> +    // array copies inside of StringBuilder.
> +    private void parseIdentifierInto(StringBuilder result) {
> +        int startIndex = index;
> +        parseLoop: while (!Character.isWhitespace(current())) {
>               char c = current();
>               switch(c) {
>               case ';':
> @@ -263,16 +278,14 @@
>               case ':':
>               case '>':
>               case '<':
> -                return result.toString();
> -            default:{
> -                result.append(c);
> +                break parseLoop;
> +            default:
>                   advance();
>               }
> +        }
> +        result.append(input, startIndex, index - startIndex);
> +    }
>
> -            }
> -        }
> -        return result.toString();
> -    }
>       /**
>        * FieldTypeSignature:
>        *     ClassTypeSignature
> @@ -325,18 +338,16 @@
>           // Parse both any optional leading PackageSpecifier as well as
>           // the following SimpleClassTypeSignature.
>
> -        String id = parseIdentifier();
> +        StringBuilder idBuild = new StringBuilder(CLASS_NAME_SB_SIZE);
> +        parseIdentifierInto(idBuild);
>
> -        if (current() == '/') { // package name
> -            StringBuilder idBuild = new StringBuilder(id);
> +        while (current() == '/') { // package name
> +            advance();
> +            idBuild.append('.');
> +            parseIdentifierInto(idBuild);
> +        }
>
> -            while(current() == '/') {
> -                advance();
> -                idBuild.append(".");
> -                idBuild.append(parseIdentifier());
> -            }
> -            id = idBuild.toString();
> -        }
> +        String id = idBuild.toString();
>
>           switch (current()) {
>           case ';':


From mkanat at google.com  Tue Nov 29 12:16:01 2016
From: mkanat at google.com (Max Kanat-Alexander)
Date: Tue, 29 Nov 2016 07:16:01 -0500
Subject: [PATCH] SignatureParser performance problems due to excessive
	StringBuilder usage
In-Reply-To: 
References: 
	
Message-ID: 

On Tue, Nov 29, 2016 at 7:08 AM, Claes Redestad 
wrote:

> Hi and welcome!
>
>   Thanks! :-)


> I've filed https://bugs.openjdk.java.net/browse/JDK-8170467 to track
> this.
>

  Great, thanks. :-)


> Introducing a parseIdentifierInto to avoid repeated creation of
> StringBuilder/String pairs seems like a no-brainer (my guess is
> this is the largest allocation reduction here?), and although I have a
> bit of a knee-jerk reaction against the magic number for the
> pre-sized builder it doesn't seem like an outrageous default for
> package.Class specifiers in the current ecosystem.
>

  Yeah, the two biggest reducers are the pre-sizing and
parseIdentifierInto.


> Noting that there's no nested StringBuilder use in this code "pooling"
> them would be trivial (a single ThreadLocal which we
> setLength(0) after toString() would do), which could reduce allocations
> further at the cost of a very slight retained footprint increase and
> some loss of cache locality. It'd be interesting to see numbers on this,
> but I won't insist. :-)
>

  Yeah, I supposed I'd also have to then be concerned about pathologically
long identifiers which cause us to hold on to some huge StringBuilder
forever, which seems like it would lead into cache management, and so forth
and so forth. I actually think that the whole class could use some
refactoring in general, but I wanted to keep this change focused on just
one simple fix for the performance issue that I found.


> Nit: the use of break-to-label in a non-nested while-loop seems
> awkward to me.


  Yeah, agreed; it has to be done because we're in a switch statement and
otherwise we would just be ending the case.

  -Max

From weijun.wang at oracle.com  Tue Nov 29 12:25:49 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Tue, 29 Nov 2016 20:25:49 +0800
Subject: RFR 8170408: LogGeneratedClassesTest.java fails with recent
	changes
In-Reply-To: <1ccdb622-9661-5b9b-c2f9-a8b608c26a5d@oracle.com>
References: 
	<1ccdb622-9661-5b9b-c2f9-a8b608c26a5d@oracle.com>
Message-ID: <4EFEF277-CD15-4EEC-87CF-CC618E04207A@oracle.com>

Like this?

   (p, a) -> p.toString().startsWith("dump/com/example")
          && a.isRegularFile()).count(),

Thanks
Max

> On Nov 29, 2016, at 7:22 PM, Daniel Fuchs  wrote:
> 
> Hi Max,
> 
> On 29/11/16 06:46, Wang Weijun wrote:
>> http://cr.openjdk.java.net/~weijun/8170408/webrev.00/
>> 
>> A lambda inside JDK is dumped, we should not count it in this test.
> 
> Looks good to me. An alternative might be to only look
> at the files under dump/com/example (I remember modifying
> LogGeneratedClassesTest::testLoggingException for exactly
> that same kind of reasons).
> 
> best regards,
> 
> -- daniel
> 
>> 
>> Thanks
>> Max
>> 
> 


From weijun.wang at oracle.com  Tue Nov 29 12:30:37 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Tue, 29 Nov 2016 20:30:37 +0800
Subject: RFR 8170408: LogGeneratedClassesTest.java fails with recent
	changes
In-Reply-To: <4EFEF277-CD15-4EEC-87CF-CC618E04207A@oracle.com>
References: 
	<1ccdb622-9661-5b9b-c2f9-a8b608c26a5d@oracle.com>
	<4EFEF277-CD15-4EEC-87CF-CC618E04207A@oracle.com>
Message-ID: <7110531E-9C3B-4B8B-92FA-B3AF81E9875C@oracle.com>

Maybe I should use

(p, a) -> p.startsWith(Paths.get("dump/com/example"))
        && a.isRegularFile()).count(),

On Windows it's \.

I'll run some test now.

Thanks
Max

> On Nov 29, 2016, at 8:25 PM, Wang Weijun  wrote:
> 
> Like this?
> 
>   (p, a) -> p.toString().startsWith("dump/com/example")
>          && a.isRegularFile()).count(),
> 
> Thanks
> Max
> 
>> On Nov 29, 2016, at 7:22 PM, Daniel Fuchs  wrote:
>> 
>> Hi Max,
>> 
>> On 29/11/16 06:46, Wang Weijun wrote:
>>> http://cr.openjdk.java.net/~weijun/8170408/webrev.00/
>>> 
>>> A lambda inside JDK is dumped, we should not count it in this test.
>> 
>> Looks good to me. An alternative might be to only look
>> at the files under dump/com/example (I remember modifying
>> LogGeneratedClassesTest::testLoggingException for exactly
>> that same kind of reasons).
>> 
>> best regards,
>> 
>> -- daniel
>> 
>>> 
>>> Thanks
>>> Max
>>> 
>> 
> 


From claes.redestad at oracle.com  Tue Nov 29 13:18:53 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 29 Nov 2016 14:18:53 +0100
Subject: RFR: 8170467: (reflect) Optimize SignatureParser's use of
	StringBuilders
Message-ID: <90b347de-fd85-03c7-51eb-44fedf6f5645@oracle.com>

Hi,

please review this patch provided by Max Kanat-Alexander[1] to improve
performance of sun.reflect.generics.parser.SignatureParser by reducing
number of StringBuilders created and the rate at which they are resized
during typical usage.

Webrev: http://cr.openjdk.java.net/~redestad/8170467/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8170467

Thanks!

/Claes

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/045046.html 


From daniel.fuchs at oracle.com  Tue Nov 29 13:26:42 2016
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 29 Nov 2016 13:26:42 +0000
Subject: RFR 8170408: LogGeneratedClassesTest.java fails with recent
	changes
In-Reply-To: <7110531E-9C3B-4B8B-92FA-B3AF81E9875C@oracle.com>
References: 
	<1ccdb622-9661-5b9b-c2f9-a8b608c26a5d@oracle.com>
	<4EFEF277-CD15-4EEC-87CF-CC618E04207A@oracle.com>
	<7110531E-9C3B-4B8B-92FA-B3AF81E9875C@oracle.com>
Message-ID: <1f8b989b-4f4a-920f-a0c2-4600f3ad90bb@oracle.com>

Hi Max,

On 29/11/16 12:30, Wang Weijun wrote:
> Maybe I should use
>
> (p, a) -> p.startsWith(Paths.get("dump/com/example"))
>         && a.isRegularFile()).count(),

Yes - something like that.
But that was just a suggestion.

>
> On Windows it's \.

I remember I had some trouble getting the filter right.

best regards,

-- daniel

>
> I'll run some test now.
>
> Thanks
> Max
>
>> On Nov 29, 2016, at 8:25 PM, Wang Weijun  wrote:
>>
>> Like this?
>>
>>   (p, a) -> p.toString().startsWith("dump/com/example")
>>          && a.isRegularFile()).count(),
>>
>> Thanks
>> Max
>>
>>> On Nov 29, 2016, at 7:22 PM, Daniel Fuchs  wrote:
>>>
>>> Hi Max,
>>>
>>> On 29/11/16 06:46, Wang Weijun wrote:
>>>> http://cr.openjdk.java.net/~weijun/8170408/webrev.00/
>>>>
>>>> A lambda inside JDK is dumped, we should not count it in this test.
>>>
>>> Looks good to me. An alternative might be to only look
>>> at the files under dump/com/example (I remember modifying
>>> LogGeneratedClassesTest::testLoggingException for exactly
>>> that same kind of reasons).
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>>>
>>>> Thanks
>>>> Max
>>>>
>>>
>>
>


From shade at redhat.com  Tue Nov 29 13:27:12 2016
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 29 Nov 2016 14:27:12 +0100
Subject: RFR: 8170467: (reflect) Optimize SignatureParser's use of
	StringBuilders
In-Reply-To: <90b347de-fd85-03c7-51eb-44fedf6f5645@oracle.com>
References: <90b347de-fd85-03c7-51eb-44fedf6f5645@oracle.com>
Message-ID: <87adf81c-2c39-7df3-3bd1-010435ec4571@redhat.com>

On 11/29/2016 02:18 PM, Claes Redestad wrote:
> please review this patch provided by Max Kanat-Alexander[1] to improve
> performance of sun.reflect.generics.parser.SignatureParser by reducing
> number of StringBuilders created and the rate at which they are resized
> during typical usage.
> 
> Webrev: http://cr.openjdk.java.net/~redestad/8170467/webrev.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170467

Okay. +1

-Aleksey


From weijun.wang at oracle.com  Tue Nov 29 13:33:47 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Tue, 29 Nov 2016 21:33:47 +0800
Subject: RFR 8170408: LogGeneratedClassesTest.java fails with recent
	changes
In-Reply-To: <1f8b989b-4f4a-920f-a0c2-4600f3ad90bb@oracle.com>
References: 
	<1ccdb622-9661-5b9b-c2f9-a8b608c26a5d@oracle.com>
	<4EFEF277-CD15-4EEC-87CF-CC618E04207A@oracle.com>
	<7110531E-9C3B-4B8B-92FA-B3AF81E9875C@oracle.com>
	<1f8b989b-4f4a-920f-a0c2-4600f3ad90bb@oracle.com>
Message-ID: <736094F2-5E20-48D0-B167-BC9FE4C45021@oracle.com>

http://cr.openjdk.java.net/~weijun/8170408/webrev.01

jdk_lang passes on all JPRT platforms.

Thanks
Max

> On Nov 29, 2016, at 9:26 PM, Daniel Fuchs  wrote:
> 
> Hi Max,
> 
> On 29/11/16 12:30, Wang Weijun wrote:
>> Maybe I should use
>> 
>> (p, a) -> p.startsWith(Paths.get("dump/com/example"))
>>        && a.isRegularFile()).count(),
> 
> Yes - something like that.
> But that was just a suggestion.
> 
>> 
>> On Windows it's \.
> 
> I remember I had some trouble getting the filter right.
> 
> best regards,
> 
> -- daniel
> 
>> 
>> I'll run some test now.
>> 
>> Thanks
>> Max
>> 
>>> On Nov 29, 2016, at 8:25 PM, Wang Weijun  wrote:
>>> 
>>> Like this?
>>> 
>>>  (p, a) -> p.toString().startsWith("dump/com/example")
>>>         && a.isRegularFile()).count(),
>>> 
>>> Thanks
>>> Max
>>> 
>>>> On Nov 29, 2016, at 7:22 PM, Daniel Fuchs  wrote:
>>>> 
>>>> Hi Max,
>>>> 
>>>> On 29/11/16 06:46, Wang Weijun wrote:
>>>>> http://cr.openjdk.java.net/~weijun/8170408/webrev.00/
>>>>> 
>>>>> A lambda inside JDK is dumped, we should not count it in this test.
>>>> 
>>>> Looks good to me. An alternative might be to only look
>>>> at the files under dump/com/example (I remember modifying
>>>> LogGeneratedClassesTest::testLoggingException for exactly
>>>> that same kind of reasons).
>>>> 
>>>> best regards,
>>>> 
>>>> -- daniel
>>>> 
>>>>> 
>>>>> Thanks
>>>>> Max
>>>>> 
>>>> 
>>> 
>> 
> 


From andrej.golovnin at gmail.com  Tue Nov 29 13:39:41 2016
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Tue, 29 Nov 2016 14:39:41 +0100
Subject: RFR: 8170467: (reflect) Optimize SignatureParser's use of
	StringBuilders
In-Reply-To: <90b347de-fd85-03c7-51eb-44fedf6f5645@oracle.com>
References: <90b347de-fd85-03c7-51eb-44fedf6f5645@oracle.com>
Message-ID: 

Hi Claes,

76     public static final int CLASS_NAME_SB_SIZE = 48;

Why is this constant public?
Btw. for our product this value is too small. We have packages with
longer names. I would use 64. :-)

Best regards,
Andrej Golovnin

On Tue, Nov 29, 2016 at 2:18 PM, Claes Redestad
 wrote:
> Hi,
>
> please review this patch provided by Max Kanat-Alexander[1] to improve
> performance of sun.reflect.generics.parser.SignatureParser by reducing
> number of StringBuilders created and the rate at which they are resized
> during typical usage.
>
> Webrev: http://cr.openjdk.java.net/~redestad/8170467/webrev.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170467
>
> Thanks!
>
> /Claes
>
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/045046.html

From daniel.fuchs at oracle.com  Tue Nov 29 13:40:49 2016
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 29 Nov 2016 13:40:49 +0000
Subject: RFR 8170408: LogGeneratedClassesTest.java fails with recent
	changes
In-Reply-To: <736094F2-5E20-48D0-B167-BC9FE4C45021@oracle.com>
References: 
	<1ccdb622-9661-5b9b-c2f9-a8b608c26a5d@oracle.com>
	<4EFEF277-CD15-4EEC-87CF-CC618E04207A@oracle.com>
	<7110531E-9C3B-4B8B-92FA-B3AF81E9875C@oracle.com>
	<1f8b989b-4f4a-920f-a0c2-4600f3ad90bb@oracle.com>
	<736094F2-5E20-48D0-B167-BC9FE4C45021@oracle.com>
Message-ID: 

On 29/11/16 13:33, Wang Weijun wrote:
> http://cr.openjdk.java.net/~weijun/8170408/webrev.01
>
> jdk_lang passes on all JPRT platforms.

Looks good to me Max!

best regards,

-- daniel

>
> Thanks
> Max
>
>> On Nov 29, 2016, at 9:26 PM, Daniel Fuchs  wrote:
>>
>> Hi Max,
>>
>> On 29/11/16 12:30, Wang Weijun wrote:
>>> Maybe I should use
>>>
>>> (p, a) -> p.startsWith(Paths.get("dump/com/example"))
>>>        && a.isRegularFile()).count(),
>>
>> Yes - something like that.
>> But that was just a suggestion.
>>
>>>
>>> On Windows it's \.
>>
>> I remember I had some trouble getting the filter right.
>>
>> best regards,
>>
>> -- daniel
>>
>>>
>>> I'll run some test now.
>>>
>>> Thanks
>>> Max
>>>
>>>> On Nov 29, 2016, at 8:25 PM, Wang Weijun  wrote:
>>>>
>>>> Like this?
>>>>
>>>>  (p, a) -> p.toString().startsWith("dump/com/example")
>>>>         && a.isRegularFile()).count(),
>>>>
>>>> Thanks
>>>> Max
>>>>
>>>>> On Nov 29, 2016, at 7:22 PM, Daniel Fuchs  wrote:
>>>>>
>>>>> Hi Max,
>>>>>
>>>>> On 29/11/16 06:46, Wang Weijun wrote:
>>>>>> http://cr.openjdk.java.net/~weijun/8170408/webrev.00/
>>>>>>
>>>>>> A lambda inside JDK is dumped, we should not count it in this test.
>>>>>
>>>>> Looks good to me. An alternative might be to only look
>>>>> at the files under dump/com/example (I remember modifying
>>>>> LogGeneratedClassesTest::testLoggingException for exactly
>>>>> that same kind of reasons).
>>>>>
>>>>> best regards,
>>>>>
>>>>> -- daniel
>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Max
>>>>>>
>>>>>
>>>>
>>>
>>
>


From claes.redestad at oracle.com  Tue Nov 29 14:03:26 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 29 Nov 2016 15:03:26 +0100
Subject: RFR: 8170467: (reflect) Optimize SignatureParser's use of
	StringBuilders
In-Reply-To: 
References: <90b347de-fd85-03c7-51eb-44fedf6f5645@oracle.com>
	
Message-ID: <972410b1-21e6-8da2-6750-a2f0d8eabcec@oracle.com>

Hi Andrej,

On 2016-11-29 14:39, Andrej Golovnin wrote:
> Hi Claes,
>
> 76     public static final int CLASS_NAME_SB_SIZE = 48;
>
> Why is this constant public?

Good catch, made it private.

> Btw. for our product this value is too small. We have packages with
> longer names. I would use 64. :-)

There's no one size fits all: something around 48 is likely to
help most common cases, while not noticeably penalizing
shorter names. I'd consider it a bad move to regress apps
with short-to-normal names to get a small gain on apps with
very long names

Thanks!

/Claes

>
> Best regards,
> Andrej Golovnin
>
> On Tue, Nov 29, 2016 at 2:18 PM, Claes Redestad
>  wrote:
>> Hi,
>>
>> please review this patch provided by Max Kanat-Alexander[1] to improve
>> performance of sun.reflect.generics.parser.SignatureParser by reducing
>> number of StringBuilders created and the rate at which they are resized
>> during typical usage.
>>
>> Webrev: http://cr.openjdk.java.net/~redestad/8170467/webrev.01/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170467
>>
>> Thanks!
>>
>> /Claes
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/045046.html


From aph at redhat.com  Tue Nov 29 15:35:16 2016
From: aph at redhat.com (Andrew Haley)
Date: Tue, 29 Nov 2016 15:35:16 +0000
Subject: [aarch64-port-dev ] RFR(s) PPC64/s390x/aarch64: Poor StrictMath
	performance due to non-optimized compilation
In-Reply-To: 
References: <583C5B10.8040204@linux.vnet.ibm.com>
	
Message-ID: 

On 29/11/16 09:41, Volker Simonis wrote:
> Thanks Gustavo,
> 
> the change looks good.
> 
> So now we're just waiting for another review from somebody of the aarch64 folks.
> Once we have that and the fc-request is approved I'll push the changes.

One thing I don't understand:

cos 0.17098435541865692 1m7.433s 0.1709843554185943 0m56.678s
sin 1.7136493465700289 1m10.654s 1.7136493465700542 0m57.114s

Do you know what causes the lower digits to be different?  Is
it that Math and StrictMath use different algorithms, not just
different optimization levels?

Andrew.


From Roger.Riggs at Oracle.com  Tue Nov 29 16:03:08 2016
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 29 Nov 2016 11:03:08 -0500
Subject: RFR of JDK-8049316: TEST_BUG:
	java/nio/channels/Selector/Wakeup.java fails in same binary run b19
In-Reply-To: <55b7c230-6f1a-57fd-847b-6ee79728f67c@oracle.com>
References: <55b7c230-6f1a-57fd-847b-6ee79728f67c@oracle.com>
Message-ID: <0d58f7a4-aec3-5190-2240-ef75d9733944@Oracle.com>

Hi Hamlin,

Wakeup.java:

  - Some refactoring may make it easier to understand.
    Perhaps moving waitSleeper to be a method on Sleeper.
    The use of cyclicBarrier seems fine but could use a comment 
somewhere saying what
threads/functions are being coordinated; putting them both in Sleeper 
would make it easier to see.

- line 126,127:  Add a Sleeper constructor to initialize these as needed.

- Some of the test stimulus is buried in the newSleeper methods that was 
previously
   in line in main.  It seemed clearer what case was being tested in the 
original.
   They are buried in static factory 'newSleeper' functions with 
uninformative names.
    lines 112, 116, 120.

  - If I read it right, some cases where events don't happen that used 
to be reported as exceptions
    ("Interrupt never delivered") will now be reported as the test 
timing out.  (infinite loop at line 85).

Thanks, Roger

On 11/29/2016 4:23 AM, Hamlin Li wrote:
> Would you please review the below patch?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8049316
> webrev: http://cr.openjdk.java.net/~mli/8049316/webrev.00/
>
> Root cause:
> 1. it depends on sleeping time to check failure, which is not reliable 
> in some extreme situation
> 2. it mix several tests together with a loop in Sleeper
>
> Solution:
> 1. synchronize between threads.
> 2. isolate tests.
>
> Thank you
> Hamlin


From gromero at linux.vnet.ibm.com  Tue Nov 29 16:31:58 2016
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Tue, 29 Nov 2016 14:31:58 -0200
Subject: [aarch64-port-dev ] RFR(s) PPC64/s390x/aarch64: Poor StrictMath
	performance due to non-optimized compilation
In-Reply-To: 
References: <583C5B10.8040204@linux.vnet.ibm.com>
	
	
Message-ID: <583DAD7E.7020807@linux.vnet.ibm.com>

Hi Andrew,

On 29-11-2016 13:35, Andrew Haley wrote:
> On 29/11/16 09:41, Volker Simonis wrote:
>> Thanks Gustavo,
>>
>> the change looks good.
>>
>> So now we're just waiting for another review from somebody of the aarch64 folks.
>> Once we have that and the fc-request is approved I'll push the changes.
> 
> One thing I don't understand:
> 
> cos 0.17098435541865692 1m7.433s 0.1709843554185943 0m56.678s
> sin 1.7136493465700289 1m10.654s 1.7136493465700542 0m57.114s
> 
> Do you know what causes the lower digits to be different?  Is
> it that Math and StrictMath use different algorithms, not just
> different optimization levels?

I don't know exactly what's the root cause for that difference (in the result).
The difference is not present on x64, however on PPC64 even with -O0 (as it is
by now) that difference exists.

Math methods are intrisified, but StricMath are not. But I understand that Math
and StrictMath share the fdlibm code since I already changed some code in fdlibm
that reflected both on Math and StrictMath, so it's not clear to me where the
Math relaxation occurs on PPC64 (given that such a relaxation is allowed [1]).

For sure others much more experienced than I can comment about difference.


Regards,
Gustavo

[1] https://docs.oracle.com/javase/8/docs/api/java/lang/Math.html


From Roger.Riggs at Oracle.com  Tue Nov 29 16:50:54 2016
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 29 Nov 2016 11:50:54 -0500
Subject: RFR of JDK-8019538: TEST_BUG:
	java/rmi/activation/rmidViaInheritedChannel tests may fail
In-Reply-To: <73753d7c-9d58-8632-da37-10e12e13e400@oracle.com>
References: <73753d7c-9d58-8632-da37-10e12e13e400@oracle.com>
Message-ID: <9658e687-9e58-be70-cc58-6bf6dc3ea76c@Oracle.com>

Hi Hamlin,

The changes proposed are fine as far as they go, but...

I think this test can be completely removed.
The recent change to use inherited channel for many  of the rmid tests 
makes this test redundant.
It does not add anything over other activation/RMID tests.

The test before the changes, was successful because it launched the 
daemon with
a specific selector provider whose only action was to notify that it was 
launched successfully
(by invoking a method on an object registered in the registry) and was 
successful if the invoking
test program received the notification.

That function is now replaced by RMID.createRMIDonEphemeralPort().
If it succeeds to launch and retrieve the port number, then the 
InheritedChannel mechanism is fully working.

So I think the test can be removed entirely.
Make sense?

Thanks, Roger

On 11/23/2016 4:49 AM, Hamlin Li wrote:
> Would you please review the fix for below bug?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8019538
> webrev: http://cr.openjdk.java.net/~mli/8019538/webrev.00/
>
> There are 4 issues in the bug,
> 2 in RmidViaInheritedChannel.java:  "port in use" in registry, "port 
> in use" in rmid start.
> 2 InheritedChannelNotServerSocket.java: "port in use" in registry, 
> "port in use" in rmid start.
>
> This patch fixes 2 issues in RmidViaInheritedChannel, and only "port 
> in use" in registry in InheritedChannelNotServerSocket.
> The "port in use" in rmid in InheritedChannelNotServerSocket is little 
> bit hard, as it intends to test rmid when inherited channel not work. 
> Currently the only solution in my mind is to retry when rmid fails 
> with "port in use", but as we discussed earlier, it's not a good 
> solution as it might impact other programs or tests, and it's not 
> efficient.
> So I hope to push the fix for the other issues first to improve the 
> stability of RMI tests, and keep studying if there are other better 
> solutions for the "port in use" in rmid in 
> InheritedChannelNotServerSocket.
>
> Thank you
> -Hamlin


From peter.levart at gmail.com  Tue Nov 29 16:57:06 2016
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 29 Nov 2016 17:57:06 +0100
Subject: RFR: 8170467: (reflect) Optimize SignatureParser's use of
	StringBuilders
In-Reply-To: <972410b1-21e6-8da2-6750-a2f0d8eabcec@oracle.com>
References: <90b347de-fd85-03c7-51eb-44fedf6f5645@oracle.com>
	
	<972410b1-21e6-8da2-6750-a2f0d8eabcec@oracle.com>
Message-ID: <7c343eb3-a8ba-fbfc-9630-c2f0d6f096db@gmail.com>

Hi,

What about not using StringBuilder at all?

http://cr.openjdk.java.net/~plevart/jdk9-dev/8170467_SignatureParser/webrev.01/

There's also some mockery in getNext()/current()/advance() that uses 
exceptions for control flow which can be fixed while changing this part 
of code. The asserts in getNext()/current()/advance() could even fail if 
getNext()/advance() was called after already returning EOI (== character 
':')...

Regards, Peter


On 11/29/2016 03:03 PM, Claes Redestad wrote:
> Hi Andrej,
>
> On 2016-11-29 14:39, Andrej Golovnin wrote:
>> Hi Claes,
>>
>> 76     public static final int CLASS_NAME_SB_SIZE = 48;
>>
>> Why is this constant public?
>
> Good catch, made it private.
>
>> Btw. for our product this value is too small. We have packages with
>> longer names. I would use 64. :-)
>
> There's no one size fits all: something around 48 is likely to
> help most common cases, while not noticeably penalizing
> shorter names. I'd consider it a bad move to regress apps
> with short-to-normal names to get a small gain on apps with
> very long names
>
> Thanks!
>
> /Claes
>
>>
>> Best regards,
>> Andrej Golovnin
>>
>> On Tue, Nov 29, 2016 at 2:18 PM, Claes Redestad
>>  wrote:
>>> Hi,
>>>
>>> please review this patch provided by Max Kanat-Alexander[1] to improve
>>> performance of sun.reflect.generics.parser.SignatureParser by reducing
>>> number of StringBuilders created and the rate at which they are resized
>>> during typical usage.
>>>
>>> Webrev: http://cr.openjdk.java.net/~redestad/8170467/webrev.01/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170467
>>>
>>> Thanks!
>>>
>>> /Claes
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/045046.html 
>>>
>


From claes.redestad at oracle.com  Tue Nov 29 17:34:46 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 29 Nov 2016 09:34:46 -0800
Subject: RFR: 8170467: (reflect) Optimize SignatureParser's use of
	StringBuilders
In-Reply-To: <7c343eb3-a8ba-fbfc-9630-c2f0d6f096db@gmail.com>
References: <90b347de-fd85-03c7-51eb-44fedf6f5645@oracle.com>
	
	<972410b1-21e6-8da2-6750-a2f0d8eabcec@oracle.com>
	<7c343eb3-a8ba-fbfc-9630-c2f0d6f096db@gmail.com>
Message-ID: <583DBC36.8040606@oracle.com>

Hi Peter,

On 11/29/2016 08:57 AM, Peter Levart wrote:
> Hi,
>
> What about not using StringBuilder at all?
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/8170467_SignatureParser/webrev.01/ 
>

your patch idea is rather clever but might prove to be better across the 
board with no
need for any magic numbers, which is nice.

>
> There's also some mockery in getNext()/current()/advance() that uses 
> exceptions for control flow which can be fixed while changing this 
> part of code. The asserts in getNext()/current()/advance() could even 
> fail if getNext()/advance() was called after already returning EOI (== 
> character ':')...
>

(mockery :D)

Unfortunately I've already pushed Max's patch, but there's also 
https://bugs.openjdk.java.net/browse/JDK-8035424
which asks for getting rid of the exceptional flow using a suggestion 
similar to yours, and I don't mind sponsoring
another go at this. I suggest we move ahead with your patch using that 
bug ID.

(getNext - and matches - appear unused and could be removed rather than 
fixed?)

/Claes

> Regards, Peter
>
>
> On 11/29/2016 03:03 PM, Claes Redestad wrote:
>> Hi Andrej,
>>
>> On 2016-11-29 14:39, Andrej Golovnin wrote:
>>> Hi Claes,
>>>
>>> 76     public static final int CLASS_NAME_SB_SIZE = 48;
>>>
>>> Why is this constant public?
>>
>> Good catch, made it private.
>>
>>> Btw. for our product this value is too small. We have packages with
>>> longer names. I would use 64. :-)
>>
>> There's no one size fits all: something around 48 is likely to
>> help most common cases, while not noticeably penalizing
>> shorter names. I'd consider it a bad move to regress apps
>> with short-to-normal names to get a small gain on apps with
>> very long names
>>
>> Thanks!
>>
>> /Claes
>>
>>>
>>> Best regards,
>>> Andrej Golovnin
>>>
>>> On Tue, Nov 29, 2016 at 2:18 PM, Claes Redestad
>>>  wrote:
>>>> Hi,
>>>>
>>>> please review this patch provided by Max Kanat-Alexander[1] to improve
>>>> performance of sun.reflect.generics.parser.SignatureParser by reducing
>>>> number of StringBuilders created and the rate at which they are 
>>>> resized
>>>> during typical usage.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~redestad/8170467/webrev.01/
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170467
>>>>
>>>> Thanks!
>>>>
>>>> /Claes
>>>>
>>>> [1]
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/045046.html 
>>>>
>>
>


From volker.simonis at gmail.com  Tue Nov 29 18:06:05 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 29 Nov 2016 19:06:05 +0100
Subject: [aarch64-port-dev ] RFR(s) PPC64/s390x/aarch64: Poor StrictMath
	performance due to non-optimized compilation
In-Reply-To: <583DAD7E.7020807@linux.vnet.ibm.com>
References: <583C5B10.8040204@linux.vnet.ibm.com>
	
	
	<583DAD7E.7020807@linux.vnet.ibm.com>
Message-ID: 

On Tue, Nov 29, 2016 at 5:31 PM, Gustavo Romero
 wrote:
> Hi Andrew,
>
> On 29-11-2016 13:35, Andrew Haley wrote:
>> On 29/11/16 09:41, Volker Simonis wrote:
>>> Thanks Gustavo,
>>>
>>> the change looks good.
>>>
>>> So now we're just waiting for another review from somebody of the aarch64 folks.
>>> Once we have that and the fc-request is approved I'll push the changes.
>>
>> One thing I don't understand:
>>
>> cos 0.17098435541865692 1m7.433s 0.1709843554185943 0m56.678s
>> sin 1.7136493465700289 1m10.654s 1.7136493465700542 0m57.114s
>>
>> Do you know what causes the lower digits to be different?  Is
>> it that Math and StrictMath use different algorithms, not just
>> different optimization levels?
>
> I don't know exactly what's the root cause for that difference (in the result).
> The difference is not present on x64, however on PPC64 even with -O0 (as it is
> by now) that difference exists.
>
> Math methods are intrisified, but StricMath are not. But I understand that Math
> and StrictMath share the fdlibm code since I already changed some code in fdlibm
> that reflected both on Math and StrictMath, so it's not clear to me where the
> Math relaxation occurs on PPC64 (given that such a relaxation is allowed [1]).
>

I think the difference is because Math functions can be intrinsified
(and optimized) while StricMath functions can not.

HotSpot has different ways of intrinsifying the Math functions. If the
CPU is supporting the corresponding function the VM generates special
nodes for that. Otherwise, if there exist special optimized assembler
stubs for a function (e.g. see "StubRoutines::_dsin =
generate_libmSin()" in stubGenerator_x86_64.cpp) the VM makes use of
them. Otherwise it still uses leaf-calls into HotSpots internal
C++-Implementation of the functions (e.g. SharedRuntime::dsin() in
sharedRuntimeTrig.cpp) which are faster than doing a native call into
the fdlibm version.

The implementation in SharedRuntime doesn't has to be "strict" so it
probably uses fused multiplication and it is also build with full
optimization without '-ffp-contract=off' (which is OK in this case).

@Andrew: are you fine with Gustavos latest version of the change?

> For sure others much more experienced than I can comment about difference.
>
>
> Regards,
> Gustavo
>
> [1] https://docs.oracle.com/javase/8/docs/api/java/lang/Math.html
>

From aph at redhat.com  Tue Nov 29 18:15:09 2016
From: aph at redhat.com (Andrew Haley)
Date: Tue, 29 Nov 2016 18:15:09 +0000
Subject: [aarch64-port-dev ] RFR(s) PPC64/s390x/aarch64: Poor StrictMath
	performance due to non-optimized compilation
In-Reply-To: 
References: <583C5B10.8040204@linux.vnet.ibm.com>
	
	
	<583DAD7E.7020807@linux.vnet.ibm.com>
	
Message-ID: <3c3aa7f0-01c7-46ae-ce8d-414d43213e4a@redhat.com>

On 29/11/16 18:06, Volker Simonis wrote:
> @Andrew: are you fine with Gustavos latest version of the change?

Sure.  The StrictMath versions all seem to give the same results.

Andrew.


From Roger.Riggs at Oracle.com  Tue Nov 29 18:31:00 2016
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 29 Nov 2016 13:31:00 -0500
Subject: RFR 9: 8169527 : Typo in getCalendarType() method of Chronology class
Message-ID: <669b3270-7ee7-284a-8ce9-3274567f24ed@Oracle.com>

Please review editorial javadoc corrections in java.time.chrono.Chronology.

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-typo-8169527/

Issue:
    https://bugs.openjdk.java.net/browse/JDK-8169527

Thanks, Roger


From brian.burkhalter at oracle.com  Tue Nov 29 18:34:33 2016
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 29 Nov 2016 10:34:33 -0800
Subject: RFR 9: 8169527 : Typo in getCalendarType() method of Chronology
	class
In-Reply-To: <669b3270-7ee7-284a-8ce9-3274567f24ed@Oracle.com>
References: <669b3270-7ee7-284a-8ce9-3274567f24ed@Oracle.com>
Message-ID: 

Hi Roger,

+1

Brian

On Nov 29, 2016, at 10:31 AM, Roger Riggs  wrote:

> Please review editorial javadoc corrections in java.time.chrono.Chronology.
> 
> Webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-typo-8169527/
> 
> Issue:
>   https://bugs.openjdk.java.net/browse/JDK-8169527
> 
> Thanks, Roger
> 


From gromero at linux.vnet.ibm.com  Tue Nov 29 18:37:01 2016
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Tue, 29 Nov 2016 16:37:01 -0200
Subject: [aarch64-port-dev ] RFR(s) PPC64/s390x/aarch64: Poor StrictMath
	performance due to non-optimized compilation
In-Reply-To: <3c3aa7f0-01c7-46ae-ce8d-414d43213e4a@redhat.com>
References: <583C5B10.8040204@linux.vnet.ibm.com>
	
	
	<583DAD7E.7020807@linux.vnet.ibm.com>
	
	<3c3aa7f0-01c7-46ae-ce8d-414d43213e4a@redhat.com>
Message-ID: <583DCACD.3090803@linux.vnet.ibm.com>

Hi Erik, Volker, Andrew

On 29-11-2016 16:15, Andrew Haley wrote:
> On 29/11/16 18:06, Volker Simonis wrote:
>> @Andrew: are you fine with Gustavos latest version of the change?
> 
> Sure.  The StrictMath versions all seem to give the same results.
> 
> Andrew.
> 

Thanks for reviewing the change!

I changed the "FC Extension Request" status to "reviewed".


Regards,
Gustavo


From martinrb at google.com  Tue Nov 29 18:47:15 2016
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 29 Nov 2016 10:47:15 -0800
Subject: RFR: jsr166 jdk9 integration wave 12
In-Reply-To: 
References: 
	<8cc0d5a9-9245-e6b1-0ff2-616127dbc583@oracle.com>
	
	
	
	
	
	
	
	
	
	
	<36B64BBF-7010-45FC-99DD-0207CDAC3BDB@oracle.com>
	
Message-ID: 

This finally got committed, after a lot of performance and testing rework,
and discovering plenty of opportunity for future performance, scalability
and testing improvements.  Thanks to reviewers for performance push back,
leading especially to a better ArrayDeque.

From ivan.gerasimov at oracle.com  Tue Nov 29 19:02:18 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 29 Nov 2016 22:02:18 +0300
Subject: RFR 9: 8169527 : Typo in getCalendarType() method of Chronology
	class
In-Reply-To: <669b3270-7ee7-284a-8ce9-3274567f24ed@Oracle.com>
References: <669b3270-7ee7-284a-8ce9-3274567f24ed@Oracle.com>
Message-ID: 

Hi Roger!

Looks good!

My grep found a few similar typos nearby:

./ZoneOffset.java:     * @throws DateTimeException if unable to convert 
to *an* {@code ZoneOffset}
./ZonedDateTime.java:     * @throws DateTimeException if unable to 
convert to *an *{@code ZonedDateTime}
./temporal/TemporalQueries.java:     * It will not be returned if the 
date-time only conceptually has *an *{@code ZoneOffset}.
./chrono/ChronoLocalDateTimeImpl.java: * "2nd October 2007 at 
13:45.30.123456789" can be stored in *an *{@code ChronoLocalDateTime}.
./Instant.java:     * This returns *an *{@code ZonedDateTime} formed 
from this instant at the

Maybe worth including it in the same fix.

With kind regards,
Ivan

On 29.11.2016 21:31, Roger Riggs wrote:
> Please review editorial javadoc corrections in 
> java.time.chrono.Chronology.
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-typo-8169527/
>
> Issue:
>    https://bugs.openjdk.java.net/browse/JDK-8169527
>
> Thanks, Roger
>
>


From john_platts at hotmail.com  Tue Nov 29 20:13:52 2016
From: john_platts at hotmail.com (John Platts)
Date: Tue, 29 Nov 2016 20:13:52 +0000
Subject: Enhancements to Java Collections API
Message-ID: 

There are many features that are missing from the Java Collections API that should be added to the Java Collections API, including the following:

  *   Bidirectional iterators for collections other than lists
     *   New interfaces
        *   BidiIterator - bidirectional iterator
           *   extended by ListIterator interface
           *   has hasPrevious() and previous() methods
        *   ReverseIterable - reverse iterable
           *   extends Iterable
           *   extended by List, Deque, NavigableSet, and BidiIterable
           *   has descendingIterator() and reverseForEach(Consumer) methods
        *   BidiIterable - bidirectional iterable
           *   extends ReverseIterable
           *   bidiIterator() returns a BidiIterator
           *   bidiIteratorFromEnd() returns a BidiIterator that is positioned just past the last element in the collection
           *   extended by List, BidiIterableCollection, BidiIterableSet, BidiIterableNavigableSet, and BidiIterableDeque
        *   BidiIterableCollection - bidirectional iterable collection, extends BidiIterable and Collection
           *   extended by List, BidiIterableSet, BidiIterableNavigableSet, and BidiIterableDeque
           *   default implementation of bidiIterator() method added to the java.util.List interface that delegates to java.util.List.listIterator()
           *   default implementation of bidiIteratorFromEnd() method added to the java.util.List interface that delegates to java.util.List.listIterator(size())
        *   BidiIterableSet - bidirectional iterable set, extends BidiCollection and Set
        *   BidiIterableNavigableSet - bidirectional iterable navigable iterable set, extends BidiIterableSet and NavigableSet
           *   subSet(), headSet(), and tailSet() all return BidiIterableNavigableSet instances
        *   BidiIterableDeque - bidirectional iterable deque, extends BidiCollection and Deque
        *   BidiIterableMap - bidirectional iterable map
           *   extends Map
           *   keySet() and entrySet() return BidiIterableSet
           *   values() returns BidiCollection
           *   has reverseForEach(BiConsumer) method
        *   BidiIterableNavigableMap - bidirectional iterable navigable map
           *   extends BidiIterableMap and NavigableMap
           *   keySet(), navigableKeySet(), and descendingKeySet() all return BidiNavigableSet
           *   entrySet() returns BidiIterableSet
           *   values() returns BidiCollection
           *   subMap(), headMap() and tailMap() all return BidiIterableNavigableMap instances
     *   BidiIterableDeque interface implemented on java.util.ArrayDeque, java.util.concurrent.ConcurrentLinkedDeque, java.util.concurrent.LinkedBlockingDeque, and java.util.LinkedList
     *   BidiIterableSet interface implemented on java.util.LinkedHashSet, java.util.TreeSet, and java.util.concurrent.ConcurrentSkipListSet
     *   BidiIterableNavigableSet interface implemented on java.util.TreeSet and java.util.concurrent.ConcurrentSkipListSet
     *   BidiIterableMap interface implemented on java.util.LinkedHashMap, java.util.TreeMap, and java.util.concurrent.ConcurrentSkipListMap
     *   BidiIterableNavigableMap interface implemented on java.util.TreeMap and java.util.concurrent.ConcurrentSkipListMap
  *   Pollable interface
     *   Extended by the Queue, Deque, and NavigableSet interfaces
     *   Also implemented by the java.lang.ref.ReferenceQueue class
     *   Contains the poll() method, which is already defined by the Queue and Deque interfaces
  *   BidiPollable interface
     *   Extends the Pollable interface
     *   Extended by the Deque and NavigableSet interfaces
     *   Contains the pollFirst() and pollLast() methods, which are already defined in both the Deque and NavigableSet interfaces
  *   Navigable versions of java.util.EnumMap and java.util.EnumSet
     *   Option #1: Implement the NavigableMap interface on top of java.util.EnumMap and java.util.EnumSet
     *   Option #2: Implement separate java.util.NavigableEnumMap and java.util.NavigableEnumSet classes that behave similarly to the existing java.util.EnumMap and java.util.EnumSet classes, except that the java.util.NavigableEnumMap class has the functionality of the java.util.NavigableMap interface and that the java.util.NavigableEnumSet class has the functionality of the java.util.NavigableSet interface.
     *   Under both options, the comparator() method of the navigable versions of EnumMap and EnumSet would return null
     *   Navigable versions of EnumMap and EnumSet are possible since all enum types implement the Comparable interface
  *   New enhanced map and set implementations
     *   Support for hash maps and hash sets with custom hashcode function and custom equality predicate
     *   Enhanced map interface that defines a Optional getIfPresent(K key) method that returns the following:
        *   A non-empty optional if the key is contained in the map and the value is non-null
        *   An empty optional if the key is contained in the map, but the value is null
        *   null if the map does not contain key

Will these enhancements ever make it into Java SE 10 or Java SE 11?

  *

From patrick at reini.net  Tue Nov 29 21:15:34 2016
From: patrick at reini.net (Patrick Reinhart)
Date: Tue, 29 Nov 2016 22:15:34 +0100
Subject: Request for Review and Sponsor needed: JDK-8167648:
	java.io.PrintWriter should have PrintWriter((String|File), Charset)
	constructors
Message-ID: <6D1ED283-28C4-4787-B33E-9EF5B8AB9F50@reini.net>

Does anyone sponsor this fix?

http://cr.openjdk.java.net/~reinhapa/reviews/8167648/webrev.00

-Patrick

From peter.levart at gmail.com  Tue Nov 29 21:28:23 2016
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 29 Nov 2016 22:28:23 +0100
Subject: RFR: 8035424: (reflect) Performance problem in
	sun.reflect.generics.parser.SignatureParser
In-Reply-To: <583DBC36.8040606@oracle.com>
References: <90b347de-fd85-03c7-51eb-44fedf6f5645@oracle.com>
	
	<972410b1-21e6-8da2-6750-a2f0d8eabcec@oracle.com>
	<7c343eb3-a8ba-fbfc-9630-c2f0d6f096db@gmail.com>
	<583DBC36.8040606@oracle.com>
Message-ID: <068104fd-643b-539a-c0d0-20c2b1099153@gmail.com>

Hi Claes,

On 11/29/2016 06:34 PM, Claes Redestad wrote:
> Hi Peter,
>
> On 11/29/2016 08:57 AM, Peter Levart wrote:
>> Hi,
>>
>> What about not using StringBuilder at all?
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8170467_SignatureParser/webrev.01/ 
>>
>
> your patch idea is rather clever but might prove to be better across 
> the board with no
> need for any magic numbers, which is nice.

It also improves the parseIdentifier() method - no double copying of 
chars as done when using StringBuilder.

>
>>
>> There's also some mockery in getNext()/current()/advance() that uses 
>> exceptions for control flow which can be fixed while changing this 
>> part of code. The asserts in getNext()/current()/advance() could even 
>> fail if getNext()/advance() was called after already returning EOI 
>> (== character ':')...
>>
>
> (mockery :D)
>
> Unfortunately I've already pushed Max's patch, but there's also 
> https://bugs.openjdk.java.net/browse/JDK-8035424
> which asks for getting rid of the exceptional flow using a suggestion 
> similar to yours, and I don't mind sponsoring
> another go at this. I suggest we move ahead with your patch using that 
> bug ID.
>
> (getNext - and matches - appear unused and could be removed rather 
> than fixed?)

Right, do you want just removal of exceptions or the whole thing?

I reduced copying further. The 'input' field is a char[], but could 
simply be a String. No need to extract input String's chars into an 
array 1st:

http://cr.openjdk.java.net/~plevart/jdk9-dev/8035424_SignatureParser.performance/webrev.01/


Regards, Peter

>
> /Claes
>
>> Regards, Peter
>>
>>
>> On 11/29/2016 03:03 PM, Claes Redestad wrote:
>>> Hi Andrej,
>>>
>>> On 2016-11-29 14:39, Andrej Golovnin wrote:
>>>> Hi Claes,
>>>>
>>>> 76     public static final int CLASS_NAME_SB_SIZE = 48;
>>>>
>>>> Why is this constant public?
>>>
>>> Good catch, made it private.
>>>
>>>> Btw. for our product this value is too small. We have packages with
>>>> longer names. I would use 64. :-)
>>>
>>> There's no one size fits all: something around 48 is likely to
>>> help most common cases, while not noticeably penalizing
>>> shorter names. I'd consider it a bad move to regress apps
>>> with short-to-normal names to get a small gain on apps with
>>> very long names
>>>
>>> Thanks!
>>>
>>> /Claes
>>>
>>>>
>>>> Best regards,
>>>> Andrej Golovnin
>>>>
>>>> On Tue, Nov 29, 2016 at 2:18 PM, Claes Redestad
>>>>  wrote:
>>>>> Hi,
>>>>>
>>>>> please review this patch provided by Max Kanat-Alexander[1] to 
>>>>> improve
>>>>> performance of sun.reflect.generics.parser.SignatureParser by 
>>>>> reducing
>>>>> number of StringBuilders created and the rate at which they are 
>>>>> resized
>>>>> during typical usage.
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~redestad/8170467/webrev.01/
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170467
>>>>>
>>>>> Thanks!
>>>>>
>>>>> /Claes
>>>>>
>>>>> [1]
>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/045046.html 
>>>>>
>>>
>>
>


From scolebourne at joda.org  Tue Nov 29 21:46:25 2016
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 29 Nov 2016 21:46:25 +0000
Subject: RFR 9: 8169527 : Typo in getCalendarType() method of Chronology
	class
In-Reply-To: <669b3270-7ee7-284a-8ce9-3274567f24ed@Oracle.com>
References: <669b3270-7ee7-284a-8ce9-3274567f24ed@Oracle.com>
Message-ID: 

+1
Stephen

On 29 November 2016 at 18:31, Roger Riggs  wrote:
> Please review editorial javadoc corrections in java.time.chrono.Chronology.
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-typo-8169527/
>
> Issue:
>    https://bugs.openjdk.java.net/browse/JDK-8169527
>
> Thanks, Roger
>

From claes.redestad at oracle.com  Tue Nov 29 21:58:24 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 29 Nov 2016 13:58:24 -0800
Subject: RFR: 8035424: (reflect) Performance problem in
	sun.reflect.generics.parser.SignatureParser
In-Reply-To: <068104fd-643b-539a-c0d0-20c2b1099153@gmail.com>
References: <90b347de-fd85-03c7-51eb-44fedf6f5645@oracle.com>
	
	<972410b1-21e6-8da2-6750-a2f0d8eabcec@oracle.com>
	<7c343eb3-a8ba-fbfc-9630-c2f0d6f096db@gmail.com>
	<583DBC36.8040606@oracle.com>
	<068104fd-643b-539a-c0d0-20c2b1099153@gmail.com>
Message-ID: <583DFA00.4030108@oracle.com>

Hi Peter,

On 11/29/2016 01:28 PM, Peter Levart wrote:
> Hi Claes,
>
> On 11/29/2016 06:34 PM, Claes Redestad wrote:
>> Hi Peter,
>>
>> On 11/29/2016 08:57 AM, Peter Levart wrote:
>>> Hi,
>>>
>>> What about not using StringBuilder at all?
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8170467_SignatureParser/webrev.01/ 
>>>
>>
>> your patch idea is rather clever but might prove to be better across 
>> the board with no
>> need for any magic numbers, which is nice.
>
> It also improves the parseIdentifier() method - no double copying of 
> chars as done when using StringBuilder.

Yes, I didn't suggest otherwise. :-)

>
>>
>>>
>>> There's also some mockery in getNext()/current()/advance() that uses 
>>> exceptions for control flow which can be fixed while changing this 
>>> part of code. The asserts in getNext()/current()/advance() could 
>>> even fail if getNext()/advance() was called after already returning 
>>> EOI (== character ':')...
>>>
>>
>> (mockery :D)
>>
>> Unfortunately I've already pushed Max's patch, but there's also 
>> https://bugs.openjdk.java.net/browse/JDK-8035424
>> which asks for getting rid of the exceptional flow using a suggestion 
>> similar to yours, and I don't mind sponsoring
>> another go at this. I suggest we move ahead with your patch using 
>> that bug ID.
>>
>> (getNext - and matches - appear unused and could be removed rather 
>> than fixed?)
>
> Right, do you want just removal of exceptions or the whole thing?
>
> I reduced copying further. The 'input' field is a char[], but could 
> simply be a String. No need to extract input String's chars into an 
> array 1st:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/8035424_SignatureParser.performance/webrev.01/

I think pushing this as 8035424 is OK.

I know I just told you to remove it, but wouldn't the slightly awkward 
for loops read better as:

char c = current();
while (!(...)) {
   c = getNext();
}

Thanks!

/Claes

From peter.levart at gmail.com  Tue Nov 29 22:30:07 2016
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 29 Nov 2016 23:30:07 +0100
Subject: RFR: 8035424: (reflect) Performance problem in
	sun.reflect.generics.parser.SignatureParser
In-Reply-To: <583DFA00.4030108@oracle.com>
References: <90b347de-fd85-03c7-51eb-44fedf6f5645@oracle.com>
	
	<972410b1-21e6-8da2-6750-a2f0d8eabcec@oracle.com>
	<7c343eb3-a8ba-fbfc-9630-c2f0d6f096db@gmail.com>
	<583DBC36.8040606@oracle.com>
	<068104fd-643b-539a-c0d0-20c2b1099153@gmail.com>
	<583DFA00.4030108@oracle.com>
Message-ID: <7aae60a7-3e4c-c000-6acc-cfdcb1b59f66@gmail.com>



On 11/29/2016 10:58 PM, Claes Redestad wrote:
> Hi Peter,
>
> On 11/29/2016 01:28 PM, Peter Levart wrote:
>> Hi Claes,
>>
>> On 11/29/2016 06:34 PM, Claes Redestad wrote:
>>> Hi Peter,
>>>
>>> On 11/29/2016 08:57 AM, Peter Levart wrote:
>>>> Hi,
>>>>
>>>> What about not using StringBuilder at all?
>>>>
>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8170467_SignatureParser/webrev.01/ 
>>>>
>>>
>>> your patch idea is rather clever but might prove to be better across 
>>> the board with no
>>> need for any magic numbers, which is nice.
>>
>> It also improves the parseIdentifier() method - no double copying of 
>> chars as done when using StringBuilder.
>
> Yes, I didn't suggest otherwise. :-)
>
>>
>>>
>>>>
>>>> There's also some mockery in getNext()/current()/advance() that 
>>>> uses exceptions for control flow which can be fixed while changing 
>>>> this part of code. The asserts in getNext()/current()/advance() 
>>>> could even fail if getNext()/advance() was called after already 
>>>> returning EOI (== character ':')...
>>>>
>>>
>>> (mockery :D)
>>>
>>> Unfortunately I've already pushed Max's patch, but there's also 
>>> https://bugs.openjdk.java.net/browse/JDK-8035424
>>> which asks for getting rid of the exceptional flow using a 
>>> suggestion similar to yours, and I don't mind sponsoring
>>> another go at this. I suggest we move ahead with your patch using 
>>> that bug ID.
>>>
>>> (getNext - and matches - appear unused and could be removed rather 
>>> than fixed?)
>>
>> Right, do you want just removal of exceptions or the whole thing?
>>
>> I reduced copying further. The 'input' field is a char[], but could 
>> simply be a String. No need to extract input String's chars into an 
>> array 1st:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8035424_SignatureParser.performance/webrev.01/
>
> I think pushing this as 8035424 is OK.
>
> I know I just told you to remove it, but wouldn't the slightly awkward 
> for loops read better as:
>
> char c = current();
> while (!(...)) {
>   c = getNext();
> }

They would if c = getNext(); was equivalent to { advance(); c = 
current(); }, but it was not. It was defined as: { c = current(); 
advance(); }.

I could re-introduce a different getNext() with the desired behavior, 
but here's another variant with a more "streaming" approach which tries 
to re-use the logic for parsing the identifier:

http://cr.openjdk.java.net/~plevart/jdk9-dev/8035424_SignatureParser.performance/webrev.02/


What do you think of this one?

Regards, Peter


>
> Thanks!
>
> /Claes


From peter.levart at gmail.com  Tue Nov 29 22:41:26 2016
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 29 Nov 2016 23:41:26 +0100
Subject: RFR: 8035424: (reflect) Performance problem in
	sun.reflect.generics.parser.SignatureParser
In-Reply-To: <7aae60a7-3e4c-c000-6acc-cfdcb1b59f66@gmail.com>
References: <90b347de-fd85-03c7-51eb-44fedf6f5645@oracle.com>
	
	<972410b1-21e6-8da2-6750-a2f0d8eabcec@oracle.com>
	<7c343eb3-a8ba-fbfc-9630-c2f0d6f096db@gmail.com>
	<583DBC36.8040606@oracle.com>
	<068104fd-643b-539a-c0d0-20c2b1099153@gmail.com>
	<583DFA00.4030108@oracle.com>
	<7aae60a7-3e4c-c000-6acc-cfdcb1b59f66@gmail.com>
Message-ID: <13241b6e-c5ff-85d7-e312-c2aba940ee5e@gmail.com>

Hi Claes,

On 11/29/2016 11:30 PM, Peter Levart wrote:
>
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/8035424_SignatureParser.performance/webrev.02/
>

Which loop do you prefer. The above one or the following?

     private void skipIdentifier() {
         char c;
         while (!((c = current()) == ';' || c == '.' || c == '/' ||
                  c == '[' || c == ':' || c == '>' || c == '<' ||
                  Character.isWhitespace(c))) {
             advance();
         }
     }


Peter


From claes.redestad at oracle.com  Tue Nov 29 22:53:58 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 29 Nov 2016 14:53:58 -0800
Subject: RFR: 8035424: (reflect) Performance problem in
	sun.reflect.generics.parser.SignatureParser
In-Reply-To: <7aae60a7-3e4c-c000-6acc-cfdcb1b59f66@gmail.com>
References: <90b347de-fd85-03c7-51eb-44fedf6f5645@oracle.com>
	
	<972410b1-21e6-8da2-6750-a2f0d8eabcec@oracle.com>
	<7c343eb3-a8ba-fbfc-9630-c2f0d6f096db@gmail.com>
	<583DBC36.8040606@oracle.com>
	<068104fd-643b-539a-c0d0-20c2b1099153@gmail.com>
	<583DFA00.4030108@oracle.com>
	<7aae60a7-3e4c-c000-6acc-cfdcb1b59f66@gmail.com>
Message-ID: <583E0706.10403@oracle.com>

On 11/29/2016 02:30 PM, Peter Levart wrote:
>
>
>
> On 11/29/2016 10:58 PM, Claes Redestad wrote:
>> Hi Peter,
>>
>> On 11/29/2016 01:28 PM, Peter Levart wrote:
>>> Hi Claes,
>>>
>>> On 11/29/2016 06:34 PM, Claes Redestad wrote:
>>>> Hi Peter,
>>>>
>>>> On 11/29/2016 08:57 AM, Peter Levart wrote:
>>>>> Hi,
>>>>>
>>>>> What about not using StringBuilder at all?
>>>>>
>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8170467_SignatureParser/webrev.01/ 
>>>>>
>>>>
>>>> your patch idea is rather clever but might prove to be better 
>>>> across the board with no
>>>> need for any magic numbers, which is nice.
>>>
>>> It also improves the parseIdentifier() method - no double copying of 
>>> chars as done when using StringBuilder.
>>
>> Yes, I didn't suggest otherwise. :-)
>>
>>>
>>>>
>>>>>
>>>>> There's also some mockery in getNext()/current()/advance() that 
>>>>> uses exceptions for control flow which can be fixed while changing 
>>>>> this part of code. The asserts in getNext()/current()/advance() 
>>>>> could even fail if getNext()/advance() was called after already 
>>>>> returning EOI (== character ':')...
>>>>>
>>>>
>>>> (mockery :D)
>>>>
>>>> Unfortunately I've already pushed Max's patch, but there's also 
>>>> https://bugs.openjdk.java.net/browse/JDK-8035424
>>>> which asks for getting rid of the exceptional flow using a 
>>>> suggestion similar to yours, and I don't mind sponsoring
>>>> another go at this. I suggest we move ahead with your patch using 
>>>> that bug ID.
>>>>
>>>> (getNext - and matches - appear unused and could be removed rather 
>>>> than fixed?)
>>>
>>> Right, do you want just removal of exceptions or the whole thing?
>>>
>>> I reduced copying further. The 'input' field is a char[], but could 
>>> simply be a String. No need to extract input String's chars into an 
>>> array 1st:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8035424_SignatureParser.performance/webrev.01/
>>
>> I think pushing this as 8035424 is OK.
>>
>> I know I just told you to remove it, but wouldn't the slightly 
>> awkward for loops read better as:
>>
>> char c = current();
>> while (!(...)) {
>>   c = getNext();
>> }
>
> They would if c = getNext(); was equivalent to { advance(); c = 
> current(); }, but it was not. It was defined as: { c = current(); 
> advance(); }.
>
> I could re-introduce a different getNext() with the desired behavior, 
> but here's another variant with a more "streaming" approach which 
> tries to re-use the logic for parsing the identifier:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/8035424_SignatureParser.performance/webrev.02/
>
>
> What do you think of this one?

Fair point. I think this is easier to follow and should do the trick 
just as nicely.

What you have here is fine, but in this day and age of compact strings I 
wonder if return mar.replace('/', '.') might have both a readability and 
a slight performance edge (assuming signatures are almost always ASCII).

Thanks!

/Claes

>
> Regards, Peter
>
>
>>
>> Thanks!
>>
>> /Claes
>


From huaming.li at oracle.com  Wed Nov 30 02:09:49 2016
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 30 Nov 2016 10:09:49 +0800
Subject: RFR of JDK-8049316: TEST_BUG:
	java/nio/channels/Selector/Wakeup.java fails in same binary run b19
In-Reply-To: <0d58f7a4-aec3-5190-2240-ef75d9733944@Oracle.com>
References: <55b7c230-6f1a-57fd-847b-6ee79728f67c@oracle.com>
	<0d58f7a4-aec3-5190-2240-ef75d9733944@Oracle.com>
Message-ID: 

Hi Roger,

Thank you for reviewing, please check comments in line.

webrev: http://cr.openjdk.java.net/~mli/8049316/webrev.01/


On 2016/11/30 0:03, Roger Riggs wrote:
> Hi Hamlin,
>
> Wakeup.java:
>
>  - Some refactoring may make it easier to understand.
>    Perhaps moving waitSleeper to be a method on Sleeper.
>    The use of cyclicBarrier seems fine but could use a comment 
> somewhere saying what
> threads/functions are being coordinated; putting them both in Sleeper 
> would make it easier to see.
>
> - line 126,127:  Add a Sleeper constructor to initialize these as needed.
>
> - Some of the test stimulus is buried in the newSleeper methods that 
> was previously
>   in line in main.  It seemed clearer what case was being tested in 
> the original.
>   They are buried in static factory 'newSleeper' functions with 
> uninformative names.
>    lines 112, 116, 120.
All above fixed.
>
>  - If I read it right, some cases where events don't happen that used 
> to be reported as exceptions
>    ("Interrupt never delivered") will now be reported as the test 
> timing out.  (infinite loop at line 85).
No, it will finally checked by a time sleeper.finish(0). At first, I 
don't want to depends on a specific time, because I don't know what 
exact timeout we should use, but as you asked, I think it's ok to 
finish(20_000), it should be long enough.

Thank you
-Hamlin
>
> Thanks, Roger
>
> On 11/29/2016 4:23 AM, Hamlin Li wrote:
>> Would you please review the below patch?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8049316
>> webrev: http://cr.openjdk.java.net/~mli/8049316/webrev.00/
>>
>> Root cause:
>> 1. it depends on sleeping time to check failure, which is not 
>> reliable in some extreme situation
>> 2. it mix several tests together with a loop in Sleeper
>>
>> Solution:
>> 1. synchronize between threads.
>> 2. isolate tests.
>>
>> Thank you
>> Hamlin
>


From huaming.li at oracle.com  Wed Nov 30 02:25:37 2016
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 30 Nov 2016 10:25:37 +0800
Subject: RFR of JDK-8019538: TEST_BUG:
	java/rmi/activation/rmidViaInheritedChannel tests may fail
In-Reply-To: <9658e687-9e58-be70-cc58-6bf6dc3ea76c@Oracle.com>
References: <73753d7c-9d58-8632-da37-10e12e13e400@oracle.com>
	<9658e687-9e58-be70-cc58-6bf6dc3ea76c@Oracle.com>
Message-ID: <453b4744-6e6c-733f-281a-508b9bf03295@oracle.com>

Hi Roger,

Thank you for reviewing. please check the comments in line.


On 2016/11/30 0:50, Roger Riggs wrote:
> Hi Hamlin,
>
> The changes proposed are fine as far as they go, but...
>
> I think this test can be completely removed.
> The recent change to use inherited channel for many  of the rmid tests 
> makes this test redundant.
> It does not add anything over other activation/RMID tests.
>
> The test before the changes, was successful because it launched the 
> daemon with
> a specific selector provider whose only action was to notify that it 
> was launched successfully
> (by invoking a method on an object registered in the registry) and was 
> successful if the invoking
> test program received the notification.
>
> That function is now replaced by RMID.createRMIDonEphemeralPort().
> If it succeeds to launch and retrieve the port number, then the 
> InheritedChannel mechanism is fully working.
>
> So I think the test can be removed entirely.
> Make sense?
Agree, I had the same thought. It might be useful to keep it, even if it 
looks like do no more test. It's specifically checking inherited 
channel, and it's can be a sanity test for RMID+RMIDSelectorProvider 
test library.
I can do either way. Please let me know your final thought.

Thank you
-Hamlin

>
> Thanks, Roger
>
> On 11/23/2016 4:49 AM, Hamlin Li wrote:
>> Would you please review the fix for below bug?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8019538
>> webrev: http://cr.openjdk.java.net/~mli/8019538/webrev.00/
>>
>> There are 4 issues in the bug,
>> 2 in RmidViaInheritedChannel.java:  "port in use" in registry, "port 
>> in use" in rmid start.
>> 2 InheritedChannelNotServerSocket.java: "port in use" in registry, 
>> "port in use" in rmid start.
>>
>> This patch fixes 2 issues in RmidViaInheritedChannel, and only "port 
>> in use" in registry in InheritedChannelNotServerSocket.
>> The "port in use" in rmid in InheritedChannelNotServerSocket is 
>> little bit hard, as it intends to test rmid when inherited channel 
>> not work. Currently the only solution in my mind is to retry when 
>> rmid fails with "port in use", but as we discussed earlier, it's not 
>> a good solution as it might impact other programs or tests, and it's 
>> not efficient.
>> So I hope to push the fix for the other issues first to improve the 
>> stability of RMI tests, and keep studying if there are other better 
>> solutions for the "port in use" in rmid in 
>> InheritedChannelNotServerSocket.
>>
>> Thank you
>> -Hamlin
>


From huaming.li at oracle.com  Wed Nov 30 03:02:40 2016
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 30 Nov 2016 11:02:40 +0800
Subject: RFR of JDK-8170338:
	com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java failed
	with "Port already in use"
Message-ID: <7368009d-68fd-dd1e-6b82-a2de29bcd44f@oracle.com>

Would you please review the patch?

bug: https://bugs.openjdk.java.net/browse/JDK-8170338
webrev: http://cr.openjdk.java.net/~mli/8170338/webrev.00/

Thank you
-Hamlin

------------------------------------------------------------------------

diff -r 17b7d5ac2da7 
test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java
--- 
a/test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java 
Wed Nov 30 08:02:39 2016 +0800
+++ 
b/test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java 
Tue Nov 29 18:59:30 2016 -0800
@@ -43,7 +43,7 @@
  public class UnbindIdempotent {

      public static void main(String[] args) throws Exception {
-        Registry registry = TestLibrary.createRegistryOnUnusedPort();
+        Registry registry = TestLibrary.createRegistryOnEphemeralPort();
          int registryPort = TestLibrary.getRegistryPort(registry);
          InitialContext ictx = new InitialContext();
          Context rctx;


From masayoshi.okutsu at oracle.com  Wed Nov 30 04:37:52 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 30 Nov 2016 13:37:52 +0900
Subject:  RFR: 8169191: (tz) Support tzdata2016j
In-Reply-To: 
References: <31739ca3-0ad5-418e-963b-be01ac2ef6c4@default>
	
Message-ID: <852b8995-4c71-7b8f-29a6-d09872a8ba4d@oracle.com>

Sorry, but I was confused with the wrong bug ID in Subject...

Looks good to me.

Masayoshi


On 11/29/2016 4:28 AM, Martin Buchholz wrote:
> Thanks as always for keeping the tzdata pipeline moving!
> Looks good to me.
>
> On Mon, Nov 28, 2016 at 1:24 AM, Ramanand Patil 
> wrote:
>
>> Hi all,
>> Please review the latest TZDATA integration (tzdata2016j) to JDK9.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170316
>> Webrev: http://cr.openjdk.java.net/~rpatil/8170316/webrev.00/
>>
>> All the TimeZone related tests are passed after integration.
>>
>> Regards,
>> Ramanand.
>>


From kumar.x.srinivasan at oracle.com  Wed Nov 30 05:18:42 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 29 Nov 2016 21:18:42 -0800
Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build
In-Reply-To: 
References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap>
	
	<57E28D3D.5040802@oracle.com>
	
	<57EBBF9A.6010103@oracle.com>
	
	
	
	<389F5342-B5FA-4C83-A646-6703C8910416@oracle.com>
	
	<2993770b-b888-0762-cec2-0e7250a9e797@oracle.com>
	
	
Message-ID: <583E6132.7090103@oracle.com>

Hi Volker et. al.,

Was a bug opened to track this ? I still see these files around
http://hg.openjdk.java.net/jdk9/dev/jdk/file/ff45c582ca8a/src/java.base/aix/native/libjli

Would you like me to create a bug for you ?

Thanks
Kumar

On 9/29/2016 9:59 AM, Volker Simonis wrote:
> On Thu, Sep 29, 2016 at 5:25 PM, Erik Joelsson  wrote:
>>
>> On 2016-09-29 16:54, Alan Burlison wrote:
>>> On 29/09/2016 08:03, Volker Simonis wrote:
>>>
>>>> Sorry, but that doesn't sound like a solution to me at all. I think we
>>>> should keep the OpenJDK sources self-contained. I don't want to depend
>>>> on yet another non-standard, third party library which doesn't even
>>>> exist now.
>>>
>>> Unless I'm completely misunderstanding, that's not what is being proposed.
>>> What is being proposed is refactoring code that's currently duplicated
>>> across the JVM & JDK into a common library. Such a library would be a
>>> standard Java component, not non-standard and not third-party. I can't see
>>> what the problem is, to be honest.
>>>
>> Volker's comment above was directed at the suggestion of taking the
>> problematic AIX specific code out of the OpenJDK repositories and create a
>> separate library with a separate lifecycle somewhere else that OpenJDK for
>> AIX would then need to depend on. Volker was instead proposing what you
>> describe.
>>
> Thanks Erik, this is exactly what I meant :)
>
> And I think the solution you ssketched in your previous mail is the
> right way to address this problem.
>
> Regards,
> Volker
>
>
>> /Erik


From ramanand.patil at oracle.com  Wed Nov 30 05:24:49 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Tue, 29 Nov 2016 21:24:49 -0800 (PST)
Subject:  RFR: 8170316: (tz) Support tzdata2016j
Message-ID: 

Hi Masayoshi,

Sorry, that was an error from my side. Thank you for pointing that out and for your review.

[Changed the BugID in Subject now].

Regards,
Ramanand.

-----Original Message-----
From: Masayoshi Okutsu 
Sent: Wednesday, November 30, 2016 10:08 AM
To: Ramanand Patil 
Cc: Martin Buchholz ; core-libs-dev ; i18n-dev at openjdk.java.net
Subject: Re:  RFR: 8169191: (tz) Support tzdata2016j

Sorry, but I was confused with the wrong bug ID in Subject...

Looks good to me.

Masayoshi


On 11/29/2016 4:28 AM, Martin Buchholz wrote:
> Thanks as always for keeping the tzdata pipeline moving!
> Looks good to me.
>
> On Mon, Nov 28, 2016 at 1:24 AM, Ramanand Patil 
> wrote:
>
>> Hi all,
>> Please review the latest TZDATA integration (tzdata2016j) to JDK9.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170316
>> Webrev: http://cr.openjdk.java.net/~rpatil/8170316/webrev.00/
>>
>> All the TimeZone related tests are passed after integration.
>>
>> Regards,
>> Ramanand.
>>


From ramanand.patil at oracle.com  Wed Nov 30 05:24:58 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Tue, 29 Nov 2016 21:24:58 -0800 (PST)
Subject:  RFR: 8170316: (tz) Support tzdata2016j
Message-ID: <1b639ecd-8af9-4693-8b22-dae8750d0980@default>

Thank you Martin.

?

Regards,

Ramanand.

From: Martin Buchholz [mailto:martinrb at google.com] 
Sent: Tuesday, November 29, 2016 12:59 AM
To: Ramanand Patil 
Cc: i18n-dev at openjdk.java.net; core-libs-dev 
Subject: Re:  RFR: 8169191: (tz) Support tzdata2016j

?

Thanks as always for keeping the tzdata pipeline moving!

Looks good to me.

?

On Mon, Nov 28, 2016 at 1:24 AM, Ramanand Patil  wrote:

Hi all,
Please review the latest TZDATA integration (tzdata2016j) to JDK9.
Bug: https://bugs.openjdk.java.net/browse/JDK-8170316
Webrev: http://cr.openjdk.java.net/~rpatil/8170316/webrev.00/

All the TimeZone related tests are passed after integration.

Regards,
Ramanand.

?

From andrej.golovnin at gmail.com  Wed Nov 30 07:38:59 2016
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Wed, 30 Nov 2016 08:38:59 +0100
Subject: RFR: 8035424: (reflect) Performance problem in
	sun.reflect.generics.parser.SignatureParser
In-Reply-To: <13241b6e-c5ff-85d7-e312-c2aba940ee5e@gmail.com>
References: <90b347de-fd85-03c7-51eb-44fedf6f5645@oracle.com>
	
	<972410b1-21e6-8da2-6750-a2f0d8eabcec@oracle.com>
	<7c343eb3-a8ba-fbfc-9630-c2f0d6f096db@gmail.com>
	<583DBC36.8040606@oracle.com>
	<068104fd-643b-539a-c0d0-20c2b1099153@gmail.com>
	<583DFA00.4030108@oracle.com>
	<7aae60a7-3e4c-c000-6acc-cfdcb1b59f66@gmail.com>
	<13241b6e-c5ff-85d7-e312-c2aba940ee5e@gmail.com>
Message-ID: 

Hi Peter,

I know it is matter of taste, but don't you think this:

 269         for (char c = current();
 270                c != ';' && c != '.' && c != '/' && c != '[' &&
 271                c != ':' && c != '>' && c != '<' &&
 272                !Character.isWhitespace(c);
 273              c = current())
 274         {

is easier to read than the long or-condition which is then negated?

Best regards,
Andrej Golovnin

On Tue, Nov 29, 2016 at 11:41 PM, Peter Levart  wrote:
> Hi Claes,
>
> On 11/29/2016 11:30 PM, Peter Levart wrote:
>>
>>
>>
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8035424_SignatureParser.performance/webrev.02/
>>
>
> Which loop do you prefer. The above one or the following?
>
>     private void skipIdentifier() {
>         char c;
>         while (!((c = current()) == ';' || c == '.' || c == '/' ||
>                  c == '[' || c == ':' || c == '>' || c == '<' ||
>                  Character.isWhitespace(c))) {
>             advance();
>         }
>     }
>
>
> Peter
>

From masayoshi.okutsu at oracle.com  Wed Nov 30 09:39:04 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 30 Nov 2016 18:39:04 +0900
Subject: RFR: JDK-8075577: java.time does not support HOST provider
In-Reply-To: 
References: 
Message-ID: <59be845e-7afa-45c7-a7b1-6fe6e01c4edc@oracle.com>

Looks good to me.

Masayoshi


On 11/22/2016 6:30 PM, Rachna Goel wrote:
> Hi,
>
> Please review fix for JDK-8075577.
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8075577
>
> webrev : http://cr.openjdk.java.net/~rgoel/JDK-8075577/webrev.01/
>
> Fix is to introduce new private spi 
> "sun.text.spi.JavaTimeDateTimePatternProvider.java"  to retrieve 
> LocaleProvider specific Date/Time Patterns for "java.time" .
>
> Thanks,
> Rachna
>
>
>


From chris.hegarty at oracle.com  Wed Nov 30 10:41:22 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 30 Nov 2016 10:41:22 +0000
Subject: RFR of JDK-8170338:
	com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java failed
	with "Port already in use"
In-Reply-To: <7368009d-68fd-dd1e-6b82-a2de29bcd44f@oracle.com>
References: <7368009d-68fd-dd1e-6b82-a2de29bcd44f@oracle.com>
Message-ID: 



On 30/11/16 03:02, Hamlin Li wrote:
> Would you please review the patch?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8170338
> webrev: http://cr.openjdk.java.net/~mli/8170338/webrev.00/

Reviewed. Thanks Hamlin.

-Chris.


> Thank you
> -Hamlin
>
> ------------------------------------------------------------------------
>
> diff -r 17b7d5ac2da7
> test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java
> ---
> a/test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java
> Wed Nov 30 08:02:39 2016 +0800
> +++
> b/test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java
> Tue Nov 29 18:59:30 2016 -0800
> @@ -43,7 +43,7 @@
>  public class UnbindIdempotent {
>
>      public static void main(String[] args) throws Exception {
> -        Registry registry = TestLibrary.createRegistryOnUnusedPort();
> +        Registry registry = TestLibrary.createRegistryOnEphemeralPort();
>          int registryPort = TestLibrary.getRegistryPort(registry);
>          InitialContext ictx = new InitialContext();
>          Context rctx;
>

From peter.levart at gmail.com  Wed Nov 30 11:36:01 2016
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 30 Nov 2016 12:36:01 +0100
Subject: RFR: 8035424: (reflect) Performance problem in
	sun.reflect.generics.parser.SignatureParser
In-Reply-To: <583E0706.10403@oracle.com>
References: <90b347de-fd85-03c7-51eb-44fedf6f5645@oracle.com>
	
	<972410b1-21e6-8da2-6750-a2f0d8eabcec@oracle.com>
	<7c343eb3-a8ba-fbfc-9630-c2f0d6f096db@gmail.com>
	<583DBC36.8040606@oracle.com>
	<068104fd-643b-539a-c0d0-20c2b1099153@gmail.com>
	<583DFA00.4030108@oracle.com>
	<7aae60a7-3e4c-c000-6acc-cfdcb1b59f66@gmail.com>
	<583E0706.10403@oracle.com>
Message-ID: 

Hi Claes, Andrej,

On 11/29/2016 11:53 PM, Claes Redestad wrote:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8035424_SignatureParser.performance/webrev.02/
>>
>>
>> What do you think of this one?
>
> Fair point. I think this is easier to follow and should do the trick 
> just as nicely.
>
> What you have here is fine, but in this day and age of compact strings 
> I wonder if return mar.replace('/', '.') might have both a readability 
> and a slight performance edge (assuming signatures are almost always 
> ASCII).

Good idea. It simplifies code and improves performance.


On 11/30/2016 08:38 AM, Andrej Golovnin wrote:
> Hi Peter,
>
> I know it is matter of taste, but don't you think this:
>
>   269         for (char c = current();
>   270                c != ';' && c != '.' && c != '/' && c != '[' &&
>   271                c != ':' && c != '>' && c != '<' &&
>   272                !Character.isWhitespace(c);
>   273              c = current())
>   274         {
>
> is easier to read than the long or-condition which is then negated?

Indeed it is. Another good idea, thanks.

Here's a webrev incorporating both suggestions. All 73 java/jang/reflect 
jtreg tests are passing...

http://cr.openjdk.java.net/~plevart/jdk9-dev/8035424_SignatureParser.performance/webrev.03/


Regards, Peter


From claes.redestad at oracle.com  Wed Nov 30 11:41:35 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 30 Nov 2016 12:41:35 +0100
Subject: RFR: 8035424: (reflect) Performance problem in
	sun.reflect.generics.parser.SignatureParser
In-Reply-To: 
References: <90b347de-fd85-03c7-51eb-44fedf6f5645@oracle.com>
	
	<972410b1-21e6-8da2-6750-a2f0d8eabcec@oracle.com>
	<7c343eb3-a8ba-fbfc-9630-c2f0d6f096db@gmail.com>
	<583DBC36.8040606@oracle.com>
	<068104fd-643b-539a-c0d0-20c2b1099153@gmail.com>
	<583DFA00.4030108@oracle.com>
	<7aae60a7-3e4c-c000-6acc-cfdcb1b59f66@gmail.com>
	<583E0706.10403@oracle.com>
	
Message-ID: <5f8c12e3-f27c-849b-86e7-d9e0dfb7a556@oracle.com>

+1

Found a reference to getNext in a comment that should be removed, no 
re-review required.

/Claes

On 2016-11-30 12:36, Peter Levart wrote:
> Here's a webrev incorporating both suggestions. All 73 
> java/jang/reflect jtreg tests are passing...
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/8035424_SignatureParser.performance/webrev.03/
>
>
> Regards, Peter


From mkanat at google.com  Wed Nov 30 12:44:55 2016
From: mkanat at google.com (Max Kanat-Alexander)
Date: Wed, 30 Nov 2016 07:44:55 -0500
Subject: RFR: 8035424: (reflect) Performance problem in
	sun.reflect.generics.parser.SignatureParser
In-Reply-To: <5f8c12e3-f27c-849b-86e7-d9e0dfb7a556@oracle.com>
References: <90b347de-fd85-03c7-51eb-44fedf6f5645@oracle.com>
	
	<972410b1-21e6-8da2-6750-a2f0d8eabcec@oracle.com>
	<7c343eb3-a8ba-fbfc-9630-c2f0d6f096db@gmail.com>
	<583DBC36.8040606@oracle.com>
	<068104fd-643b-539a-c0d0-20c2b1099153@gmail.com>
	<583DFA00.4030108@oracle.com>
	<7aae60a7-3e4c-c000-6acc-cfdcb1b59f66@gmail.com>
	<583E0706.10403@oracle.com>
	
	<5f8c12e3-f27c-849b-86e7-d9e0dfb7a556@oracle.com>
Message-ID: 

For what it's worth, this looks good to me too. :-)

The name "mark" is a bit confusing, as are all the methods with the word
"mark" in it; I have to think for a moment about what each of them do.
Perhaps identifierStart would be better or something, along with
setIdentifierStart()? Also, "skipIdentifier" is a bit confusing, perhaps
that means advanceToNextIdentifier?

On Wed, Nov 30, 2016 at 6:41 AM, Claes Redestad 
wrote:

> +1
>
> Found a reference to getNext in a comment that should be removed, no
> re-review required.
>
> /Claes
>
>
> On 2016-11-30 12:36, Peter Levart wrote:
>
>> Here's a webrev incorporating both suggestions. All 73 java/jang/reflect
>> jtreg tests are passing...
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8035424_Signatu
>> reParser.performance/webrev.03/
>>
>>
>> Regards, Peter
>>
>
>

From volker.simonis at gmail.com  Wed Nov 30 15:21:41 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 30 Nov 2016 16:21:41 +0100
Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build
In-Reply-To: <583E6132.7090103@oracle.com>
References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap>
	
	<57E28D3D.5040802@oracle.com>
	
	<57EBBF9A.6010103@oracle.com>
	
	
	
	<389F5342-B5FA-4C83-A646-6703C8910416@oracle.com>
	
	<2993770b-b888-0762-cec2-0e7250a9e797@oracle.com>
	
	
	<583E6132.7090103@oracle.com>
Message-ID: 

On Wed, Nov 30, 2016 at 6:18 AM, Kumar Srinivasan
 wrote:
> Hi Volker et. al.,
>
> Was a bug opened to track this ? I still see these files around
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/ff45c582ca8a/src/java.base/aix/native/libjli
>

Hi Kumar,

no, as far as I know there's no bug for this issue until now.
The current situation is not ideal, but it works and it doesn't impact
any other platform except AIX.
So there's no reason for us to address this with high priority and
surely not within the jdk9 time frame.

I think ideally, this could be addressed the next time we see a
similar problem, otherwise it is probably always too much at the
bottom of the priority list :)

Thank you and best regards,
Volker

> Would you like me to create a bug for you ?
>
> Thanks
> Kumar
>
>
> On 9/29/2016 9:59 AM, Volker Simonis wrote:
>>
>> On Thu, Sep 29, 2016 at 5:25 PM, Erik Joelsson 
>> wrote:
>>>
>>>
>>> On 2016-09-29 16:54, Alan Burlison wrote:
>>>>
>>>> On 29/09/2016 08:03, Volker Simonis wrote:
>>>>
>>>>> Sorry, but that doesn't sound like a solution to me at all. I think we
>>>>> should keep the OpenJDK sources self-contained. I don't want to depend
>>>>> on yet another non-standard, third party library which doesn't even
>>>>> exist now.
>>>>
>>>>
>>>> Unless I'm completely misunderstanding, that's not what is being
>>>> proposed.
>>>> What is being proposed is refactoring code that's currently duplicated
>>>> across the JVM & JDK into a common library. Such a library would be a
>>>> standard Java component, not non-standard and not third-party. I can't
>>>> see
>>>> what the problem is, to be honest.
>>>>
>>> Volker's comment above was directed at the suggestion of taking the
>>> problematic AIX specific code out of the OpenJDK repositories and create
>>> a
>>> separate library with a separate lifecycle somewhere else that OpenJDK
>>> for
>>> AIX would then need to depend on. Volker was instead proposing what you
>>> describe.
>>>
>> Thanks Erik, this is exactly what I meant :)
>>
>> And I think the solution you ssketched in your previous mail is the
>> right way to address this problem.
>>
>> Regards,
>> Volker
>>
>>
>>> /Erik
>
>

From peter.levart at gmail.com  Wed Nov 30 15:31:47 2016
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 30 Nov 2016 16:31:47 +0100
Subject: RFR: 8035424: (reflect) Performance problem in
	sun.reflect.generics.parser.SignatureParser
In-Reply-To: 
References: <90b347de-fd85-03c7-51eb-44fedf6f5645@oracle.com>
	
	<972410b1-21e6-8da2-6750-a2f0d8eabcec@oracle.com>
	<7c343eb3-a8ba-fbfc-9630-c2f0d6f096db@gmail.com>
	<583DBC36.8040606@oracle.com>
	<068104fd-643b-539a-c0d0-20c2b1099153@gmail.com>
	<583DFA00.4030108@oracle.com>
	<7aae60a7-3e4c-c000-6acc-cfdcb1b59f66@gmail.com>
	<583E0706.10403@oracle.com>
	
	<5f8c12e3-f27c-849b-86e7-d9e0dfb7a556@oracle.com>
	
Message-ID: 

Hi Max,

On 11/30/2016 01:44 PM, Max Kanat-Alexander wrote:
> For what it's worth, this looks good to me too. :-)
>
> The name "mark" is a bit confusing, as are all the methods with the 
> word "mark" in it; I have to think for a moment about what each of 
> them do. Perhaps identifierStart would be better or something, along 
> with setIdentifierStart()?

I borrowed the name from java.io.InputStream::mark() which likewise 
"remembers" current read position of the stream. The InputStream uses 
the remembered position so it can reset() current position to it, while 
the parser uses the remembered position so it can return the subsequence 
of input from markToCurrent().

> Also, "skipIdentifier" is a bit confusing, perhaps that means 
> advanceToNextIdentifier?

The semantics of the method is to parse the following input as an 
identifier, but not give anything back as a result besides moving 
current position past the parsed identifier (hence the prefix "skip").  
After this method returns, the parser is typically not positioned at the 
start of next identifier, but at some delimiter, so 
"advanceToNextIdentifier" would mean something completely different. I 
think the name is right for what it means.

Regards, Peter

>
> On Wed, Nov 30, 2016 at 6:41 AM, Claes Redestad 
> > wrote:
>
>     +1
>
>     Found a reference to getNext in a comment that should be removed,
>     no re-review required.
>
>     /Claes
>
>
>     On 2016-11-30 12:36, Peter Levart wrote:
>
>         Here's a webrev incorporating both suggestions. All 73
>         java/jang/reflect jtreg tests are passing...
>
>         http://cr.openjdk.java.net/~plevart/jdk9-dev/8035424_SignatureParser.performance/webrev.03/
>         
>
>
>         Regards, Peter
>
>
>


From Alan.Bateman at oracle.com  Wed Nov 30 15:42:27 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 30 Nov 2016 15:42:27 +0000
Subject: 8170539: Test clashes with another test with a similar name
Message-ID: <910cc723-e59b-879a-f112-103474aef3e4@oracle.com>

I need a reviewer to blow away a file in jdk9/dev/jdk:

hg rm 
test/java/awt/Focus/DisposedWindow/DisposeDialogNotActivateOwnerTest/DisposeDialogNotActivateOwnerTest.html

This is a dup of JDK-8169840 [1] but that change was pushed to 
jdk9/client rather than jdk9/dev, leaving jdk9/dev hosed. I can't hg 
import && hg import without causing problems for the next client -> dev 
integration so this is the reason for the next bug number and a new 
changeset.

-Alan

[1] http://hg.openjdk.java.net/jdk9/client/jdk/rev/983d90dfdadf


From Roger.Riggs at Oracle.com  Wed Nov 30 15:45:59 2016
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 30 Nov 2016 10:45:59 -0500
Subject: 8170539: Test clashes with another test with a similar name
In-Reply-To: <910cc723-e59b-879a-f112-103474aef3e4@oracle.com>
References: <910cc723-e59b-879a-f112-103474aef3e4@oracle.com>
Message-ID: <82c8ed0c-836a-59ca-bc83-acbde123731f@Oracle.com>

+++1

Thanks, Roger

On 11/30/2016 10:42 AM, Alan Bateman wrote:
> I need a reviewer to blow away a file in jdk9/dev/jdk:
>
> hg rm 
> test/java/awt/Focus/DisposedWindow/DisposeDialogNotActivateOwnerTest/DisposeDialogNotActivateOwnerTest.html
>
> This is a dup of JDK-8169840 [1] but that change was pushed to 
> jdk9/client rather than jdk9/dev, leaving jdk9/dev hosed. I can't hg 
> import && hg import without causing problems for the next client -> 
> dev integration so this is the reason for the next bug number and a 
> new changeset.
>
> -Alan
>
> [1] http://hg.openjdk.java.net/jdk9/client/jdk/rev/983d90dfdadf
>


From chris.hegarty at oracle.com  Wed Nov 30 15:48:47 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 30 Nov 2016 15:48:47 +0000
Subject: 8170539: Test clashes with another test with a similar name
In-Reply-To: <910cc723-e59b-879a-f112-103474aef3e4@oracle.com>
References: <910cc723-e59b-879a-f112-103474aef3e4@oracle.com>
Message-ID: <41710561-8398-d502-4230-8074f3ec4d17@oracle.com>


On 30/11/16 15:42, Alan Bateman wrote:
> I need a reviewer to blow away a file in jdk9/dev/jdk:
>
> hg rm
> test/java/awt/Focus/DisposedWindow/DisposeDialogNotActivateOwnerTest/DisposeDialogNotActivateOwnerTest.html
>
>
> This is a dup of JDK-8169840 [1] but that change was pushed to
> jdk9/client rather than jdk9/dev, leaving jdk9/dev hosed. I can't hg
> import && hg import without causing problems for the next client -> dev
> integration so this is the reason for the next bug number and a new
> changeset.
>

This seems reasonable to me. When 8169840 comes into jdk9/dev it
should merge in seamlessly.

-Chris.

> -Alan
>
> [1] http://hg.openjdk.java.net/jdk9/client/jdk/rev/983d90dfdadf
>

From Roger.Riggs at Oracle.com  Wed Nov 30 16:47:09 2016
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 30 Nov 2016 11:47:09 -0500
Subject: RFR: JDK-8075577: java.time does not support HOST provider
In-Reply-To: <59be845e-7afa-45c7-a7b1-6fe6e01c4edc@oracle.com>
References: 
	<59be845e-7afa-45c7-a7b1-6fe6e01c4edc@oracle.com>
Message-ID: <2ee441e3-eda4-fd36-171c-8ebdf1d6c65c@Oracle.com>

Hi Rachna,

macosx//HostLocaleProviderAdapterImpl.java:

  - line 172-177,  might be a good place to use the new 
ConcurrentMap.computeIfAbsent

  - line 197: you could pre-size the StringBuilder since the target 
length can be estimated
    (unless they are all less than the default 16)

macosx && windows//HostLocaleProviderAdapterImpl.java
  -  toJavaTimeDateTimePattern()  - is there a way to avoid having two 
copies of this function?
     Perhaps as a static method in JavaTimeDateTimePatternImpl.java.

The noreg-hard label on issue indicates testing is difficult and 
specific to OS and host
configuration but it also seems unusual to have this much code and not 
have a regression test.

If Masayoshi is satisfied and you have tested it in the target 
configuration then
perhaps it is not worthwhile to invest in a special case regression test.

Thanks, Roger

On 11/30/2016 4:39 AM, Masayoshi Okutsu wrote:
> Looks good to me.
>
> Masayoshi
>
>
> On 11/22/2016 6:30 PM, Rachna Goel wrote:
>> Hi,
>>
>> Please review fix for JDK-8075577.
>>
>> Bug : https://bugs.openjdk.java.net/browse/JDK-8075577
>>
>> webrev : http://cr.openjdk.java.net/~rgoel/JDK-8075577/webrev.01/
>>
>> Fix is to introduce new private spi 
>> "sun.text.spi.JavaTimeDateTimePatternProvider.java"  to retrieve 
>> LocaleProvider specific Date/Time Patterns for "java.time" .
>>
>> Thanks,
>> Rachna
>>
>>
>>
>


From martinrb at google.com  Wed Nov 30 16:53:12 2016
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 30 Nov 2016 08:53:12 -0800
Subject: 8170539: Test clashes with another test with a similar name
In-Reply-To: <910cc723-e59b-879a-f112-103474aef3e4@oracle.com>
References: <910cc723-e59b-879a-f112-103474aef3e4@oracle.com>
Message-ID: 

This was blocking me too, but jjg pointed out -noreport on the other
thread, and now I use that unconditionally with jtreg,
and DisposeDialogNotActivateOwnerTest doesn't bother me any more.

Also, in a case like this where a forest is broken with a fix available,
shouldn't there be an emergency client -> dev integration?

On Wed, Nov 30, 2016 at 7:42 AM, Alan Bateman 
wrote:

> I need a reviewer to blow away a file in jdk9/dev/jdk:
>
> hg rm test/java/awt/Focus/DisposedWindow/DisposeDialogNotActivateO
> wnerTest/DisposeDialogNotActivateOwnerTest.html
>
> This is a dup of JDK-8169840 [1] but that change was pushed to jdk9/client
> rather than jdk9/dev, leaving jdk9/dev hosed. I can't hg import && hg
> import without causing problems for the next client -> dev integration so
> this is the reason for the next bug number and a new changeset.
>
> -Alan
>
> [1] http://hg.openjdk.java.net/jdk9/client/jdk/rev/983d90dfdadf
>
>

From Alan.Bateman at oracle.com  Wed Nov 30 16:58:58 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 30 Nov 2016 16:58:58 +0000
Subject: 8170539: Test clashes with another test with a similar name
In-Reply-To: 
References: <910cc723-e59b-879a-f112-103474aef3e4@oracle.com>
	
Message-ID: <6ff86ff7-266c-486e-0118-ad6095fc395c@oracle.com>

On 30/11/2016 16:53, Martin Buchholz wrote:

> :
>
> Also, in a case like this where a forest is broken with a fix 
> available, shouldn't there be an emergency client -> dev integration?
>
The jdk9/client -> jdk9/dev integration involve PIT so not doable in 
minutes.

In any case,  I'm surprised that the issue didn't block the original 
jdk9/client -> jdk9/dev integration. Also when the issue was discovered 
then the fix should have been pushed to jdk9/dev and pulled down to 
jdk9/client.

-Alan

From Roger.Riggs at Oracle.com  Wed Nov 30 19:01:33 2016
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 30 Nov 2016 14:01:33 -0500
Subject: Request for Review and Sponsor needed: JDK-8167648:
	java.io.PrintWriter should have PrintWriter((String|File), Charset)
	constructors
In-Reply-To: <6D1ED283-28C4-4787-B33E-9EF5B8AB9F50@reini.net>
References: <6D1ED283-28C4-4787-B33E-9EF5B8AB9F50@reini.net>
Message-ID: <7983a3c2-5943-d32a-b0e8-755958700ba8@Oracle.com>

Hi Patrick,

I have reservations about trying to get this into JDK 9.  Because it is 
a new API,
it should have some bake time before feature freeze and it needs further 
review
from the compatibility point of view and resources committed to create 
new JCK tests.
Many folks are fully loaded also trying to hit feature freeze.

A few comments on the webrev:

  - 359: The withAutoFlush javadoc should be more explicit about when a 
new vs the same
    PrintWriter is returned.  The 'activates' verb doesn't convey any 
sense about the instance that is returned.

- 375:  Can this use the new private constructor that will handle psOut.

  -320, etc. The @since should be 1 or 2 digits to match the version scheme

  - no tests for new PrintWriter(OutputStream , Charset)

  - From the test file name 'FailngConstructors", its not clear that's 
the right place
    for the positive tests of the withAutoFlush methods.

That's all I have time for at the moment,

Regards, Roger


On 11/29/2016 4:15 PM, Patrick Reinhart wrote:
> Does anyone sponsor this fix?
>
> http://cr.openjdk.java.net/~reinhapa/reviews/8167648/webrev.00
>
> -Patrick


From Roger.Riggs at Oracle.com  Wed Nov 30 19:08:38 2016
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 30 Nov 2016 14:08:38 -0500
Subject: RFR of JDK-8019538: TEST_BUG:
	java/rmi/activation/rmidViaInheritedChannel tests may fail
In-Reply-To: <453b4744-6e6c-733f-281a-508b9bf03295@oracle.com>
References: <73753d7c-9d58-8632-da37-10e12e13e400@oracle.com>
	<9658e687-9e58-be70-cc58-6bf6dc3ea76c@Oracle.com>
	<453b4744-6e6c-733f-281a-508b9bf03295@oracle.com>
Message-ID: <327ba64a-1e9f-8965-4a19-b0ad0fb643ff@Oracle.com>

Hi Hamlin,

I would just remove it.

Stuart?  Chris?

Roger

p.s. If you think there might be a reason to resurrect it later, attach 
the current webrev to the issue
before updating it to remove.




On 11/29/2016 9:25 PM, Hamlin Li wrote:
> Hi Roger,
>
> Thank you for reviewing. please check the comments in line.
>
>
> On 2016/11/30 0:50, Roger Riggs wrote:
>> Hi Hamlin,
>>
>> The changes proposed are fine as far as they go, but...
>>
>> I think this test can be completely removed.
>> The recent change to use inherited channel for many  of the rmid 
>> tests makes this test redundant.
>> It does not add anything over other activation/RMID tests.
>>
>> The test before the changes, was successful because it launched the 
>> daemon with
>> a specific selector provider whose only action was to notify that it 
>> was launched successfully
>> (by invoking a method on an object registered in the registry) and 
>> was successful if the invoking
>> test program received the notification.
>>
>> That function is now replaced by RMID.createRMIDonEphemeralPort().
>> If it succeeds to launch and retrieve the port number, then the 
>> InheritedChannel mechanism is fully working.
>>
>> So I think the test can be removed entirely.
>> Make sense?
> Agree, I had the same thought. It might be useful to keep it, even if 
> it looks like do no more test. It's specifically checking inherited 
> channel, and it's can be a sanity test for RMID+RMIDSelectorProvider 
> test library.
> I can do either way. Please let me know your final thought.
>
> Thank you
> -Hamlin
>
>>
>> Thanks, Roger
>>
>> On 11/23/2016 4:49 AM, Hamlin Li wrote:
>>> Would you please review the fix for below bug?
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8019538
>>> webrev: http://cr.openjdk.java.net/~mli/8019538/webrev.00/
>>>
>>> There are 4 issues in the bug,
>>> 2 in RmidViaInheritedChannel.java:  "port in use" in registry, "port 
>>> in use" in rmid start.
>>> 2 InheritedChannelNotServerSocket.java: "port in use" in registry, 
>>> "port in use" in rmid start.
>>>
>>> This patch fixes 2 issues in RmidViaInheritedChannel, and only "port 
>>> in use" in registry in InheritedChannelNotServerSocket.
>>> The "port in use" in rmid in InheritedChannelNotServerSocket is 
>>> little bit hard, as it intends to test rmid when inherited channel 
>>> not work. Currently the only solution in my mind is to retry when 
>>> rmid fails with "port in use", but as we discussed earlier, it's not 
>>> a good solution as it might impact other programs or tests, and it's 
>>> not efficient.
>>> So I hope to push the fix for the other issues first to improve the 
>>> stability of RMI tests, and keep studying if there are other better 
>>> solutions for the "port in use" in rmid in 
>>> InheritedChannelNotServerSocket.
>>>
>>> Thank you
>>> -Hamlin
>>
>


From Roger.Riggs at Oracle.com  Wed Nov 30 19:49:06 2016
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 30 Nov 2016 14:49:06 -0500
Subject: RFR of JDK-8049316: TEST_BUG:
	java/nio/channels/Selector/Wakeup.java fails in same binary run b19
In-Reply-To: 
References: <55b7c230-6f1a-57fd-847b-6ee79728f67c@oracle.com>
	<0d58f7a4-aec3-5190-2240-ef75d9733944@Oracle.com>
	
Message-ID: 

Hi Hamlin,


On 11/29/2016 9:09 PM, Hamlin Li wrote:
> Hi Roger,
>
> Thank you for reviewing, please check comments in line.
>
> webrev: http://cr.openjdk.java.net/~mli/8049316/webrev.01/
>
>
> On 2016/11/30 0:03, Roger Riggs wrote:
>> Hi Hamlin,
>>
>> Wakeup.java:
>>
>>  - Some refactoring may make it easier to understand.
>>    Perhaps moving waitSleeper to be a method on Sleeper.
>>    The use of cyclicBarrier seems fine but could use a comment 
>> somewhere saying what
>> threads/functions are being coordinated; putting them both in Sleeper 
>> would make it easier to see.
>>
>> - line 126,127:  Add a Sleeper constructor to initialize these as 
>> needed.
>>
>> - Some of the test stimulus is buried in the newSleeper methods that 
>> was previously
>>   in line in main.  It seemed clearer what case was being tested in 
>> the original.
>>   They are buried in static factory 'newSleeper' functions with 
>> uninformative names.
>>    lines 112, 116, 120.
> All above fixed.
I was thinking that the createSleeper(sel, want, before) method forced 
two cases together that
didn't need to be in the same method and could be separated in the 
newSleeperWantInterrupt and
newSleeperWithInterruptBeforeSelect factory methods.


line 104: the timeout value should be scaled by 
jdk/testlibrary/Utils.adjustTimeout (test.timeout.factor).

>>
>>  - If I read it right, some cases where events don't happen that used 
>> to be reported as exceptions
>>    ("Interrupt never delivered") will now be reported as the test 
>> timing out.  (infinite loop at line 85).
> No, it will finally checked by a time sleeper.finish(0). At first, I 
> don't want to depends on a specific time, because I don't know what 
> exact timeout we should use, but as you asked, I think it's ok to 
> finish(20_000), it should be long enough.

Otherwise is fine.

Thanks, Roger

>
> Thank you
> -Hamlin
>>
>> Thanks, Roger
>>
>> On 11/29/2016 4:23 AM, Hamlin Li wrote:
>>> Would you please review the below patch?
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8049316
>>> webrev: http://cr.openjdk.java.net/~mli/8049316/webrev.00/
>>>
>>> Root cause:
>>> 1. it depends on sleeping time to check failure, which is not 
>>> reliable in some extreme situation
>>> 2. it mix several tests together with a loop in Sleeper
>>>
>>> Solution:
>>> 1. synchronize between threads.
>>> 2. isolate tests.
>>>
>>> Thank you
>>> Hamlin
>>
>


From chris.hegarty at oracle.com  Wed Nov 30 20:48:23 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 30 Nov 2016 20:48:23 +0000
Subject: RFR of JDK-8019538: TEST_BUG:
	java/rmi/activation/rmidViaInheritedChannel tests may fail
In-Reply-To: <327ba64a-1e9f-8965-4a19-b0ad0fb643ff@Oracle.com>
References: <73753d7c-9d58-8632-da37-10e12e13e400@oracle.com>
	<9658e687-9e58-be70-cc58-6bf6dc3ea76c@Oracle.com>
	<453b4744-6e6c-733f-281a-508b9bf03295@oracle.com>
	<327ba64a-1e9f-8965-4a19-b0ad0fb643ff@Oracle.com>
Message-ID: <48868038-F478-4CC4-B74B-B40DE7803242@oracle.com>


> On 30 Nov 2016, at 19:08, Roger Riggs  wrote:
> 
> Hi Hamlin,
> 
> I would just remove it.

Removal is fine with me. This area is now well tested.

-Chris.

> Stuart?  Chris? 
> 
> Roger
> 
> p.s. If you think there might be a reason to resurrect it later, attach the current webrev to the issue
> before updating it to remove.
> 
> 
> 
> 
> On 11/29/2016 9:25 PM, Hamlin Li wrote:
>> Hi Roger, 
>> 
>> Thank you for reviewing. please check the comments in line. 
>> 
>> 
>> On 2016/11/30 0:50, Roger Riggs wrote: 
>>> Hi Hamlin, 
>>> 
>>> The changes proposed are fine as far as they go, but... 
>>> 
>>> I think this test can be completely removed. 
>>> The recent change to use inherited channel for many  of the rmid tests makes this test redundant. 
>>> It does not add anything over other activation/RMID tests. 
>>> 
>>> The test before the changes, was successful because it launched the daemon with 
>>> a specific selector provider whose only action was to notify that it was launched successfully 
>>> (by invoking a method on an object registered in the registry) and was successful if the invoking 
>>> test program received the notification. 
>>> 
>>> That function is now replaced by RMID.createRMIDonEphemeralPort(). 
>>> If it succeeds to launch and retrieve the port number, then the InheritedChannel mechanism is fully working. 
>>> 
>>> So I think the test can be removed entirely. 
>>> Make sense? 
>> Agree, I had the same thought. It might be useful to keep it, even if it looks like do no more test. It's specifically checking inherited channel, and it's can be a sanity test for RMID+RMIDSelectorProvider test library. 
>> I can do either way. Please let me know your final thought. 
>> 
>> Thank you 
>> -Hamlin 
>> 
>>> 
>>> Thanks, Roger 
>>> 
>>> On 11/23/2016 4:49 AM, Hamlin Li wrote: 
>>>> Would you please review the fix for below bug? 
>>>> 
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8019538  
>>>> webrev: http://cr.openjdk.java.net/~mli/8019538/webrev.00/  
>>>> 
>>>> There are 4 issues in the bug, 
>>>> 2 in RmidViaInheritedChannel.java:  "port in use" in registry, "port in use" in rmid start. 
>>>> 2 InheritedChannelNotServerSocket.java: "port in use" in registry, "port in use" in rmid start. 
>>>> 
>>>> This patch fixes 2 issues in RmidViaInheritedChannel, and only "port in use" in registry in InheritedChannelNotServerSocket. 
>>>> The "port in use" in rmid in InheritedChannelNotServerSocket is little bit hard, as it intends to test rmid when inherited channel not work. Currently the only solution in my mind is to retry when rmid fails with "port in use", but as we discussed earlier, it's not a good solution as it might impact other programs or tests, and it's not efficient. 
>>>> So I hope to push the fix for the other issues first to improve the stability of RMI tests, and keep studying if there are other better solutions for the "port in use" in rmid in InheritedChannelNotServerSocket. 
>>>> 
>>>> Thank you 
>>>> -Hamlin 
>>> 
>> 
> 


From huizhe.wang at oracle.com  Wed Nov 30 21:21:20 2016
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 30 Nov 2016 13:21:20 -0800
Subject: RFR (JAXP) 8167340: XMLStreamReader.getElementText return corrupt
	content when size of element is > 8192
Message-ID: <583F42D0.2000703@oracle.com>

Hi,

Please review an one-line fix and a bunch of cleanups.

The reported issue was caused by a missed setting when the 
XMLStreamReader initializes the XML 1.1 scanner, so while the changeset 
involved 350 lines, the fix is really just the following:

XMLStreamReaderImpl.java:
@@ -605,11 +604,12 @@
...
+        fEntityScanner.registerListener(fScanner);


All other changes are cleanups, warnings. And BTW, warnings in the jaxp 
repo have come down from 5230 in 2015 to 3265, a result of a bit of 
cleanups here and there when we touch those classes. Still a long way to 
go, and it shows we may need to have a few dedicated patches.

JBS: https://bugs.openjdk.java.net/browse/JDK-8167340
webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8167340/webrev/

Thanks,
Joe

From patrick at reini.net  Wed Nov 30 21:47:23 2016
From: patrick at reini.net (Patrick Reinhart)
Date: Wed, 30 Nov 2016 22:47:23 +0100
Subject: Request for Review and Sponsor needed: JDK-8167648:
	java.io.PrintWriter should have PrintWriter((String|File), Charset)
	constructors
In-Reply-To: <7983a3c2-5943-d32a-b0e8-755958700ba8@Oracle.com>
References: <6D1ED283-28C4-4787-B33E-9EF5B8AB9F50@reini.net>
	<7983a3c2-5943-d32a-b0e8-755958700ba8@Oracle.com>
Message-ID: <11EFA41B-9978-4CC6-B941-1EE6B4F313E6@reini.net>

Hi Roger,

> Am 30.11.2016 um 20:01 schrieb Roger Riggs :
> 
> Hi Patrick,
> 
> I have reservations about trying to get this into JDK 9.  Because it is a new API,
> it should have some bake time before feature freeze and it needs further review
> from the compatibility point of view and resources committed to create new JCK tests.
> Many folks are fully loaded also trying to hit feature freeze.

I did not expect that the first iteration is good enough. I took this issue, because it was 
marked for target 9. So I?m open for other views.

> A few comments on the webrev:
> 
> - 359: The withAutoFlush javadoc should be more explicit about when a new vs the same
>   PrintWriter is returned.  The ?activates? verb doesn't convey any sense about the instance that is returned.

 359      * Activates {@code printf}, or {@code format} methods to automatically 
 360      * flush the output buffer after writing their data.

Would the following be better:

Returns the same instance if {@code autoFlush} does not change the 
actual setting, otherwise a new instance with changed behavior is returned


> - 375:  Can this use the new private constructor that will handle psOut.

Here I can not get hold on the encoding at this point or have I missed something here?


> -320, etc. The @since should be 1 or 2 digits to match the version scheme

It seems, that I?m still not in the new version scheme ;-) - should be 9 - I will change that, the same for 343

> - no tests for new PrintWriter(OutputStream , Charset)

I will also add that

> - From the test file name 'FailngConstructors", its not clear that's the right place
>   for the positive tests of the withAutoFlush methods.

I will move that out to a new Test as soon we are more clear about the other points

> That's all I have time for at the moment,
> 
> Regards, Roger
> 
> 
> On 11/29/2016 4:15 PM, Patrick Reinhart wrote:
>> Does anyone sponsor this fix?
>> 
>> http://cr.openjdk.java.net/~reinhapa/reviews/8167648/webrev.00
>> 
>> -Patrick
> 


From paul.sandoz at oracle.com  Wed Nov 30 23:20:37 2016
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 30 Nov 2016 15:20:37 -0800
Subject: Request for Review and Sponsor needed: JDK-8167648:
	java.io.PrintWriter should have PrintWriter((String|File),
	Charset) constructors
In-Reply-To: <11EFA41B-9978-4CC6-B941-1EE6B4F313E6@reini.net>
References: <6D1ED283-28C4-4787-B33E-9EF5B8AB9F50@reini.net>
	<7983a3c2-5943-d32a-b0e8-755958700ba8@Oracle.com>
	<11EFA41B-9978-4CC6-B941-1EE6B4F313E6@reini.net>
Message-ID: <89B016D9-1197-45C2-8BB1-1E914EA6B167@oracle.com>


> On 30 Nov 2016, at 13:47, Patrick Reinhart  wrote:
> 
> Hi Roger,
> 
>> Am 30.11.2016 um 20:01 schrieb Roger Riggs :
>> 
>> Hi Patrick,
>> 
>> I have reservations about trying to get this into JDK 9.  Because it is a new API,
>> it should have some bake time before feature freeze and it needs further review
>> from the compatibility point of view and resources committed to create new JCK tests.
>> Many folks are fully loaded also trying to hit feature freeze.
> 
> I did not expect that the first iteration is good enough. I took this issue, because it was
> marked for target 9. So I?m open for other views.
> 

We should defer to 10, hopefully the repos will be open soonish. Recommend that you assign the issue to yourself, triage it, and set the fix version to 10.

Paul.

From mkanat at google.com  Wed Nov 30 23:43:33 2016
From: mkanat at google.com (Max Kanat-Alexander)
Date: Wed, 30 Nov 2016 18:43:33 -0500
Subject: RFR: 8035424: (reflect) Performance problem in
	sun.reflect.generics.parser.SignatureParser
In-Reply-To: 
References: <90b347de-fd85-03c7-51eb-44fedf6f5645@oracle.com>
	
	<972410b1-21e6-8da2-6750-a2f0d8eabcec@oracle.com>
	<7c343eb3-a8ba-fbfc-9630-c2f0d6f096db@gmail.com>
	<583DBC36.8040606@oracle.com>
	<068104fd-643b-539a-c0d0-20c2b1099153@gmail.com>
	<583DFA00.4030108@oracle.com>
	<7aae60a7-3e4c-c000-6acc-cfdcb1b59f66@gmail.com>
	<583E0706.10403@oracle.com>
	
	<5f8c12e3-f27c-849b-86e7-d9e0dfb7a556@oracle.com>
	
	
Message-ID: 

Okay. As a reader, "skip" to me means "ignore" or something like that, and
"mark" isn't inherently meaningful, although I figured it out by the time I
read the whole file.

On Wed, Nov 30, 2016 at 10:31 AM, Peter Levart 
wrote:

> Hi Max,
>
> On 11/30/2016 01:44 PM, Max Kanat-Alexander wrote:
>
> For what it's worth, this looks good to me too. :-)
>
> The name "mark" is a bit confusing, as are all the methods with the word
> "mark" in it; I have to think for a moment about what each of them do.
> Perhaps identifierStart would be better or something, along with
> setIdentifierStart()?
>
>
> I borrowed the name from java.io.InputStream::mark() which likewise
> "remembers" current read position of the stream. The InputStream uses the
> remembered position so it can reset() current position to it, while the
> parser uses the remembered position so it can return the subsequence of
> input from markToCurrent().
>
> Also, "skipIdentifier" is a bit confusing, perhaps that means
> advanceToNextIdentifier?
>
>
> The semantics of the method is to parse the following input as an
> identifier, but not give anything back as a result besides moving current
> position past the parsed identifier (hence the prefix "skip").  After this
> method returns, the parser is typically not positioned at the start of next
> identifier, but at some delimiter, so "advanceToNextIdentifier" would mean
> something completely different. I think the name is right for what it means.
>
> Regards, Peter
>
>
> On Wed, Nov 30, 2016 at 6:41 AM, Claes Redestad  > wrote:
>
>> +1
>>
>> Found a reference to getNext in a comment that should be removed, no
>> re-review required.
>>
>> /Claes
>>
>>
>> On 2016-11-30 12:36, Peter Levart wrote:
>>
>>> Here's a webrev incorporating both suggestions. All 73 java/jang/reflect
>>> jtreg tests are passing...
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8035424_Signatu
>>> reParser.performance/webrev.03/
>>>
>>>
>>> Regards, Peter
>>>
>>
>>
>
>