From jeff.maxwell at gmail.com Sun May 1 00:48:42 2016 From: jeff.maxwell at gmail.com (Jeff Maxwell) Date: Sat, 30 Apr 2016 17:48:42 -0700 (MST) Subject: RFR(m): 8140281 deprecate Optional.get() In-Reply-To: References: <571FE3EF.7050001@oracle.com> <5720C1CE.2000301@oracle.com> Message-ID: <1462063722646-269209.post@n7.nabble.com> "I think our first time Optional use error rate is near 100%." First, I am using "error" broadly here to include non-optimal usages, all but one inappropriate usage was guarded with isPresent. Second, these cases all occurred on the developer's initial encounter with Optional (and with functional programming in Java). After initial reviews developers began to use Optional as it was intended and when they felt the need to use isPresent and/or get() they would consult a colleague before proceeding. Why do developers make these mistakes? As others have said it is the "obvious" choice when following code completion driven development ("It has a short familiar name, it takes no arguments, the javadoc says it throws an exception but it's unchecked, and it returns the thing I want, that must be what they intend for me to use!"). Further, I think that many devs are unfamiliar with programming in a functional style to begin with and when they encounter methods that take Suppliers, Consumers, and Functions they will instinctively avoid them in favor of good old get(). Unlike some on the list, I do believe developers read the javadoc, as unguarded get() usages are rare, but they only read the method level javadoc they receive via code completion. If the javadoc on the get() method was more explicit about proper usage this would likely reduce improper usage. In fact maybe this is why the Google team reports few improper usages with Guava's Optional as its get() javadoc (since at least r11) reads "If the instance might be absent, use {@link #or(Object)} or {@link #orNull} instead.". Is more opinionated javadoc the answer? Maybe, but I think javadoc improvements along with the deprecation and a less seductively named alternative would help a significant amount more than javadoc improvements alone. -- View this message in context: http://openjdk.5641.n7.nabble.com/RFR-m-8140281-deprecate-Optional-get-tp268177p269209.html Sent from the OpenJDK Core Libraries mailing list archive at Nabble.com. From joe.darcy at oracle.com Sun May 1 03:24:20 2016 From: joe.darcy at oracle.com (joe darcy) Date: Sat, 30 Apr 2016 20:24:20 -0700 Subject: JDK 9 RFR of JDK-4943627 Deprecate rounding mode integer constants in BigDecimal and their uses Message-ID: <37790f91-579f-8333-c7af-f98e1cb4fde6@oracle.com> Hello, Please review the changes to address JDK-4943627 Deprecate rounding mode integer constants in BigDecimal and their uses http://cr.openjdk.java.net/~darcy/4943627.0/ Since JDK 5, the java.math package has had a RoundMode enum to model and manage the various rounding modes used by methods in BigDecimal (and elsewhere). Those rounding modes enum constants were added in parallel to a set of integer constants in BigDecimal previously used to model rounding modes. For each BigDecimal method which took an int rounding mode constant, a sibling method was added to take a RoundMode object. As the synopsis of the bug implies, the time has come to deprecate the legacy int rounding mode constants and the method taking those ints as arguments. Thanks, -Joe From Alan.Bateman at oracle.com Sun May 1 07:45:06 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 1 May 2016 08:45:06 +0100 Subject: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them In-Reply-To: <1F3D7F60-5D0E-4FDD-B253-C05F4619CC4F@oracle.com> References: <4A20DDA6-0E1F-4AD4-8966-5FC47315CA82@oracle.com> <57237074.6050608@oracle.com> <1F3280AE-A8FF-4F19-87B1-066EB73E6B30@oracle.com> <57239319.1060901@oracle.com> <52BA6F85-48BA-4E63-89BD-56504EEFE68B@oracle.com> <5723C838.3010804@oracle.com> <977D17CB-EE89-43E7-B68A-66CDF768CDB6@oracle.com> <5723D507.7050302@oracle.com> <5E89A276-997C-44E3-B23A-ADA669AF2DF3@oracle.com> <7044D545-58E6-4F6D-B65A-09C19F3D8FBA@oracle.com> <5723F299.1050203@oracle.com> <1F3D7F60-5D0E-4FDD-B253-C05F4619CC4F@oracle.com> Message-ID: <5725B402.7020905@oracle.com> On 30/04/2016 01:10, Steve Drach wrote: > Hopefully the last one ;-) This webrev removes the lowercase of > protocol, and incorporates better (in my mind) seperation of choices > for choosing the loader, similar to what Paul suggested. Everything > else remains the same. Only URLClassPath changed from previous webrev. > > http://cr.openjdk.java.net/~sdrach/8151542/webrev.04/index.html > > This version looks okay but a comment to explain why the protocol is checked without regard to case would be useful. Also would it be possible to fix the overly long lines (L377-378) as that is very inconsistent with the existing code and annoying when looking at side-by-side diffs. -Alan. From chris.hegarty at oracle.com Sun May 1 21:22:12 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 1 May 2016 22:22:12 +0100 Subject: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them In-Reply-To: <5725B402.7020905@oracle.com> References: <4A20DDA6-0E1F-4AD4-8966-5FC47315CA82@oracle.com> <57237074.6050608@oracle.com> <1F3280AE-A8FF-4F19-87B1-066EB73E6B30@oracle.com> <57239319.1060901@oracle.com> <52BA6F85-48BA-4E63-89BD-56504EEFE68B@oracle.com> <5723C838.3010804@oracle.com> <977D17CB-EE89-43E7-B68A-66CDF768CDB6@oracle.com> <5723D507.7050302@oracle.com> <5E89A276-997C-44E3-B23A-ADA669AF2DF3@oracle.com> <7044D545-58E6-4F6D-B65A-09C19F3D8FBA@oracle.com> <5723F299.1050203@oracle.com> <1F3D7F60-5D0E-4FDD-B253-C05F4619CC4F@oracle.com> <5725B402.7020905@oracle.com> Message-ID: <97506B67-88E6-47A8-A576-188536A7A311@oracle.com> > On 1 May 2016, at 08:45, Alan Bateman wrote: > > On 30/04/2016 01:10, Steve Drach wrote: >> Hopefully the last one ;-) This webrev removes the lowercase of protocol, and incorporates better (in my mind) seperation of choices for choosing the loader, similar to what Paul suggested. Everything else remains the same. Only URLClassPath changed from previous webrev. >> >> http://cr.openjdk.java.net/~sdrach/8151542/webrev.04/index.html >> > This version looks okay but a comment to explain why the protocol is checked without regard to case would be useful. Also would it be possible to fix the overly long lines (L377-378) as that is very inconsistent with the existing code and annoying when looking at side-by-side diffs. +1 Also, it may be worth considering an overloaded JarLoader constructor that accepts a ?jar:? URL, rather than stripping and wrapping. Also, some jar URLs will now go through JarLoader that previously didn?t. I?m not saying that this wrong, just trying to understand the behavioural change. For example, some URLs that previously didn?t have their jar index checked now will. I?ve been looking at this code, for another reason, sorry you have had to deal with it, it?s a bit of a mess. We may need to revisit some of this when 8155770 is resolved. -Chris. From andrey at tweak.su Sun May 1 22:52:12 2016 From: andrey at tweak.su (Andrey) Date: Mon, 02 May 2016 01:52:12 +0300 Subject: String.equalsIgnoreCase(...) optimization In-Reply-To: <5720A492.7070102@oracle.com> References: <753291461680757@web10h.yandex.ru> <571F86D9.2030909@redhat.com> <1922171461709293@web27h.yandex.ru> <4179981461751031@web2g.yandex.ru> <5720A492.7070102@oracle.com> Message-ID: <2627991462143132@web27g.yandex.ru> Hello! I extract JDK 9 code from String, StringLatin1, StringUTF16 and optimize some functions https://github.com/volodin-aa/openjdk-benchmark My optimization: 1. Create fullMatchesCI() methods with simple for (...) loop https://github.com/volodin-aa/openjdk-benchmark/blob/master/src/su/tweak/openjdk/FastStringUTF16.java#L101 2. Remove 'constants' for equalsIgnoreCase() https://github.com/volodin-aa/openjdk-benchmark/blob/master/src/su/tweak/openjdk/FastString.java#L213 3. Optimize upper case verifying http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/56379812ec5e/src/java.base/share/classes/java/lang/StringUTF16.java#l549 Character.toUpperCase(c2) more expencive then simple if (...) and I write if (u1 == c2) instead if (u1 == u2) ... // Try convert c1 to upper case and compare with c2 char u1 = Character.toUpperCase(c1); if (u1 == c2) { continue; } // Try convert c2 to upper case and compare with u1 char u2 = Character.toUpperCase(c2); if (u1 == u2) { continue; } ... For 'random case' strings it is more efficient. And developers can optimeze code like this http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/56379812ec5e/src/java.base/share/classes/java/lang/Boolean.java#l130 public static boolean parseBoolean(String s) { return "true".equalsIgnoreCase(s); } My results https://docs.google.com/spreadsheets/d/1_Fxky6ftZTHpyuRJbM9wvqOzpoORLpIeciukMWuYuXw/pubhtml In table I compute equalsIgnoreCase() time without initialisation time. For case "string" and "String" my version more faster then internalVM version. In other cases VM optimization is faster. 27.04.2016, 14:38, "Aleksey Shipilev" : > ?Hi Andrey, > > ?On 04/27/2016 12:57 PM, Andrey wrote: >> ??I publish my JMH benchmark at github https://github.com/volodin-aa/openjdk-benchmark > > ?Please note that you really should compete with JDK 9 String, not with > ?JDK 8. String.equalsIgnoreCase is different in JDK 9, and the obvious > ?improvement one can do there is: > > ?diff -r 5a6df35b0f97 src/java.base/share/classes/java/lang/StringLatin1.java > ?--- a/src/java.base/share/classes/java/lang/StringLatin1.java Wed Apr 27 > ?09:13:51 2016 +0200 > ?+++ b/src/java.base/share/classes/java/lang/StringLatin1.java Wed Apr 27 > ?14:16:14 2016 +0300 > ?@@ -315,11 +315,14 @@ > ????????????????????????????????????????????byte[] other, int ooffset, > ?int len) { > ??????????int last = toffset + len; > ??????????while (toffset < last) { > ?- char c1 = (char)(value[toffset++] & 0xff); > ?- char c2 = (char)(other[ooffset++] & 0xff); > ?- if (c1 == c2) { > ?+ byte b1 = value[toffset++]; > ?+ byte b2 = other[ooffset++]; > ?+ if (b1 == b2) { > ??????????????????continue; > ??????????????} > ?+ char c1 = (char)(b1 & 0xff); > ?+ char c2 = (char)(b2 & 0xff); > ?+ > ??????????????char u1 = Character.toUpperCase(c1); > ??????????????char u2 = Character.toUpperCase(c2); > ??????????????if (u1 == u2) { > > ?...which improves performance even on short Strings. Maybe specializing > ?Character.toUpperCase for Latin1 strings would pay off more. Maybe > ?specializing regionMatches for complete Strings would worth the > ?increased complexity too, but that should be tried on JDK code first. > > ?To make a good justification for the change, the benchmark should really > ?test: > ??a) Different lengths; > ??b) Different starting mismatch offset; > ??c) Different Latin1/UTF16 pairs. > > ?Note well: these optimizations would require studying the generated code > ?looking for the compiler quirks, and as such would require much more > ?time than anyone thinks it would take (even after taking Hofstadter's > ?Law into account). > > ?Thanks, > ?-Aleksey From claes.redestad at oracle.com Sun May 1 23:35:40 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 2 May 2016 01:35:40 +0200 Subject: RFR: 8155775: Re-examine naming of privileged methods to access System properties Message-ID: <572692CC.8040902@oracle.com> Hi, JDK-8154231 added methods to simplify access to system properties from internal code, but after some discussion it's been decided to rename these methods and document them to make it abundantly clear that they are performing a privileged action and that care needs to be taken to tread the input and output accordingly: Webrev: http://cr.openjdk.java.net/~redestad/8155775/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8155775 Thanks! /Claes From jan.lahoda at oracle.com Mon May 2 06:55:28 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 2 May 2016 08:55:28 +0200 Subject: RFR 8147984: WindowsTerminal should support function keys In-Reply-To: References: <56A21578.5080105@oracle.com> Message-ID: <5726F9E0.4000801@oracle.com> Hi Stuart, Thanks for the comments and the link! A webrev which includes the link is here: http://cr.openjdk.java.net/~jlahoda/8147984/webrev.01/ Delta webrev to the last iteration is here: http://cr.openjdk.java.net/~jlahoda/8147984/webrev.01/delta/webrev Thanks, Jan On 29.4.2016 23:49, Stuart Marks wrote: > Hi Jan, > > I finally got a chance to take a look at this. The change looks fine. > > It would be nice to have a reference to where the escape sequences are > documented. There are links to the Windows VK_ codes there, which is > great. But there's no reference for the escape sequences that each > keypress is mapped to, e.g. F4 is "ESC O S", and F5 is "ESC [ 1 5 ~" > (and what happened to "ESC [ 1 6 ~"??) > > I did some searching, and it seems really hard to find a definitive > reference. Perhaps the best reference is "XTerm Control Sequences" [1] > which seems to document xterm pretty thoroughly, which is what everybody > seems to follow nowadays. It even looks like it's being kept up to date > (last modified 2016-02-21). > > Anyway I'd suggest adding a comment with a reference to this document. > > As a cross-check, these sequences match what my Mac's Terminal.app > emits, at least for unshifted F1-F12. (The Terminal app was probably > copied from xterm.) > > Thanks, > > s'marks > > > [1] http://invisible-island.net/xterm/ctlseqs/ctlseqs.html > > > On 1/22/16 3:41 AM, Jan Lahoda wrote: >> Hello, >> >> I'd like to enhance the WindowsTerminal in jdk.internal.le with >> function keys >> handling. The intent is so that jshell can bind actions for shortcuts >> including >> function keys. >> >> The patch for adding the function keys support is here: >> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.00/ >> >> An example of a feature that uses/may use this support is here: >> http://mail.openjdk.java.net/pipermail/kulla-dev/2016-January/001226.html >> >> Any comments are welcome! >> >> Thanks, >> Jan From aleksey.shipilev at oracle.com Mon May 2 11:56:35 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 2 May 2016 14:56:35 +0300 Subject: RFR (M) 8155739: [TESTBUG] VarHandles/Unsafe tests for weakCAS should allow spurious failures In-Reply-To: <76809325-CB53-499E-885B-9ED4AB0DBBB5@oracle.com> References: <5723DC4D.8090507@oracle.com> <76809325-CB53-499E-885B-9ED4AB0DBBB5@oracle.com> Message-ID: <57274073.1070508@oracle.com> On 04/30/2016 02:42 AM, Paul Sandoz wrote: >> On 29 Apr 2016, at 15:12, Aleksey Shipilev wrote: > Looks good. > > Small tweak if you so wish to do so: > > #if[JdkInternalMisc] > static final int WEAK_ATTEMPTS = Integer.getInteger("weakAttempts", 10); > #end[JdkInternalMisc] > > which avoids changes to the SunMiscUnsafe* tests. Alas, there are still whitespace changes in SunMiscUnsafe* tests, so changes are unavoidable, and I would like to keep the patch in its current form. Thanks, -Aleksey From aleksey.shipilev at oracle.com Mon May 2 11:57:45 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 2 May 2016 14:57:45 +0300 Subject: JDK 9 RFR of adding a few @jls tags to java.lang.String In-Reply-To: References: Message-ID: <572740B9.4050908@oracle.com> Hi, Looks good to me! Thanks for taking care of this. -Aleksey On 04/30/2016 10:34 PM, joe darcy wrote: > Hello, > > Please review the small patch below to add some JLS references to the > string class to supplement its textual discussion of a few sections of > the JLS. > > Thanks, > > -Joe > > > --- a/src/java.base/share/classes/java/lang/String.java Fri Apr 29 > 16:58:00 2016 -0700 > +++ b/src/java.base/share/classes/java/lang/String.java Sat Apr 30 > 12:32:19 2016 -0700 > @@ -117,6 +117,7 @@ > * @see java.lang.StringBuilder > * @see java.nio.charset.Charset > * @since 1.0 > + * @jls 15.18.1 String Concatenation Operator + > */ > > public final class String > @@ -2979,6 +2980,7 @@ > * > * @return a string that has the same contents as this string, but is > * guaranteed to be from a pool of unique strings. > + * @jls 3.10.5 String Literals > */ > public native String intern(); > > From david.holmes at oracle.com Mon May 2 12:01:42 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 2 May 2016 22:01:42 +1000 Subject: JDK 9 RFR of adding a few @jls tags to java.lang.String In-Reply-To: References: Message-ID: <1b12a36b-39a5-295f-64c9-bc0d34fb2c16@oracle.com> On 1/05/2016 5:34 AM, joe darcy wrote: > Hello, > > Please review the small patch below to add some JLS references to the > string class to supplement its textual discussion of a few sections of > the JLS. Side question: what mechanism is there to detect stale references if/when the JLS section numbers change? David > Thanks, > > -Joe > > > --- a/src/java.base/share/classes/java/lang/String.java Fri Apr 29 > 16:58:00 2016 -0700 > +++ b/src/java.base/share/classes/java/lang/String.java Sat Apr 30 > 12:32:19 2016 -0700 > @@ -117,6 +117,7 @@ > * @see java.lang.StringBuilder > * @see java.nio.charset.Charset > * @since 1.0 > + * @jls 15.18.1 String Concatenation Operator + > */ > > public final class String > @@ -2979,6 +2980,7 @@ > * > * @return a string that has the same contents as this string, but is > * guaranteed to be from a pool of unique strings. > + * @jls 3.10.5 String Literals > */ > public native String intern(); > > From claes.redestad at oracle.com Mon May 2 14:07:58 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 2 May 2016 16:07:58 +0200 Subject: RFR: 8155795: Optimize Integer/Long.reverse by using reverseBytes Message-ID: <57275F3E.6000709@oracle.com> Hi, I'd like to sponsor this patch proposed by Jaroslav Kamen?k here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040660.html Bug https://bugs.openjdk.java.net/browse/JDK-8155795 Webrev: http://cr.openjdk.java.net/~redestad/8155795/webrev.01/ The idea is that reusing reverseBytes can bring a speedup since this method is intrinsified on many platforms. Thanks! /Claes From daniel.fuchs at oracle.com Mon May 2 14:13:23 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 2 May 2016 16:13:23 +0200 Subject: RFR: 8139982 Re-examine java.management dependency on java.util.logging.LoggingMXBean In-Reply-To: <63AA09C6-F10E-46A8-B207-AF22BE3D50B1@oracle.com> References: <63AA09C6-F10E-46A8-B207-AF22BE3D50B1@oracle.com> Message-ID: <9d7880b1-e8ee-836e-4dd8-4cd08b3f74e9@oracle.com> Hi Mandy, Answers inline, and new webrev at the end. On 29/04/16 21:55, Mandy Chung wrote: > Hi Daniel, > >> On Apr 29, 2016, at 8:08 AM, Daniel Fuchs wrote: >> >> Hi, >> >> Please find below a patch [2] that eliminates a static >> dependency of java.lang.management on java.util.logging.LoggingMXBean. >> >> When JDK-6876135 was fixed, it introduced the PlatformLoggingMXBean >> interface, and recommended using PlatformLoggingMXBean over >> LoggingMXBean. > > Adding to this, JDK-6876135 prepared the JDK for modularization and PlatformLoggingMXBean was introduced that can be replaced with existing usage of LoggingMXBean. > > With this change, java.management dependency on java.logging will become implementation details for logging purpose and can be eliminated completely in the future. > > About the deprecation, to be specific, LoggingMXBean will no longer be a platform MXBean and an instance of LoggingMXBean will not register in the platform MBeanServer. > > This is a revised wording for the deprecation note for LoggingMXBean: > > @deprecated {@code LoggingMXBean} is no longer a {@link java.lang.management.PlatformManagedObject platform MXBean} and replaced with {@link java.lang.management.PlatformLoggingMXBean}. > It will not register in the platform MBeanServer. Use > {@code ManagementFactory.getPlatformMXBean(PlatformLoggingMXBean.class)} instead. Done. > One question about: ManagementFactory::getPlatformMXBean(MBeanServerConnection, PlatformLoggingMXBean.class) > - what would happen if this method is called from an image with java.logging module present and connect to > a VM with no java.logging module? > Should the ManagementFactory::getPlatformMXBean spec or PlatformLoggingMXBean spec be clarified? I don't think there's anything to clarify: it will throw an IllegalArgumentException as specified in the spec. (it will get an InstanceNotFoundException from the remote VM, which will be wrapped and thrown as the cause of an IllegalArgumentException) > ManagementFactoryHelper.java > > 191 if (result != null) { > 192 LoggingMXBeanSupport.class.getModule().addReads(m); > 193 } > > Reflection access assumes readability now: > http://openjdk.java.net/projects/jigsaw/spec/issues/#ReflectionWithoutReadability > > So this addReads is not needed. Oh - OK thanks for the pointer! > > 252 final Map methods = AccessController.doPrivileged( > 253 new PrivilegedAction<>() { > 254 @Override > 255 public Map run() { > 256 return initMethodMap(impl); > 257 } > 258 }); > > I believe this doPrivileged is not necessary and so do the other getMethod calls. > Probably you are thinking ahead what if java.management may one day be defined > by a child loader of the defining loader of java.logging. > Then you can move doPrivileged to initMethodMap. The doPrivileged around initMethod is necessary because the implementation class from which the methods are looked up is package protected, so unfortunately Method.setAccessible needs to be called. Another possibility would be to lookup the method on java.util.logging.LoggingMXBean instead of looking them up on the concrete implementation class. In that case setAccessible should no longer be needed. Do you think I should modify the code to do that? However your remark made me review the doPrivs and I believe the one in getMXBeanImplementation() is not needed, since it invokes a public static method on public exported class. I removed that. > 217 // skip > - better to throw InternalError since it expects all methods are used? No. getObjectName() will fall in this bucket - it's not defined on LoggingMXBean. > 273 throw new SecurityException(ex); > - should not reach here. SecurityException may cause confusion since this will be thrown even without security manager. could simply throw InternalException OK - Wrapped in UnsupportedOperationException instead. > 296 private PlatformLoggingImpl(LoggingMXBeanSupport support) { > - perhaps renaming LoggingMXBeanSupport to LoggingProxy to better represent it. It's not really a proxy - it only implemements "invoke". Maybe it should be called LoggingMXBeanAccess? >> Backward Compatibility considerations: >> -------------------------------------- >> >> 1. Local clients which obtain an instance of the logging >> MXBean by calling ManagementFactory.getPlatformMXBean( >> "java.util.logging:type=Logging", >> PlatformLoggingMXBean.class) >> will no longer be able to cast the result on >> java.util.logging.LoggingMXBean. >> [There should be few, given that PlatformLoggingMXBean >> already has all the methods defined in LoggingMXBean] >> > > I expect this would be really rare too. > >> 2. ManagementFactory.getPlatformMBeanServer().isInstanceOf( >> ObjectName, "java.util.logging.LoggingMXBean") >> will now return 'false' instead of 'true'. >> >> 3. The Logging MXBean MBeanInfo will now report that its >> management interface is "java.lang.management.PlatformLoggingMXBean" >> instead of "sun.management.ManagementFactoryHelper$LoggingMXBean?. > > Any impact to permission confiugred in security policy? Should also document that. The permission are checked against the concrete implementation class name "sun.management.ManagementFactoryHelper$PlatformLoggingImpl" and we're not changing that - so there should be no incompatibility here. Thanks a lot for the feedback! New webrev here: http://cr.openjdk.java.net/~dfuchs/8139982_webrev/webrev.07/index.html -- daniel >> 4. Calls to ManagementFactory.newPlatformMXBeanProxy( >> MBeanServerConnection, ObjectName, >> java.util.logging.LoggingMXBean.class); and >> JMX.newMXBeanProxy(MBeanServerConnection, ObjectName, >> java.util.logging.LoggingMXBean.class) >> will continue to work as before. >> > >> 5. Remote clients running previous version of the JDK >> should see no changes, except for the interface >> name in MBeanInfo, and the change in isInstanceOf >> reported in 2. > > This is good. > > The incompatibility risk for this change is rather low. > > Mandy > From sean.mullan at oracle.com Mon May 2 14:15:29 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 2 May 2016 10:15:29 -0400 Subject: RFR: 8155775: Re-examine naming of privileged methods to access System properties In-Reply-To: <572692CC.8040902@oracle.com> References: <572692CC.8040902@oracle.com> Message-ID: <57276101.7040306@oracle.com> This looks good. Just a couple of comments: * src/java.base/share/classes/java/util/TimeZone.java 698 props.setProperty("user.timezone", id); This will only change the local copy of the property. I think you want to keep the original code which does a System.setProperty. * src/java.base/share/classes/jdk/Version.java This is not an issue in your changes, but the current javadoc for Version.current() says: 266 * @throws SecurityException 267 * If a security manager exists and its {@link 268 * SecurityManager#checkPropertyAccess(String) 269 * checkPropertyAccess} method does not allow access to the 270 * system property "java.version" but this can never occur since the code is wrapping the call to System.getProperty("java.version") in doPrivileged, so the caller's permissions are never checked. I think that this is a bug in the javadoc of this method and that it should not be specified to throw SecurityException. All code already has permission to read "java.version" in the default java.policy file. Can you file a followon bug to have this fixed? Thanks, Sean On 05/01/2016 07:35 PM, Claes Redestad wrote: > Hi, > > JDK-8154231 added methods to simplify access to system properties from > internal code, but after some discussion it's been decided to rename > these methods and document them to make it abundantly clear that they > are performing a privileged action and that care needs to be taken to > tread the input and output accordingly: > > Webrev: http://cr.openjdk.java.net/~redestad/8155775/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8155775 > > Thanks! > > /Claes From volker.simonis at gmail.com Mon May 2 14:34:56 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 2 May 2016 16:34:56 +0200 Subject: RFR (M) 8155739: [TESTBUG] VarHandles/Unsafe tests for weakCAS should allow spurious failures In-Reply-To: <76809325-CB53-499E-885B-9ED4AB0DBBB5@oracle.com> References: <5723DC4D.8090507@oracle.com> <76809325-CB53-499E-885B-9ED4AB0DBBB5@oracle.com> Message-ID: Hi Aleksey, thanks for this quick fix. The change looks good! Adding to Paul, you could restrict the definition of WEAK_ATTEMPTS even further if you want: #if[CAS] #if[JdkInternalMisc] static final int WEAK_ATTEMPTS = Integer.getInteger("weakAttempts", 10); #end[JdkInternalMisc] #end[CAS] We still have two other test failures with our new intrinsic implementation on ppc64, but that's pretty sure our fault :) Regards, Volker On Sat, Apr 30, 2016 at 1:42 AM, Paul Sandoz wrote: > >> On 29 Apr 2016, at 15:12, Aleksey Shipilev wrote: >> >> Hi, >> >> I would like to fix a simple testbug in our weakCompareAndSet VarHandles >> and Unsafe intrinsics tests. weakCompareAndSet is spec-ed to allow >> spurious failures, but current tests do not allow that. This blocks >> development and testing on non-x86 platforms. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8155739 >> >> Webrevs: >> http://cr.openjdk.java.net/~shade/8155739/webrev.hs.00/ >> http://cr.openjdk.java.net/~shade/8155739/webrev.jdk.00/ >> > > Looks good. > > Small tweak if you so wish to do so: > > #if[JdkInternalMisc] > static final int WEAK_ATTEMPTS = Integer.getInteger("weakAttempts", 10); > #end[JdkInternalMisc] > > which avoids changes to the SunMiscUnsafe* tests. > > Paul. > >> The tests are auto-generated, and the substantiative changes are in >> *.template files. I also removed obsolete generate-unsafe-tests.sh. I >> would like to push through hs-comp to expose this to Power and AArch64 >> folks early. >> >> Testing: x86_64, jdk:java/lang/invoke/VarHandle, hotspot:compiler/unsafe >> >> Thanks, >> -Aleksey >> > From aleksey.shipilev at oracle.com Mon May 2 14:48:04 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 2 May 2016 17:48:04 +0300 Subject: RFR: 8155795: Optimize Integer/Long.reverse by using reverseBytes In-Reply-To: <57275F3E.6000709@oracle.com> References: <57275F3E.6000709@oracle.com> Message-ID: <572768A4.6010105@oracle.com> On 05/02/2016 05:07 PM, Claes Redestad wrote: > I'd like to sponsor this patch proposed by Jaroslav Kamen?k here: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040660.html > > Bug https://bugs.openjdk.java.net/browse/JDK-8155795 > Webrev: http://cr.openjdk.java.net/~redestad/8155795/webrev.01/ *) I wonder if Integer.reverseBytes is better spelled as: return (i >>> 24) | ((i & 0xFF0000) >> 8) | ((i & 0xFF00) << 8) | (i << 24); *) The test should probably follow the same randomized testing pattern as other tests: for (int i = 0; i < N; i++) { int x = rnd.nextInt(); String expected = new StringBuilder(). .append(leftpad(Integer.toBinaryString(x), 32)) .reverse().toString(); String actual = leftpad(Integer.toBinaryString(Integer.reverse(x)), 32); if (!expected.equals(actual)) { throw new RuntimeException("reverse: \n" + expected + " \n" + actual); } // That's how development looks like in 2016. private static String leftpad(String s, int width) { String r = s; for (int c = 0; c < width - s.length(); c++) { r = "0" + r; } return r; } ...and should probably precede any other test that uses reverse(). Thanks, -Aleksey From sean.mullan at oracle.com Mon May 2 15:01:22 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 2 May 2016 11:01:22 -0400 Subject: RFR: 8155775: Re-examine naming of privileged methods to access System properties In-Reply-To: <57276101.7040306@oracle.com> References: <572692CC.8040902@oracle.com> <57276101.7040306@oracle.com> Message-ID: <57276BC2.4080203@oracle.com> On 05/02/2016 10:15 AM, Sean Mullan wrote: > This looks good. Just a couple of comments: > > * src/java.base/share/classes/java/util/TimeZone.java > > 698 props.setProperty("user.timezone", id); > > This will only change the local copy of the property. I think you want > to keep the original code which does a System.setProperty. Ignore this comment. I missed the fact that System.getProperties() returns the props field without any defensive cloning. --Sean From claes.redestad at oracle.com Mon May 2 15:00:14 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 2 May 2016 17:00:14 +0200 Subject: RFR: 8155795: Optimize Integer/Long.reverse by using reverseBytes In-Reply-To: <572768A4.6010105@oracle.com> References: <57275F3E.6000709@oracle.com> <572768A4.6010105@oracle.com> Message-ID: <57276B7E.80006@oracle.com> On 2016-05-02 16:48, Aleksey Shipilev wrote: > On 05/02/2016 05:07 PM, Claes Redestad wrote: >> I'd like to sponsor this patch proposed by Jaroslav Kamen?k here: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040660.html >> >> Bug https://bugs.openjdk.java.net/browse/JDK-8155795 >> Webrev: http://cr.openjdk.java.net/~redestad/8155795/webrev.01/ > *) I wonder if Integer.reverseBytes is better spelled as: > > return (i >>> 24) | > ((i & 0xFF0000) >> 8) | > ((i & 0xFF00) << 8) | > (i << 24); The reverseBytes changes were motivated by seeing slightly better performance on the micro with the suggested changes, but after discussing this a bit I think we should revert to the original code alone and investigate if there's some compiler quirk lurking here separately. I'll file a bug. > > *) The test should probably follow the same randomized testing pattern > as other tests: > > for (int i = 0; i < N; i++) { > int x = rnd.nextInt(); > > String expected = new StringBuilder(). > .append(leftpad(Integer.toBinaryString(x), 32)) > .reverse().toString(); > > String actual = > leftpad(Integer.toBinaryString(Integer.reverse(x)), 32); > > if (!expected.equals(actual)) { > throw new RuntimeException("reverse: \n" + > expected + " \n" + actual); > } > > // That's how development looks like in 2016. > private static String leftpad(String s, int width) { > String r = s; > for (int c = 0; c < width - s.length(); c++) { > r = "0" + r; > } > return r; > } > > ...and should probably precede any other test that uses reverse(). Seems reasonable. Jaroslav, do you mind improving the test as per Aleksey's suggestions? Thanks! /Claes From Ulf.Zibis at CoSoCo.de Mon May 2 15:18:56 2016 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Mon, 2 May 2016 17:18:56 +0200 Subject: RFR: 8155795: Optimize Integer/Long.reverse by using reverseBytes In-Reply-To: <57276B7E.80006@oracle.com> References: <57275F3E.6000709@oracle.com> <572768A4.6010105@oracle.com> <57276B7E.80006@oracle.com> Message-ID: <57276FE0.7070704@CoSoCo.de> Am 02.05.2016 um 17:00 schrieb Claes Redestad: > The reverseBytes changes were motivated by seeing slightly better > performance on the micro with the suggested changes, but after > discussing this a bit I think we should revert to the original code alone > and investigate if there's some compiler quirk lurking here separately. Maybe (i & 0xFF00) is faster than (i & 0xFF0000), because the first can be executed by shorter 16-bit CPU op code. Looking at HotSpot disassembler output could solve the miracle. -Ulf From steve.drach at oracle.com Mon May 2 16:23:10 2016 From: steve.drach at oracle.com (Steve Drach) Date: Mon, 2 May 2016 09:23:10 -0700 Subject: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them In-Reply-To: <97506B67-88E6-47A8-A576-188536A7A311@oracle.com> References: <4A20DDA6-0E1F-4AD4-8966-5FC47315CA82@oracle.com> <57237074.6050608@oracle.com> <1F3280AE-A8FF-4F19-87B1-066EB73E6B30@oracle.com> <57239319.1060901@oracle.com> <52BA6F85-48BA-4E63-89BD-56504EEFE68B@oracle.com> <5723C838.3010804@oracle.com> <977D17CB-EE89-43E7-B68A-66CDF768CDB6@oracle.com> <5723D507.7050302@oracle.com> <5E89A276-997C-44E3-B23A-ADA669AF2DF3@oracle.com> <7044D545-58E6-4F6D-B65A-09C19F3D8FBA@oracle.com> <5723F299.1050203@oracle.com> <1F3D7F60-5D0E-4FDD-B253-C05F4619CC4F@oracle.com> <5725B402.7020905@oracle.com> <97506B67-88E6-47A8-A576-188536A7A311@oracle.com> Message-ID: Another webrev: http://cr.openjdk.java.net/~sdrach/8151542/webrev.05/index.html Only URLClassPath has changed. I put a comment on url.getProtocol indicating the URL assures it?s lower case and I changed the long lines into multiple shorter lines. > Also, it may be worth considering an overloaded JarLoader constructor > that accepts a ?jar:? URL, rather than stripping and wrapping. I tried that this morning. There aren?t any ?good? constructors for URL that have a jarHandler that I can use. The ones I found do much more work than what we are doing. > > Also, some jar URLs will now go through JarLoader that previously didn?t. > I?m not saying that this wrong, just trying to understand the behavioural > change. For example, some URLs that previously didn?t have their jar index > checked now will. > > I?ve been looking at this code, for another reason, sorry you have had to > deal with it, it?s a bit of a mess. It is indeed a bit of a mess > We may need to revisit some of this when > 8155770 is resolved. > > -Chris. > > > From mandy.chung at oracle.com Mon May 2 17:00:25 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 2 May 2016 10:00:25 -0700 Subject: RFR: 8139982 Re-examine java.management dependency on java.util.logging.LoggingMXBean In-Reply-To: <9d7880b1-e8ee-836e-4dd8-4cd08b3f74e9@oracle.com> References: <63AA09C6-F10E-46A8-B207-AF22BE3D50B1@oracle.com> <9d7880b1-e8ee-836e-4dd8-4cd08b3f74e9@oracle.com> Message-ID: <8A964073-883E-4A63-992D-A6ECCE24178D@oracle.com> > On May 2, 2016, at 7:13 AM, Daniel Fuchs wrote: > > >> One question about: ManagementFactory::getPlatformMXBean(MBeanServerConnection, PlatformLoggingMXBean.class) >> - what would happen if this method is called from an image with java.logging module present and connect to >> a VM with no java.logging module? >> Should the ManagementFactory::getPlatformMXBean spec or PlatformLoggingMXBean spec be clarified? > > I don't think there's anything to clarify: it will throw > an IllegalArgumentException as specified in the spec. > (it will get an InstanceNotFoundException from the > remote VM, which will be wrapped and thrown as the > cause of an IllegalArgumentException) > OK. thanks for checking. > >> >> 252 final Map methods = AccessController.doPrivileged( >> 253 new PrivilegedAction<>() { >> 254 @Override >> 255 public Map run() { >> 256 return initMethodMap(impl); >> 257 } >> 258 }); >> >> I believe this doPrivileged is not necessary and so do the other getMethod calls. >> Probably you are thinking ahead what if java.management may one day be defined >> by a child loader of the defining loader of java.logging. >> Then you can move doPrivileged to initMethodMap. > > The doPrivileged around initMethod is necessary because > the implementation class from which the methods are looked > up is package protected, so unfortunately Method.setAccessible > needs to be called. Another possibility would be to lookup > the method on java.util.logging.LoggingMXBean instead of > looking them up on the concrete implementation class. > In that case setAccessible should no longer be needed. > > Do you think I should modify the code to do that? > I think that?d be cleaner to inspect java.util.logging.LoggingMXBean instead as Logging class now implements it. > However your remark made me review the doPrivs and I believe > the one in getMXBeanImplementation() is not needed, since > it invokes a public static method on public exported class. > I removed that. > Good. > >> 217 // skip >> - better to throw InternalError since it expects all methods are used? > > No. getObjectName() will fall in this bucket - it's not > defined on LoggingMXBean. I missed it inspected implementation class rather than LoggingMXBean. Once you change it to find methods on LoggingMXBean, it should expect all methods can be found. > >> 273 throw new SecurityException(ex); >> - should not reach here. SecurityException may cause confusion since this will be thrown even without security manager. could simply throw InternalException > > OK - Wrapped in UnsupportedOperationException instead. > > >> 296 private PlatformLoggingImpl(LoggingMXBeanSupport support) { >> - perhaps renaming LoggingMXBeanSupport to LoggingProxy to better represent it. > > It's not really a proxy - it only implemements "invoke". Maybe it should > be called LoggingMXBeanAccess? > Sounds good. > >> >> Any impact to permission confiugred in security policy? Should also document that. > > The permission are checked against the concrete implementation > class name "sun.management.ManagementFactoryHelper$PlatformLoggingImpl" > and we're not changing that - so there should be no incompatibility > here. > Good. > Thanks a lot for the feedback! > > New webrev here: > http://cr.openjdk.java.net/~dfuchs/8139982_webrev/webrev.07/index.html Nit: in the class spec for LoggingMXBean.java - wrap type names with {@code?} such as MBeanServer, PlatformLoggingMXBean. ManagementFactoryHelper.java line 333: extra line to be removed? Mandy From daniel.fuchs at oracle.com Mon May 2 17:59:04 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 2 May 2016 19:59:04 +0200 Subject: RFR: 8139982 Re-examine java.management dependency on java.util.logging.LoggingMXBean In-Reply-To: <8A964073-883E-4A63-992D-A6ECCE24178D@oracle.com> References: <63AA09C6-F10E-46A8-B207-AF22BE3D50B1@oracle.com> <9d7880b1-e8ee-836e-4dd8-4cd08b3f74e9@oracle.com> <8A964073-883E-4A63-992D-A6ECCE24178D@oracle.com> Message-ID: <34815912-f657-910c-dd48-df5ef6655bd0@oracle.com> Hi Mandy, I applied the suggested changes. http://cr.openjdk.java.net/~dfuchs/8139982_webrev/webrev.08/index.html best regards, -- daniel On 02/05/16 19:00, Mandy Chung wrote: >> hanks a lot for the feedback! >> > >> > New webrev here: >> > http://cr.openjdk.java.net/~dfuchs/8139982_webrev/webrev.07/index.html > Nit: in the class spec for LoggingMXBean.java - wrap type names with {@code?} such as MBeanServer, PlatformLoggingMXBean. > > ManagementFactoryHelper.java > line 333: extra line to be removed? From mandy.chung at oracle.com Mon May 2 18:06:48 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 2 May 2016 11:06:48 -0700 Subject: RFR: 8139982 Re-examine java.management dependency on java.util.logging.LoggingMXBean In-Reply-To: <34815912-f657-910c-dd48-df5ef6655bd0@oracle.com> References: <63AA09C6-F10E-46A8-B207-AF22BE3D50B1@oracle.com> <9d7880b1-e8ee-836e-4dd8-4cd08b3f74e9@oracle.com> <8A964073-883E-4A63-992D-A6ECCE24178D@oracle.com> <34815912-f657-910c-dd48-df5ef6655bd0@oracle.com> Message-ID: <69DADC3E-4C8C-4404-B059-3DCEBFBEE7A8@oracle.com> > On May 2, 2016, at 10:59 AM, Daniel Fuchs wrote: > > Hi Mandy, > > I applied the suggested changes. > > http://cr.openjdk.java.net/~dfuchs/8139982_webrev/webrev.08/index.html > Looks very good and much cleaner. Nits: 166 // The LoggingMXBeanSupport class uses reflection to determine s/LoggingMXBeanSupport/LoggingMXBeanAccess/ Also renaming the variable name ?support? to ?loggingAccess? (or something like that) might help. You can fix it up before you push. No need to generate a new webrev. Mandy From claes.redestad at oracle.com Mon May 2 18:21:07 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 2 May 2016 20:21:07 +0200 Subject: RFR: 8155775: Re-examine naming of privileged methods to access System properties In-Reply-To: <57276101.7040306@oracle.com> References: <572692CC.8040902@oracle.com> <57276101.7040306@oracle.com> Message-ID: <57279A93.40206@oracle.com> On 2016-05-02 16:15, Sean Mullan wrote: > This looks good. Thanks! > > * src/java.base/share/classes/jdk/Version.java > > This is not an issue in your changes, but the current javadoc for > Version.current() says: > > 266 * @throws SecurityException > 267 * If a security manager exists and its {@link > 268 * SecurityManager#checkPropertyAccess(String) > 269 * checkPropertyAccess} method does not allow access > to the > 270 * system property "java.version" > > but this can never occur since the code is wrapping the call to > System.getProperty("java.version") in doPrivileged, so the caller's > permissions are never checked. > > I think that this is a bug in the javadoc of this method and that it > should not be specified to throw SecurityException. All code already > has permission to read "java.version" in the default java.policy file. > Can you file a followon bug to have this fixed? Filed: https://bugs.openjdk.java.net/browse/JDK-8155853 /Claes From daniel.fuchs at oracle.com Mon May 2 18:21:58 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 2 May 2016 20:21:58 +0200 Subject: RFR: 8139982 Re-examine java.management dependency on java.util.logging.LoggingMXBean In-Reply-To: <69DADC3E-4C8C-4404-B059-3DCEBFBEE7A8@oracle.com> References: <63AA09C6-F10E-46A8-B207-AF22BE3D50B1@oracle.com> <9d7880b1-e8ee-836e-4dd8-4cd08b3f74e9@oracle.com> <8A964073-883E-4A63-992D-A6ECCE24178D@oracle.com> <34815912-f657-910c-dd48-df5ef6655bd0@oracle.com> <69DADC3E-4C8C-4404-B059-3DCEBFBEE7A8@oracle.com> Message-ID: On 02/05/16 20:06, Mandy Chung wrote: > >> On May 2, 2016, at 10:59 AM, Daniel Fuchs wrote: >> >> Hi Mandy, >> >> I applied the suggested changes. >> >> http://cr.openjdk.java.net/~dfuchs/8139982_webrev/webrev.08/index.html >> > > Looks very good and much cleaner. Nits: > > 166 // The LoggingMXBeanSupport class uses reflection to determine > > s/LoggingMXBeanSupport/LoggingMXBeanAccess/ > > Also renaming the variable name ?support? to ?loggingAccess? (or something like that) might help. > > You can fix it up before you push. No need to generate a new webrev. Thanks! Done. -- done > > Mandy > From paul.sandoz at oracle.com Mon May 2 18:30:52 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 2 May 2016 11:30:52 -0700 Subject: RFR (M) 8155739: [TESTBUG] VarHandles/Unsafe tests for weakCAS should allow spurious failures In-Reply-To: <57274073.1070508@oracle.com> References: <5723DC4D.8090507@oracle.com> <76809325-CB53-499E-885B-9ED4AB0DBBB5@oracle.com> <57274073.1070508@oracle.com> Message-ID: <585095F9-EE32-4110-8057-7C50F692CE66@oracle.com> > On 2 May 2016, at 04:56, Aleksey Shipilev wrote: > > On 04/30/2016 02:42 AM, Paul Sandoz wrote: >>> On 29 Apr 2016, at 15:12, Aleksey Shipilev wrote: >> Looks good. >> >> Small tweak if you so wish to do so: >> >> #if[JdkInternalMisc] >> static final int WEAK_ATTEMPTS = Integer.getInteger("weakAttempts", 10); >> #end[JdkInternalMisc] >> >> which avoids changes to the SunMiscUnsafe* tests. > > Alas, there are still whitespace changes in SunMiscUnsafe* tests, so > changes are unavoidable, and I would like to keep the patch in its > current form. > No objections from me. Paul. From huizhe.wang at oracle.com Mon May 2 18:30:54 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 02 May 2016 11:30:54 -0700 Subject: RFR (JAXP) 8152912: SAX XMLReaderFactory needs to be ServiceLoader compliant Message-ID: <57279CDE.7070207@oracle.com> Hi, Please review a change that adds a step using the ServiceLoader to XMLReaderFactory's provider-lookup process. Meanwhile, XMLReaderFactory is deprecated in favor of javax.xml.parsers.SAXParserFactory. JBS: https://bugs.openjdk.java.net/browse/JDK-8152912 Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8152912/webrev/ The change has been verified by SQE test that Frank will submit soon for review (that is, when he starts to work at his local time). Thanks, Joe From stuart.marks at oracle.com Mon May 2 18:31:16 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 2 May 2016 11:31:16 -0700 Subject: RFR 8147984: WindowsTerminal should support function keys In-Reply-To: <5726F9E0.4000801@oracle.com> References: <56A21578.5080105@oracle.com> <5726F9E0.4000801@oracle.com> Message-ID: <8e47a023-b313-d40e-7ed7-c91428f2d700@oracle.com> Hi Jan, Thanks for the update. Including the link is fine, but I'm a bit suspicious of the durability of that website -- it appears to be the personal website of the current maintainer. Who knows if it'll be around in a couple years. I'd suggest including in the comment the official title of the document, "XTerm Control Sequences" along with a mention of the authors (Moy, Gildea, Dickey) so that if the link were to go bad, it would be possible to do a web search to find some version of the document. No need for an updated webrev. Thanks, s'marks On 5/1/16 11:55 PM, Jan Lahoda wrote: > Hi Stuart, > > Thanks for the comments and the link! > > A webrev which includes the link is here: > http://cr.openjdk.java.net/~jlahoda/8147984/webrev.01/ > > Delta webrev to the last iteration is here: > http://cr.openjdk.java.net/~jlahoda/8147984/webrev.01/delta/webrev > > Thanks, > Jan > > On 29.4.2016 23:49, Stuart Marks wrote: >> Hi Jan, >> >> I finally got a chance to take a look at this. The change looks fine. >> >> It would be nice to have a reference to where the escape sequences are >> documented. There are links to the Windows VK_ codes there, which is >> great. But there's no reference for the escape sequences that each >> keypress is mapped to, e.g. F4 is "ESC O S", and F5 is "ESC [ 1 5 ~" >> (and what happened to "ESC [ 1 6 ~"??) >> >> I did some searching, and it seems really hard to find a definitive >> reference. Perhaps the best reference is "XTerm Control Sequences" [1] >> which seems to document xterm pretty thoroughly, which is what everybody >> seems to follow nowadays. It even looks like it's being kept up to date >> (last modified 2016-02-21). >> >> Anyway I'd suggest adding a comment with a reference to this document. >> >> As a cross-check, these sequences match what my Mac's Terminal.app >> emits, at least for unshifted F1-F12. (The Terminal app was probably >> copied from xterm.) >> >> Thanks, >> >> s'marks >> >> >> [1] http://invisible-island.net/xterm/ctlseqs/ctlseqs.html >> >> >> On 1/22/16 3:41 AM, Jan Lahoda wrote: >>> Hello, >>> >>> I'd like to enhance the WindowsTerminal in jdk.internal.le with >>> function keys >>> handling. The intent is so that jshell can bind actions for shortcuts >>> including >>> function keys. >>> >>> The patch for adding the function keys support is here: >>> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.00/ >>> >>> An example of a feature that uses/may use this support is here: >>> http://mail.openjdk.java.net/pipermail/kulla-dev/2016-January/001226.html >>> >>> Any comments are welcome! >>> >>> Thanks, >>> Jan From artem.smotrakov at oracle.com Mon May 2 19:40:35 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 2 May 2016 12:40:35 -0700 Subject: [9] RFR: 8155859: Problem list tools/pack200/Pack200Props.java Message-ID: <5727AD33.8020104@oracle.com> Hello, tools/pack200/Pack200Props.java fails on multiple platforms. Please see details in https://bugs.openjdk.java.net/browse/JDK-8155857 Please review the following patch below which adds the test to ProblemList.txt Bug: https://bugs.openjdk.java.net/browse/JDK-8155859 diff -r 2bf84670f079 test/ProblemList.txt --- a/test/ProblemList.txt Sat Apr 30 16:08:48 2016 -0700 +++ b/test/ProblemList.txt Mon May 02 12:02:42 2016 -0700 @@ -319,6 +319,8 @@ tools/launcher/FXLauncherTest.java 8068049 linux-all,macosx-all +tools/pack200/Pack200Props.java 8155857 generic-all + ############################################################################ # jdk_jdi Artem From Roger.Riggs at Oracle.com Mon May 2 19:50:50 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 2 May 2016 15:50:50 -0400 Subject: [9] RFR: 8155859: Problem list tools/pack200/Pack200Props.java In-Reply-To: <5727AD33.8020104@oracle.com> References: <5727AD33.8020104@oracle.com> Message-ID: Looks fine. (It looks like all the spaces got squeezed out; the bugids should line up.) Roger On 5/2/2016 3:40 PM, Artem Smotrakov wrote: > Hello, > > tools/pack200/Pack200Props.java fails on multiple platforms. Please > see details in https://bugs.openjdk.java.net/browse/JDK-8155857 > > Please review the following patch below which adds the test to > ProblemList.txt > > Bug: https://bugs.openjdk.java.net/browse/JDK-8155859 > > diff -r 2bf84670f079 test/ProblemList.txt > --- a/test/ProblemList.txt Sat Apr 30 16:08:48 2016 -0700 > +++ b/test/ProblemList.txt Mon May 02 12:02:42 2016 -0700 > @@ -319,6 +319,8 @@ > > tools/launcher/FXLauncherTest.java 8068049 linux-all,macosx-all > > +tools/pack200/Pack200Props.java 8155857 generic-all > + > ############################################################################ > > > # jdk_jdi > > > > Artem From alexandre.iline at oracle.com Mon May 2 20:03:03 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Mon, 2 May 2016 13:03:03 -0700 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences Message-ID: Hi, Can you please take a look on: http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/ ? Thank you Shura From jaroslav at kamenik.cz Mon May 2 20:47:34 2016 From: jaroslav at kamenik.cz (=?UTF-8?Q?Jaroslav_Kamen=C3=ADk?=) Date: Mon, 2 May 2016 22:47:34 +0200 Subject: RFR: 8155795: Optimize Integer/Long.reverse by using reverseBytes In-Reply-To: <57276B7E.80006@oracle.com> References: <57275F3E.6000709@oracle.com> <572768A4.6010105@oracle.com> <57276B7E.80006@oracle.com> Message-ID: Thanks for comments. I have changed tests as Aleksey suggested. Btw. is not there some class used for utility methods as leftpad? Ad performance of changed reverseBytes, I tried to compare both reverseBytes alone, and it seems to be same, but differs when inlined to reverse(). J. 2016-05-02 17:00 GMT+02:00 Claes Redestad : > On 2016-05-02 16:48, Aleksey Shipilev wrote: > >> On 05/02/2016 05:07 PM, Claes Redestad wrote: >> >>> I'd like to sponsor this patch proposed by Jaroslav Kamen?k here: >>> >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040660.html >>> >>> Bug https://bugs.openjdk.java.net/browse/JDK-8155795 >>> Webrev: http://cr.openjdk.java.net/~redestad/8155795/webrev.01/ >>> >> *) I wonder if Integer.reverseBytes is better spelled as: >> >> return (i >>> 24) | >> ((i & 0xFF0000) >> 8) | >> ((i & 0xFF00) << 8) | >> (i << 24); >> > > The reverseBytes changes were motivated by seeing slightly better > performance on the micro with the suggested changes, but after > discussing this a bit I think we should revert to the original code alone > and investigate if there's some compiler quirk lurking here separately. > > I'll file a bug. > > >> *) The test should probably follow the same randomized testing pattern >> as other tests: >> >> for (int i = 0; i < N; i++) { >> int x = rnd.nextInt(); >> >> String expected = new StringBuilder(). >> .append(leftpad(Integer.toBinaryString(x), 32)) >> .reverse().toString(); >> >> String actual = >> leftpad(Integer.toBinaryString(Integer.reverse(x)), 32); >> >> if (!expected.equals(actual)) { >> throw new RuntimeException("reverse: \n" + >> expected + " \n" + actual); >> } >> >> // That's how development looks like in 2016. >> private static String leftpad(String s, int width) { >> String r = s; >> for (int c = 0; c < width - s.length(); c++) { >> r = "0" + r; >> } >> return r; >> } >> >> ...and should probably precede any other test that uses reverse(). >> > > Seems reasonable. > > Jaroslav, do you mind improving the test as per Aleksey's > suggestions? > > Thanks! > > /Claes > -------------- next part -------------- diff -r 2bf84670f079 src/java.base/share/classes/java/lang/Integer.java --- a/src/java.base/share/classes/java/lang/Integer.java Sat Apr 30 16:08:48 2016 -0700 +++ b/src/java.base/share/classes/java/lang/Integer.java Mon May 02 22:09:54 2016 +0200 @@ -1790,9 +1790,8 @@ i = (i & 0x55555555) << 1 | (i >>> 1) & 0x55555555; i = (i & 0x33333333) << 2 | (i >>> 2) & 0x33333333; i = (i & 0x0f0f0f0f) << 4 | (i >>> 4) & 0x0f0f0f0f; - i = (i << 24) | ((i & 0xff00) << 8) | - ((i >>> 8) & 0xff00) | (i >>> 24); - return i; + + return reverseBytes(i); } /** @@ -1820,10 +1819,10 @@ */ @HotSpotIntrinsicCandidate public static int reverseBytes(int i) { - return ((i >>> 24) ) | - ((i >> 8) & 0xFF00) | - ((i << 8) & 0xFF0000) | - ((i << 24)); + return (i << 24) | + ((i & 0xff00) << 8) | + ((i >>> 8) & 0xff00) | + (i >>> 24); } /** diff -r 2bf84670f079 src/java.base/share/classes/java/lang/Long.java --- a/src/java.base/share/classes/java/lang/Long.java Sat Apr 30 16:08:48 2016 -0700 +++ b/src/java.base/share/classes/java/lang/Long.java Mon May 02 22:09:54 2016 +0200 @@ -1952,10 +1952,8 @@ i = (i & 0x5555555555555555L) << 1 | (i >>> 1) & 0x5555555555555555L; i = (i & 0x3333333333333333L) << 2 | (i >>> 2) & 0x3333333333333333L; i = (i & 0x0f0f0f0f0f0f0f0fL) << 4 | (i >>> 4) & 0x0f0f0f0f0f0f0f0fL; - i = (i & 0x00ff00ff00ff00ffL) << 8 | (i >>> 8) & 0x00ff00ff00ff00ffL; - i = (i << 48) | ((i & 0xffff0000L) << 16) | - ((i >>> 16) & 0xffff0000L) | (i >>> 48); - return i; + + return reverseBytes(i); } /** diff -r 2bf84670f079 test/java/lang/Integer/BitTwiddle.java --- a/test/java/lang/Integer/BitTwiddle.java Sat Apr 30 16:08:48 2016 -0700 +++ b/test/java/lang/Integer/BitTwiddle.java Mon May 02 22:09:54 2016 +0200 @@ -58,6 +58,21 @@ for (int i = 0; i < N; i++) { int x = rnd.nextInt(); + + String expected = new StringBuilder() + .append(leftpad(toBinaryString(x), 32)) + .reverse().toString(); + + String actual = leftpad(toBinaryString(reverse(x)), 32); + + if (!expected.equals(actual)) { + throw new RuntimeException("reverse: \n" + + expected + " \n" + actual); + } + } + + for (int i = 0; i < N; i++) { + int x = rnd.nextInt(); if (highestOneBit(x) != reverse(lowestOneBit(reverse(x)))) throw new RuntimeException("g: " + toHexString(x)); } @@ -136,4 +151,12 @@ throw new RuntimeException("z: " + toHexString(x)); } } + + private static String leftpad(String s, int width) { + String r = s; + for (int c = 0; c < width - s.length(); c++) { + r = "0" + r; + } + return r; + } } diff -r 2bf84670f079 test/java/lang/Long/BitTwiddle.java --- a/test/java/lang/Long/BitTwiddle.java Sat Apr 30 16:08:48 2016 -0700 +++ b/test/java/lang/Long/BitTwiddle.java Mon May 02 22:09:54 2016 +0200 @@ -58,6 +58,21 @@ for (int i = 0; i < N; i++) { long x = rnd.nextLong(); + + String expected = new StringBuilder() + .append(leftpad(toBinaryString(x), 64)) + .reverse().toString(); + + String actual = leftpad(toBinaryString(reverse(x)), 64); + + if (!expected.equals(actual)) { + throw new RuntimeException("reverse: \n" + + expected + " \n" + actual); + } + } + + for (int i = 0; i < N; i++) { + long x = rnd.nextLong(); if (highestOneBit(x) != reverse(lowestOneBit(reverse(x)))) throw new RuntimeException("g: " + toHexString(x)); } @@ -136,4 +151,12 @@ throw new RuntimeException("z: " + toHexString(x)); } } + + private static String leftpad(String s, int width) { + String r = s; + for (int c = 0; c < width - s.length(); c++) { + r = "0" + r; + } + return r; + } } From Roger.Riggs at Oracle.com Mon May 2 21:13:01 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 2 May 2016 17:13:01 -0400 Subject: RFR:JDK-8079628:java.time: DateTimeFormatter containing "DD" fails on 3-digit day-of-year value In-Reply-To: <572250A2.8030709@oracle.com> References: <571F558F.9090008@oracle.com> <57220BCA.5000608@oracle.com> <572250A2.8030709@oracle.com> Message-ID: <8b789366-7479-383c-00ad-8b70adcb9b59@Oracle.com> Hi Nadeesh, src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 1835: the appendValue(field) method has a sign-style of NORMAL; should that be NOT_NEGATIVE? test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java: What is being tested in test_dayOfYearFieldPattern? It does not check that the value parsed matches the input. test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java 686, 688: should these cases show with sign-style NOT_NEGATIVE also? Thanks, Roger On 4/28/2016 2:04 PM, nadeesh tv wrote: > Hi all, > > Please see the updated webrev > http://cr.openjdk.java.net/~ntv/8079628/webrev.02/ > > Thanks and Regards, > Nadeesh TV > > On 4/28/2016 8:17 PM, Stephen Colebourne wrote: >> My mistake on the spec for "DD". It should be SignStyle.NOT_NEGATIVE, >> not NORMAL. >> >> I'd like to see a test that checks adjacent value parsing works >> correctly for "DDD". ie. yyyyDDDHHmm should be able to parse into a >> LocalDateTime where the date-time value can be checked against the >> input string. >> >> I think this will be a good fix once complete. >> thanks >> Stephen >> >> On 28 April 2016 at 14:10, nadeesh tv wrote: >>> Hi all, >>> >>> Thanks Stephen for the comments. >>> >>> Please see the updated webrev >>> http://cr.openjdk.java.net/~ntv/8079628/webrev.01/ >>> >>> Regards, >>> Nadeesh TV >>> >>> On 4/26/2016 5:42 PM, Stephen Colebourne wrote: >>>> This change introduces inconsistencies and problems. For example, it >>>> will parse up to 19 digits for "D" but only up to 2 digits for "d". >>>> The following would be better: >>>> >>>> * D 1 appendValue(ChronoField.DAY_OF_YEAR) >>>> * DD 2 appendValue(ChronoField.DAY_OF_YEAR, 2, 3, >>>> SignStyle.NORMAL) >>>> * DDD 3 appendValue(ChronoField.DAY_OF_YEAR, 3) >>>> >>>> This limits the accepted input to 3 digits, which is quite sufficient >>>> here. It is also clearer for the common "D" and "DDD" cases. >>>> >>>> Note that a test case needs to cover adjacent value parsing for >>>> day-of-year. This pattern "yyyyDDD" should be tested and work. With >>>> the webrev changes, it will not work as adjacent value parsing mode >>>> will not be triggered. >>>> >>>> (The change will alter the meaning of "yyyyDD" but no-one should be >>>> using that anyway as it is broken, only working for the first 99 days >>>> of the year.) >>>> >>>> The code in TCKDateTimeFormatterBuilder needs a blank line after the >>>> new methods. >>>> >>>> Stephen >>>> >>>> >>>> On 26 April 2016 at 12:48, nadeesh tv wrote: >>>>> Hi all, >>>>> >>>>> Please review a fix for >>>>> >>>>> Bug ID - https://bugs.openjdk.java.net/browse/JDK-8079628 >>>>> >>>>> Issue - Pattern 'D' is not implemented as intended by CLDR >>>>> >>>>> Solution - Changed the definition of 'D' to D..D 1..3 >>>>> appendValue(ChronoField.DAY_OF_YEAR, n, 19, SignStyle.NORMAL) >>>>> >>>>> Webrev - http://cr.openjdk.java.net/~ntv/8079628/webrev.00/ >>>>> >>>>> -- >>>>> Thanks and Regards, >>>>> Nadeesh TV >>>>> >>> -- >>> Thanks and Regards, >>> Nadeesh TV >>> > From mandy.chung at oracle.com Mon May 2 21:31:14 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 2 May 2016 14:31:14 -0700 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: References: Message-ID: <6DA4027B-523F-416A-AD26-78A5B04DA870@oracle.com> > On May 2, 2016, at 1:03 PM, Alexandre (Shura) Iline wrote: > > Hi, > > Can you please take a look on: > http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/ > ? Looks okay to me. Mandy From steve.drach at oracle.com Mon May 2 21:48:29 2016 From: steve.drach at oracle.com (Steve Drach) Date: Mon, 2 May 2016 14:48:29 -0700 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: References: Message-ID: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> Looks fine to me, although I am not an official reviewer. Thanks for doing this. > On May 2, 2016, at 1:03 PM, Alexandre (Shura) Iline wrote: > > Hi, > > Can you please take a look on: > http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/ > ? > > Thank you > > Shura > From Paul.Sandoz at oracle.com Mon May 2 22:18:06 2016 From: Paul.Sandoz at oracle.com (Paul Sandoz) Date: Mon, 2 May 2016 15:18:06 -0700 Subject: RFR 8155258: VarHandle implementation improvements Message-ID: <43CCC631-B8BA-40BF-A292-7F1ED00FDCDD@oracle.com> Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-jdk/webrev/ http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-hotspot/webrev/ The hotspot changes are really small. Is there is precedent in such cases to push through jdk9-dev rather than hs, thus speeding up the integration? There are a bunch of improvements (mostly space/time): 1) By default a VarHandle does not hold its method types for access mode methods. Instead the erased types are held on VarForm (this shared across many VH instances) and are leveraged by the guard methods (see 4). 1.1) The non-erased method types are created on demand and cached (see 3). 2) Remove the use of ClassValue to hold VarForm instances. Each VarHandle implement holds its VarForm as a static instance. MemberNames to each access mode method implementation are still calculated on construction (this can be revisited to be lazy as a further issue). 3) A VarHandle caches invoker-based MethodHandles (access mode method type prefixed with VarHandle as the first parameter) to the corresponding MemberNames held on VarForm. Such handles are used by the VarHandle.toMethodHandle, by the guard methods (see 4), or general linkers/invokers. 4) The guard methods (on VarHandleGuards) were revamped to: 4.1) leverage the erased types in 1) 4.2) optimize for the void calling case (dropping the return value) when linking to a non-void access mode method. This is an edge case but avoids surprises (e.g. dropping the return value of a CompareAndExchange). This leverages a little known fact of invokehandle linking where it is safe to drop the return value (John assures me this is safe!), and required a slight tweak to hotspot for verification under fastdebug execution. 4.3) leverage the cached invoker method handle in 3) for the case where boxing/conversion is required, with an asType transformation. This is the non-optimal path, but is much better than before since the invoker method handle is a constant. JPRT core and hotspot tests pass. Paul. From Paul.Sandoz at oracle.com Mon May 2 22:37:36 2016 From: Paul.Sandoz at oracle.com (Paul Sandoz) Date: Mon, 2 May 2016 15:37:36 -0700 Subject: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package Message-ID: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-jdk/webrev/ http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-hotspot/webrev/ This patch is based on that for 8155258 (VarHandle impl improvements) [1] sent previously. The hotspot changes are really small. Likewise for the 8155258 changes is there is precedent in such cases to push through jdk9-dev rather than hs? CCC reviewers strongly indicated for the advanced methods that can customise the exceptions: "You aren't gonna need it?. For expediency I propose to move such methods to an internal class jdk.internal.util.Preconditions. I would still like to sweep through java.base and leverage these methods while preserving exception reporting where possible. The hotspot changes are just for renaming of the intrinsic method signatures. Since the intrinsic method is now internal i have added an @ForceInline on the corresponding public method, given the potential for this to be used in performance sensitive code. JPRT core and hotspot tests pass. Paul. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040740.html From xueming.shen at oracle.com Mon May 2 23:28:21 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 02 May 2016 16:28:21 -0700 Subject: RFR: JDK-8150496,(zipfs) Fix performance issues in zip-fs Message-ID: <5727E295.1000303@oracle.com> Hi, Please help review the performance cleanup for zipfs issue: https://bugs.openjdk.java.net/browse/JDK-8150496 webrev: http://cr.openjdk.java.net/~sherman/8150496/webrev This is a cleanup update to improve the performance of most frequent used access methods and the internal memory usage. While there is definitely more places to investigate, it seems it is worth putting the current version in with the performance improvement achieved. Here are the result of the sample benchmark that measures the improvement. http://cr.openjdk.java.net/~sherman/8150496/MyBenchmark.java ---------------------------------------new--------------------------------------- Benchmark Mode Cnt Score Error Units MyBenchmark.ZFS_Exists avgt 25 4.380 ? 0.745 ms/op MyBenchmark.ZFS_GetPath avgt 25 11.722 ? 0.606 ms/op MyBenchmark.ZFS_GetPathExists avgt 25 21.031 ? 2.554 ms/op MyBenchmark.ZFS_GetPathIsDirectory avgt 25 26.823 ? 4.522 ms/op MyBenchmark.ZFS_GetPathIsRegularFile avgt 25 26.049 ? 3.441 ms/op MyBenchmark.ZFS_GetPathNewInputStream avgt 25 31.945 ? 3.330 ms/op MyBenchmark.ZFS_GetPathToRealPath avgt 25 21.375 ? 2.875 ms/op MyBenchmark.ZFS_IsDirectory avgt 25 9.309 ? 0.633 ms/op MyBenchmark.ZFS_IsRegularFile avgt 25 9.454 ? 0.928 ms/op MyBenchmark.ZFS_Itr avgt 25 18.583 ? 0.841 ms/op MyBenchmark.ZFS_Open avgt 25 1527.769 ? 221.997 ms/op MyBenchmark.ZFS_ToRealPath avgt 25 4.666 ? 0.584 ms/op MyBenchmark.ZFS_newInputStream avgt 25 14.864 ? 0.618 ms/op ----------------------------------------old--------------------------------------- Benchmark Mode Cnt Score Error Units MyBenchmark.ZFS_Exists avgt 25 10.229 ? 1.236 ms/op MyBenchmark.ZFS_GetPath avgt 25 12.964 ? 2.739 ms/op MyBenchmark.ZFS_GetPathExists avgt 25 28.095 ? 3.595 ms/op MyBenchmark.ZFS_GetPathIsDirectory avgt 25 28.566 ? 1.430 ms/op MyBenchmark.ZFS_GetPathIsRegularFile avgt 25 29.102 ? 3.308 ms/op MyBenchmark.ZFS_GetPathNewInputStream avgt 25 151.271 ? 3.311 ms/op MyBenchmark.ZFS_GetPathToRealPath avgt 25 42.717 ? 6.112 ms/op MyBenchmark.ZFS_IsDirectory avgt 25 10.884 ? 0.810 ms/op MyBenchmark.ZFS_IsRegularFile avgt 25 11.801 ? 1.053 ms/op MyBenchmark.ZFS_Itr avgt 25 21.498 ? 1.165 ms/op MyBenchmark.ZFS_Open avgt 25 1673.597 ? 190.083 ms/op MyBenchmark.ZFS_ToRealPath avgt 25 19.266 ? 0.886 ms/op MyBenchmark.ZFS_newInputStream avgt 25 125.307 ? 2.818 ms/op Thanks, Sherman From nadeesh.tv at oracle.com Tue May 3 07:24:48 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Tue, 03 May 2016 12:54:48 +0530 Subject: RFR:JDK-8079628:java.time: DateTimeFormatter containing "DD" fails on 3-digit day-of-year value In-Reply-To: <8b789366-7479-383c-00ad-8b70adcb9b59@Oracle.com> References: <571F558F.9090008@oracle.com> <57220BCA.5000608@oracle.com> <572250A2.8030709@oracle.com> <8b789366-7479-383c-00ad-8b70adcb9b59@Oracle.com> Message-ID: <57285240.5060004@oracle.com> Hi Roger, Please see the answers inline On 5/3/2016 2:43 AM, Roger Riggs wrote: > > Hi Nadeesh, > > src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java > > line 1835: the appendValue(field) method has a sign-style of NORMAL; > should that be NOT_NEGATIVE? > It's 'NOT_NEGATIVE' only. May be a browser caching issue. Can you please check it once again. > > test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java: > > What is being tested in test_dayOfYearFieldPattern? > It does not check that the value parsed matches the input. > These test cases added initially. Now it's become almost redundant due to 'dayOfYearFieldValues' . I could remove it. > > > test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java > > 686, 688: should these cases show with sign-style NOT_NEGATIVE also? > Suspecting browser caching here also. Updated the webrev by removing some unnecessary spaces http://cr.openjdk.java.net/~ntv/8079628/webrev.03/ Regards, Nadeesh TV > > Thanks, Roger > > > > On 4/28/2016 2:04 PM, nadeesh tv wrote: >> Hi all, >> >> Please see the updated webrev >> http://cr.openjdk.java.net/~ntv/8079628/webrev.02/ >> >> Thanks and Regards, >> Nadeesh TV >> >> On 4/28/2016 8:17 PM, Stephen Colebourne wrote: >>> My mistake on the spec for "DD". It should be SignStyle.NOT_NEGATIVE, >>> not NORMAL. >>> >>> I'd like to see a test that checks adjacent value parsing works >>> correctly for "DDD". ie. yyyyDDDHHmm should be able to parse into a >>> LocalDateTime where the date-time value can be checked against the >>> input string. >>> >>> I think this will be a good fix once complete. >>> thanks >>> Stephen >>> >>> On 28 April 2016 at 14:10, nadeesh tv wrote: >>>> Hi all, >>>> >>>> Thanks Stephen for the comments. >>>> >>>> Please see the updated webrev >>>> http://cr.openjdk.java.net/~ntv/8079628/webrev.01/ >>>> >>>> Regards, >>>> Nadeesh TV >>>> >>>> On 4/26/2016 5:42 PM, Stephen Colebourne wrote: >>>>> This change introduces inconsistencies and problems. For example, it >>>>> will parse up to 19 digits for "D" but only up to 2 digits for "d". >>>>> The following would be better: >>>>> >>>>> * D 1 appendValue(ChronoField.DAY_OF_YEAR) >>>>> * DD 2 appendValue(ChronoField.DAY_OF_YEAR, 2, 3, >>>>> SignStyle.NORMAL) >>>>> * DDD 3 appendValue(ChronoField.DAY_OF_YEAR, 3) >>>>> >>>>> This limits the accepted input to 3 digits, which is quite sufficient >>>>> here. It is also clearer for the common "D" and "DDD" cases. >>>>> >>>>> Note that a test case needs to cover adjacent value parsing for >>>>> day-of-year. This pattern "yyyyDDD" should be tested and work. With >>>>> the webrev changes, it will not work as adjacent value parsing mode >>>>> will not be triggered. >>>>> >>>>> (The change will alter the meaning of "yyyyDD" but no-one should be >>>>> using that anyway as it is broken, only working for the first 99 days >>>>> of the year.) >>>>> >>>>> The code in TCKDateTimeFormatterBuilder needs a blank line after the >>>>> new methods. >>>>> >>>>> Stephen >>>>> >>>>> >>>>> On 26 April 2016 at 12:48, nadeesh tv wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review a fix for >>>>>> >>>>>> Bug ID - https://bugs.openjdk.java.net/browse/JDK-8079628 >>>>>> >>>>>> Issue - Pattern 'D' is not implemented as intended by CLDR >>>>>> >>>>>> Solution - Changed the definition of 'D' to D..D 1..3 >>>>>> appendValue(ChronoField.DAY_OF_YEAR, n, 19, SignStyle.NORMAL) >>>>>> >>>>>> Webrev - http://cr.openjdk.java.net/~ntv/8079628/webrev.00/ >>>>>> >>>>>> -- >>>>>> Thanks and Regards, >>>>>> Nadeesh TV >>>>>> >>>> -- >>>> Thanks and Regards, >>>> Nadeesh TV >>>> >> > -- Thanks and Regards, Nadeesh TV From frank.yuan at oracle.com Tue May 3 09:37:54 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Tue, 3 May 2016 17:37:54 +0800 Subject: RFR: 8155600: jaxp.library.TestPolicy should extend the default security policy In-Reply-To: <07BE02D4-5911-4C8A-A1E9-030698DFD7FE@oracle.com> References: <06b201d1a125$9d5af1e0$d810d5a0$@oracle.com> <07BE02D4-5911-4C8A-A1E9-030698DFD7FE@oracle.com> Message-ID: <095301d1a51f$7cd2bd10$76783730$@oracle.com> Hi Mandy and Joe I have re-fixed the bug with your comment, would you like to check again? http://cr.openjdk.java.net/~fyuan/8155514/webrev.01/ Thanks, Frank > -----Original Message----- > From: Mandy Chung [mailto:mandy.chung at oracle.com] > Sent: Friday, April 29, 2016 4:00 AM > To: Frank Yuan > Cc: core-libs-dev ; huizhe wang ; Xueming Shen > > Subject: Re: RFR: 8155600: jaxp.library.TestPolicy should extend the default security policy > > Hi Frank, > > The fix looks fine. > > Thanks for verifying it with my patch to deprivilege jdk.charasets. > > Mandy > > > On Apr 28, 2016, at 1:11 AM, Frank Yuan wrote: > > > > Hi Mandy, Joe and all > > > > Would you like to review the fix for bug > > https://bugs.openjdk.java.net/browse/JDK-8155514? > > > > The webrev is at: http://cr.openjdk.java.net/~fyuan/8155514/webrev.00/. > > > > > > Thanks, > > > > Frank From chris.hegarty at oracle.com Tue May 3 10:14:50 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 3 May 2016 11:14:50 +0100 Subject: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package In-Reply-To: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> References: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> Message-ID: On 2 May 2016, at 23:37, Paul Sandoz wrote: > Hi, > > Please review: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-hotspot/webrev/ The changes look fine to me Paul. -Chris. > This patch is based on that for 8155258 (VarHandle impl improvements) [1] sent previously. > > The hotspot changes are really small. Likewise for the 8155258 changes is there is precedent in such cases to push through jdk9-dev rather than hs? > > CCC reviewers strongly indicated for the advanced methods that can customise the exceptions: "You aren't gonna need it?. > > For expediency I propose to move such methods to an internal class jdk.internal.util.Preconditions. I would still like to sweep through java.base and leverage these methods while preserving exception reporting where possible. > > The hotspot changes are just for renaming of the intrinsic method signatures. Since the intrinsic method is now internal i have added an @ForceInline on the corresponding public method, given the potential for this to be used in performance sensitive code. > > > JPRT core and hotspot tests pass. > > Paul. > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040740.html From daniel.fuchs at oracle.com Tue May 3 10:36:13 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 3 May 2016 12:36:13 +0200 Subject: RFR (JAXP) 8152912: SAX XMLReaderFactory needs to be ServiceLoader compliant In-Reply-To: <57279CDE.7070207@oracle.com> References: <57279CDE.7070207@oracle.com> Message-ID: <6ed137e8-2651-7f6f-50b9-143b00286355@oracle.com> Hi Joe, This look good but the implementation might be overly complex, which makes it difficult to read. First: 141 ClassLoader cl = ss.getContextClassLoader(); is misnamed, because as far as I can see this method returns the context class loader if not null, otherwise the system class loader. So cl is either the context class loader or the system class loader and is guaranteed to be non null. I would suggest adding a comment to make it clear. This means in turn that the new jarLookup(ClassLoader) method can be greatly simplified - you can do: final ClassLoader cl = Objects.requiresNonNull(loader); and then simplify the if (cl != null) else ... logic, because you now know that cl cannot be null. Best regards, -- daniel On 02/05/16 20:30, huizhe wang wrote: > Hi, > > Please review a change that adds a step using the ServiceLoader to > XMLReaderFactory's provider-lookup process. Meanwhile, XMLReaderFactory > is deprecated in favor of javax.xml.parsers.SAXParserFactory. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8152912 > Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8152912/webrev/ > > The change has been verified by SQE test that Frank will submit soon for > review (that is, when he starts to work at his local time). > > Thanks, > Joe From aleksey.shipilev at oracle.com Tue May 3 12:39:00 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 3 May 2016 15:39:00 +0300 Subject: RFR: JDK-8150496,(zipfs) Fix performance issues in zip-fs In-Reply-To: <5727E295.1000303@oracle.com> References: <5727E295.1000303@oracle.com> Message-ID: <57289BE4.1040605@oracle.com> Hi Sherman, On 05/03/2016 02:28 AM, Xueming Shen wrote: > Please help review the performance cleanup for zipfs > > issue: https://bugs.openjdk.java.net/browse/JDK-8150496 > webrev: http://cr.openjdk.java.net/~sherman/8150496/webrev ZipFileSystem.java: *) These should be removed? 2032 //writeShort(os, name.length); 2033 writeShort(os, nlen); 2220 //writeShort(os, name.length); 2221 writeShort(os, nlen); 2591 //inodes.forEach( (k,v) -> { System.out.printf(" %s -> %s%n", new String(k.name), new String(v.name)); }); 1080 /* 1081 byte[] name = Arrays.copyOfRange(cen, pos + CENHDR, pos + CENHDR + nlen); 1082 */ *) There is ever-so-subtle difference in doing either: 171 byte[] tmp = new byte[path.length + 1]; 172 System.arraycopy(path, 0, tmp, 1, path.length); 173 tmp[0] = '/'; ...or: 1083 byte[] name = new byte[nlen + 1]; 1084 name[0] = '/'; 1085 System.arraycopy(cen, pos + CENHDR, name, 1, nlen); Excess op between allocation and arraycopy breaks zeroing elimination, see e.g.: http://cr.openjdk.java.net/~shade/scratch/ZeroingFirstBench.java *) Missing braces: 1483 if (e2 == null) 1484 throw new ZipException("invalid loc for entry <" + e.name + ">"); *) Probably deserves a comment why these are commented out? Are these implied to be zeroes? 1713 // int disknum; 1714 // int sdisknum; > Here are the result of the sample benchmark that measures the improvement. > http://cr.openjdk.java.net/~sherman/8150496/MyBenchmark.java This benchmark is not very reliable: *) Sink everything in Blackhole. I.e. instead of, say: @Benchmark public void ZFS_Open() throws IOException { cnt = 0; for (int i = 0; i < 100; i++) { try (FileSystem fs = newFileSystem(path)) { if (Files.exists(fs.getPath(entriesS.get(0)))) cnt++; } } } do: @Benchmark public void ZFS_Open(Blackhole bh) throws IOException { for (int i = 0; i < 100; i++) { try (FileSystem fs = newFileSystem(path)) { bh.consume(fs.getPath(entriesS.get(0))); } } } This applies to all other methods. Thanks, -Aleksey From aleksey.shipilev at oracle.com Tue May 3 12:47:14 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 3 May 2016 15:47:14 +0300 Subject: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package In-Reply-To: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> References: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> Message-ID: <57289DD2.4020404@oracle.com> On 05/03/2016 01:37 AM, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-hotspot/webrev/ Both JDK and HS changes look good to me. It's somewhat painful we need to hide these, but okay, let's do it. Thanks, -Aleksey From fguillaume at nuxeo.com Tue May 3 12:58:07 2016 From: fguillaume at nuxeo.com (Florent Guillaume) Date: Tue, 3 May 2016 14:58:07 +0200 Subject: RFR 8147984: WindowsTerminal should support function keys In-Reply-To: <8e47a023-b313-d40e-7ed7-c91428f2d700@oracle.com> References: <56A21578.5080105@oracle.com> <5726F9E0.4000801@oracle.com> <8e47a023-b313-d40e-7ed7-c91428f2d700@oracle.com> Message-ID: Hi, http://www.x.org/docs/xterm/ctlseqs.pdf is probably a more canonical reference. Florent On Mon, May 2, 2016 at 8:31 PM, Stuart Marks wrote: > Hi Jan, > > Thanks for the update. Including the link is fine, but I'm a bit suspicious > of the durability of that website -- it appears to be the personal website > of the current maintainer. Who knows if it'll be around in a couple years. > > I'd suggest including in the comment the official title of the document, > "XTerm Control Sequences" along with a mention of the authors (Moy, Gildea, > Dickey) so that if the link were to go bad, it would be possible to do a web > search to find some version of the document. > > No need for an updated webrev. > > Thanks, > > s'marks > > > On 5/1/16 11:55 PM, Jan Lahoda wrote: >> >> Hi Stuart, >> >> Thanks for the comments and the link! >> >> A webrev which includes the link is here: >> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.01/ >> >> Delta webrev to the last iteration is here: >> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.01/delta/webrev >> >> Thanks, >> Jan >> >> On 29.4.2016 23:49, Stuart Marks wrote: >>> >>> Hi Jan, >>> >>> I finally got a chance to take a look at this. The change looks fine. >>> >>> It would be nice to have a reference to where the escape sequences are >>> documented. There are links to the Windows VK_ codes there, which is >>> great. But there's no reference for the escape sequences that each >>> keypress is mapped to, e.g. F4 is "ESC O S", and F5 is "ESC [ 1 5 ~" >>> (and what happened to "ESC [ 1 6 ~"??) >>> >>> I did some searching, and it seems really hard to find a definitive >>> reference. Perhaps the best reference is "XTerm Control Sequences" [1] >>> which seems to document xterm pretty thoroughly, which is what everybody >>> seems to follow nowadays. It even looks like it's being kept up to date >>> (last modified 2016-02-21). >>> >>> Anyway I'd suggest adding a comment with a reference to this document. >>> >>> As a cross-check, these sequences match what my Mac's Terminal.app >>> emits, at least for unshifted F1-F12. (The Terminal app was probably >>> copied from xterm.) >>> >>> Thanks, >>> >>> s'marks >>> >>> >>> [1] http://invisible-island.net/xterm/ctlseqs/ctlseqs.html >>> >>> >>> On 1/22/16 3:41 AM, Jan Lahoda wrote: >>>> >>>> Hello, >>>> >>>> I'd like to enhance the WindowsTerminal in jdk.internal.le with >>>> function keys >>>> handling. The intent is so that jshell can bind actions for shortcuts >>>> including >>>> function keys. >>>> >>>> The patch for adding the function keys support is here: >>>> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.00/ >>>> >>>> An example of a feature that uses/may use this support is here: >>>> >>>> http://mail.openjdk.java.net/pipermail/kulla-dev/2016-January/001226.html >>>> >>>> Any comments are welcome! >>>> >>>> Thanks, >>>> Jan -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87 From aleksey.shipilev at oracle.com Tue May 3 13:11:36 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 3 May 2016 16:11:36 +0300 Subject: RFR 8155258: VarHandle implementation improvements In-Reply-To: <43CCC631-B8BA-40BF-A292-7F1ED00FDCDD@oracle.com> References: <43CCC631-B8BA-40BF-A292-7F1ED00FDCDD@oracle.com> Message-ID: <5728A388.6050505@oracle.com> On 05/03/2016 01:18 AM, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-hotspot/webrev/ I remember testing this before, so it definitely helps performance in pathological use cases for CompareAndExchange. MethodHandleNatives: *) Not sure I "dig" the change here (apart from old code apparently blows the capacity estimate): 469 static String getVarHandleMethodSignature(MethodType mt) { 470 char[] sig = new char[mt.parameterCount() + 2]; 471 472 int i = 0; 473 for (; i < mt.parameterCount(); i++) { 474 sig[i] = getCharType(mt.parameterType(i)); 475 } 476 sig[i] = '_'; 477 sig[i + 1] = getCharType(mt.returnType()); 478 479 return String.valueOf(sig); With Compact Strings, it's beneficial to use StringBuilder instead of char[], because StringBuilder will concat in Latin1 form. char[] code would need to re-compress to byte[] during String.valueOf(). MethodType: *) Only imports are changed. Revert? Otherwise next runner up would change the imports back, ad nauseam. X-VarHandle.java.template: *) There's compareAndExchangeVolatile_V, but there is no compareAndExchange{Acquire,Release}_V, etc. Shouldn't we have the "void" entries for every method that returns a value? Or, compareAndExchangeVolatile_V is redundant, and does not participate the new mechanics? Thanks, -Aleksey From adinn at redhat.com Tue May 3 13:29:16 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 3 May 2016 14:29:16 +0100 Subject: RFR: 8152084: Introduction of ssliop protocol to corbaloc In-Reply-To: <321794846.38762864.1461088691787.JavaMail.zimbra@redhat.com> References: <321794846.38762864.1461088691787.JavaMail.zimbra@redhat.com> Message-ID: <5728A7AC.8000103@redhat.com> On 19/04/16 18:58, Tomasz Adamski wrote: > Hello All, > > I would like to propose an extension to corbaloc resolution - the > ssliop protocol. IORs created from corbaloc url with ssliop protocol > will contain SSL tagged component with indication that secured > invocation is required. As a result, connection to the resolved > object will have to be secured. > > I'm attaching a webrev of proposed enhancement: > http://cr.openjdk.java.net/~adinn/tomaszadamski/8152084/ > > Regards, Tomek Would someone care to comment on this enhancement which was proposed 2 weeks ago and has had no response? At the very least can someone confirm whether this is the right list for such discussion? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Alan.Bateman at oracle.com Tue May 3 14:02:30 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 May 2016 15:02:30 +0100 Subject: RFR: 8152084: Introduction of ssliop protocol to corbaloc In-Reply-To: <5728A7AC.8000103@redhat.com> References: <321794846.38762864.1461088691787.JavaMail.zimbra@redhat.com> <5728A7AC.8000103@redhat.com> Message-ID: <5728AF76.9020406@oracle.com> On 03/05/2016 14:29, Andrew Dinn wrote: > > On 19/04/16 18:58, Tomasz Adamski wrote: >> Hello All, >> >> I would like to propose an extension to corbaloc resolution - the >> ssliop protocol. IORs created from corbaloc url with ssliop protocol >> will contain SSL tagged component with indication that secured >> invocation is required. As a result, connection to the resolved >> object will have to be secured. >> >> I'm attaching a webrev of proposed enhancement: >> http://cr.openjdk.java.net/~adinn/tomaszadamski/8152084/ >> >> Regards, Tomek > Would someone care to comment on this enhancement which was proposed 2 > weeks ago and has had no response? At the very least can someone confirm > whether this is the right list for such discussion? > There isn't a specific list for CORBA here so using core-libs-dev should be fine. In general then CORBA is legacy so it somewhat surprising to look at rev'ing the API in the JDK now. I think it is >12 years since there has been any updates. Do you, or Tomek, have any references to the OMG specs for the proposal? -Alan. From forax at univ-mlv.fr Tue May 3 14:05:20 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 3 May 2016 16:05:20 +0200 (CEST) Subject: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package In-Reply-To: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> References: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> Message-ID: <1314424116.988033.1462284320182.JavaMail.zimbra@u-pem.fr> Looks good to me. minor nitpick, neither checkFromToIndex() nor checkFromIndexSize() are instrinsic (now !) but i think they also should be annotated with @ForceInline in j.u.Objects to avoid the code to be asymmetric or weird if one of these methods is intrinsinfied later. R?mi ----- Mail original ----- > De: "Paul Sandoz" > ?: "Core-Libs-Dev" , "hotspot-dev developers" > Envoy?: Mardi 3 Mai 2016 00:37:36 > Objet: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package > > Hi, > > Please review: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-hotspot/webrev/ > > This patch is based on that for 8155258 (VarHandle impl improvements) [1] > sent previously. > > The hotspot changes are really small. Likewise for the 8155258 changes is > there is precedent in such cases to push through jdk9-dev rather than hs? > > CCC reviewers strongly indicated for the advanced methods that can customise > the exceptions: "You aren't gonna need it?. > > For expediency I propose to move such methods to an internal class > jdk.internal.util.Preconditions. I would still like to sweep through > java.base and leverage these methods while preserving exception reporting > where possible. > > The hotspot changes are just for renaming of the intrinsic method signatures. > Since the intrinsic method is now internal i have added an @ForceInline on > the corresponding public method, given the potential for this to be used in > performance sensitive code. > > > JPRT core and hotspot tests pass. > > Paul. > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040740.html > > From Roger.Riggs at Oracle.com Tue May 3 14:22:04 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 3 May 2016 10:22:04 -0400 Subject: RFR:JDK-8079628:java.time: DateTimeFormatter containing "DD" fails on 3-digit day-of-year value In-Reply-To: <57285240.5060004@oracle.com> References: <571F558F.9090008@oracle.com> <57220BCA.5000608@oracle.com> <572250A2.8030709@oracle.com> <8b789366-7479-383c-00ad-8b70adcb9b59@Oracle.com> <57285240.5060004@oracle.com> Message-ID: <1f89d623-e7af-61ae-821c-658be59a3f77@Oracle.com> Hi Nadeesh, On 5/3/2016 3:24 AM, nadeesh tv wrote: > Hi Roger, > Please see the answers inline > > On 5/3/2016 2:43 AM, Roger Riggs wrote: >> >> Hi Nadeesh, >> >> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java >> >> line 1835: the appendValue(field) method has a sign-style of NORMAL; >> should that be NOT_NEGATIVE? >> > It's 'NOT_NEGATIVE' only. May be a browser caching issue. Can you > please check it once again. My question was about the existing case for "D" that uses appendValue(field). That is a shorthand for: appendValue(new NumberPrinterParser(field, 1, 19, SignStyle.NORMAL)); >> >> test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java: >> >> What is being tested in test_dayOfYearFieldPattern? >> It does not check that the value parsed matches the input. >> > These test cases added initially. Now it's become almost redundant due > to 'dayOfYearFieldValues' . I could remove it. If they are redundant, they should be removed. >> >> >> test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java >> >> 686, 688: should these cases show with sign-style NOT_NEGATIVE also? >> > Suspecting browser caching here also. I'm referring to the test case for "D", which seems like it should show up as NOT_NEGATIVE. > > Updated the webrev by removing some unnecessary spaces > http://cr.openjdk.java.net/~ntv/8079628/webrev.03/ Thanks, Roger From Roger.Riggs at Oracle.com Tue May 3 14:37:40 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 3 May 2016 10:37:40 -0400 Subject: RFR:JDK-8148949:DateTimeFormatter pattern letters 'A','n','N' In-Reply-To: <57226CD7.1060907@oracle.com> References: <571E2C01.6050407@oracle.com> <57220C52.5030609@oracle.com> <57226CD7.1060907@oracle.com> Message-ID: Hi Nadeesh, src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder:1522-1524 Is the switch from SignStyle.NOT_NEGATIVE to NORMAL intentional? The ValueRange of MilliOfDay for example is (0, 86400000-1), so negative values would be out of range. Similarly, NanoOfSecond and NanoOfDay are non-negative. (Otherwise, there should be test cases for negative values). Thanks, Roger On 4/28/2016 4:04 PM, nadeesh tv wrote: > Hi all, > Thanks Stephen for the comments. > Please see the updated webrev > http://cr.openjdk.java.net/~ntv/8148949/webrev.02/ > > Regards, > Nadeesh > > > On 4/28/2016 7:58 PM, Stephen Colebourne wrote: >> I'd like to see the test cases in test_secondsPattern() check the >> result of the parse (by passing more arguments from >> data_secondsPattern) >> >> Otherwise looks good. >> Stephen >> >> On 28 April 2016 at 14:12, nadeesh tv wrote: >>> Hi all, >>> Please see the updated webrev >>> http://cr.openjdk.java.net/~ntv/8148949/webrev.01/ >>> >>> Regards, >>> Nadeesh TV >>> >>> On 4/25/2016 8:08 PM, nadeesh tv wrote: >>>> HI all, >>>> Please review a fix for >>>> Bug ID - https://bugs.openjdk.java.net/browse/JDK-8148949 >>>> >>>> Issue - Pattern letters 'A' does not match the intent of LDML/CLDR >>>> >>>> Solution - Changed the definition of pattern letters 'A','n','N' >>>> >>>> Webrev - http://cr.openjdk.java.net/~ntv/8148949/webrev.00/ >>>> >>>> >>> -- >>> Thanks and Regards, >>> Nadeesh TV >>> > From claes.redestad at oracle.com Tue May 3 14:46:36 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 3 May 2016 16:46:36 +0200 Subject: RFR: 8155939: sun.launcher.LauncherHelper INSTANCE is unused Message-ID: <5728B9CC.1030903@oracle.com> Hi, sun.launcher.LauncherHelper is currently a singleton enum class, but the INSTANCE is never used. With encapsulation in place we shouldn't worry about cleaning this up. jdeps data show no usage of this helper class outside of the JDK. Bug: https://bugs.openjdk.java.net/browse/JDK-8155939 Patch: diff -r 930d3aef37ee src/java.base/share/classes/sun/launcher/LauncherHelper.java --- a/src/java.base/share/classes/sun/launcher/LauncherHelper.java Tue May 03 15:50:54 2016 +0200 +++ b/src/java.base/share/classes/sun/launcher/LauncherHelper.java Tue May 03 16:23:26 2016 +0200 @@ -84,8 +84,10 @@ import jdk.internal.misc.VM; -public enum LauncherHelper { - INSTANCE; +public final class LauncherHelper { + + // No instantiation + private LauncherHelper() {} // used to identify JavaFX applications private static final String JAVAFX_APPLICATION_MARKER = Thanks! /Claes From Roger.Riggs at Oracle.com Tue May 3 14:56:34 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 3 May 2016 10:56:34 -0400 Subject: RFR: 8155939: sun.launcher.LauncherHelper INSTANCE is unused In-Reply-To: <5728B9CC.1030903@oracle.com> References: <5728B9CC.1030903@oracle.com> Message-ID: <6440a002-9311-4c67-380e-f27e38810ba3@Oracle.com> Looks fine, Roger On 5/3/2016 10:46 AM, Claes Redestad wrote: > Hi, > > sun.launcher.LauncherHelper is currently a singleton enum class, but > the INSTANCE is never used. With encapsulation in place we shouldn't > worry about cleaning this up. > > jdeps data show no usage of this helper class outside of the JDK. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8155939 > > Patch: > diff -r 930d3aef37ee > src/java.base/share/classes/sun/launcher/LauncherHelper.java > --- a/src/java.base/share/classes/sun/launcher/LauncherHelper.java Tue > May 03 15:50:54 2016 +0200 > +++ b/src/java.base/share/classes/sun/launcher/LauncherHelper.java Tue > May 03 16:23:26 2016 +0200 > @@ -84,8 +84,10 @@ > import jdk.internal.misc.VM; > > > -public enum LauncherHelper { > - INSTANCE; > +public final class LauncherHelper { > + > + // No instantiation > + private LauncherHelper() {} > > // used to identify JavaFX applications > private static final String JAVAFX_APPLICATION_MARKER = > > Thanks! > > /Claes From Alan.Bateman at oracle.com Tue May 3 14:58:25 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 May 2016 15:58:25 +0100 Subject: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them In-Reply-To: References: <4A20DDA6-0E1F-4AD4-8966-5FC47315CA82@oracle.com> <57237074.6050608@oracle.com> <1F3280AE-A8FF-4F19-87B1-066EB73E6B30@oracle.com> <57239319.1060901@oracle.com> <52BA6F85-48BA-4E63-89BD-56504EEFE68B@oracle.com> <5723C838.3010804@oracle.com> <977D17CB-EE89-43E7-B68A-66CDF768CDB6@oracle.com> <5723D507.7050302@oracle.com> <5E89A276-997C-44E3-B23A-ADA669AF2DF3@oracle.com> <7044D545-58E6-4F6D-B65A-09C19F3D8FBA@oracle.com> <5723F299.1050203@oracle.com> <1F3D7F60-5D0E-4FDD-B253-C05F4619CC4F@oracle.com> <5725B402.7020905@oracle.com> <97506B67-88E6-47A8-A576-188536A7A311@oracle.com> Message-ID: <5728BC91.4040806@oracle.com> On 02/05/2016 17:23, Steve Drach wrote: > Another webrev: http://cr.openjdk.java.net/~sdrach/8151542/webrev.05/index.html > > Only URLClassPath has changed. I put a comment on url.getProtocol indicating the URL assures it?s lower case and I changed the long lines into multiple shorter lines. > > I think this looks okay now. -Alan. From claes.redestad at oracle.com Tue May 3 15:00:00 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 3 May 2016 17:00:00 +0200 Subject: RFR: 8155939: sun.launcher.LauncherHelper INSTANCE is unused In-Reply-To: <6440a002-9311-4c67-380e-f27e38810ba3@Oracle.com> References: <5728B9CC.1030903@oracle.com> <6440a002-9311-4c67-380e-f27e38810ba3@Oracle.com> Message-ID: <5728BCF0.4070902@oracle.com> Thanks Roger! /Claes On 2016-05-03 16:56, Roger Riggs wrote: > Looks fine, Roger > > > On 5/3/2016 10:46 AM, Claes Redestad wrote: >> Hi, >> >> sun.launcher.LauncherHelper is currently a singleton enum class, but >> the INSTANCE is never used. With encapsulation in place we shouldn't >> worry about cleaning this up. >> >> jdeps data show no usage of this helper class outside of the JDK. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8155939 >> >> Patch: >> diff -r 930d3aef37ee >> src/java.base/share/classes/sun/launcher/LauncherHelper.java >> --- a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >> Tue May 03 15:50:54 2016 +0200 >> +++ b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >> Tue May 03 16:23:26 2016 +0200 >> @@ -84,8 +84,10 @@ >> import jdk.internal.misc.VM; >> >> >> -public enum LauncherHelper { >> - INSTANCE; >> +public final class LauncherHelper { >> + >> + // No instantiation >> + private LauncherHelper() {} >> >> // used to identify JavaFX applications >> private static final String JAVAFX_APPLICATION_MARKER = >> >> Thanks! >> >> /Claes > From scolebourne at joda.org Tue May 3 15:07:23 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 3 May 2016 16:07:23 +0100 Subject: RFR:JDK-8148949:DateTimeFormatter pattern letters 'A','n','N' In-Reply-To: References: <571E2C01.6050407@oracle.com> <57220C52.5030609@oracle.com> <57226CD7.1060907@oracle.com> Message-ID: The current behaviour is to use NORMAL for "A" and NOT_NEGATIVE for "AA", "AAA" and so on. The sensible behaviour going forward is to use NOT_NEGATIVE for all these, simply because the values do not make sense to be negative. Given how these fields are nigh-on useless as currently defined, this seems reasonable. Stephen On 3 May 2016 at 15:37, Roger Riggs wrote: > Hi Nadeesh, > > src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder:1522-1524 > > Is the switch from SignStyle.NOT_NEGATIVE to NORMAL intentional? > > The ValueRange of MilliOfDay for example is (0, 86400000-1), so negative > values would be out of range. > > Similarly, NanoOfSecond and NanoOfDay are non-negative. (Otherwise, there > should be test cases for negative values). > > Thanks, Roger > > > > On 4/28/2016 4:04 PM, nadeesh tv wrote: > > Hi all, > Thanks Stephen for the comments. > Please see the updated webrev > http://cr.openjdk.java.net/~ntv/8148949/webrev.02/ > > Regards, > Nadeesh > > > On 4/28/2016 7:58 PM, Stephen Colebourne wrote: > > I'd like to see the test cases in test_secondsPattern() check the > result of the parse (by passing more arguments from > data_secondsPattern) > > Otherwise looks good. > Stephen > > On 28 April 2016 at 14:12, nadeesh tv wrote: > > Hi all, > Please see the updated webrev > http://cr.openjdk.java.net/~ntv/8148949/webrev.01/ > > Regards, > Nadeesh TV > > On 4/25/2016 8:08 PM, nadeesh tv wrote: > > HI all, > Please review a fix for > Bug ID - https://bugs.openjdk.java.net/browse/JDK-8148949 > > Issue - Pattern letters 'A' does not match the intent of LDML/CLDR > > Solution - Changed the definition of pattern letters 'A','n','N' > > Webrev - http://cr.openjdk.java.net/~ntv/8148949/webrev.00/ > > > -- > Thanks and Regards, > Nadeesh TV > > > From chris.hegarty at oracle.com Tue May 3 15:10:33 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 3 May 2016 16:10:33 +0100 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> Message-ID: <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> On 2 May 2016, at 22:48, Steve Drach wrote: > Looks fine to me, +1. -Chris. > although I am not an official reviewer. Thanks for doing this. > >> On May 2, 2016, at 1:03 PM, Alexandre (Shura) Iline wrote: >> >> Hi, >> >> Can you please take a look on: >> http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/ >> ? >> >> Thank you >> >> Shura >> > From scolebourne at joda.org Tue May 3 15:15:55 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 3 May 2016 16:15:55 +0100 Subject: RFR:JDK-8079628:java.time: DateTimeFormatter containing "DD" fails on 3-digit day-of-year value In-Reply-To: <1f89d623-e7af-61ae-821c-658be59a3f77@Oracle.com> References: <571F558F.9090008@oracle.com> <57220BCA.5000608@oracle.com> <572250A2.8030709@oracle.com> <8b789366-7479-383c-00ad-8b70adcb9b59@Oracle.com> <57285240.5060004@oracle.com> <1f89d623-e7af-61ae-821c-658be59a3f77@Oracle.com> Message-ID: Letters "Q", "q", "M", "L", "d", "D", "F", "h", "H", "k", "K", "m", "s" and no doubt others use NORMAL via appendValue(field); Changing these to use NOT_NEGATIVE would be a big change and doesn't seem justified. For "D", "DD" and "DDD" these seem to be the best balance (as discussed up-thread): * D 1 appendValue(ChronoField.DAY_OF_YEAR) * DD 2 appendValue(ChronoField.DAY_OF_YEAR, 2, 3, SignStyle.NOT_NEGATIVE) * DDD 3 appendValue(ChronoField.DAY_OF_YEAR, 3) ie. we use NOT_NEGATIVE when we are making changes to a field and that is the best option, but otherwise we stick with NORMAL for single letter patterns like "D". Stephen On 3 May 2016 at 15:22, Roger Riggs wrote: > Hi Nadeesh, > > > On 5/3/2016 3:24 AM, nadeesh tv wrote: > > Hi Roger, > Please see the answers inline > > On 5/3/2016 2:43 AM, Roger Riggs wrote: > > Hi Nadeesh, > > src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java > > line 1835: the appendValue(field) method has a sign-style of NORMAL; should > that be NOT_NEGATIVE? > > It's 'NOT_NEGATIVE' only. May be a browser caching issue. Can you please > check it once again. > > My question was about the existing case for "D" that uses > appendValue(field). > That is a shorthand for: > appendValue(new NumberPrinterParser(field, 1, 19, SignStyle.NORMAL)); > > test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java: > > What is being tested in test_dayOfYearFieldPattern? > It does not check that the value parsed matches the input. > > These test cases added initially. Now it's become almost redundant due to > 'dayOfYearFieldValues' . I could remove it. > > If they are redundant, they should be removed. > > > test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java > > 686, 688: should these cases show with sign-style NOT_NEGATIVE also? > > Suspecting browser caching here also. > > I'm referring to the test case for "D", which seems like it should show up > as NOT_NEGATIVE. > > > Updated the webrev by removing some unnecessary spaces > http://cr.openjdk.java.net/~ntv/8079628/webrev.03/ > > > Thanks, Roger > From mandy.chung at oracle.com Tue May 3 16:42:48 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 3 May 2016 09:42:48 -0700 Subject: RFR: 8155600: jaxp.library.TestPolicy should extend the default security policy In-Reply-To: <095301d1a51f$7cd2bd10$76783730$@oracle.com> References: <06b201d1a125$9d5af1e0$d810d5a0$@oracle.com> <07BE02D4-5911-4C8A-A1E9-030698DFD7FE@oracle.com> <095301d1a51f$7cd2bd10$76783730$@oracle.com> Message-ID: <5C2197AB-5171-4AD3-BFE5-0E1F67ABE200@oracle.com> > On May 3, 2016, at 2:37 AM, Frank Yuan wrote: > > Hi Mandy and Joe > > I have re-fixed the bug with your comment, would you like to check again? http://cr.openjdk.java.net/~fyuan/8155514/webrev.01/ > This patch extending the default security policy is a better fix. Looks fine. I saw that you already pushed the previous version to jdk9/dev. Please create a new JBS issue for this patch since you can?t push with a duplicated bug ID. Mandy > Thanks, > > Frank > >> -----Original Message----- >> From: Mandy Chung [mailto:mandy.chung at oracle.com] >> Sent: Friday, April 29, 2016 4:00 AM >> To: Frank Yuan >> Cc: core-libs-dev ; huizhe wang ; Xueming Shen >> >> Subject: Re: RFR: 8155600: jaxp.library.TestPolicy should extend the default security policy >> >> Hi Frank, >> >> The fix looks fine. >> >> Thanks for verifying it with my patch to deprivilege jdk.charasets. >> >> Mandy >> >>> On Apr 28, 2016, at 1:11 AM, Frank Yuan wrote: >>> >>> Hi Mandy, Joe and all >>> >>> Would you like to review the fix for bug >>> https://bugs.openjdk.java.net/browse/JDK-8155514? >>> >>> The webrev is at: http://cr.openjdk.java.net/~fyuan/8155514/webrev.00/. >>> >>> >>> Thanks, >>> >>> Frank > > From stevenschlansker at gmail.com Tue May 3 17:19:41 2016 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Tue, 3 May 2016 10:19:41 -0700 Subject: JEP 118 Parameter Names by default In-Reply-To: References: Message-ID: <29F3B591-49BC-461F-B54C-4B187F790D32@gmail.com> Hi Michael, Thanks for the link, this is exactly the explanation I was looking for. I am disappointed in the decision, but not exactly surprised. It really makes the feature less useful to have to go and educate every user that they must now pass special compiler flags, as well as ensure that every environment (Eclipse, IntelliJ, Maven, etc) honors the configuration. I would love for this decision to be reconsidered for 9, but don't really expect to have much luck pushing that point :) Thanks! > On Apr 27, 2016, at 7:19 PM, Michael Hixson wrote: > > I found this old email reply to someone who asked a similar question. > Maybe the same reasoning still applies: > > http://mail.openjdk.java.net/pipermail/enhanced-metadata-spec-discuss/2013-May/000201.html > > -Michael > > On Wed, Apr 27, 2016 at 1:18 PM, Steven Schlansker > wrote: >> Hi core-libs-dev, >> >> Apologies in advance if this is the wrong list, I was torn between this >> one and compiler-dev, but I'm already subscribed here so we'll try this first :) >> >> I am trying to understand why the javac '-parameters' option is not enabled by >> default. >> >> Normally it would not be too onerous, but due to some limitations in e.g. Maven >> it is surprisingly difficult to configure correctly in a world where you must >> build code that both targets e.g. 1.8 and 1.7 (and soon 1.9): >> http://mail-archives.apache.org/mod_mbox/maven-dev/201604.mbox/browser >> >> While I am happy to work with the Maven project to improve their support >> for sending compiler arguments more flexibly, I did wonder -- why is >> this feature not on by default? >> >> I did some brief searching and was unable to come up with any downside, >> but maybe I missed something obvious? Can we turn it on by default for Java 9? >> >> Thanks for humoring me, >> Steven >> >> From paul.sandoz at oracle.com Tue May 3 18:35:06 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 3 May 2016 11:35:06 -0700 Subject: RFR 8155258: VarHandle implementation improvements In-Reply-To: <5728A388.6050505@oracle.com> References: <43CCC631-B8BA-40BF-A292-7F1ED00FDCDD@oracle.com> <5728A388.6050505@oracle.com> Message-ID: > On 3 May 2016, at 06:11, Aleksey Shipilev wrote: > > On 05/03/2016 01:18 AM, Paul Sandoz wrote: >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-jdk/webrev/ >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-hotspot/webrev/ > > I remember testing this before, so it definitely helps performance in > pathological use cases for CompareAndExchange. > > MethodHandleNatives: > > *) Not sure I "dig" the change here (apart from old code apparently > blows the capacity estimate): > Right, blows the estimate and i did some extra fiddling to remove the dependency on StringBuilder at the same time. > 469 static String getVarHandleMethodSignature(MethodType mt) { > 470 char[] sig = new char[mt.parameterCount() + 2]; > 471 > 472 int i = 0; > 473 for (; i < mt.parameterCount(); i++) { > 474 sig[i] = getCharType(mt.parameterType(i)); > 475 } > 476 sig[i] = '_'; > 477 sig[i + 1] = getCharType(mt.returnType()); > 478 > 479 return String.valueOf(sig); > > With Compact Strings, it's beneficial to use StringBuilder instead of > char[], because StringBuilder will concat in Latin1 form. char[] code > would need to re-compress to byte[] during String.valueOf(). > Good point, reverted. > MethodType: > > *) Only imports are changed. Revert? Otherwise next runner up would > change the imports back, ad nauseam. > Reverted. > X-VarHandle.java.template: > > *) There's compareAndExchangeVolatile_V, but there is no > compareAndExchange{Acquire,Release}_V, etc. Shouldn't we have the "void" > entries for every method that returns a value? Or, > compareAndExchangeVolatile_V is redundant, and does not participate the > new mechanics? > Ah, that is a left-over from a previous experiment, before i realised the return value can be dropped. Removed. http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-jdk/webrev/ Thanks, Paul. From aleksey.shipilev at oracle.com Tue May 3 18:40:57 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 3 May 2016 21:40:57 +0300 Subject: RFR 8155258: VarHandle implementation improvements In-Reply-To: References: <43CCC631-B8BA-40BF-A292-7F1ED00FDCDD@oracle.com> <5728A388.6050505@oracle.com> Message-ID: <5728F0B9.8030602@oracle.com> On 05/03/2016 09:35 PM, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-jdk/webrev/ Okay then, looks good. -Aleksey From brent.christian at oracle.com Tue May 3 19:00:27 2016 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 03 May 2016 12:00:27 -0700 Subject: RFR 8147039 : Incorrect locals and operands in compiled frames Message-ID: <5728F54B.8070007@oracle.com> Hi, Please review this change which fixes buggy behavior (including SEGV) in the experimental LiveStackFrame feature of StackWalker. Bug: https://bugs.openjdk.java.net/browse/JDK-8147039 Webrev: http://cr.openjdk.java.net/~bchristi/8147039/webrev.02/ As suggested in the bug report, stack walking is reimplemented using javaVFrame/vframe::java_sender. The native StackWalkerAnchor class is updated (and renamed) with a similar interface and function to vframeStream. I've also removed the now-unneeded vframeStreamCommon::java_frame() function, added by 8140450. Thanks, -Brent From joe.darcy at oracle.com Tue May 3 19:14:06 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 3 May 2016 12:14:06 -0700 Subject: JDK 9 RFR of JDK-8155963: Fix deprecation warning in windows java.net implementation Message-ID: Hello, Please review the patch below is address windows-specific code which was overlooked on the cleanup passes ahead of fixing JDK-6850612: Deprecate Class.newInstance since it violates the checked exception language contract. Thanks, -Joe diff -r 03453120a011 src/java.base/windows/classes/java/net/DefaultDatagramSocketImplFactory.java --- a/src/java.base/windows/classes/java/net/DefaultDatagramSocketImplFactory.java Tue May 03 10:40:54 2016 -0700 +++ b/src/java.base/windows/classes/java/net/DefaultDatagramSocketImplFactory.java Tue May 03 12:12:09 2016 -0700 @@ -90,7 +90,9 @@ throws SocketException { if (prefixImplClass != null) { try { - return (DatagramSocketImpl) prefixImplClass.newInstance(); + @SuppressWarnings("deprecation") + Object result = prefixImplClass.newInstance(); + return (DatagramSocketImpl) result; } catch (Exception e) { throw new SocketException("can't instantiate DatagramSocketImpl"); } From philip.race at oracle.com Tue May 3 19:10:20 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 03 May 2016 12:10:20 -0700 Subject: JDK 9 RFR of JDK-8155963: Fix deprecation warning in windows java.net implementation In-Reply-To: References: Message-ID: <5728F79C.10807@oracle.com> +1 -phil. On 05/03/2016 12:14 PM, joe darcy wrote: > Hello, > > Please review the patch below is address windows-specific code which > was overlooked on the cleanup passes ahead of fixing JDK-6850612: > Deprecate Class.newInstance since it violates the checked exception > language contract. > > Thanks, > > -Joe > > > diff -r 03453120a011 > src/java.base/windows/classes/java/net/DefaultDatagramSocketImplFactory.java > --- > a/src/java.base/windows/classes/java/net/DefaultDatagramSocketImplFactory.java > Tue May 03 10:40:54 2016 -0700 > +++ > b/src/java.base/windows/classes/java/net/DefaultDatagramSocketImplFactory.java > Tue May 03 12:12:09 2016 -0700 > @@ -90,7 +90,9 @@ > throws SocketException { > if (prefixImplClass != null) { > try { > - return (DatagramSocketImpl) > prefixImplClass.newInstance(); > + @SuppressWarnings("deprecation") > + Object result = prefixImplClass.newInstance(); > + return (DatagramSocketImpl) result; > } catch (Exception e) { > throw new SocketException("can't instantiate > DatagramSocketImpl"); > } > From paul.sandoz at oracle.com Tue May 3 20:03:12 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 3 May 2016 13:03:12 -0700 Subject: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package In-Reply-To: <1314424116.988033.1462284320182.JavaMail.zimbra@u-pem.fr> References: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> <1314424116.988033.1462284320182.JavaMail.zimbra@u-pem.fr> Message-ID: <0457D70E-7BA2-4A92-AC0E-0E56103F4DE5@oracle.com> > On 3 May 2016, at 07:05, Remi Forax wrote: > > Looks good to me. > minor nitpick, neither checkFromToIndex() nor checkFromIndexSize() are instrinsic (now !) but i think they also should be annotated with @ForceInline in j.u.Objects to avoid the code to be asymmetric or weird if one of these methods is intrinsinfied later. > I was tempted, but for the moment i am inclined to leave as is and revisit if/when necessary. Trying to be conservative when using those annotations. Thanks, Paul. From mandy.chung at oracle.com Tue May 3 20:16:45 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 3 May 2016 13:16:45 -0700 Subject: Review request: 8154190 & 8155513: Deprivilege java.compiler and jdk.charsets In-Reply-To: <57244FE7.4000302@oracle.com> References: <57244FE7.4000302@oracle.com> Message-ID: > On Apr 29, 2016, at 11:25 PM, Alan Bateman wrote: > > On 30/04/2016 06:02, Mandy Chung wrote: >> JDK-8154190: Deprivilege java.compiler module >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8154190/webrev.00/ >> >> JDK-8155513: Deprivilege jdk.charsets module >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155513/webrev.00/ >> >> Very simple change. >> >> These patches move java.compiler and jdk.charsets module to be defined by the platform class loader and grant with AllPermissions initially. We could grant finer-grained permissions in the future. >> > This looks okay to me. For jdk.charsets then I expect it should be easy to identify the permission it needs as there are only a few cases where it needs os.name or to read a resource file in the image. I originally asked Sherman to identify the permissions for jdk.charsets as a follow up issue. I took another look and define the list: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155513/webrev.01/ Mandy From xueming.shen at oracle.com Tue May 3 20:19:00 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 03 May 2016 13:19:00 -0700 Subject: RFR: JDK-8150496,(zipfs) Fix performance issues in zip-fs In-Reply-To: <57289BE4.1040605@oracle.com> References: <5727E295.1000303@oracle.com> <57289BE4.1040605@oracle.com> Message-ID: <572907B4.1020305@oracle.com> Hi Aleksey, Again, thanks for the review. The webrev has been updated accordingly, as well as the MyBenchmark.java (to use Blackhole, as suggested) http://cr.openjdk.java.net/~sherman/8150496/webrev/ http://cr.openjdk.java.net/~sherman/8150496/MyBenchmark.java -Sherman On 05/03/2016 05:39 AM, Aleksey Shipilev wrote: > Hi Sherman, > > On 05/03/2016 02:28 AM, Xueming Shen wrote: >> Please help review the performance cleanup for zipfs >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8150496 >> webrev: http://cr.openjdk.java.net/~sherman/8150496/webrev > ZipFileSystem.java: > > *) These should be removed? > > 2032 //writeShort(os, name.length); > 2033 writeShort(os, nlen); > > 2220 //writeShort(os, name.length); > 2221 writeShort(os, nlen); > > 2591 //inodes.forEach( (k,v) -> { System.out.printf(" %s -> > %s%n", new String(k.name), new String(v.name)); }); > > 1080 /* > 1081 byte[] name = Arrays.copyOfRange(cen, pos + CENHDR, > pos + CENHDR + nlen); > 1082 */ > > *) There is ever-so-subtle difference in doing either: > > 171 byte[] tmp = new byte[path.length + 1]; > 172 System.arraycopy(path, 0, tmp, 1, path.length); > 173 tmp[0] = '/'; > > ...or: > > 1083 byte[] name = new byte[nlen + 1]; > 1084 name[0] = '/'; > 1085 System.arraycopy(cen, pos + CENHDR, name, 1, nlen); > > Excess op between allocation and arraycopy breaks zeroing elimination, > see e.g.: > http://cr.openjdk.java.net/~shade/scratch/ZeroingFirstBench.java > > > *) Missing braces: > > 1483 if (e2 == null) > 1484 throw new ZipException("invalid loc for entry > <" + e.name +">"); > > *) Probably deserves a comment why these are commented out? Are these > implied to be zeroes? > > 1713 // int disknum; > 1714 // int sdisknum; > > >> Here are the result of the sample benchmark that measures the improvement. >> http://cr.openjdk.java.net/~sherman/8150496/MyBenchmark.java > This benchmark is not very reliable: > > *) Sink everything in Blackhole. I.e. instead of, say: > > @Benchmark > public void ZFS_Open() throws IOException { > cnt = 0; > for (int i = 0; i< 100; i++) { > try (FileSystem fs = newFileSystem(path)) { > if (Files.exists(fs.getPath(entriesS.get(0)))) > cnt++; > } > } > } > > do: > > @Benchmark > public void ZFS_Open(Blackhole bh) throws IOException { > for (int i = 0; i< 100; i++) { > try (FileSystem fs = newFileSystem(path)) { > bh.consume(fs.getPath(entriesS.get(0))); > } > } > } > > This applies to all other methods. > > Thanks, > -Aleksey > From mandy.chung at oracle.com Tue May 3 20:45:01 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 3 May 2016 13:45:01 -0700 Subject: RFR 8147039 : Incorrect locals and operands in compiled frames In-Reply-To: <5728F54B.8070007@oracle.com> References: <5728F54B.8070007@oracle.com> Message-ID: <7773B9CF-84F9-454D-8DCC-A2ED28DEEEBC@oracle.com> > On May 3, 2016, at 12:00 PM, Brent Christian wrote: > > Hi, > > Please review this change which fixes buggy behavior (including SEGV) in the experimental LiveStackFrame feature of StackWalker. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8147039 > Webrev: > http://cr.openjdk.java.net/~bchristi/8147039/webrev.02/ > > As suggested in the bug report, stack walking is reimplemented using javaVFrame/vframe::java_sender. The native StackWalkerAnchor class is updated (and renamed) with a similar interface and function to vframeStream. I've also removed the now-unneeded vframeStreamCommon::java_frame() function, added by 8140450. This patch looks good. I?m happy that the fix turns out to be very simple and clean. One minor nit: in stackwalk.cpp, the local variable ?anchor? used in a couple places should also be renamed. You can fix that up before you push (no need for a new webrev) thanks Mandy From aleksey.shipilev at oracle.com Tue May 3 21:50:15 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 4 May 2016 00:50:15 +0300 Subject: RFR 8154049: DualPivot sorting calculates incorrect runs for nearly sorted arrays In-Reply-To: <4BCDB485-4D6C-479E-8E92-BA790BDD75AB@oracle.com> References: <4BCDB485-4D6C-479E-8E92-BA790BDD75AB@oracle.com> Message-ID: <57291D17.7060603@oracle.com> On 04/21/2016 04:24 PM, Paul Sandoz wrote: > Please review: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154049-dual-pivot-sort-one-off-error/webrev/ Ew. It is a complete brain-twister to understand the original code, the original improvement, the bug, and the fix -- all four! This is a manifestation of Kernigan's "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" In constructive vein, I think the comment needs to be expanded to: // These invariants should hold true: // run[0] = 0 // run[] = right + 1; (terminator) if (count == 0) { // A single run of equal elements. return; } else if (count == 1 && run[count] > right) { // Either a single ascending or a transformed descending run. // Always check that a final run is a proper terminator, otherwise // we have an unterminated trailing run, to handle downstream. return; } right++; if (run[count] < right) { // Corner case: the final run is not a terminator. This may happen // if a final run is an equals run, or there is a single-element run // at the end. Fix up by adding a proper terminator at the end. // Note that we terminate with (right + 1), incremented earlier. run[++count] = right; } ...or somehow rewire the "equals" run logic to add a proper terminator before breaking from the loop. But this is beyond my capacity this fine evening. Thanks, -Aleksey From huizhe.wang at oracle.com Tue May 3 21:58:39 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 03 May 2016 14:58:39 -0700 Subject: Original Bug ID: 8155514 -> Re: RFR: 8155600: jaxp.library.TestPolicy should extend the default security policy In-Reply-To: <5C2197AB-5171-4AD3-BFE5-0E1F67ABE200@oracle.com> References: <06b201d1a125$9d5af1e0$d810d5a0$@oracle.com> <07BE02D4-5911-4C8A-A1E9-030698DFD7FE@oracle.com> <095301d1a51f$7cd2bd10$76783730$@oracle.com> <5C2197AB-5171-4AD3-BFE5-0E1F67ABE200@oracle.com> Message-ID: <57291F0F.5020304@oracle.com> On 5/3/2016 9:42 AM, Mandy Chung wrote: >> On May 3, 2016, at 2:37 AM, Frank Yuan wrote: >> >> Hi Mandy and Joe >> >> I have re-fixed the bug with your comment, would you like to check again? http://cr.openjdk.java.net/~fyuan/8155514/webrev.01/ >> > This patch extending the default security policy is a better fix. Looks fine. Looks good to me too. > > I saw that you already pushed the previous version to jdk9/dev. Please create a new JBS issue for this patch since you can?t push with a duplicated bug ID. Indeed. And also, the Bug Id in the Subject is incorrect, that's somebody else's enhancement. -Joe > > Mandy > > >> Thanks, >> >> Frank >> >>> -----Original Message----- >>> From: Mandy Chung [mailto:mandy.chung at oracle.com] >>> Sent: Friday, April 29, 2016 4:00 AM >>> To: Frank Yuan >>> Cc: core-libs-dev ; huizhe wang ; Xueming Shen >>> >>> Subject: Re: RFR: 8155600: jaxp.library.TestPolicy should extend the default security policy >>> >>> Hi Frank, >>> >>> The fix looks fine. >>> >>> Thanks for verifying it with my patch to deprivilege jdk.charasets. >>> >>> Mandy >>> >>>> On Apr 28, 2016, at 1:11 AM, Frank Yuan wrote: >>>> >>>> Hi Mandy, Joe and all >>>> >>>> Would you like to review the fix for bug >>>> https://bugs.openjdk.java.net/browse/JDK-8155514? >>>> >>>> The webrev is at: http://cr.openjdk.java.net/~fyuan/8155514/webrev.00/. >>>> >>>> >>>> Thanks, >>>> >>>> Frank >> From joe.darcy at oracle.com Tue May 3 22:10:26 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 03 May 2016 15:10:26 -0700 Subject: JDK 9 RFR of adding a few @jls tags to java.lang.String In-Reply-To: <1b12a36b-39a5-295f-64c9-bc0d34fb2c16@oracle.com> References: <1b12a36b-39a5-295f-64c9-bc0d34fb2c16@oracle.com> Message-ID: <572921D2.3060300@oracle.com> Hi David, On 5/2/2016 5:01 AM, David Holmes wrote: > On 1/05/2016 5:34 AM, joe darcy wrote: >> Hello, >> >> Please review the small patch below to add some JLS references to the >> string class to supplement its textual discussion of a few sections of >> the JLS. > > Side question: what mechanism is there to detect stale references > if/when the JLS section numbers change? > There is no such mechanism to detect stale references. In previously conversations with Alex, by default he plans to keep the existing section numbers and titles stable going forward. Thanks, -Joe From paul.sandoz at oracle.com Tue May 3 22:20:26 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 3 May 2016 15:20:26 -0700 Subject: RFR 8154049: DualPivot sorting calculates incorrect runs for nearly sorted arrays In-Reply-To: <57291D17.7060603@oracle.com> References: <4BCDB485-4D6C-479E-8E92-BA790BDD75AB@oracle.com> <57291D17.7060603@oracle.com> Message-ID: <6F65260B-0680-4F9D-9391-3C368936BCAD@oracle.com> > On 3 May 2016, at 14:50, Aleksey Shipilev wrote: > > On 04/21/2016 04:24 PM, Paul Sandoz wrote: >> Please review: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154049-dual-pivot-sort-one-off-error/webrev/ > > Ew. It is a complete brain-twister to understand the original code, the > original improvement, the bug, and the fix -- all four! This is a > manifestation of Kernigan's "Everyone knows that debugging is twice as > hard as writing a program in the first place. So if you're as clever as > you can be when you write it, how will you ever debug it?? > and ?real programmers don?t comment code? :-) > In constructive vein, I think the comment needs to be expanded to: > > // These invariants should hold true: > // run[0] = 0 > // run[] = right + 1; (terminator) > > if (count == 0) { > // A single run of equal elements. > return; > } else if (count == 1 && run[count] > right) { > // Either a single ascending or a transformed descending run. > // Always check that a final run is a proper terminator, otherwise > // we have an unterminated trailing run, to handle downstream. > return; > } > > right++; > if (run[count] < right) { > // Corner case: the final run is not a terminator. This may happen > // if a final run is an equals run, or there is a single-element run > // at the end. Fix up by adding a proper terminator at the end. > // Note that we terminate with (right + 1), incremented earlier. > run[++count] = right; > } > Yes, that helps a lot, many thanks. I will update accordingly. > ...or somehow rewire the "equals" run logic to add a proper terminator > before breaking from the loop. But this is beyond my capacity this fine > evening. > Someday i might revisit and rewrite? Paul. From brian.burkhalter at oracle.com Tue May 3 22:22:40 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 3 May 2016 15:22:40 -0700 Subject: JDK 9 RFR of JDK-4943627 Deprecate rounding mode integer constants in BigDecimal and their uses In-Reply-To: <37790f91-579f-8333-c7af-f98e1cb4fde6@oracle.com> References: <37790f91-579f-8333-c7af-f98e1cb4fde6@oracle.com> Message-ID: <480650B0-BBFA-4A52-A4A0-9F4087E2EBED@oracle.com> Hi Joe, On Apr 30, 2016, at 8:24 PM, joe darcy wrote: > Please review the changes to address > > JDK-4943627 Deprecate rounding mode integer constants in BigDecimal and their uses > > http://cr.openjdk.java.net/~darcy/4943627.0/ > > Since JDK 5, the java.math package has had a RoundMode s/RoundMode/RoundingMode/ Also the more recent copyright year is not updated in RoundingMode.java. > enum to model and manage the various rounding modes used by methods in BigDecimal (and elsewhere). Those rounding modes enum constants were added in parallel to a set of integer constants in BigDecimal previously used to model rounding modes. For each BigDecimal method which took an int rounding mode constant, a sibling method was added to take a RoundMode object. > > As the synopsis of the bug implies, the time has come to deprecate the legacy int rounding mode constants and the method taking those ints as arguments. Godspeed, legacy constants. +1 Brian From joe.darcy at oracle.com Tue May 3 23:21:21 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 03 May 2016 16:21:21 -0700 Subject: JDK 9 RFR of JDK-4943627 Deprecate rounding mode integer constants in BigDecimal and their uses In-Reply-To: <480650B0-BBFA-4A52-A4A0-9F4087E2EBED@oracle.com> References: <37790f91-579f-8333-c7af-f98e1cb4fde6@oracle.com> <480650B0-BBFA-4A52-A4A0-9F4087E2EBED@oracle.com> Message-ID: <57293271.10709@oracle.com> Hi Brian, Pushed with updated copyright range; thanks, -Joe On 5/3/2016 3:22 PM, Brian Burkhalter wrote: > Hi Joe, > > On Apr 30, 2016, at 8:24 PM, joe darcy > wrote: > >> Please review the changes to address >> >> JDK-4943627 Deprecate rounding mode integer constants in >> BigDecimal and their uses >> >> http://cr.openjdk.java.net/~darcy/4943627.0/ >> >> >> Since JDK 5, the java.math package has had a RoundMode > > s/RoundMode/RoundingMode/ > > Also the more recent copyright year is not updated in RoundingMode.java. > >> enum to model and manage the various rounding modes used by methods >> in BigDecimal (and elsewhere). Those rounding modes enum constants >> were added in parallel to a set of integer constants in BigDecimal >> previously used to model rounding modes. For each BigDecimal method >> which took an int rounding mode constant, a sibling method was added >> to take a RoundMode object. >> >> As the synopsis of the bug implies, the time has come to deprecate >> the legacy int rounding mode constants and the method taking those >> ints as arguments. > > Godspeed, legacy constants. > > +1 > > Brian From xueming.shen at oracle.com Tue May 3 23:29:53 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 03 May 2016 16:29:53 -0700 Subject: RFR: regex changes In-Reply-To: <56EC5F76.4080106@oracle.com> References: <56EC5F76.4080106@oracle.com> Message-ID: <57293471.8020503@oracle.com> Hi, This one has be out for review for a while. If there is no further comments and feedback the changes will be pushed in shortly. Thanks, Sherman On 3/18/16, 1:05 PM, Xueming Shen wrote: > Hi, > > There are couple regex related changes waiting for review. I have pull > them > together here (with the notes) to make it easy to review. > > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ > > (1) Exponential backtracking > > Note: > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/backtracking > > https://bugs.openjdk.java.net/browse/JDK-6328855 > https://bugs.openjdk.java.net/browse/JDK-6192895 > https://bugs.openjdk.java.net/browse/JDK-6345469 > https://bugs.openjdk.java.net/browse/JDK-6988218 > https://bugs.openjdk.java.net/browse/JDK-6693451 > https://bugs.openjdk.java.net/browse/JDK-7006761 > https://bugs.openjdk.java.net/browse/JDK-8140212 > > (2) Anonymous class to lambda function cleanup > > Note: > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/lambdafunction > > https://bugs.openjdk.java.net/browse/JDK-8151481 > https://bugs.openjdk.java.net/browse/JDK-6609854 > > (3) Canonical Equivalents > > Note: > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/canonEQ > > https://bugs.openjdk.java.net/browse/JDK-4916384 > https://bugs.openjdk.java.net/browse/JDK-4867170 > https://bugs.openjdk.java.net/browse/JDK-6995635 > https://bugs.openjdk.java.net/browse/JDK-6728861 > https://bugs.openjdk.java.net/browse/JDK-6736245 > https://bugs.openjdk.java.net/browse/JDK-7080302 > > Thanks > Sherman From brent.christian at oracle.com Tue May 3 23:43:39 2016 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 03 May 2016 16:43:39 -0700 Subject: RFR 8147039 : Incorrect locals and operands in compiled frames In-Reply-To: <7773B9CF-84F9-454D-8DCC-A2ED28DEEEBC@oracle.com> References: <5728F54B.8070007@oracle.com> <7773B9CF-84F9-454D-8DCC-A2ED28DEEEBC@oracle.com> Message-ID: <572937AB.3010508@oracle.com> Hi, Mandy On 05/03/2016 01:45 PM, Mandy Chung wrote: > > One minor nit: in stackwalk.cpp, the local variable ?anchor? used in > a couple places should also be renamed. You can fix that up before > you push (no need for a new webrev) Ah, looks like I missed JavaFrameStream::from_current(). Are you okay with _anchor as a field name in JavaFrameStream, or would you prefer, say, "_magic"? Thanks for having a look. -Brent From huizhe.wang at oracle.com Wed May 4 00:22:51 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 03 May 2016 17:22:51 -0700 Subject: RFR (JAXP) 8152912: SAX XMLReaderFactory needs to be ServiceLoader compliant In-Reply-To: <6ed137e8-2651-7f6f-50b9-143b00286355@oracle.com> References: <57279CDE.7070207@oracle.com> <6ed137e8-2651-7f6f-50b9-143b00286355@oracle.com> Message-ID: <572940DB.10003@oracle.com> On 5/3/2016 3:36 AM, Daniel Fuchs wrote: > Hi Joe, > > This look good but the implementation might be overly complex, > which makes it difficult to read. It was basically the existing code with some cleanup. What's in jarLookup was a copy of the original code. As you can see I was eager to add ServiceLoader support and forget about it (deprecated) :-) > > First: > 141 ClassLoader cl = ss.getContextClassLoader(); > is misnamed, because as far as I can see this method returns > the context class loader if not null, otherwise the system > class loader. Make sense. That method was changed. I now renamed it to getClassLoader with javadoc. > > So cl is either the context class loader or the system class > loader and is guaranteed to be non null. > I would suggest adding a comment to make it clear. > > This means in turn that the new jarLookup(ClassLoader) > method can be greatly simplified - you can do: > final ClassLoader cl = Objects.requiresNonNull(loader); > and then simplify the if (cl != null) else ... logic, > because you now know that cl cannot be null. The cl-null checks in both jarLookup and findServiceProvider are removed. The new webrev also includes some cleanup of warnings, deprecation with javadocs (since Java SE 5) but without the annotation. I limited the patch to the sax package only. New webrev: http://cr.openjdk.java.net/~joehw/jdk9/8152912/webrev01/ Best, Joe > > Best regards, > > -- daniel > > > > On 02/05/16 20:30, huizhe wang wrote: >> Hi, >> >> Please review a change that adds a step using the ServiceLoader to >> XMLReaderFactory's provider-lookup process. Meanwhile, XMLReaderFactory >> is deprecated in favor of javax.xml.parsers.SAXParserFactory. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8152912 >> Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8152912/webrev/ >> >> The change has been verified by SQE test that Frank will submit soon for >> review (that is, when he starts to work at his local time). >> >> Thanks, >> Joe > > From mandy.chung at oracle.com Wed May 4 00:24:35 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 3 May 2016 17:24:35 -0700 Subject: RFR 8147039 : Incorrect locals and operands in compiled frames In-Reply-To: <572937AB.3010508@oracle.com> References: <5728F54B.8070007@oracle.com> <7773B9CF-84F9-454D-8DCC-A2ED28DEEEBC@oracle.com> <572937AB.3010508@oracle.com> Message-ID: <84A0AE41-26DB-4D0B-B367-CAD5D5407FAF@oracle.com> > On May 3, 2016, at 4:43 PM, Brent Christian wrote: > > Hi, Mandy > >> On 05/03/2016 01:45 PM, Mandy Chung wrote: >> >> One minor nit: in stackwalk.cpp, the local variable ?anchor? used in >> a couple places should also be renamed. You can fix that up before >> you push (no need for a new webrev) > > Ah, looks like I missed JavaFrameStream::from_current(). > > Are you okay with _anchor as a field name in JavaFrameStream, or would you prefer, say, "_magic"? > _anchor as a field name is fine as that also serves as the purpose. Mandy > Thanks for having a look. > > -Brent From amy.lu at oracle.com Wed May 4 01:24:05 2016 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 4 May 2016 09:24:05 +0800 Subject: JDK 9 RFR of JDK-8154911: Move GCDuringIteration.java back to tier1 In-Reply-To: <571D8844.5040805@oracle.com> References: <571D8844.5040805@oracle.com> Message-ID: <57294F35.9050704@oracle.com> Please review. Thanks, Amy On 4/25/16 11:00 AM, Amy Lu wrote: > java/util/WeakHashMap/GCDuringIteration.java > > This test was failing intermittently (JDK-6842353) and demoted to > tier2. Mentioned issues have been resolved and no open bug (no failure > reported) till now. > > This patch is to move the test back to tier1. > > bug: https://bugs.openjdk.java.net/browse/JDK-8154911 > webrev: http://cr.openjdk.java.net/~amlu/8154911/webrev.00/ > > Thanks, > Amy > > > --- old/test/TEST.groups 2016-04-25 10:54:59.000000000 +0800 > +++ new/test/TEST.groups 2016-04-25 10:54:58.000000000 +0800 > @@ -29,7 +29,6 @@ > :jdk_lang \ > -java/lang/ProcessHandle/TreeTest.java \ > :jdk_util \ > - -java/util/WeakHashMap/GCDuringIteration.java \ > -java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ > -java/util/concurrent/forkjoin/FJExceptionTableLeak.java \ > sun/nio/cs/ISO8859x.java \ > @@ -39,7 +38,6 @@ > > tier2 = \ > java/lang/ProcessHandle/TreeTest.java \ > - java/util/WeakHashMap/GCDuringIteration.java \ > java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ > java/util/concurrent/forkjoin/FJExceptionTableLeak.java \ > :jdk_io \ > > From martinrb at google.com Wed May 4 02:30:20 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 3 May 2016 19:30:20 -0700 Subject: JDK 9 RFR of JDK-8154911: Move GCDuringIteration.java back to tier1 In-Reply-To: <57294F35.9050704@oracle.com> References: <571D8844.5040805@oracle.com> <57294F35.9050704@oracle.com> Message-ID: Looks good! Thanks for watching over our tests, and apologies for the years of flakiness! On Tue, May 3, 2016 at 6:24 PM, Amy Lu wrote: > Please review. > > Thanks, > Amy > > On 4/25/16 11:00 AM, Amy Lu wrote: >> >> java/util/WeakHashMap/GCDuringIteration.java >> >> This test was failing intermittently (JDK-6842353) and demoted to tier2. >> Mentioned issues have been resolved and no open bug (no failure reported) >> till now. >> >> This patch is to move the test back to tier1. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8154911 >> webrev: http://cr.openjdk.java.net/~amlu/8154911/webrev.00/ >> >> Thanks, >> Amy >> >> >> --- old/test/TEST.groups 2016-04-25 10:54:59.000000000 +0800 >> +++ new/test/TEST.groups 2016-04-25 10:54:58.000000000 +0800 >> @@ -29,7 +29,6 @@ >> :jdk_lang \ >> -java/lang/ProcessHandle/TreeTest.java \ >> :jdk_util \ >> - -java/util/WeakHashMap/GCDuringIteration.java \ >> -java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ >> -java/util/concurrent/forkjoin/FJExceptionTableLeak.java \ >> sun/nio/cs/ISO8859x.java \ >> @@ -39,7 +38,6 @@ >> >> tier2 = \ >> java/lang/ProcessHandle/TreeTest.java \ >> - java/util/WeakHashMap/GCDuringIteration.java \ >> java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ >> java/util/concurrent/forkjoin/FJExceptionTableLeak.java \ >> :jdk_io \ >> >> > From joe.darcy at oracle.com Wed May 4 02:38:16 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 3 May 2016 19:38:16 -0700 Subject: JDK 9 RFR of JDK-8154911: Move GCDuringIteration.java back to tier1 In-Reply-To: References: <571D8844.5040805@oracle.com> <57294F35.9050704@oracle.com> Message-ID: <3959e5e0-c50c-4fee-ef11-c3177e3260c7@oracle.com> +1 Thanks, -Joe On 5/3/2016 7:30 PM, Martin Buchholz wrote: > Looks good! > Thanks for watching over our tests, and apologies for the years of flakiness! > > On Tue, May 3, 2016 at 6:24 PM, Amy Lu wrote: >> Please review. >> >> Thanks, >> Amy >> >> On 4/25/16 11:00 AM, Amy Lu wrote: >>> java/util/WeakHashMap/GCDuringIteration.java >>> >>> This test was failing intermittently (JDK-6842353) and demoted to tier2. >>> Mentioned issues have been resolved and no open bug (no failure reported) >>> till now. >>> >>> This patch is to move the test back to tier1. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8154911 >>> webrev: http://cr.openjdk.java.net/~amlu/8154911/webrev.00/ >>> >>> Thanks, >>> Amy >>> >>> >>> --- old/test/TEST.groups 2016-04-25 10:54:59.000000000 +0800 >>> +++ new/test/TEST.groups 2016-04-25 10:54:58.000000000 +0800 >>> @@ -29,7 +29,6 @@ >>> :jdk_lang \ >>> -java/lang/ProcessHandle/TreeTest.java \ >>> :jdk_util \ >>> - -java/util/WeakHashMap/GCDuringIteration.java \ >>> -java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ >>> -java/util/concurrent/forkjoin/FJExceptionTableLeak.java \ >>> sun/nio/cs/ISO8859x.java \ >>> @@ -39,7 +38,6 @@ >>> >>> tier2 = \ >>> java/lang/ProcessHandle/TreeTest.java \ >>> - java/util/WeakHashMap/GCDuringIteration.java \ >>> java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ >>> java/util/concurrent/forkjoin/FJExceptionTableLeak.java \ >>> :jdk_io \ >>> >>> From stuart.marks at oracle.com Wed May 4 04:55:35 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 3 May 2016 21:55:35 -0700 Subject: RFR(m): 8139233 add initial compact immutable collection implementations Message-ID: Hi all, This is a reimplementation of collections created by the JEP 269 convenience factory methods. These implementations are overall quite a bit smaller than their conventional collections counterparts, particularly at small sizes. Lookup performance for the hash-based structures (Set and Map) is not particularly fast, though in most cases it's comparable to TreeSet/TreeMap. Further improvements are likely possible. There are no API changes in this changeset. Please review: http://cr.openjdk.java.net/~smarks/reviews/8139233/webrev.0/ JEP link: http://openjdk.java.net/jeps/269 Thanks, s'marks From forax at univ-mlv.fr Wed May 4 06:58:13 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 4 May 2016 08:58:13 +0200 (CEST) Subject: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package In-Reply-To: <0457D70E-7BA2-4A92-AC0E-0E56103F4DE5@oracle.com> References: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> <1314424116.988033.1462284320182.JavaMail.zimbra@u-pem.fr> <0457D70E-7BA2-4A92-AC0E-0E56103F4DE5@oracle.com> Message-ID: <1714212430.1187040.1462345093295.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Paul Sandoz" > Cc: "hotspot-dev developers" , "Core-Libs-Dev" > Envoy?: Mardi 3 Mai 2016 22:03:12 > Objet: Re: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package > > > > On 3 May 2016, at 07:05, Remi Forax wrote: > > > > Looks good to me. > > minor nitpick, neither checkFromToIndex() nor checkFromIndexSize() are > > instrinsic (now !) but i think they also should be annotated with > > @ForceInline in j.u.Objects to avoid the code to be asymmetric or weird if > > one of these methods is intrinsinfied later. > > > > I was tempted, but for the moment i am inclined to leave as is and revisit > if/when necessary. Trying to be conservative when using those annotations. Ok, in fact i wonder if @ForceInline on checkIndex is even useful because the VM considers the implementation as trivial, so it will be routinely inlined. > > Thanks, > Paul. > cheers, R?mi From nadeesh.tv at oracle.com Wed May 4 07:13:41 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Wed, 04 May 2016 12:43:41 +0530 Subject: RFR:JDK-8148949:DateTimeFormatter pattern letters 'A','n','N' In-Reply-To: References: <571E2C01.6050407@oracle.com> <57220C52.5030609@oracle.com> <57226CD7.1060907@oracle.com> Message-ID: <5729A125.1080309@oracle.com> Hi, Updated the webrev http://cr.openjdk.java.net/~ntv/8148949/webrev.03/ Thanks and Regards, Nadeesh On 5/3/2016 8:37 PM, Stephen Colebourne wrote: > The current behaviour is to use NORMAL for "A" and NOT_NEGATIVE for > "AA", "AAA" and so on. The sensible behaviour going forward is to use > NOT_NEGATIVE for all these, simply because the values do not make > sense to be negative. Given how these fields are nigh-on useless as > currently defined, this seems reasonable. > > Stephen > > > On 3 May 2016 at 15:37, Roger Riggs wrote: >> Hi Nadeesh, >> >> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder:1522-1524 >> >> Is the switch from SignStyle.NOT_NEGATIVE to NORMAL intentional? >> >> The ValueRange of MilliOfDay for example is (0, 86400000-1), so negative >> values would be out of range. >> >> Similarly, NanoOfSecond and NanoOfDay are non-negative. (Otherwise, there >> should be test cases for negative values). >> >> Thanks, Roger >> >> >> >> On 4/28/2016 4:04 PM, nadeesh tv wrote: >> >> Hi all, >> Thanks Stephen for the comments. >> Please see the updated webrev >> http://cr.openjdk.java.net/~ntv/8148949/webrev.02/ >> >> Regards, >> Nadeesh >> >> >> On 4/28/2016 7:58 PM, Stephen Colebourne wrote: >> >> I'd like to see the test cases in test_secondsPattern() check the >> result of the parse (by passing more arguments from >> data_secondsPattern) >> >> Otherwise looks good. >> Stephen >> >> On 28 April 2016 at 14:12, nadeesh tv wrote: >> >> Hi all, >> Please see the updated webrev >> http://cr.openjdk.java.net/~ntv/8148949/webrev.01/ >> >> Regards, >> Nadeesh TV >> >> On 4/25/2016 8:08 PM, nadeesh tv wrote: >> >> HI all, >> Please review a fix for >> Bug ID - https://bugs.openjdk.java.net/browse/JDK-8148949 >> >> Issue - Pattern letters 'A' does not match the intent of LDML/CLDR >> >> Solution - Changed the definition of pattern letters 'A','n','N' >> >> Webrev - http://cr.openjdk.java.net/~ntv/8148949/webrev.00/ >> >> >> -- >> Thanks and Regards, >> Nadeesh TV >> >> >> -- Thanks and Regards, Nadeesh TV From nadeesh.tv at oracle.com Wed May 4 07:15:16 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Wed, 04 May 2016 12:45:16 +0530 Subject: RFR:JDK-8079628:java.time: DateTimeFormatter containing "DD" fails on 3-digit day-of-year value In-Reply-To: References: <571F558F.9090008@oracle.com> <57220BCA.5000608@oracle.com> <572250A2.8030709@oracle.com> <8b789366-7479-383c-00ad-8b70adcb9b59@Oracle.com> <57285240.5060004@oracle.com> <1f89d623-e7af-61ae-821c-658be59a3f77@Oracle.com> Message-ID: <5729A184.3010304@oracle.com> Hi, Updated the webev http://cr.openjdk.java.net/~ntv/8079628/webrev.04/ Regards, Nadeesh On 5/3/2016 8:45 PM, Stephen Colebourne wrote: > Letters "Q", "q", "M", "L", "d", "D", "F", "h", "H", "k", "K", "m", > "s" and no doubt others use NORMAL via > > appendValue(field); > > Changing these to use NOT_NEGATIVE would be a big change and doesn't > seem justified. > > For "D", "DD" and "DDD" these seem to be the best balance (as > discussed up-thread): > > * D 1 appendValue(ChronoField.DAY_OF_YEAR) > * DD 2 appendValue(ChronoField.DAY_OF_YEAR, 2, 3, > SignStyle.NOT_NEGATIVE) > * DDD 3 appendValue(ChronoField.DAY_OF_YEAR, 3) > > ie. we use NOT_NEGATIVE when we are making changes to a field and that > is the best option, but otherwise we stick with NORMAL for single > letter patterns like "D". > > Stephen > > > On 3 May 2016 at 15:22, Roger Riggs wrote: >> Hi Nadeesh, >> >> >> On 5/3/2016 3:24 AM, nadeesh tv wrote: >> >> Hi Roger, >> Please see the answers inline >> >> On 5/3/2016 2:43 AM, Roger Riggs wrote: >> >> Hi Nadeesh, >> >> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java >> >> line 1835: the appendValue(field) method has a sign-style of NORMAL; should >> that be NOT_NEGATIVE? >> >> It's 'NOT_NEGATIVE' only. May be a browser caching issue. Can you please >> check it once again. >> >> My question was about the existing case for "D" that uses >> appendValue(field). >> That is a shorthand for: >> appendValue(new NumberPrinterParser(field, 1, 19, SignStyle.NORMAL)); >> >> test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java: >> >> What is being tested in test_dayOfYearFieldPattern? >> It does not check that the value parsed matches the input. >> >> These test cases added initially. Now it's become almost redundant due to >> 'dayOfYearFieldValues' . I could remove it. >> >> If they are redundant, they should be removed. >> >> >> test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java >> >> 686, 688: should these cases show with sign-style NOT_NEGATIVE also? >> >> Suspecting browser caching here also. >> >> I'm referring to the test case for "D", which seems like it should show up >> as NOT_NEGATIVE. >> >> >> Updated the webrev by removing some unnecessary spaces >> http://cr.openjdk.java.net/~ntv/8079628/webrev.03/ >> >> >> Thanks, Roger >> -- Thanks and Regards, Nadeesh TV From peter.levart at gmail.com Wed May 4 07:20:07 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 4 May 2016 09:20:07 +0200 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: References: Message-ID: <5cf3bcb5-49a4-9784-454c-e0b2a61eeceb@gmail.com> Hi Stuart, Good to see these implementations finally appear. I have a few comments: - What's the point of 11 overloaded List.of() methods for 0 ... 10-arity if you then invoke the var-args ListN(E...input) constructor that does the array cloning with 8 of them? The same for Set.of()... I suggest that you don't clone the array in ListN(E... input) constructor but only in List.of(E ... input) method. - {Set0, Set1, Set2}.contains(null) return false, but SetN.contains(null) throws NPE. All List{0,1,2,N}.contains(null) return false. What should be the correct behavior? ConcurrentHashMap.keySet().contains(null) throws NPE for example. - SetN.probe(E pe) and MapN.probe(K pk) invoke ee.equals(pe) and ek.equals(pk) respectively. Although it should be logically equivalent, it has been a practice in collections to invoke the .equals() method on the passed-in argument rather than on individual elements of the collection. - Should unchecked exceptions from constructors be wrapped with InvalidObjectException in SerialProxy.readResolve() or does the Serialization infrastructure already perform the equivalent? Regards, Peter On 05/04/2016 06:55 AM, Stuart Marks wrote: > Hi all, > > This is a reimplementation of collections created by the JEP 269 > convenience factory methods. These implementations are overall quite a > bit smaller than their conventional collections counterparts, > particularly at small sizes. Lookup performance for the hash-based > structures (Set and Map) is not particularly fast, though in most > cases it's comparable to TreeSet/TreeMap. Further improvements are > likely possible. > > There are no API changes in this changeset. > > Please review: > > http://cr.openjdk.java.net/~smarks/reviews/8139233/webrev.0/ > > JEP link: > > http://openjdk.java.net/jeps/269 > > Thanks, > > s'marks From peter.levart at gmail.com Wed May 4 07:50:13 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 4 May 2016 09:50:13 +0200 Subject: RFR: JDK-8150496,(zipfs) Fix performance issues in zip-fs In-Reply-To: <57289BE4.1040605@oracle.com> References: <5727E295.1000303@oracle.com> <57289BE4.1040605@oracle.com> Message-ID: <109bd636-f97a-d4cd-f098-f67a49040ae1@gmail.com> Hi Aleksey, On 05/03/2016 02:39 PM, Aleksey Shipilev wrote: > *) There is ever-so-subtle difference in doing either: > > 171 byte[] tmp = new byte[path.length + 1]; > 172 System.arraycopy(path, 0, tmp, 1, path.length); > 173 tmp[0] = '/'; > > ...or: > > 1083 byte[] name = new byte[nlen + 1]; > 1084 name[0] = '/'; > 1085 System.arraycopy(cen, pos + CENHDR, name, 1, nlen); > > Excess op between allocation and arraycopy breaks zeroing elimination, > see e.g.: > http://cr.openjdk.java.net/~shade/scratch/ZeroingFirstBench.java ...so when allocation of array is immediately followed with arraycopy where the newly allocated array is the target, only the part of the array that is not overwritten by arraycopy will be zeroed? Because not the whole array is overwritten in your example/benchmark. That's good to know. Regards, Peter From vladimir.x.ivanov at oracle.com Wed May 4 08:33:07 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 4 May 2016 11:33:07 +0300 Subject: RFR 8147039 : Incorrect locals and operands in compiled frames In-Reply-To: <5728F54B.8070007@oracle.com> References: <5728F54B.8070007@oracle.com> Message-ID: <5729B3C3.3040202@oracle.com> Looks good. Best regards, Vladimir Ivanov On 5/3/16 10:00 PM, Brent Christian wrote: > Hi, > > Please review this change which fixes buggy behavior (including SEGV) in > the experimental LiveStackFrame feature of StackWalker. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8147039 > Webrev: > http://cr.openjdk.java.net/~bchristi/8147039/webrev.02/ > > As suggested in the bug report, stack walking is reimplemented using > javaVFrame/vframe::java_sender. The native StackWalkerAnchor class is > updated (and renamed) with a similar interface and function to > vframeStream. I've also removed the now-unneeded > vframeStreamCommon::java_frame() function, added by 8140450. > > Thanks, > -Brent From forax at univ-mlv.fr Wed May 4 08:38:11 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 4 May 2016 10:38:11 +0200 (CEST) Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: References: Message-ID: <1715865599.1253418.1462351091150.JavaMail.zimbra@u-pem.fr> Hi Stuart, nice work ! first, all classes should be final otherwise, they are not truly immutable and all arrays should be marked as @Stable. List0, List1, why not using Collections.emptyList(), Collections.singletonList() here ? ListN: - i don't think that extending AbstractList is a good idea here, AbstractList provide the failfast/modCount mecanism not needed here. Moreover, i think you should have some overriden methods on par with Arrays.asList() (i.e. a custom isEmpty, toArray, indexOf, contains, iterator, spliterator and forEach) otherwise people will use Arrays.asList just because it's faster :( - in the constructor, you should use a local variable here, @SafeVarargs ListN(E... input) { // copy and check manually to avoid TOCTOU @SuppressWarnings("unchecked") E[] elements = (E[])new Object[input.length]; // implicit nullcheck of input for (int i = 0; i < input.length; i++) { elements[i] = Objects.requireNonNull(input[i]); } this.elements = elements; } - List2: - same as for ListN, should not inherits from AbstractList. - i wonder why iterator() is not overriden like with Set2. Set2: - again, here, i don't think that inheriting from AbstractSet is a good idea. - in the iterator, pos (position ?) should be private and next() can be written without the '+=', public E next() { if (pos == 0) { pos = 1; return e0; } else if (pos == 1) { pos = 2; return e1; } else { throw new NoSuchElementException(); } } - the iterator should not be defined as inner class (with a reference to Set2) but be defined as a static class that contains a copy of e1 and e2, this will save an indirection and avoid to keep a link on the Set if it is transient. SetN: - in the constructor, use a local variable like for ListN - the @SuppressWarnings for contains is wrong, probe should take an Object, not an E. - the iterator should not be an inner class like Set2 and take the array as parameter. idx should be private. Instead of doing the loop in hasNext and next, the loop should be done once in the constructor and in next. So the code of hasNext will be simple and the JIT will be able to fold a call to hasNext() followed by a call to next(). final static class SetNIterator implements Iterator { private final E[] elements; private int index = nextIndex(0); SetNIterator(E[] elements) { this.elements = elements; } private static int nextIndex(int index) { for(; index < elements.length; index++) { if (elements[index] != null) { return index; } } return -1; } @Override public boolean hasNext() { return index != -1; } @Override public E next() { if (index == -1) { throw new NoSuchElementException(); } E element = elements[index]; index = nextIndex(index + 1); return element; } } - i don't understand how the serialization can work given that the SALT may be different between two VMs MapN: - see SetN :) SerialProxy: - I believe the class SerialProxy should be public, no ? - The constructor should take a Object... to simplify all calls in the different writeReplace. - fields flags and array should be private regards, R?mi ----- Mail original ----- > De: "Stuart Marks" > ?: "core-libs-dev" > Envoy?: Mercredi 4 Mai 2016 06:55:35 > Objet: RFR(m): 8139233 add initial compact immutable collection implementations > > Hi all, > > This is a reimplementation of collections created by the JEP 269 convenience > factory methods. These implementations are overall quite a bit smaller than > their conventional collections counterparts, particularly at small sizes. > Lookup > performance for the hash-based structures (Set and Map) is not particularly > fast, though in most cases it's comparable to TreeSet/TreeMap. Further > improvements are likely possible. > > There are no API changes in this changeset. > > Please review: > > http://cr.openjdk.java.net/~smarks/reviews/8139233/webrev.0/ > > JEP link: > > http://openjdk.java.net/jeps/269 > > Thanks, > > s'marks > From chris.hegarty at oracle.com Wed May 4 08:40:07 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 4 May 2016 09:40:07 +0100 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> Message-ID: On 3 May 2016, at 16:10, Chris Hegarty wrote: >>> >>> Can you please take a look on: >>> http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/ Taking another look over this before sponsoring?. The test library dependency seems to be on java.compiler, and not jdk.compiler, right ? Also, I see no reason for the addition of jdk.zipfs. -Chris. From scolebourne at joda.org Wed May 4 10:00:13 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 4 May 2016 11:00:13 +0100 Subject: RFR:JDK-8148949:DateTimeFormatter pattern letters 'A','n','N' In-Reply-To: <5729A125.1080309@oracle.com> References: <571E2C01.6050407@oracle.com> <57220C52.5030609@oracle.com> <57226CD7.1060907@oracle.com> <5729A125.1080309@oracle.com> Message-ID: Fine by me. thanks Stephen On 4 May 2016 at 08:13, nadeesh tv wrote: > Hi, > > Updated the webrev http://cr.openjdk.java.net/~ntv/8148949/webrev.03/ > > Thanks and Regards, > Nadeesh > > On 5/3/2016 8:37 PM, Stephen Colebourne wrote: >> >> The current behaviour is to use NORMAL for "A" and NOT_NEGATIVE for >> "AA", "AAA" and so on. The sensible behaviour going forward is to use >> NOT_NEGATIVE for all these, simply because the values do not make >> sense to be negative. Given how these fields are nigh-on useless as >> currently defined, this seems reasonable. >> >> Stephen >> >> >> On 3 May 2016 at 15:37, Roger Riggs wrote: >>> >>> Hi Nadeesh, >>> >>> >>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder:1522-1524 >>> >>> Is the switch from SignStyle.NOT_NEGATIVE to NORMAL intentional? >>> >>> The ValueRange of MilliOfDay for example is (0, 86400000-1), so negative >>> values would be out of range. >>> >>> Similarly, NanoOfSecond and NanoOfDay are non-negative. (Otherwise, >>> there >>> should be test cases for negative values). >>> >>> Thanks, Roger >>> >>> >>> >>> On 4/28/2016 4:04 PM, nadeesh tv wrote: >>> >>> Hi all, >>> Thanks Stephen for the comments. >>> Please see the updated webrev >>> http://cr.openjdk.java.net/~ntv/8148949/webrev.02/ >>> >>> Regards, >>> Nadeesh >>> >>> >>> On 4/28/2016 7:58 PM, Stephen Colebourne wrote: >>> >>> I'd like to see the test cases in test_secondsPattern() check the >>> result of the parse (by passing more arguments from >>> data_secondsPattern) >>> >>> Otherwise looks good. >>> Stephen >>> >>> On 28 April 2016 at 14:12, nadeesh tv wrote: >>> >>> Hi all, >>> Please see the updated webrev >>> http://cr.openjdk.java.net/~ntv/8148949/webrev.01/ >>> >>> Regards, >>> Nadeesh TV >>> >>> On 4/25/2016 8:08 PM, nadeesh tv wrote: >>> >>> HI all, >>> Please review a fix for >>> Bug ID - https://bugs.openjdk.java.net/browse/JDK-8148949 >>> >>> Issue - Pattern letters 'A' does not match the intent of LDML/CLDR >>> >>> Solution - Changed the definition of pattern letters 'A','n','N' >>> >>> Webrev - http://cr.openjdk.java.net/~ntv/8148949/webrev.00/ >>> >>> >>> -- >>> Thanks and Regards, >>> Nadeesh TV >>> >>> >>> > > -- > Thanks and Regards, > Nadeesh TV > From Alan.Bateman at oracle.com Wed May 4 10:07:13 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 May 2016 11:07:13 +0100 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> Message-ID: <5729C9D1.5040506@oracle.com> On 04/05/2016 09:40, Chris Hegarty wrote: > On 3 May 2016, at 16:10, Chris Hegarty wrote: > >>>> Can you please take a look on: >>>> http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/ > Taking another look over this before sponsoring?. > > The test library dependency seems to be on java.compiler, and not jdk.compiler, > right ? Also, I see no reason for the addition of jdk.zipfs. > java.compiler is just the API module, the runtime image needs to have jdk.compiler linked in to be useful. So I think @modules jdk.compiler is right here as otherwise the test will be selected when testing a "JRE". java. javac needs the zipfs provider in order to compiler against libraries that are packaged as JAR/zip files so I assume this is why it listed here. -Alan. From daniel.fuchs at oracle.com Wed May 4 10:08:13 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 4 May 2016 12:08:13 +0200 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: References: Message-ID: <8939214f-7974-c50b-8fe0-bfe24f05b77c@oracle.com> Hi Stuart, It will be good to have really immutable collections! But I have one comment: I wonder about serial interoperability with earlier versions of the JDK. For instance it will not be possible to send a Set created with Set.of(...) in JDK 9 to a JDK 8 VM. I wonder if there is any good solution to that. You could of course use writeReplace() to return a plain HashSet - but then you would only get a plain HashSet on the other end. That might be fine if that other end is JDK 8, but maybe not so good if it's actually JDK 9. What worries me is that it will be very easy to forget about the serial incompatibility, and start using these new factory methods in e.g. java.lang.management, and then discover later on that it has introduced an interoperability issue. Is there any good way to prevent that - except thorough code reviews? best regards, -- daniel On 04/05/16 06:55, Stuart Marks wrote: > Hi all, > > This is a reimplementation of collections created by the JEP 269 > convenience factory methods. These implementations are overall quite a > bit smaller than their conventional collections counterparts, > particularly at small sizes. Lookup performance for the hash-based > structures (Set and Map) is not particularly fast, though in most cases > it's comparable to TreeSet/TreeMap. Further improvements are likely > possible. > > There are no API changes in this changeset. > > Please review: > > http://cr.openjdk.java.net/~smarks/reviews/8139233/webrev.0/ > > JEP link: > > http://openjdk.java.net/jeps/269 > > Thanks, > > s'marks From chris.hegarty at oracle.com Wed May 4 10:24:06 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 4 May 2016 11:24:06 +0100 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: <5729C9D1.5040506@oracle.com> References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> <5729C9D1.5040506@oracle.com> Message-ID: On 4 May 2016, at 11:07, Alan Bateman wrote: > On 04/05/2016 09:40, Chris Hegarty wrote: >> On 3 May 2016, at 16:10, Chris Hegarty wrote: >> >>>>> Can you please take a look on: >>>>> http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/ >> Taking another look over this before sponsoring?. >> >> The test library dependency seems to be on java.compiler, and not jdk.compiler, >> right ? Also, I see no reason for the addition of jdk.zipfs. >> > java.compiler is just the API module, the runtime image needs to have jdk.compiler linked in to be useful. So the test depends on both the compiler API and impl, which is implicit with the 'requires public java.compiler? in the jdk.compiler module. That?s fine, and makes sense. > So I think @modules jdk.compiler is right here as otherwise the test will be selected when testing a "JRE". java. javac needs the zipfs provider in order to compiler against libraries that are packaged as JAR/zip files so I assume this is why it listed here. The tests cause compilation of test library classes, but only some tests actually use the methods that provoke compilation. Similar to above, tests that don?t actually compile anything could depend on just java.compiler. This is all to fragile and may cause problems with future refactoring. I think we should add the same set of @moduels to all these tests, rather than an individual set determined by intimate knowledge of the inner workings of the test. @modules java.compiler jdk.compiler jdk.zipfs jdk.jartool with the addition of jdk.httpserver for MultiReleaseJarHttpProperties. -Chris From Alan.Bateman at oracle.com Wed May 4 11:48:11 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 May 2016 12:48:11 +0100 Subject: Review request: 8154190 & 8155513: Deprivilege java.compiler and jdk.charsets In-Reply-To: References: <57244FE7.4000302@oracle.com> Message-ID: <5729E17B.8000501@oracle.com> On 03/05/2016 21:16, Mandy Chung wrote: > I originally asked Sherman to identify the permissions for jdk.charsets as a follow up issue. I took another look and define the list: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155513/webrev.01/ > This looks okay to me. -Alan. From Alan.Bateman at oracle.com Wed May 4 13:22:51 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 May 2016 14:22:51 +0100 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: References: Message-ID: <5729F7AB.6050705@oracle.com> On 04/05/2016 05:55, Stuart Marks wrote: > Hi all, > > This is a reimplementation of collections created by the JEP 269 > convenience factory methods. These implementations are overall quite a > bit smaller than their conventional collections counterparts, > particularly at small sizes. Lookup performance for the hash-based > structures (Set and Map) is not particularly fast, though in most > cases it's comparable to TreeSet/TreeMap. Further improvements are > likely possible. > > There are no API changes in this changeset. > > Please review: > > http://cr.openjdk.java.net/~smarks/reviews/8139233/webrev.0/ This looks very good, but I just wonder about the iteration order varying from run to run in the Set/Map implementations. I recall the section added to the javadoc where it made it very clear that the iteration order is unspecified and subject to change and no issue with that. I'm just thinking about troubleshooting scenarios where it could make some issue harder to diagnose. -Alan From jan.lahoda at oracle.com Wed May 4 13:29:16 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 4 May 2016 15:29:16 +0200 Subject: RFR 8147984: WindowsTerminal should support function keys In-Reply-To: References: <56A21578.5080105@oracle.com> <5726F9E0.4000801@oracle.com> <8e47a023-b313-d40e-7ed7-c91428f2d700@oracle.com> Message-ID: <5729F92C.4030201@oracle.com> On 3.5.2016 14:58, Florent Guillaume wrote: > Hi, > > http://www.x.org/docs/xterm/ctlseqs.pdf is probably a more canonical reference. It seems that this version of the document unfortunately does not specify the codes the terminal sends for the function keys? Jan > > Florent > > > > On Mon, May 2, 2016 at 8:31 PM, Stuart Marks wrote: >> Hi Jan, >> >> Thanks for the update. Including the link is fine, but I'm a bit suspicious >> of the durability of that website -- it appears to be the personal website >> of the current maintainer. Who knows if it'll be around in a couple years. >> >> I'd suggest including in the comment the official title of the document, >> "XTerm Control Sequences" along with a mention of the authors (Moy, Gildea, >> Dickey) so that if the link were to go bad, it would be possible to do a web >> search to find some version of the document. >> >> No need for an updated webrev. >> >> Thanks, >> >> s'marks >> >> >> On 5/1/16 11:55 PM, Jan Lahoda wrote: >>> >>> Hi Stuart, >>> >>> Thanks for the comments and the link! >>> >>> A webrev which includes the link is here: >>> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.01/ >>> >>> Delta webrev to the last iteration is here: >>> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.01/delta/webrev >>> >>> Thanks, >>> Jan >>> >>> On 29.4.2016 23:49, Stuart Marks wrote: >>>> >>>> Hi Jan, >>>> >>>> I finally got a chance to take a look at this. The change looks fine. >>>> >>>> It would be nice to have a reference to where the escape sequences are >>>> documented. There are links to the Windows VK_ codes there, which is >>>> great. But there's no reference for the escape sequences that each >>>> keypress is mapped to, e.g. F4 is "ESC O S", and F5 is "ESC [ 1 5 ~" >>>> (and what happened to "ESC [ 1 6 ~"??) >>>> >>>> I did some searching, and it seems really hard to find a definitive >>>> reference. Perhaps the best reference is "XTerm Control Sequences" [1] >>>> which seems to document xterm pretty thoroughly, which is what everybody >>>> seems to follow nowadays. It even looks like it's being kept up to date >>>> (last modified 2016-02-21). >>>> >>>> Anyway I'd suggest adding a comment with a reference to this document. >>>> >>>> As a cross-check, these sequences match what my Mac's Terminal.app >>>> emits, at least for unshifted F1-F12. (The Terminal app was probably >>>> copied from xterm.) >>>> >>>> Thanks, >>>> >>>> s'marks >>>> >>>> >>>> [1] http://invisible-island.net/xterm/ctlseqs/ctlseqs.html >>>> >>>> >>>> On 1/22/16 3:41 AM, Jan Lahoda wrote: >>>>> >>>>> Hello, >>>>> >>>>> I'd like to enhance the WindowsTerminal in jdk.internal.le with >>>>> function keys >>>>> handling. The intent is so that jshell can bind actions for shortcuts >>>>> including >>>>> function keys. >>>>> >>>>> The patch for adding the function keys support is here: >>>>> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.00/ >>>>> >>>>> An example of a feature that uses/may use this support is here: >>>>> >>>>> http://mail.openjdk.java.net/pipermail/kulla-dev/2016-January/001226.html >>>>> >>>>> Any comments are welcome! >>>>> >>>>> Thanks, >>>>> Jan > > > From Alan.Bateman at oracle.com Wed May 4 13:32:14 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 May 2016 14:32:14 +0100 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> <5729C9D1.5040506@oracle.com> Message-ID: <5729F9DE.4080909@oracle.com> On 04/05/2016 11:24, Chris Hegarty wrote: > : > The tests cause compilation of test library classes, but only some tests > actually use the methods that provoke compilation. Similar to above, tests > that don?t actually compile anything could depend on just java.compiler. > > This is all to fragile and may cause problems with future refactoring. I > think we should add the same set of @moduels to all these tests, rather > than an individual set determined by intimate knowledge of the inner > workings of the test. > > @modules java.compiler > jdk.compiler > jdk.zipfs > jdk.jartool > > with the addition of jdk.httpserver for MultiReleaseJarHttpProperties. > or we could move the tests into their own MultiRelease sub-directory and create a TEST.properties with a module key. That would allow these tests to drop @modules, except the test that uses the HTTP server. -Alan From fguillaume at nuxeo.com Wed May 4 14:12:05 2016 From: fguillaume at nuxeo.com (Florent Guillaume) Date: Wed, 4 May 2016 16:12:05 +0200 Subject: RFR 8147984: WindowsTerminal should support function keys In-Reply-To: <5729F92C.4030201@oracle.com> References: <56A21578.5080105@oracle.com> <5726F9E0.4000801@oracle.com> <8e47a023-b313-d40e-7ed7-c91428f2d700@oracle.com> <5729F92C.4030201@oracle.com> Message-ID: On Wed, May 4, 2016 at 3:29 PM, Jan Lahoda wrote: > On 3.5.2016 14:58, Florent Guillaume wrote: >> http://www.x.org/docs/xterm/ctlseqs.pdf is probably a more canonical >> reference. > > It seems that this version of the document unfortunately does not specify > the codes the terminal sends for the function keys? Apologies, it's an old doc indeed. http://xorg.freedesktop.org/releases/X11R6.8.1/PDF/ctlseqs.pdf seems to contain it. Note that later release of X11 (7.x) don't seem to have this doc included, it seems that 6.8.1 is the last one with it. Florent > Jan >> >> Florent >> >> On Mon, May 2, 2016 at 8:31 PM, Stuart Marks >> wrote: >>> >>> Hi Jan, >>> >>> Thanks for the update. Including the link is fine, but I'm a bit >>> suspicious >>> of the durability of that website -- it appears to be the personal >>> website >>> of the current maintainer. Who knows if it'll be around in a couple >>> years. >>> >>> I'd suggest including in the comment the official title of the document, >>> "XTerm Control Sequences" along with a mention of the authors (Moy, >>> Gildea, >>> Dickey) so that if the link were to go bad, it would be possible to do a >>> web >>> search to find some version of the document. >>> >>> No need for an updated webrev. >>> >>> Thanks, >>> >>> s'marks >>> >>> >>> On 5/1/16 11:55 PM, Jan Lahoda wrote: >>>> >>>> >>>> Hi Stuart, >>>> >>>> Thanks for the comments and the link! >>>> >>>> A webrev which includes the link is here: >>>> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.01/ >>>> >>>> Delta webrev to the last iteration is here: >>>> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.01/delta/webrev >>>> >>>> Thanks, >>>> Jan >>>> >>>> On 29.4.2016 23:49, Stuart Marks wrote: >>>>> >>>>> >>>>> Hi Jan, >>>>> >>>>> I finally got a chance to take a look at this. The change looks fine. >>>>> >>>>> It would be nice to have a reference to where the escape sequences are >>>>> documented. There are links to the Windows VK_ codes there, which is >>>>> great. But there's no reference for the escape sequences that each >>>>> keypress is mapped to, e.g. F4 is "ESC O S", and F5 is "ESC [ 1 5 ~" >>>>> (and what happened to "ESC [ 1 6 ~"??) >>>>> >>>>> I did some searching, and it seems really hard to find a definitive >>>>> reference. Perhaps the best reference is "XTerm Control Sequences" [1] >>>>> which seems to document xterm pretty thoroughly, which is what >>>>> everybody >>>>> seems to follow nowadays. It even looks like it's being kept up to date >>>>> (last modified 2016-02-21). >>>>> >>>>> Anyway I'd suggest adding a comment with a reference to this document. >>>>> >>>>> As a cross-check, these sequences match what my Mac's Terminal.app >>>>> emits, at least for unshifted F1-F12. (The Terminal app was probably >>>>> copied from xterm.) >>>>> >>>>> Thanks, >>>>> >>>>> s'marks >>>>> >>>>> >>>>> [1] http://invisible-island.net/xterm/ctlseqs/ctlseqs.html >>>>> >>>>> >>>>> On 1/22/16 3:41 AM, Jan Lahoda wrote: >>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> I'd like to enhance the WindowsTerminal in jdk.internal.le with >>>>>> function keys >>>>>> handling. The intent is so that jshell can bind actions for shortcuts >>>>>> including >>>>>> function keys. >>>>>> >>>>>> The patch for adding the function keys support is here: >>>>>> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.00/ >>>>>> >>>>>> An example of a feature that uses/may use this support is here: >>>>>> >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/kulla-dev/2016-January/001226.html >>>>>> >>>>>> Any comments are welcome! >>>>>> >>>>>> Thanks, >>>>>> Jan >> >> >> >> > -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87 From Roger.Riggs at Oracle.com Wed May 4 14:22:15 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 4 May 2016 10:22:15 -0400 Subject: RFR:JDK-8148949:DateTimeFormatter pattern letters 'A','n','N' In-Reply-To: References: <571E2C01.6050407@oracle.com> <57220C52.5030609@oracle.com> <57226CD7.1060907@oracle.com> <5729A125.1080309@oracle.com> Message-ID: <97728431-e33b-e5a7-7f55-fcb729e1ca80@Oracle.com> +1 Roger On 5/4/2016 6:00 AM, Stephen Colebourne wrote: > Fine by me. > thanks > Stephen > > On 4 May 2016 at 08:13, nadeesh tv wrote: >> Hi, >> >> Updated the webrev http://cr.openjdk.java.net/~ntv/8148949/webrev.03/ >> >> Thanks and Regards, >> Nadeesh >> >> On 5/3/2016 8:37 PM, Stephen Colebourne wrote: >>> The current behaviour is to use NORMAL for "A" and NOT_NEGATIVE for >>> "AA", "AAA" and so on. The sensible behaviour going forward is to use >>> NOT_NEGATIVE for all these, simply because the values do not make >>> sense to be negative. Given how these fields are nigh-on useless as >>> currently defined, this seems reasonable. >>> >>> Stephen >>> >>> >>> On 3 May 2016 at 15:37, Roger Riggs wrote: >>>> Hi Nadeesh, >>>> >>>> >>>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder:1522-1524 >>>> >>>> Is the switch from SignStyle.NOT_NEGATIVE to NORMAL intentional? >>>> >>>> The ValueRange of MilliOfDay for example is (0, 86400000-1), so negative >>>> values would be out of range. >>>> >>>> Similarly, NanoOfSecond and NanoOfDay are non-negative. (Otherwise, >>>> there >>>> should be test cases for negative values). >>>> >>>> Thanks, Roger >>>> >>>> >>>> >>>> On 4/28/2016 4:04 PM, nadeesh tv wrote: >>>> >>>> Hi all, >>>> Thanks Stephen for the comments. >>>> Please see the updated webrev >>>> http://cr.openjdk.java.net/~ntv/8148949/webrev.02/ >>>> >>>> Regards, >>>> Nadeesh >>>> >>>> >>>> On 4/28/2016 7:58 PM, Stephen Colebourne wrote: >>>> >>>> I'd like to see the test cases in test_secondsPattern() check the >>>> result of the parse (by passing more arguments from >>>> data_secondsPattern) >>>> >>>> Otherwise looks good. >>>> Stephen >>>> >>>> On 28 April 2016 at 14:12, nadeesh tv wrote: >>>> >>>> Hi all, >>>> Please see the updated webrev >>>> http://cr.openjdk.java.net/~ntv/8148949/webrev.01/ >>>> >>>> Regards, >>>> Nadeesh TV >>>> >>>> On 4/25/2016 8:08 PM, nadeesh tv wrote: >>>> >>>> HI all, >>>> Please review a fix for >>>> Bug ID - https://bugs.openjdk.java.net/browse/JDK-8148949 >>>> >>>> Issue - Pattern letters 'A' does not match the intent of LDML/CLDR >>>> >>>> Solution - Changed the definition of pattern letters 'A','n','N' >>>> >>>> Webrev - http://cr.openjdk.java.net/~ntv/8148949/webrev.00/ >>>> >>>> >>>> -- >>>> Thanks and Regards, >>>> Nadeesh TV >>>> >>>> >>>> >> -- >> Thanks and Regards, >> Nadeesh TV >> From Roger.Riggs at Oracle.com Wed May 4 14:28:57 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 4 May 2016 10:28:57 -0400 Subject: RFR:JDK-8079628:java.time: DateTimeFormatter containing "DD" fails on 3-digit day-of-year value In-Reply-To: <5729A184.3010304@oracle.com> References: <571F558F.9090008@oracle.com> <57220BCA.5000608@oracle.com> <572250A2.8030709@oracle.com> <8b789366-7479-383c-00ad-8b70adcb9b59@Oracle.com> <57285240.5060004@oracle.com> <1f89d623-e7af-61ae-821c-658be59a3f77@Oracle.com> <5729A184.3010304@oracle.com> Message-ID: Hi Nadeesh, java/time/format/DateTimeFormatterBuilder.java: 1836-1839 Correct as is, but could collapse both count ==2 and count ==3 into a single appendValue call: appendValue(field, count, 3, SignStyle.NOT_NEGATIVE); Reviewed. Roger On 5/4/2016 3:15 AM, nadeesh tv wrote: > Hi, > Updated the webev http://cr.openjdk.java.net/~ntv/8079628/webrev.04/ > Regards, > Nadeesh > On 5/3/2016 8:45 PM, Stephen Colebourne wrote: >> Letters "Q", "q", "M", "L", "d", "D", "F", "h", "H", "k", "K", "m", >> "s" and no doubt others use NORMAL via >> >> appendValue(field); >> >> Changing these to use NOT_NEGATIVE would be a big change and doesn't >> seem justified. >> >> For "D", "DD" and "DDD" these seem to be the best balance (as >> discussed up-thread): >> >> * D 1 appendValue(ChronoField.DAY_OF_YEAR) >> * DD 2 appendValue(ChronoField.DAY_OF_YEAR, 2, 3, >> SignStyle.NOT_NEGATIVE) >> * DDD 3 appendValue(ChronoField.DAY_OF_YEAR, 3) >> >> ie. we use NOT_NEGATIVE when we are making changes to a field and that >> is the best option, but otherwise we stick with NORMAL for single >> letter patterns like "D". >> >> Stephen >> >> >> On 3 May 2016 at 15:22, Roger Riggs wrote: >>> Hi Nadeesh, >>> >>> >>> On 5/3/2016 3:24 AM, nadeesh tv wrote: >>> >>> Hi Roger, >>> Please see the answers inline >>> >>> On 5/3/2016 2:43 AM, Roger Riggs wrote: >>> >>> Hi Nadeesh, >>> >>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java >>> >>> >>> line 1835: the appendValue(field) method has a sign-style of NORMAL; >>> should >>> that be NOT_NEGATIVE? >>> >>> It's 'NOT_NEGATIVE' only. May be a browser caching issue. Can you >>> please >>> check it once again. >>> >>> My question was about the existing case for "D" that uses >>> appendValue(field). >>> That is a shorthand for: >>> appendValue(new NumberPrinterParser(field, 1, 19, >>> SignStyle.NORMAL)); >>> >>> test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java: >>> >>> What is being tested in test_dayOfYearFieldPattern? >>> It does not check that the value parsed matches the input. >>> >>> These test cases added initially. Now it's become almost redundant >>> due to >>> 'dayOfYearFieldValues' . I could remove it. >>> >>> If they are redundant, they should be removed. >>> >>> >>> test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java >>> >>> 686, 688: should these cases show with sign-style NOT_NEGATIVE also? >>> >>> Suspecting browser caching here also. >>> >>> I'm referring to the test case for "D", which seems like it should >>> show up >>> as NOT_NEGATIVE. >>> >>> >>> Updated the webrev by removing some unnecessary spaces >>> http://cr.openjdk.java.net/~ntv/8079628/webrev.03/ >>> >>> >>> Thanks, Roger >>> > From tadamski at redhat.com Wed May 4 14:36:20 2016 From: tadamski at redhat.com (Tomasz Adamski) Date: Wed, 4 May 2016 10:36:20 -0400 (EDT) Subject: RFR: 8152084: Introduction of ssliop protocol to corbaloc In-Reply-To: <5728AF76.9020406@oracle.com> References: <321794846.38762864.1461088691787.JavaMail.zimbra@redhat.com> <5728A7AC.8000103@redhat.com> <5728AF76.9020406@oracle.com> Message-ID: <63067504.43350431.1462372580193.JavaMail.zimbra@redhat.com> I'm proposing this extension from practical reasons as it would enable configuration of fully secured iiop invocations - the feature that was present in ORB implementation that we used previously (JacORB). ORB specification allows adding new corbaloc protocols if necessary: "This specification only defines use of iiop with corbaloc. New protocols can be added to corbaloc as required. Each new protocol must implement the component of the URL and define described in corbaloc URL." ORB Architecture Specification v3.3, Part 2: CORBA Interoperability, 7.6.10.6 Regards, Tomek -- Tomasz Adamski Software Engineer JBoss by Red Hat ----- Original Message ----- > From: "Alan Bateman" > To: "Andrew Dinn" , "Tomasz Adamski" , core-libs-dev at openjdk.java.net > Sent: Tuesday, May 3, 2016 4:02:30 PM > Subject: Re: RFR: 8152084: Introduction of ssliop protocol to corbaloc > > On 03/05/2016 14:29, Andrew Dinn wrote: > > > > On 19/04/16 18:58, Tomasz Adamski wrote: > >> Hello All, > >> > >> I would like to propose an extension to corbaloc resolution - the > >> ssliop protocol. IORs created from corbaloc url with ssliop protocol > >> will contain SSL tagged component with indication that secured > >> invocation is required. As a result, connection to the resolved > >> object will have to be secured. > >> > >> I'm attaching a webrev of proposed enhancement: > >> http://cr.openjdk.java.net/~adinn/tomaszadamski/8152084/ > >> > >> Regards, Tomek > > Would someone care to comment on this enhancement which was proposed 2 > > weeks ago and has had no response? At the very least can someone confirm > > whether this is the right list for such discussion? > > > There isn't a specific list for CORBA here so using core-libs-dev should > be fine. > > In general then CORBA is legacy so it somewhat surprising to look at > rev'ing the API in the JDK now. I think it is >12 years since there has > been any updates. Do you, or Tomek, have any references to the OMG specs > for the proposal? > > -Alan. > From felix.yang at oracle.com Wed May 4 14:39:16 2016 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 4 May 2016 22:39:16 +0800 Subject: RFR 8155088, Fix module dependencies in java/sql/* and javax/* tests In-Reply-To: <57230C62.7010607@oracle.com> References: <8a466652-c0da-1f0c-8272-d1b51bea6c73@oracle.com> <57230C62.7010607@oracle.com> Message-ID: <136f5ce3-e751-c062-f486-6cd18fb4809e@oracle.com> Hi Alan, please review the updated webrev. Reverted changes for those tests with "-addmods". http://cr.openjdk.java.net/~xiaofeya/8155088/webrev.01/ Thanks, Felix On 2016/4/29 15:25, Alan Bateman wrote: > On 29/04/2016 03:16, Felix Yang wrote: >> Hi there, >> >> please review the changes to explicitly declare module >> dependencies for "java/sql/*" and "javax/*" tests; >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8155088 >> >> Webrev: http://cr.openjdk.java.net/~xiaofeya/8155088/webrev.00/ > Felix - would it be disruptive to you if I asked to hold off on this > until we get the changes in jake pushed to jdk9/dev (next week). The > reason is that this we've changed most of these tests in jake to use > -addmods. We've also replaced the TEST.properties for the > javax.transaction tests so that they are run with a driver class > instead. This is also related to the policy for root modules which > impacts the tests that we have for the EE modules in the jdk repo. > > -Alan From nadeesh.tv at oracle.com Wed May 4 14:40:56 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Wed, 04 May 2016 20:10:56 +0530 Subject: RFR:JDK-8079628:java.time: DateTimeFormatter containing "DD" fails on 3-digit day-of-year value In-Reply-To: References: <571F558F.9090008@oracle.com> <57220BCA.5000608@oracle.com> <572250A2.8030709@oracle.com> <8b789366-7479-383c-00ad-8b70adcb9b59@Oracle.com> <57285240.5060004@oracle.com> <1f89d623-e7af-61ae-821c-658be59a3f77@Oracle.com> <5729A184.3010304@oracle.com> Message-ID: <572A09F8.6010503@oracle.com> Hi Roger, Ok. Thanks. Regards, Nadeesh On 5/4/2016 7:58 PM, Roger Riggs wrote: > Hi Nadeesh, > > java/time/format/DateTimeFormatterBuilder.java: 1836-1839 > > Correct as is, but could collapse both count ==2 and count ==3 into a > single appendValue call: > > appendValue(field, count, 3, SignStyle.NOT_NEGATIVE); Reviewed. > > Roger > > > On 5/4/2016 3:15 AM, nadeesh tv wrote: >> Hi, >> Updated the webev http://cr.openjdk.java.net/~ntv/8079628/webrev.04/ >> Regards, >> Nadeesh >> On 5/3/2016 8:45 PM, Stephen Colebourne wrote: >>> Letters "Q", "q", "M", "L", "d", "D", "F", "h", "H", "k", "K", "m", >>> "s" and no doubt others use NORMAL via >>> >>> appendValue(field); >>> >>> Changing these to use NOT_NEGATIVE would be a big change and doesn't >>> seem justified. >>> >>> For "D", "DD" and "DDD" these seem to be the best balance (as >>> discussed up-thread): >>> >>> * D 1 appendValue(ChronoField.DAY_OF_YEAR) >>> * DD 2 appendValue(ChronoField.DAY_OF_YEAR, 2, 3, >>> SignStyle.NOT_NEGATIVE) >>> * DDD 3 appendValue(ChronoField.DAY_OF_YEAR, 3) >>> >>> ie. we use NOT_NEGATIVE when we are making changes to a field and that >>> is the best option, but otherwise we stick with NORMAL for single >>> letter patterns like "D". >>> >>> Stephen >>> >>> >>> On 3 May 2016 at 15:22, Roger Riggs wrote: >>>> Hi Nadeesh, >>>> >>>> >>>> On 5/3/2016 3:24 AM, nadeesh tv wrote: >>>> >>>> Hi Roger, >>>> Please see the answers inline >>>> >>>> On 5/3/2016 2:43 AM, Roger Riggs wrote: >>>> >>>> Hi Nadeesh, >>>> >>>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java >>>> >>>> >>>> line 1835: the appendValue(field) method has a sign-style of >>>> NORMAL; should >>>> that be NOT_NEGATIVE? >>>> >>>> It's 'NOT_NEGATIVE' only. May be a browser caching issue. Can you >>>> please >>>> check it once again. >>>> >>>> My question was about the existing case for "D" that uses >>>> appendValue(field). >>>> That is a shorthand for: >>>> appendValue(new NumberPrinterParser(field, 1, 19, >>>> SignStyle.NORMAL)); >>>> >>>> test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java: >>>> >>>> What is being tested in test_dayOfYearFieldPattern? >>>> It does not check that the value parsed matches the input. >>>> >>>> These test cases added initially. Now it's become almost redundant >>>> due to >>>> 'dayOfYearFieldValues' . I could remove it. >>>> >>>> If they are redundant, they should be removed. >>>> >>>> >>>> test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java >>>> >>>> 686, 688: should these cases show with sign-style NOT_NEGATIVE also? >>>> >>>> Suspecting browser caching here also. >>>> >>>> I'm referring to the test case for "D", which seems like it should >>>> show up >>>> as NOT_NEGATIVE. >>>> >>>> >>>> Updated the webrev by removing some unnecessary spaces >>>> http://cr.openjdk.java.net/~ntv/8079628/webrev.03/ >>>> >>>> >>>> Thanks, Roger >>>> >> > -- Thanks and Regards, Nadeesh TV From Alan.Bateman at oracle.com Wed May 4 14:45:24 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 May 2016 15:45:24 +0100 Subject: RFR 8155088, Fix module dependencies in java/sql/* and javax/* tests In-Reply-To: <136f5ce3-e751-c062-f486-6cd18fb4809e@oracle.com> References: <8a466652-c0da-1f0c-8272-d1b51bea6c73@oracle.com> <57230C62.7010607@oracle.com> <136f5ce3-e751-c062-f486-6cd18fb4809e@oracle.com> Message-ID: <572A0B04.5000502@oracle.com> On 04/05/2016 15:39, Felix Yang wrote: > Hi Alan, > > please review the updated webrev. Reverted changes for those tests > with "-addmods". > > http://cr.openjdk.java.net/~xiaofeya/8155088/webrev.01/ For the javax.transaction test then don't you also add "java.transaction" in the @modules value? The rest looks fine. -Alan From aleksey.shipilev at oracle.com Wed May 4 14:48:56 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 4 May 2016 17:48:56 +0300 Subject: RFR: JDK-8150496,(zipfs) Fix performance issues in zip-fs In-Reply-To: <109bd636-f97a-d4cd-f098-f67a49040ae1@gmail.com> References: <5727E295.1000303@oracle.com> <57289BE4.1040605@oracle.com> <109bd636-f97a-d4cd-f098-f67a49040ae1@gmail.com> Message-ID: <572A0BD8.1070307@oracle.com> On 05/04/2016 10:50 AM, Peter Levart wrote: > On 05/03/2016 02:39 PM, Aleksey Shipilev wrote: >> *) There is ever-so-subtle difference in doing either: >> >> 171 byte[] tmp = new byte[path.length + 1]; >> 172 System.arraycopy(path, 0, tmp, 1, path.length); >> 173 tmp[0] = '/'; >> >> ...or: >> >> 1083 byte[] name = new byte[nlen + 1]; >> 1084 name[0] = '/'; >> 1085 System.arraycopy(cen, pos + CENHDR, name, 1, nlen); >> >> Excess op between allocation and arraycopy breaks zeroing elimination, >> see e.g.: >> http://cr.openjdk.java.net/~shade/scratch/ZeroingFirstBench.java > > ...so when allocation of array is immediately followed with arraycopy > where the newly allocated array is the target, only the part of the > array that is not overwritten by arraycopy will be zeroed? Because not > the whole array is overwritten in your example/benchmark. That's good to > know. Yes, only not overwritten part would be zeroed. This is a little trick in C2. I think it works only for heads/tails, not for arbitrary overwrites. So it is a limited micro-optimization here. -Aleksey From adinn at redhat.com Wed May 4 14:53:22 2016 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 4 May 2016 15:53:22 +0100 Subject: RFR: 8152084: Introduction of ssliop protocol to corbaloc In-Reply-To: <63067504.43350431.1462372580193.JavaMail.zimbra@redhat.com> References: <321794846.38762864.1461088691787.JavaMail.zimbra@redhat.com> <5728A7AC.8000103@redhat.com> <5728AF76.9020406@oracle.com> <63067504.43350431.1462372580193.JavaMail.zimbra@redhat.com> Message-ID: <572A0CE2.8020101@redhat.com> On 04/05/16 15:36, Tomasz Adamski wrote: > I'm proposing this extension from practical reasons as it would > enable configuration of fully secured iiop invocations - the feature > that was present in ORB implementation that we used previously > (JacORB). ORB specification allows adding new corbaloc protocols if > necessary: > > "This specification only defines use of iiop with corbaloc. New > protocols can be added to corbaloc as required. Each new protocol > must implement the component of the URL and define > described in corbaloc URL." ORB Architecture Specification v3.3, Part > 2: CORBA Interoperability, 7.6.10.6 Just to dispel any idea that this has been plucked out of thin air by the JacORB implementors I'll note that there appears to be both a standard for and more than one implementation of ssliop. Regarding implementations, OpenORB and TAO also implemented it. As regards standardization I think the relevant info is in the interop documentation found at http://www.omg.org/spec/CORBA/3.3/. Look in part 2 of the spec dealing with interoperability and search for IIOP/SSL. Tomek may be able to clarify whether that provides all the relevant information. regards, Andrew Dinn ----------- From aleksey.shipilev at oracle.com Wed May 4 14:57:07 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 4 May 2016 17:57:07 +0300 Subject: RFR: JDK-8150496,(zipfs) Fix performance issues in zip-fs In-Reply-To: <572907B4.1020305@oracle.com> References: <5727E295.1000303@oracle.com> <57289BE4.1040605@oracle.com> <572907B4.1020305@oracle.com> Message-ID: <572A0DC3.4070306@oracle.com> Hi Sherman, On 05/03/2016 11:19 PM, Xueming Shen wrote: > Again, thanks for the review. The webrev has been updated accordingly, > as well as the MyBenchmark.java (to use Blackhole, as suggested) > > http://cr.openjdk.java.net/~sherman/8150496/webrev/ Further nits, sorry for not catching them earlier: *) You can drop "public" from the ZipFileAttributes interface. *) Replace this: 109 if (!writeable) { 110 this.readOnly = true; 111 } with this? this.readOnly = !writeable; *) Parentheses to nail down eval order: if (w && zfs.isReadOnly() || x) { ...to: if ((w && zfs.isReadOnly()) || x) { > http://cr.openjdk.java.net/~sherman/8150496/MyBenchmark.java @Benchmark public void ZFS_newInputStream() throws Throwable { for (Path p : entriesP) { if (Files.isRegularFile(p)) { int n = 0; try (InputStream is = Files.newInputStream(p)) { n += is.available(); } } } } ...to @Benchmark public void ZFS_newInputStream(Blackhole bh) throws Throwable { for (Path p : entriesP) { if (Files.isRegularFile(p)) { try (InputStream is = Files.newInputStream(p)) { bh.consume(is.available()); } } } } Does performance still improve on fixed benchmark? Thanks, -Aleksey From vladimir.x.ivanov at oracle.com Wed May 4 15:16:31 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 4 May 2016 18:16:31 +0300 Subject: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package In-Reply-To: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> References: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> Message-ID: <572A124F.4000000@oracle.com> Looks good. Best regards, Vladimir Ivanov On 5/3/16 1:37 AM, Paul Sandoz wrote: > Hi, > > Please review: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-hotspot/webrev/ > > This patch is based on that for 8155258 (VarHandle impl improvements) [1] sent previously. > > The hotspot changes are really small. Likewise for the 8155258 changes is there is precedent in such cases to push through jdk9-dev rather than hs? > > CCC reviewers strongly indicated for the advanced methods that can customise the exceptions: "You aren't gonna need it?. > > For expediency I propose to move such methods to an internal class jdk.internal.util.Preconditions. I would still like to sweep through java.base and leverage these methods while preserving exception reporting where possible. > > The hotspot changes are just for renaming of the intrinsic method signatures. Since the intrinsic method is now internal i have added an @ForceInline on the corresponding public method, given the potential for this to be used in performance sensitive code. > > > JPRT core and hotspot tests pass. > > Paul. > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040740.html > From scolebourne at joda.org Wed May 4 15:25:32 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 4 May 2016 16:25:32 +0100 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: References: Message-ID: A new instance is being created each time for size-zero lists/sets/maps. This should return a singleton. The serialization proxy is reminiscent of those in JSR-310 but less space efficient. Once per stream, the proxy will write "java.util.ImmutableCollections.SerialProxy", whereas the JSR-310 one is "java.time.Ser". Thats about 29 bytes more than it needs too. ie. a package-scoped java.util.Ser would be more efficient. There are no messages for IndexOutOfBoundsException. Like Peter, I'm not convinced that extending AbstractList is the way to go, although I can see arguments both ways. equals() and hashCode() could be optimized on the size 0, 1 and 2 classes, as probably can some other methods. Should spliterator() should be overridden to add the IMMUTABLE flag? For maps, I implemented this years ago which may be of interest: http://commons.apache.org/proper/commons-collections/xref/org/apache/commons/collections4/map/Flat3Map.html#L72 I disagree with altering the iteration order. Guava's ImmutableSet and ImmutableMap have reliable iteration specified to match creation order. This aspect of the design is very useful. Stephen On 4 May 2016 at 05:55, Stuart Marks wrote: > Hi all, > > This is a reimplementation of collections created by the JEP 269 convenience > factory methods. These implementations are overall quite a bit smaller than > their conventional collections counterparts, particularly at small sizes. > Lookup performance for the hash-based structures (Set and Map) is not > particularly fast, though in most cases it's comparable to TreeSet/TreeMap. > Further improvements are likely possible. > > There are no API changes in this changeset. > > Please review: > > http://cr.openjdk.java.net/~smarks/reviews/8139233/webrev.0/ > > JEP link: > > http://openjdk.java.net/jeps/269 > > Thanks, > > s'marks From chris.hegarty at oracle.com Wed May 4 15:30:38 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 4 May 2016 16:30:38 +0100 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: <5729F9DE.4080909@oracle.com> References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> <5729C9D1.5040506@oracle.com> <5729F9DE.4080909@oracle.com> Message-ID: <907375E5-2BB6-42FF-9259-3CE8A2D06665@oracle.com> On 4 May 2016, at 14:32, Alan Bateman wrote: > > On 04/05/2016 11:24, Chris Hegarty wrote: >> : >> The tests cause compilation of test library classes, but only some tests >> actually use the methods that provoke compilation. Similar to above, tests >> that don?t actually compile anything could depend on just java.compiler. >> >> This is all to fragile and may cause problems with future refactoring. I >> think we should add the same set of @moduels to all these tests, rather >> than an individual set determined by intimate knowledge of the inner >> workings of the test. >> >> @modules java.compiler >> jdk.compiler >> jdk.zipfs >> jdk.jartool >> >> with the addition of jdk.httpserver for MultiReleaseJarHttpProperties. >> > or we could move the tests into their own MultiRelease sub-directory and create a TEST.properties with a module key. That would allow these tests to drop @modules, except the test that uses the HTTP server. I think that would be better. -Chris. From Alan.Bateman at oracle.com Wed May 4 15:37:56 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 May 2016 16:37:56 +0100 Subject: RFR: 8152084: Introduction of ssliop protocol to corbaloc In-Reply-To: <572A0CE2.8020101@redhat.com> References: <321794846.38762864.1461088691787.JavaMail.zimbra@redhat.com> <5728A7AC.8000103@redhat.com> <5728AF76.9020406@oracle.com> <63067504.43350431.1462372580193.JavaMail.zimbra@redhat.com> <572A0CE2.8020101@redhat.com> Message-ID: <572A1754.8000507@oracle.com> On 04/05/2016 15:53, Andrew Dinn wrote: > : > Just to dispel any idea that this has been plucked out of thin air by > the JacORB implementors I'll note that there appears to be both a > standard for and more than one implementation of ssliop. > > Regarding implementations, OpenORB and TAO also implemented it. > > As regards standardization I think the relevant info is in the interop > documentation found at http://www.omg.org/spec/CORBA/3.3/. Look in part > 2 of the spec dealing with interoperability and search for IIOP/SSL. > Tomek may be able to clarify whether that provides all the relevant > information. > I have a general concern that this might be overlaying part of CORBA 3.3 over an API/implementation that is based on CORBA 2.3.1. I don't know what the compliance issues are here and what certification is required to claim CORBA 3.3 or even partial compliance. So I expect there is more work to do than might initially seem. Aside from stating compliance then this will require tests and I don't see these in the patch. I don't see any javadoc either (I realize some of strangely named classes might be generated from IDL). -Alan From felix.yang at oracle.com Wed May 4 15:44:01 2016 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 4 May 2016 23:44:01 +0800 Subject: RFR 8155088, Fix module dependencies in java/sql/* and javax/* tests In-Reply-To: <572A0B04.5000502@oracle.com> References: <8a466652-c0da-1f0c-8272-d1b51bea6c73@oracle.com> <57230C62.7010607@oracle.com> <136f5ce3-e751-c062-f486-6cd18fb4809e@oracle.com> <572A0B04.5000502@oracle.com> Message-ID: <0ef38c22-33a8-8a2b-bc46-7cfaba1bb15e@oracle.com> Hi Alan, On 2016/5/4 22:45, Alan Bateman wrote: > > > On 04/05/2016 15:39, Felix Yang wrote: >> Hi Alan, >> >> please review the updated webrev. Reverted changes for those >> tests with "-addmods". >> >> http://cr.openjdk.java.net/~xiaofeya/8155088/webrev.01/ > For the javax.transaction test then don't you also add > "java.transaction" in the @modules value? The rest looks fine. I'm a bit confused here. There is "-addmods java.transaction" for @compile. Is it still necessary to declare in @modules? Actually, if add java.transaction in the @modules, the test will be skipped by jtreg. Filed https://bugs.openjdk.java.net/browse/CODETOOLS-7901671 for jtreg, because it looks to be not a good practice for either situation. -Felix > > -Alan From alexandre.iline at oracle.com Wed May 4 15:55:08 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 4 May 2016 08:55:08 -0700 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: <907375E5-2BB6-42FF-9259-3CE8A2D06665@oracle.com> References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> <5729C9D1.5040506@oracle.com> <5729F9DE.4080909@oracle.com> <907375E5-2BB6-42FF-9259-3CE8A2D06665@oracle.com> Message-ID: <7EA704D5-9C0D-416C-89E8-FA31A4A13DD5@oracle.com> This makes sense - I will move the tests into a subduer, put the dependencies into a TEST.properties file. jdk.zipfs has the code needed for access jars - the tests are failing without that dependency. Shura > On May 4, 2016, at 8:30 AM, Chris Hegarty wrote: > > On 4 May 2016, at 14:32, Alan Bateman wrote: >> >> On 04/05/2016 11:24, Chris Hegarty wrote: >>> : >>> The tests cause compilation of test library classes, but only some tests >>> actually use the methods that provoke compilation. Similar to above, tests >>> that don?t actually compile anything could depend on just java.compiler. >>> >>> This is all to fragile and may cause problems with future refactoring. I >>> think we should add the same set of @moduels to all these tests, rather >>> than an individual set determined by intimate knowledge of the inner >>> workings of the test. >>> >>> @modules java.compiler >>> jdk.compiler >>> jdk.zipfs >>> jdk.jartool >>> >>> with the addition of jdk.httpserver for MultiReleaseJarHttpProperties. >>> >> or we could move the tests into their own MultiRelease sub-directory and create a TEST.properties with a module key. That would allow these tests to drop @modules, except the test that uses the HTTP server. > > I think that would be better. > > -Chris. From vladimir.x.ivanov at oracle.com Wed May 4 16:19:48 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 4 May 2016 19:19:48 +0300 Subject: RFR 8155258: VarHandle implementation improvements In-Reply-To: <43CCC631-B8BA-40BF-A292-7F1ED00FDCDD@oracle.com> References: <43CCC631-B8BA-40BF-A292-7F1ED00FDCDD@oracle.com> Message-ID: <572A2124.9030600@oracle.com> Looks good. I'm fine with pushing it directly into jdk9/dev, since the change just relaxes the assert and the risk of a merge conflict is very small. Best regards, Vladimir Ivanov PS: I wonder whether the MH cache in VarHandle (VarHandle.typesAndInvokers.methodHandle_table) should be idempotent or not. In the past, we had to make some caches in j.l.i idempotent (specifically, Invokers.invokers and MethodTypeForm.methodHandles). The problem was that the JVM can cache a method the MH points to (e.g., inline caches in generated code for MH invokers). If it happens, the JVM doesn't expect to observe 2 different instances of the MH, otherwise an assertion is fired. I can't say for sure it's not the case for VarHandles as well. On 5/3/16 1:18 AM, Paul Sandoz wrote: > Hi, > > Please review: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-hotspot/webrev/ > > The hotspot changes are really small. Is there is precedent in such cases to push through jdk9-dev rather than hs, thus speeding up the integration? > > There are a bunch of improvements (mostly space/time): > > 1) By default a VarHandle does not hold its method types for access mode methods. Instead the erased types are held on VarForm (this shared across many VH instances) and are leveraged by the guard methods (see 4). > 1.1) The non-erased method types are created on demand and cached (see 3). > > 2) Remove the use of ClassValue to hold VarForm instances. Each VarHandle implement holds its VarForm as a static instance. MemberNames to each access mode method implementation are still calculated on construction (this can be revisited to be lazy as a further issue). > > 3) A VarHandle caches invoker-based MethodHandles (access mode method type prefixed with VarHandle as the first parameter) to the corresponding MemberNames held on VarForm. Such handles are used by the VarHandle.toMethodHandle, by the guard methods (see 4), or general linkers/invokers. > > 4) The guard methods (on VarHandleGuards) were revamped to: > 4.1) leverage the erased types in 1) > 4.2) optimize for the void calling case (dropping the return value) when linking to a non-void access mode method. This is an edge case but avoids surprises (e.g. dropping the return value of a CompareAndExchange). This leverages a little known fact of invokehandle linking where it is safe to drop the return value (John assures me this is safe!), and required a slight tweak to hotspot for verification under fastdebug execution. > 4.3) leverage the cached invoker method handle in 3) for the case where boxing/conversion is required, with an asType transformation. This is the non-optimal path, but is much better than before since the invoker method handle is a constant. > > > JPRT core and hotspot tests pass. > > Paul. > From paul.sandoz at oracle.com Wed May 4 16:47:56 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 4 May 2016 09:47:56 -0700 Subject: RFR 8155258: VarHandle implementation improvements In-Reply-To: <572A2124.9030600@oracle.com> References: <43CCC631-B8BA-40BF-A292-7F1ED00FDCDD@oracle.com> <572A2124.9030600@oracle.com> Message-ID: <6EBE2FD8-C909-44A7-9ECE-5E0737BD023C@oracle.com> > On 4 May 2016, at 09:19, Vladimir Ivanov wrote: > > Looks good. > > I'm fine with pushing it directly into jdk9/dev, since the change just relaxes the assert and the risk of a merge conflict is very small. > Thanks! > Best regards, > Vladimir Ivanov > > PS: I wonder whether the MH cache in VarHandle (VarHandle.typesAndInvokers.methodHandle_table) should be idempotent or not. > I am guessing you mean in terms of the MH ref identity? > In the past, we had to make some caches in j.l.i idempotent (specifically, Invokers.invokers and MethodTypeForm.methodHandles). > > The problem was that the JVM can cache a method the MH points to (e.g., inline caches in generated code for MH invokers). If it happens, the JVM doesn't expect to observe 2 different instances of the MH, otherwise an assertion is fired. > > I can't say for sure it's not the case for VarHandles as well. > Ok, i will take a closer look at the existing caches (i did look at those for inspiration) and follow up. I might need to synchronise the update. FWIW there are also cases in MethodHandleImpl where MHs are cached without synchronization, perhaps such constraints don?t matter in these cases? Paul. From vladimir.x.ivanov at oracle.com Wed May 4 17:23:00 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 4 May 2016 20:23:00 +0300 Subject: RFR 8155258: VarHandle implementation improvements In-Reply-To: <6EBE2FD8-C909-44A7-9ECE-5E0737BD023C@oracle.com> References: <43CCC631-B8BA-40BF-A292-7F1ED00FDCDD@oracle.com> <572A2124.9030600@oracle.com> <6EBE2FD8-C909-44A7-9ECE-5E0737BD023C@oracle.com> Message-ID: <572A2FF4.60802@oracle.com> >> >> PS: I wonder whether the MH cache in VarHandle (VarHandle.typesAndInvokers.methodHandle_table) should be idempotent or not. >> > > I am guessing you mean in terms of the MH ref identity? Yes, but I think it matters only if bytecode spinning happens (it does for LambdaForms). What matters for the JVM is the method MH points to (through MH.form.vmentry.vmtarget). So, if a method handle always points to the same method, a race when publishing the handle should be benign. Best regards, Vladimir Ivanov > > >> In the past, we had to make some caches in j.l.i idempotent (specifically, Invokers.invokers and MethodTypeForm.methodHandles). >> >> The problem was that the JVM can cache a method the MH points to (e.g., inline caches in generated code for MH invokers). If it happens, the JVM doesn't expect to observe 2 different instances of the MH, otherwise an assertion is fired. >> >> I can't say for sure it's not the case for VarHandles as well. >> > > Ok, i will take a closer look at the existing caches (i did look at those for inspiration) and follow up. I might need to synchronise the update. > > FWIW there are also cases in MethodHandleImpl where MHs are cached without synchronization, perhaps such constraints don?t matter in these cases? > > Paul. > From xueming.shen at oracle.com Wed May 4 19:14:00 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 04 May 2016 12:14:00 -0700 Subject: RFR: JDK-8150496,(zipfs) Fix performance issues in zip-fs In-Reply-To: <572A0DC3.4070306@oracle.com> References: <5727E295.1000303@oracle.com> <57289BE4.1040605@oracle.com> <572907B4.1020305@oracle.com> <572A0DC3.4070306@oracle.com> Message-ID: <572A49F8.4050304@oracle.com> Hi Aleksey, The webrev has been updated accordingly. http://cr.openjdk.java.net/~sherman/8150496/webrev --------------------------------------------------------------- *) Parentheses to nail down eval order: if (w&& zfs.isReadOnly() || x) { ...to: if ((w&& zfs.isReadOnly()) || x) { -------------------------------------------------------------- updated, but just like to know if this triggers performance difference? not likely for me though. yes, the performance gains still hold. Benchmark Mode Cnt Score Error Units -------------------------------new------------------------------------------- MyBenchmark.ZFS_Exists avgt 50 4.140 ? 0.374 ms/op MyBenchmark.ZFS_GetPath avgt 50 12.521 ? 2.003 ms/op MyBenchmark.ZFS_GetPathExists avgt 50 20.931 ? 1.986 ms/op MyBenchmark.ZFS_GetPathIsDirectory avgt 50 25.531 ? 1.322 ms/op MyBenchmark.ZFS_GetPathIsRegularFile avgt 50 26.971 ? 2.957 ms/op MyBenchmark.ZFS_GetPathNewInputStream avgt 50 31.064 ? 1.542 ms/op MyBenchmark.ZFS_GetPathToRealPath avgt 50 20.506 ? 0.512 ms/op MyBenchmark.ZFS_IsDirectory avgt 50 8.935 ? 0.367 ms/op MyBenchmark.ZFS_IsRegularFile avgt 50 8.831 ? 0.505 ms/op MyBenchmark.ZFS_Itr avgt 50 18.981 ? 0.367 ms/op MyBenchmark.ZFS_Open avgt 50 1340.401 ? 204.590 ms/op MyBenchmark.ZFS_ToRealPath avgt 50 4.803 ? 0.450 ms/op MyBenchmark.ZFS_newInputStream avgt 50 14.687 ? 0.515 ms/op -------------------------------old------------------------------------------- MyBenchmark.ZFS_Exists avgt 50 10.475 ? 0.438 ms/op MyBenchmark.ZFS_GetPath avgt 50 12.199 ? 0.522 ms/op MyBenchmark.ZFS_GetPathExists avgt 50 27.345 ? 1.886 ms/op MyBenchmark.ZFS_GetPathIsDirectory avgt 50 29.667 ? 3.120 ms/op MyBenchmark.ZFS_GetPathIsRegularFile avgt 50 28.810 ? 2.455 ms/op MyBenchmark.ZFS_GetPathNewInputStream avgt 50 152.794 ? 3.628 ms/op MyBenchmark.ZFS_GetPathToRealPath avgt 50 36.499 ? 1.331 ms/op MyBenchmark.ZFS_IsDirectory avgt 50 10.887 ? 0.454 ms/op MyBenchmark.ZFS_IsRegularFile avgt 50 11.276 ? 0.410 ms/op MyBenchmark.ZFS_Itr avgt 50 21.126 ? 0.729 ms/op MyBenchmark.ZFS_Open avgt 50 1587.028 ? 90.858 ms/op MyBenchmark.ZFS_ToRealPath avgt 50 19.399 ? 0.613 ms/op btw, it appears the jmh no longer "install" with the latest jdk9 repo. After I updated the jdk9 repo, now "mvn clean install" throws exception showed below. But it runs the benchmark fine. Maybe my jmh version is old? xueshen at sca00aky:/export/home/xueshen/jmh/jzf/test]mvn clean install [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building JMH benchmark sample: Java 1.0 [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ test --- [INFO] Deleting /export/home/xueshen/jmh/jzf/test/target [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ test --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory /export/home/xueshen/jmh/jzf/test/src/main/resources [INFO] [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ test --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 1 source file to /export/home/xueshen/jmh/jzf/test/target/classes [INFO] ------------------------------------------------------------- [ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] Annotation generator had thrown the exception. java.lang.NoClassDefFoundError: javax/annotation/Generated at org.openjdk.jmh.generators.core.BenchmarkGenerator.generateImport(BenchmarkGenerator.java:575) at org.openjdk.jmh.generators.core.BenchmarkGenerator.generateClass(BenchmarkGenerator.java:533) at org.openjdk.jmh.generators.core.BenchmarkGenerator.generate(BenchmarkGenerator.java:94) at org.openjdk.jmh.generators.BenchmarkProcessor.process(BenchmarkProcessor.java:58) at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(jdk.compiler .... From aleksey.shipilev at oracle.com Wed May 4 19:18:14 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 4 May 2016 22:18:14 +0300 Subject: RFR: JDK-8150496,(zipfs) Fix performance issues in zip-fs In-Reply-To: <572A49F8.4050304@oracle.com> References: <5727E295.1000303@oracle.com> <57289BE4.1040605@oracle.com> <572907B4.1020305@oracle.com> <572A0DC3.4070306@oracle.com> <572A49F8.4050304@oracle.com> Message-ID: <572A4AF6.7050905@oracle.com> On 05/04/2016 10:14 PM, Xueming Shen wrote: > http://cr.openjdk.java.net/~sherman/8150496/webrev Okay, good. > yes, the performance gains still hold. > > Benchmark Mode Cnt Score Error Units > -------------------------------new------------------------------------------- > > MyBenchmark.ZFS_Exists avgt 50 4.140 ? 0.374 ms/op > MyBenchmark.ZFS_GetPath avgt 50 12.521 ? 2.003 ms/op > MyBenchmark.ZFS_GetPathExists avgt 50 20.931 ? 1.986 ms/op > MyBenchmark.ZFS_GetPathIsDirectory avgt 50 25.531 ? 1.322 ms/op > MyBenchmark.ZFS_GetPathIsRegularFile avgt 50 26.971 ? 2.957 ms/op > MyBenchmark.ZFS_GetPathNewInputStream avgt 50 31.064 ? 1.542 ms/op > MyBenchmark.ZFS_GetPathToRealPath avgt 50 20.506 ? 0.512 ms/op > MyBenchmark.ZFS_IsDirectory avgt 50 8.935 ? 0.367 ms/op > MyBenchmark.ZFS_IsRegularFile avgt 50 8.831 ? 0.505 ms/op > MyBenchmark.ZFS_Itr avgt 50 18.981 ? 0.367 ms/op > MyBenchmark.ZFS_Open avgt 50 1340.401 ? 204.590 ms/op > MyBenchmark.ZFS_ToRealPath avgt 50 4.803 ? 0.450 ms/op > MyBenchmark.ZFS_newInputStream avgt 50 14.687 ? 0.515 ms/op > -------------------------------old------------------------------------------- > > MyBenchmark.ZFS_Exists avgt 50 10.475 ? 0.438 ms/op > MyBenchmark.ZFS_GetPath avgt 50 12.199 ? 0.522 ms/op > MyBenchmark.ZFS_GetPathExists avgt 50 27.345 ? 1.886 ms/op > MyBenchmark.ZFS_GetPathIsDirectory avgt 50 29.667 ? 3.120 ms/op > MyBenchmark.ZFS_GetPathIsRegularFile avgt 50 28.810 ? 2.455 ms/op > MyBenchmark.ZFS_GetPathNewInputStream avgt 50 152.794 ? 3.628 ms/op > MyBenchmark.ZFS_GetPathToRealPath avgt 50 36.499 ? 1.331 ms/op > MyBenchmark.ZFS_IsDirectory avgt 50 10.887 ? 0.454 ms/op > MyBenchmark.ZFS_IsRegularFile avgt 50 11.276 ? 0.410 ms/op > MyBenchmark.ZFS_Itr avgt 50 21.126 ? 0.729 ms/op > MyBenchmark.ZFS_Open avgt 50 1587.028 ? 90.858 ms/op > MyBenchmark.ZFS_ToRealPath avgt 50 19.399 ? 0.613 ms/op Ok, good. > btw, it appears the jmh no longer "install" with the latest jdk9 > repo. After I updated the jdk9 repo, now "mvn clean install" throws > exception showed below. But it runs the benchmark fine. Maybe my jmh > version is old? Yes, known failure. JMH 1.12 should be compatible with recent JDK 9. Thanks, -Aleksey From mandy.chung at oracle.com Wed May 4 19:29:53 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 4 May 2016 12:29:53 -0700 Subject: Review Request JDK-8155977: Update ObjectInputStream::resolveClass and resolveProxyClass to work with platform class loader Message-ID: The default implementation of ObjectInputStream::resolveClass and resolveProxyClass finds the user-defined class loader on the stack and assumes that only system classes are loaded by null loader. As JDK modules are deprivileged, classes on the stack defined by the platform class loader. These methods should be updated to prepare if any system class are defined by the platform class loader and its ancestors instead. As for the implementation, I fix JVM_LatestUserDefinedLoader to returns the first non-null class loader on the stack that is not platform class loader. This is so fragile and would be really nice if this could go away while the past work shows that it?s unlikely - Alan may say more on this. If this stays, I?d like this to be replaced with StackWalker API and remove such built-in logic in the VM in the future. Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155977/webrev.00/ Mandy From mandy.chung at oracle.com Wed May 4 19:36:19 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 4 May 2016 12:36:19 -0700 Subject: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed In-Reply-To: References: <5D245EC6-47C6-4BF1-A505-89934731A814@oracle.com> <66A0640B-408C-4276-BB79-CCFDEFFDC24B@oracle.com> <5722585A.4060408@oracle.com> Message-ID: <77C7515B-617C-428F-B4C8-F476604A305E@oracle.com> This version includes a new test: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.02/ Daniel - StackFrameInfo class is package-private class In the future this may become a final class once we decide what to do with locals and operands in a future release. I don?t worry about someone else overriding the implementation. Mandy From claes.redestad at oracle.com Wed May 4 19:38:14 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 4 May 2016 21:38:14 +0200 Subject: RFR: JDK-8150496,(zipfs) Fix performance issues in zip-fs In-Reply-To: <572A49F8.4050304@oracle.com> References: <5727E295.1000303@oracle.com> <57289BE4.1040605@oracle.com> <572907B4.1020305@oracle.com> <572A0DC3.4070306@oracle.com> <572A49F8.4050304@oracle.com> Message-ID: <572A4FA6.2030602@oracle.com> Hi Sherman, On 2016-05-04 21:14, Xueming Shen wrote: > > http://cr.openjdk.java.net/~sherman/8150496/webrev this looks good to me! Pre-existing typo 'bofore' -> 'before' in src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java /Claes From xueming.shen at oracle.com Wed May 4 19:54:51 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 04 May 2016 12:54:51 -0700 Subject: RFR: JDK-8150496,(zipfs) Fix performance issues in zip-fs In-Reply-To: <572A4FA6.2030602@oracle.com> References: <5727E295.1000303@oracle.com> <57289BE4.1040605@oracle.com> <572907B4.1020305@oracle.com> <572A0DC3.4070306@oracle.com> <572A49F8.4050304@oracle.com> <572A4FA6.2030602@oracle.com> Message-ID: <572A538B.4090504@oracle.com> Thanks Claes! fixed and webrev has been updated. http://cr.openjdk.java.net/~sherman/8150496/webrev sherman On 05/04/2016 12:38 PM, Claes Redestad wrote: > Hi Sherman, > > On 2016-05-04 21:14, Xueming Shen wrote: >> >> http://cr.openjdk.java.net/~sherman/8150496/webrev > > this looks good to me! > > Pre-existing typo 'bofore' -> 'before' in src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java > > /Claes From brent.christian at oracle.com Wed May 4 20:14:43 2016 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 04 May 2016 13:14:43 -0700 Subject: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed In-Reply-To: <77C7515B-617C-428F-B4C8-F476604A305E@oracle.com> References: <5D245EC6-47C6-4BF1-A505-89934731A814@oracle.com> <66A0640B-408C-4276-BB79-CCFDEFFDC24B@oracle.com> <5722585A.4060408@oracle.com> <77C7515B-617C-428F-B4C8-F476604A305E@oracle.com> Message-ID: <572A5833.6070609@oracle.com> The new test looks good, Mandy. Thanks, -Brent On 05/04/2016 12:36 PM, Mandy Chung wrote: > This version includes a new test: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.02/ > > Daniel - StackFrameInfo class is package-private class In the future this may become a final class once we decide what to do with locals and operands in a future release. I don?t worry about someone else overriding the implementation. > > Mandy > From karen.kinnear at oracle.com Wed May 4 20:31:57 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 4 May 2016 16:31:57 -0400 Subject: Review Request JDK-8155977: Update ObjectInputStream::resolveClass and resolveProxyClass to work with platform class loader In-Reply-To: References: Message-ID: <53ABE86C-C7F8-4DB6-A190-9E667969F765@oracle.com> For the record, I reviewed the jvm changes and they look good. thanks, Karen > On May 4, 2016, at 3:29 PM, Mandy Chung wrote: > > The default implementation of ObjectInputStream::resolveClass and resolveProxyClass finds the user-defined class loader on the stack and assumes that only system classes are loaded by null loader. As JDK modules are deprivileged, classes on the stack defined by the platform class loader. > > These methods should be updated to prepare if any system class are defined by the platform class loader and its ancestors instead. > > As for the implementation, I fix JVM_LatestUserDefinedLoader to returns the first non-null class loader on the stack that is not platform class loader. This is so fragile and would be really nice if this could go away while the past work shows that it?s unlikely - Alan may say more on this. If this stays, I?d like this to be replaced with StackWalker API and remove such built-in logic in the VM in the future. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155977/webrev.00/ > > Mandy From peter.levart at gmail.com Wed May 4 21:58:13 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 4 May 2016 23:58:13 +0200 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: References: Message-ID: <2bd06258-7f46-faf5-c30d-19400d0fb2fe@gmail.com> On 05/04/2016 05:25 PM, Stephen Colebourne wrote: > I disagree with altering the iteration order. Guava's ImmutableSet and > ImmutableMap have reliable iteration specified to match creation > order. This aspect of the design is very useful. > > Stephen Are they also O(1) on lookup at the same time? Altering iteration order from VM run to VM run is a double-edged sword. I can understand that by doing so, programs written to depend on iteration order are practically not possible. In the absence of such "randomization", a simple change of hashCode algorithm of some element of the collection (could be a user class) could break the program. But as Alan pointed out it is also harder to reproduce problems that way. OTOH one might argue that randomization actually prevents such problems to appear in the first place. It forces the programs to be written in a way so that they don't depend on any particular iteration order as it uncovers any potential problems dependent on iteration order early in the development phase. Regards, Peter From forax at univ-mlv.fr Wed May 4 22:15:57 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 5 May 2016 00:15:57 +0200 (CEST) Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: <2bd06258-7f46-faf5-c30d-19400d0fb2fe@gmail.com> References: <2bd06258-7f46-faf5-c30d-19400d0fb2fe@gmail.com> Message-ID: <1192038385.1538711.1462400157733.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Peter Levart" > ?: "Stephen Colebourne" , "core-libs-dev" > Envoy?: Mercredi 4 Mai 2016 23:58:13 > Objet: Re: RFR(m): 8139233 add initial compact immutable collection implementations > > > > On 05/04/2016 05:25 PM, Stephen Colebourne wrote: > > I disagree with altering the iteration order. Guava's ImmutableSet and > > ImmutableMap have reliable iteration specified to match creation > > order. This aspect of the design is very useful. > > > > Stephen > > Are they also O(1) on lookup at the same time? yes, the elements are stored twice (in two different arrays, one to keep the ordering (minus duplicates) the other to guarantee fast access. so it's 0(1) but it's not a 'compact' implementation. > > Altering iteration order from VM run to VM run is a double-edged sword. > I can understand that by doing so, programs written to depend on > iteration order are practically not possible. In the absence of such > "randomization", a simple change of hashCode algorithm of some element > of the collection (could be a user class) could break the program. But > as Alan pointed out it is also harder to reproduce problems that way. > OTOH one might argue that randomization actually prevents such problems > to appear in the first place. It forces the programs to be written in a > way so that they don't depend on any particular iteration order as it > uncovers any potential problems dependent on iteration order early in > the development phase. > > Regards, Peter > > cheers, R?mi From brian.burkhalter at oracle.com Wed May 4 23:17:59 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 4 May 2016 16:17:59 -0700 Subject: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds Message-ID: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8130679 Patch: http://cr.openjdk.java.net/~bpb/8130679/webrev.00/ Summary: Add ?@throws IndexOutOfBoundsException [?]? to all write() methods which accept an index parameter and for which no such throws tag is already present. Thanks, Brian From brent.christian at oracle.com Wed May 4 23:47:01 2016 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 04 May 2016 16:47:01 -0700 Subject: RFR 8147039 : Incorrect locals and operands in compiled frames In-Reply-To: <5729B3C3.3040202@oracle.com> References: <5728F54B.8070007@oracle.com> <5729B3C3.3040202@oracle.com> Message-ID: <572A89F5.3010009@oracle.com> Thanks, Vladimir. BTW, automated build+test has revealed that my test's simple array of expected values doesn't cut it in the face of other [endian|bit]ness-es. For now, I need to skip checking of a couple of locals until something more robust can be added. Thanks, -Brent jdk/test/java/lang/StackWalker/LocalsAndOperands.java *************** *** 292,295 **** "0", ! "1000000", ! "0", "1293080650", --- 292,295 ---- "0", ! null, // skip, fix in 8156073 ! null, // skip, fix in 8156073 "1293080650", On 05/04/2016 01:33 AM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 5/3/16 10:00 PM, Brent Christian wrote: >> Hi, >> >> Please review this change which fixes buggy behavior (including SEGV) in >> the experimental LiveStackFrame feature of StackWalker. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8147039 >> Webrev: >> http://cr.openjdk.java.net/~bchristi/8147039/webrev.02/ >> >> As suggested in the bug report, stack walking is reimplemented using >> javaVFrame/vframe::java_sender. The native StackWalkerAnchor class is >> updated (and renamed) with a similar interface and function to >> vframeStream. I've also removed the now-unneeded >> vframeStreamCommon::java_frame() function, added by 8140450. >> >> Thanks, >> -Brent From artem.smotrakov at oracle.com Wed May 4 23:48:39 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 4 May 2016 16:48:39 -0700 Subject: [9] RFR: 8152207: Perform array bound checks while getting a length of bytecode instructions Message-ID: <572A8A57.5080907@oracle.com> Hello, Please review two small patches for jdk and hotspot repos which add array bound checks to functions which return a length of bytecode instruction. Please see details in https://bugs.openjdk.java.net/browse/JDK-8152207 http://cr.openjdk.java.net/~asmotrak/8152207/jdk/webrev.00/ http://cr.openjdk.java.net/~asmotrak/8152207/hotspot/webrev.00/ Artem From stuart.marks at oracle.com Wed May 4 23:52:51 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 4 May 2016 16:52:51 -0700 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: <5cf3bcb5-49a4-9784-454c-e0b2a61eeceb@gmail.com> References: <5cf3bcb5-49a4-9784-454c-e0b2a61eeceb@gmail.com> Message-ID: <03391b09-e64d-0310-61d4-5abaa722edd8@oracle.com> Hi Peter, Great comments and questions. Responses below.... On 5/4/16 12:20 AM, Peter Levart wrote: > - What's the point of 11 overloaded List.of() methods for 0 ... 10-arity if you > then invoke the var-args ListN(E...input) constructor that does the array > cloning with 8 of them? The same for Set.of()... I suggest that you don't clone > the array in ListN(E... input) constructor but only in List.of(E ... input) method. Yes, it is silly to have fixed-arg overloads to provide a fast path, and then to turn around and use them in a varargs context that creates an array and then copies them, after which the constructor clones the array. The main point, though, is that the API allows for a fast path. Even if the current implementation doesn't take advantage of it, it can be updated later without changing the API. There's tension here between avoiding copying and central enforcement of all the invariants. I'll probably need to do something like adding non-cloning constructors and possibly fixed-arg constructor overloads to avoid varargs array creation. This is a bit more than I want to do at the moment, but I agree it's important. I've filed JDK-8156071 to track this. > - {Set0, Set1, Set2}.contains(null) return false, but SetN.contains(null) throws > NPE. All List{0,1,2,N}.contains(null) return false. What should be the correct > behavior? ConcurrentHashMap.keySet().contains(null) throws NPE for example. Good catch. I did some investigation, and the results are interesting. All of the List implementations allow nulls. But the all the Queue and Deque implementations all disallow nulls, and they all return false from contains(null): - ArrayBlockingQueue - ArrayDeque - ConcurrentLinkedDeque - ConcurrentLinkedQueue - LinkedBlockingDeque - LinkedBlockingQueue - LinkedTransferQueue - PriorityBlockingQueue - PriorityQueue The following Set implementations disallow nulls, and they throw NPE from contains(null): - ConcurrentHashMap$KeySetView - ConcurrentSkipListSet The following Map implementations disallow null keys, and they throw NPE from containsKey(null) and containsValue(null): - ConcurrentHashMap - ConcurrentSkipListMap - Hashtable Things seem pretty consistent across the null-unfriendly collections: on Deques and Queues, contains(null) is allowed, but on Sets and Maps, contains(null) throws NPE. (I have no idea why things are this way.) Although there are no existing Lists that disallow nulls, based on the Queue and Deque behavior, the current behavior of contains(null) on the new List implementations seems reasonable. I will update/override the various contains() methods on the new Set and Map implementations to adjust them to throw NPE. This area could use more tests, too. I've filed JDK-8156074 to track this. > - SetN.probe(E pe) and MapN.probe(K pk) invoke ee.equals(pe) and ek.equals(pk) > respectively. Although it should be logically equivalent, it has been a practice > in collections to invoke the .equals() method on the passed-in argument rather > than on individual elements of the collection. Huh, I didn't know that. Good catch. Will fix. > - Should unchecked exceptions from constructors be wrapped with > InvalidObjectException in SerialProxy.readResolve() or does the Serialization > infrastructure already perform the equivalent? Another good question! The serialization mechanism does deal with any exception that's thrown here, since readResolve is invoked reflectively. But basically it just rethrows runtime exceptions. Callers are presumably prepared to catch ObjectStreamExceptions, so wrapping exceptions thrown from the constructors in a suitable exception instance (probably InvalidObjectException) seems like a sensible thing to do. Thanks, s'marks From stuart.marks at oracle.com Thu May 5 00:21:12 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 4 May 2016 17:21:12 -0700 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: <8939214f-7974-c50b-8fe0-bfe24f05b77c@oracle.com> References: <8939214f-7974-c50b-8fe0-bfe24f05b77c@oracle.com> Message-ID: <1e526249-7706-350f-4fce-f01865ceb8de@oracle.com> Hi Daniel, On 5/4/16 3:08 AM, Daniel Fuchs wrote: > I wonder about serial interoperability with earlier > versions of the JDK. For instance it will not be possible to > send a Set created with Set.of(...) in JDK 9 to a JDK 8 VM. > I wonder if there is any good solution to that. > You could of course use writeReplace() to return a plain > HashSet - but then you would only get a plain HashSet on > the other end. That might be fine if that other end > is JDK 8, but maybe not so good if it's actually JDK 9. Right, in general, you can't serialize a "new" class in a JDK release and deserialize it on an older JDK. If backward serialization compatibility were a goal, one could serialize them as a HashSet within an unmodifiable wrapper. But yes, deserializing that would increase the space consumption considerably. > What worries me is that it will be very easy to forget about > the serial incompatibility, and start using these new factory > methods in e.g. java.lang.management, and then discover later > on that it has introduced an interoperability issue. > > Is there any good way to prevent that - except thorough code > reviews? Well I think you'd need to have some kind of interoperability tests. The most straightforward way to do this would be to keep old versions of the system around and test them against each other. This is tedious to set up and maintain and automate though. Maybe you could have some kind of serialization scanner that takes some serialized data and scans the serialized classes to make sure they're all in the expected set. But ultimately, if you're sending data that old versions need to process, you need to keep a close eye on everything that's serialized. The convenience of being able to serialize an entire object graph automatically works against you here. s'marks From stuart.marks at oracle.com Thu May 5 00:28:15 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 4 May 2016 17:28:15 -0700 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: <5729F7AB.6050705@oracle.com> References: <5729F7AB.6050705@oracle.com> Message-ID: <2a2ae77b-09d2-db9c-d4b8-c7199e3c8cd3@oracle.com> On 5/4/16 6:22 AM, Alan Bateman wrote: > This looks very good, but I just wonder about the iteration order varying from > run to run in the Set/Map implementations. I recall the section added to the > javadoc where it made it very clear that the iteration order is unspecified and > subject to change and no issue with that. I'm just thinking about > troubleshooting scenarios where it could make some issue harder to diagnose. Hi Alan, Yes, the unpredictability does introduce some risk of intermittent and hard-to-diagnose failures. On the other hand, the unspecified-but-mostly-stable iteration order we have with things like HashMap lets implicit order dependencies creep into code, which makes such failures even more rare and harder to diagnose. Plus, as hard as we try to make iteration order stable, there the times we make changes that do change the iteration order. Then, everything breaks. The goal here is to expose code that uses these collections to more frequent order changes in order to "toughen" it up by flushing out inadvertent order dependencies. That way, we can change the implementation at will without worrying about changes to iteration order. We'll see if this works. I can add an option to change the iteration order on every iteration, if you think that'll help. :-) s'marks From stuart.marks at oracle.com Thu May 5 01:30:47 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 4 May 2016 18:30:47 -0700 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: References: Message-ID: <252b8a3c-dea0-3785-37f7-e3d722136087@oracle.com> Hi Stephen, On 5/4/16 8:25 AM, Stephen Colebourne wrote: > A new instance is being created each time for size-zero > lists/sets/maps. This should return a singleton. Yes, this is a fairly obvious optimization. It's been on my personal to-do list, but I've moved this to a sub-task in JIRA: JDK-8156079. On the other hand, the tradeoff isn't so obvious. By analogy, we cache the small, integral boxed values. This saves memory but reduces locality. Still, this ought to be considered. > The serialization proxy is reminiscent of those in JSR-310 but less > space efficient. Once per stream, the proxy will write > "java.util.ImmutableCollections.SerialProxy", whereas the JSR-310 one > is "java.time.Ser". Thats about 29 bytes more than it needs too. ie. a > package-scoped java.util.Ser would be more efficient. Good point. I'll refactor this to a top-level, private class with a shorter name. > There are no messages for IndexOutOfBoundsException. Will fix to use Objects.checkIndex(). > Like Peter, I'm not convinced that extending AbstractList is the way > to go, although I can see arguments both ways. (I think this was R?mi.) Extending AbstractList makes it convenient to have a bunch of different variations, but it does come with some baggage. More discussion in my (forthcoming) reply to R?mi. > equals() and hashCode() could be optimized on the size 0, 1 and 2 > classes, as probably can some other methods. > > Should spliterator() should be overridden to add the IMMUTABLE flag? Yes, there are a bunch of methods that can and should be overridden in order to improve things. As you point out, spliterator() is one of them. This is already tracked by JDK-8133978, still future work. > For maps, I implemented this years ago which may be of interest: > http://commons.apache.org/proper/commons-collections/xref/org/apache/commons/collections4/map/Flat3Map.html#L72 Interesting. Thanks for the link. > I disagree with altering the iteration order. Guava's ImmutableSet and > ImmutableMap have reliable iteration specified to match creation > order. This aspect of the design is very useful. I think this is a reasonable thing to want, but it would be a different API. The current Set.of() and Map.of() APIs have unspecified iteration order, and I want to "enforce" that via randomizing the iteration order. Having unspecified iteration order, but with the implementation giving a stable order, is the worst of both worlds. It lets clients bake in inadvertent order dependencies, and then when we do change it, it breaks them. (This seems to happen every couple years with HashMap.) Randomizing iteration order helps preserve implementation freedom. That said, it's a fine thing to have a different API that gives a Set or Map with a stable iteration order. Several people have asked for this. I've filed JDK-8156070 to track this. s'marks From stuart.marks at oracle.com Thu May 5 06:32:08 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 4 May 2016 23:32:08 -0700 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: <1715865599.1253418.1462351091150.JavaMail.zimbra@u-pem.fr> References: <1715865599.1253418.1462351091150.JavaMail.zimbra@u-pem.fr> Message-ID: On 5/4/16 1:38 AM, Remi Forax wrote: > nice work ! Spoken like a true university professor: "nice work" followed by 100 lines of criticism. :-) > first, all classes should be final otherwise, they are not truly immutable and all arrays should be marked as @Stable. OK, I'll make the classes final. On @Stable, I had a chat with Paul Sandoz about this, and he suggested holding back from adding this. Its semantics are quite particular and are subject to change, and widespread use could easily turn into misuse. > List0, List1, > why not using Collections.emptyList(), Collections.singletonList() here ? Serialization compatibility with future versions. I want all of these to serialize to the same serial proxy in JDK 9, so that in JDK 9+ they can be deserialized to whatever equivalent implementation classes exist in that version of the JDK. For example, there might be a single field-based implementation that covers a small range of sizes, or an implementation using value types. > ListN: > - i don't think that extending AbstractList is a good idea here, > AbstractList provide the failfast/modCount mecanism not needed here. > Moreover, i think you should have some overriden methods on par with Arrays.asList() > (i.e. a custom isEmpty, toArray, indexOf, contains, iterator, spliterator and forEach) > otherwise people will use Arrays.asList just because it's faster :( The implementations all extend AbstractList/Set/Map mainly for implementation convenience. This way it makes it easy to add and remove implementations tailored for specific sizes, since so much code is shared with the abstract superclasses. But they do come with some baggage, as you point out. As the set of implementation classes settles down, it would make more sense to override more methods, and refactor to handle sharing, at which point maybe the dependence on the abstract superclasses can be severed. > - in the constructor, you should use a local variable here, > @SafeVarargs > ListN(E... input) { > // copy and check manually to avoid TOCTOU > @SuppressWarnings("unchecked") > E[] elements = (E[])new Object[input.length]; // implicit nullcheck of input > for (int i = 0; i < input.length; i++) { > elements[i] = Objects.requireNonNull(input[i]); > } > this.elements = elements; > } Nice. Will fix. > List2: > - same as for ListN, should not inherits from AbstractList. > - i wonder why iterator() is not overriden like with Set2. Bringing up a List implementation with AbstractList requires only overriding get() and size(), but not iterator(). On the other hand, bringing up a Set implementation using AbstractSet requires overriding only iterator() and size(). > Set2: > - again, here, i don't think that inheriting from AbstractSet is a good idea. > - in the iterator, pos (position ?) should be private and next() can be written without the '+=', > public E next() { > if (pos == 0) { > pos = 1; > return e0; > } else if (pos == 1) { > pos = 2; > return e1; > } else { > throw new NoSuchElementException(); > } > } > - the iterator should not be defined as inner class (with a reference to Set2) but > be defined as a static class that contains a copy of e1 and e2, > this will save an indirection and avoid to keep a link on the Set if it is transient. Good fixes, thanks. Some of this is stuff left over from when there were field-based implementations with larger sizes. > SetN: > - in the constructor, use a local variable like for ListN > - the @SuppressWarnings for contains is wrong, probe should take an Object, not an E. Ah, nice cleanup. > - the iterator should not be an inner class like Set2 and take the array as parameter. > idx should be private. Instead of doing the loop in hasNext and next, the loop should > be done once in the constructor and in next. So the code of hasNext will be simple > and the JIT will be able to fold a call to hasNext() followed by a call to next(). OK, I'll look at this. > - i don't understand how the serialization can work given that the SALT may be different between two VMs The salt is XORed with the element's hash to determine the position in the collection's array. Serializing it writes all the objects in the array from left to right, but we don't actually care what the order is. Upon deserialization, the objects' hash values are XORed with the deserializing JVM's salt and (probably) end up in different positions in the array of the newly deserialized collection. But again we don't care where they end up. Same goes for MapN's keys and values. > MapN: > - see SetN :) :-) > SerialProxy: > - I believe the class SerialProxy should be public, no ? No, the proxy object can and usually should be private. What's missing is a doc comment specifying the serial format. This should have an "@serial include" tag, which will cause the doc comment to end up in the serialized-form.html file. This works even if the proxy class itself is private. This work is tracked by JDK-8133977. > - The constructor should take a Object... to simplify all calls in the different writeReplace. Good idea. > - fields flags and array should be private OK. Thanks for all the comments! I'll work on an updated webrev and post it soon. s'marks From chris.hegarty at oracle.com Thu May 5 08:46:13 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 5 May 2016 09:46:13 +0100 Subject: Review Request JDK-8155977: Update ObjectInputStream::resolveClass and resolveProxyClass to work with platform class loader In-Reply-To: References: Message-ID: <998D4E88-34CB-41B3-9483-915E5443D657@oracle.com> On 4 May 2016, at 20:29, Mandy Chung wrote: > The default implementation of ObjectInputStream::resolveClass and resolveProxyClass finds the user-defined class loader on the stack and assumes that only system classes are loaded by null loader. As JDK modules are deprivileged, classes on the stack defined by the platform class loader. > > These methods should be updated to prepare if any system class are defined by the platform class loader and its ancestors instead. > > As for the implementation, I fix JVM_LatestUserDefinedLoader to returns the first non-null class loader on the stack that is not platform class loader. This is so fragile and would be really nice if this could go away while the past work shows that it?s unlikely - Alan may say more on this. If this stays, I?d like this to be replaced with StackWalker API and remove such built-in logic in the VM in the future. That would be a good future enhancement. > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155977/webrev.00/ The changes look good to me. The wording for resolveProxyClass seems a little overly complicated, and always has been. Would it be better to just take the same, more direct, wording as resolveClass? where loader is determined as follows: if there is a method on the current thread's stack whose declaring class was defined by a user-defined class loader (and was not a generated to implement reflective invocations), then loader is class loader corresponding to the closest such method to the currently executing frame; otherwise, loader is the {@linkplain ClassLoader#getPlatformClassLoader() platform class loader}. -Chris. From bhanu.prakash.gopularam at oracle.com Thu May 5 09:10:18 2016 From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam) Date: Thu, 5 May 2016 02:10:18 -0700 (PDT) Subject: RFR 8066291: ZoneIdPrinterParser can be optimized Message-ID: Hi all, Please review fix following issue Bug Id : https://bugs.openjdk.java.net/browse/JDK-8066291 Solution: provided new method to get size of available zone ids webrev : http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.00 Thanks, Bhanu From scolebourne at joda.org Thu May 5 09:48:04 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 5 May 2016 10:48:04 +0100 Subject: RFR 8066291: ZoneIdPrinterParser can be optimized In-Reply-To: References: Message-ID: In ZoneRulesProvider.getAvailableZoneIdsSize() there is no need for the trailing paragraph

tag in the Javadoc. Otherwise, fine by me. thanks Stephen On 5 May 2016 at 10:10, Bhanu Gopularam wrote: > Hi all, > > > > Please review fix following issue > > > > Bug Id : https://bugs.openjdk.java.net/browse/JDK-8066291 > > > > Solution: provided new method to get size of available zone ids > > > > webrev : http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.00 > > > > Thanks, > > Bhanu From bhanu.prakash.gopularam at oracle.com Thu May 5 09:57:27 2016 From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam) Date: Thu, 5 May 2016 02:57:27 -0700 (PDT) Subject: RFR 8066291: ZoneIdPrinterParser can be optimized In-Reply-To: References: Message-ID: <0cc8a482-dd16-4671-b3ea-cbd14474c10e@default> Please see the updated webrev: http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.01/ Thanks, Bhanu -----Original Message----- From: Stephen Colebourne [mailto:scolebourne at joda.org] Sent: Thursday, May 05, 2016 3:18 PM To: core-libs-dev Subject: Re: RFR 8066291: ZoneIdPrinterParser can be optimized In ZoneRulesProvider.getAvailableZoneIdsSize() there is no need for the trailing paragraph

tag in the Javadoc. Otherwise, fine by me. thanks Stephen On 5 May 2016 at 10:10, Bhanu Gopularam wrote: > Hi all, > > > > Please review fix following issue > > > > Bug Id : https://bugs.openjdk.java.net/browse/JDK-8066291 > > > > Solution: provided new method to get size of available zone ids > > > > webrev : > http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.00 > > > > Thanks, > > Bhanu From scolebourne at joda.org Thu May 5 10:10:53 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 5 May 2016 11:10:53 +0100 Subject: RFR 8066291: ZoneIdPrinterParser can be optimized In-Reply-To: <0cc8a482-dd16-4671-b3ea-cbd14474c10e@default> References: <0cc8a482-dd16-4671-b3ea-cbd14474c10e@default> Message-ID: Fine by me thanks Stephen On 5 May 2016 at 10:57, Bhanu Gopularam wrote: > Please see the updated webrev: http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.01/ > > Thanks, > Bhanu > > -----Original Message----- > From: Stephen Colebourne [mailto:scolebourne at joda.org] > Sent: Thursday, May 05, 2016 3:18 PM > To: core-libs-dev > Subject: Re: RFR 8066291: ZoneIdPrinterParser can be optimized > > In ZoneRulesProvider.getAvailableZoneIdsSize() there is no need for the trailing paragraph

tag in the Javadoc. > Otherwise, fine by me. > thanks > Stephen > > > On 5 May 2016 at 10:10, Bhanu Gopularam > wrote: >> Hi all, >> >> >> >> Please review fix following issue >> >> >> >> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8066291 >> >> >> >> Solution: provided new method to get size of available zone ids >> >> >> >> webrev : >> http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.00 >> >> >> >> Thanks, >> >> Bhanu From frank.yuan at oracle.com Thu May 5 10:44:58 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Thu, 5 May 2016 18:44:58 +0800 Subject: RFR (JAXP) JDK-8156119: Update ServiceProviderTest for XMLReaderFactory Message-ID: <01a401d1a6bb$2c9d0c40$85d724c0$@oracle.com> Hi Would you like to review http://cr.openjdk.java.net/~fyuan/8156119/webrev.00/? Bug: https://bugs.openjdk.java.net/browse/JDK-8156119 This change is to add/update some tests for verifying JDK-8152912: SAX XMLReaderFactory needs to be ServiceLoader compliant, see Joe's RFR mail thread http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040731.html XMLReaderFactoryTest.java tests 1. XMLReaderFactory can create XMLReader as legacy way, and fix JDK-8015099 Classloading boundary crossing in Java 7 2. XMLReaderFactory can load XMLReader impl by service resource I also updated existing tests to verify XMLReaderFactory can load XMLReader impl from provider module. Thanks, Frank From forax at univ-mlv.fr Thu May 5 11:34:53 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 5 May 2016 13:34:53 +0200 (CEST) Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: References: <1715865599.1253418.1462351091150.JavaMail.zimbra@u-pem.fr> Message-ID: <1116513937.1590215.1462448093838.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Stuart Marks" > ?: "Remi Forax" > Cc: "core-libs-dev" > Envoy?: Jeudi 5 Mai 2016 08:32:08 > Objet: Re: RFR(m): 8139233 add initial compact immutable collection implementations > > On 5/4/16 1:38 AM, Remi Forax wrote: > > nice work ! > > Spoken like a true university professor: "nice work" followed by 100 lines of > criticism. :-) professional bias :) > > > first, all classes should be final otherwise, they are not truly immutable > > and all arrays should be marked as @Stable. > > OK, I'll make the classes final. > > On @Stable, I had a chat with Paul Sandoz about this, and he suggested > holding > back from adding this. Its semantics are quite particular and are subject to > change, and widespread use could easily turn into misuse. the third item of an immutable list stored in a static final should be a constant, no ? > > > List0, List1, > > why not using Collections.emptyList(), Collections.singletonList() here ? > > Serialization compatibility with future versions. I want all of these to > serialize to the same serial proxy in JDK 9, so that in JDK 9+ they can be > deserialized to whatever equivalent implementation classes exist in that > version > of the JDK. For example, there might be a single field-based implementation > that > covers a small range of sizes, or an implementation using value types. ok ! > > > ListN: > > - i don't think that extending AbstractList is a good idea here, > > AbstractList provide the failfast/modCount mecanism not needed here. > > Moreover, i think you should have some overriden methods on par with > > Arrays.asList() > > (i.e. a custom isEmpty, toArray, indexOf, contains, iterator, > > spliterator and forEach) > > otherwise people will use Arrays.asList just because it's faster :( > > The implementations all extend AbstractList/Set/Map mainly for implementation > convenience. This way it makes it easy to add and remove implementations > tailored for specific sizes, since so much code is shared with the abstract > superclasses. But they do come with some baggage, as you point out. As the > set > of implementation classes settles down, it would make more sense to override > more methods, and refactor to handle sharing, at which point maybe the > dependence on the abstract superclasses can be severed. The problem is that AbstractList is a public class, removing it from the hierarchy is not a backward compatible change, so it's not something that can be changed as an after through. > > > - in the constructor, you should use a local variable here, > > @SafeVarargs > > ListN(E... input) { > > // copy and check manually to avoid TOCTOU > > @SuppressWarnings("unchecked") > > E[] elements = (E[])new Object[input.length]; // implicit > > nullcheck of input > > for (int i = 0; i < input.length; i++) { > > elements[i] = Objects.requireNonNull(input[i]); > > } > > this.elements = elements; > > } > > Nice. Will fix. > > > List2: > > - same as for ListN, should not inherits from AbstractList. > > - i wonder why iterator() is not overriden like with Set2. > > Bringing up a List implementation with AbstractList requires only overriding > get() and size(), but not iterator(). On the other hand, bringing up a Set > implementation using AbstractSet requires overriding only iterator() and > size(). I think you will have to override iterator anyway (for the same reason the result of Arrays.asList() override the iterator). > > > Set2: > > - again, here, i don't think that inheriting from AbstractSet is a good > > idea. > > - in the iterator, pos (position ?) should be private and next() can be > > written without the '+=', > > public E next() { > > if (pos == 0) { > > pos = 1; > > return e0; > > } else if (pos == 1) { > > pos = 2; > > return e1; > > } else { > > throw new NoSuchElementException(); > > } > > } > > - the iterator should not be defined as inner class (with a reference to > > Set2) but > > be defined as a static class that contains a copy of e1 and e2, > > this will save an indirection and avoid to keep a link on the Set if it > > is transient. > > Good fixes, thanks. Some of this is stuff left over from when there were > field-based implementations with larger sizes. > > > SetN: > > - in the constructor, use a local variable like for ListN > > - the @SuppressWarnings for contains is wrong, probe should take an > > Object, not an E. > > Ah, nice cleanup. > > > - the iterator should not be an inner class like Set2 and take the array > > as parameter. > > idx should be private. Instead of doing the loop in hasNext and next, > > the loop should > > be done once in the constructor and in next. So the code of hasNext > > will be simple > > and the JIT will be able to fold a call to hasNext() followed by a call > > to next(). > > OK, I'll look at this. > > > - i don't understand how the serialization can work given that the SALT > > may be different between two VMs > > The salt is XORed with the element's hash to determine the position in the > collection's array. Serializing it writes all the objects in the array from > left > to right, but we don't actually care what the order is. Upon deserialization, > the objects' hash values are XORed with the deserializing JVM's salt and > (probably) end up in different positions in the array of the newly > deserialized > collection. But again we don't care where they end up. > > Same goes for MapN's keys and values. ok, i will re-review that code later ... > > > MapN: > > - see SetN :) > > :-) > > > SerialProxy: > > - I believe the class SerialProxy should be public, no ? > > No, the proxy object can and usually should be private. What's missing is a > doc > comment specifying the serial format. This should have an "@serial include" > tag, > which will cause the doc comment to end up in the serialized-form.html file. > This works even if the proxy class itself is private. > > This work is tracked by JDK-8133977. > > > - The constructor should take a Object... to simplify all calls in the > > different writeReplace. > > Good idea. > > > - fields flags and array should be private > > OK. > > Thanks for all the comments! I'll work on an updated webrev and post it soon. > > s'marks > > R?mi From Alan.Bateman at oracle.com Thu May 5 12:18:24 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 May 2016 13:18:24 +0100 Subject: RFR: JDK-8150496,(zipfs) Fix performance issues in zip-fs In-Reply-To: <572A538B.4090504@oracle.com> References: <5727E295.1000303@oracle.com> <57289BE4.1040605@oracle.com> <572907B4.1020305@oracle.com> <572A0DC3.4070306@oracle.com> <572A49F8.4050304@oracle.com> <572A4FA6.2030602@oracle.com> <572A538B.4090504@oracle.com> Message-ID: <572B3A10.3050101@oracle.com> On 04/05/2016 20:54, Xueming Shen wrote: > Thanks Claes! fixed and webrev has been updated. > > http://cr.openjdk.java.net/~sherman/8150496/webrev > > sherman I skimmed through this and it looks quite. I just wonder if we should check in the micro benchmarks as it is likely we'll need those again in the future. One thing that isn't clear (to me anyway) is the change to detecting \u0000 in the normalization code. Do we have any cases where IllegalPathException is thrown? In checkAccess there is a comment about needing to read the CEN. It this method needed? I would check that ZipFileSystemProvider should just need to invoke exists (+ checks when w or x modes). In cen then the versionMade-attrsEx is commented out, should they be removed? -Alan. From Alan.Bateman at oracle.com Thu May 5 12:34:09 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 May 2016 13:34:09 +0100 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: <2a2ae77b-09d2-db9c-d4b8-c7199e3c8cd3@oracle.com> References: <5729F7AB.6050705@oracle.com> <2a2ae77b-09d2-db9c-d4b8-c7199e3c8cd3@oracle.com> Message-ID: <572B3DC1.2080302@oracle.com> On 05/05/2016 01:28, Stuart Marks wrote: > > Hi Alan, > > Yes, the unpredictability does introduce some risk of intermittent and > hard-to-diagnose failures. On the other hand, the > unspecified-but-mostly-stable iteration order we have with things like > HashMap lets implicit order dependencies creep into code, which makes > such failures even more rare and harder to diagnose. Plus, as hard as > we try to make iteration order stable, there the times we make changes > that do change the iteration order. Then, everything breaks. > > The goal here is to expose code that uses these collections to more > frequent order changes in order to "toughen" it up by flushing out > inadvertent order dependencies. That way, we can change the > implementation at will without worrying about changes to iteration > order. We'll see if this works. > > I can add an option to change the iteration order on every iteration, > if you think that'll help. :-) I understand the goal, just wondering if there is something less devious that would make sense here. One idea is to use some portion of the Version, say the build number, so that it at least changes each week or build. That would at keeping the ordering consistent from run to run but it might change when someone updates. -Alan From tadamski at redhat.com Thu May 5 12:51:32 2016 From: tadamski at redhat.com (Tomasz Adamski) Date: Thu, 5 May 2016 08:51:32 -0400 (EDT) Subject: RFR: 8152084: Introduction of ssliop protocol to corbaloc In-Reply-To: <572A1754.8000507@oracle.com> References: <321794846.38762864.1461088691787.JavaMail.zimbra@redhat.com> <5728A7AC.8000103@redhat.com> <5728AF76.9020406@oracle.com> <63067504.43350431.1462372580193.JavaMail.zimbra@redhat.com> <572A0CE2.8020101@redhat.com> <572A1754.8000507@oracle.com> Message-ID: <494597590.43598332.1462452692542.JavaMail.zimbra@redhat.com> Added classes are indeed generated from idl present in Security Server Specification which is part of Corba 3.3 specification. I can find no information about formal corba compliance process. Can you please point me to people who can help me regarding this? Regards, Tomek -- Tomasz Adamski Software Engineer JBoss by Red Hat ----- Original Message ----- > From: "Alan Bateman" > To: "Andrew Dinn" , "Tomasz Adamski" > Cc: core-libs-dev at openjdk.java.net > Sent: Wednesday, May 4, 2016 5:37:56 PM > Subject: Re: RFR: 8152084: Introduction of ssliop protocol to corbaloc > > > On 04/05/2016 15:53, Andrew Dinn wrote: > > : > > Just to dispel any idea that this has been plucked out of thin air by > > the JacORB implementors I'll note that there appears to be both a > > standard for and more than one implementation of ssliop. > > > > Regarding implementations, OpenORB and TAO also implemented it. > > > > As regards standardization I think the relevant info is in the interop > > documentation found at http://www.omg.org/spec/CORBA/3.3/. Look in part > > 2 of the spec dealing with interoperability and search for IIOP/SSL. > > Tomek may be able to clarify whether that provides all the relevant > > information. > > > I have a general concern that this might be overlaying part of CORBA 3.3 > over an API/implementation that is based on CORBA 2.3.1. I don't know > what the compliance issues are here and what certification is required > to claim CORBA 3.3 or even partial compliance. So I expect there is more > work to do than might initially seem. Aside from stating compliance then > this will require tests and I don't see these in the patch. I don't see > any javadoc either (I realize some of strangely named classes might be > generated from IDL). > > -Alan > From scolebourne at joda.org Thu May 5 12:54:50 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 5 May 2016 13:54:50 +0100 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: <252b8a3c-dea0-3785-37f7-e3d722136087@oracle.com> References: <252b8a3c-dea0-3785-37f7-e3d722136087@oracle.com> Message-ID: On 5 May 2016 at 02:30, Stuart Marks wrote: >> I disagree with altering the iteration order. Guava's ImmutableSet and >> ImmutableMap have reliable iteration specified to match creation >> order. This aspect of the design is very useful. > > > I think this is a reasonable thing to want, but it would be a different API. > The current Set.of() and Map.of() APIs have unspecified iteration order, and > I want to "enforce" that via randomizing the iteration order. Having > unspecified iteration order, but with the implementation giving a stable > order, is the worst of both worlds. It lets clients bake in inadvertent > order dependencies, and then when we do change it, it breaks them. (This > seems to happen every couple years with HashMap.) Randomizing iteration > order helps preserve implementation freedom. > > That said, it's a fine thing to have a different API that gives a Set or Map > with a stable iteration order. Several people have asked for this. I've > filed JDK-8156070 to track this. To be clear, I believe that the spec of Set.of() and Map.of() should require iteration order matching insertion order (because the order is very clearly defined in this case and anything else will be surprising). Stephen From aleksej.efimov at oracle.com Thu May 5 12:56:24 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Thu, 5 May 2016 15:56:24 +0300 Subject: [9] RFR: 8152927: Incorrect GPL header in StubFactoryDynamicBase.java reported Message-ID: <572B42F8.1000903@oracle.com> Hello, corba/src/java.corba/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryDynamicBase.java file contains incorrect GPL header which fails make/scripts/lic_check.sh script check with such error: ### Checking copyright notice in the file: corba/src/java.corba/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryDynamicBase.java ### ERROR: Copyright string is not correct or missing in 9/corba/src/java.corba/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryDynamicBase.java ### Failure is caused by missing comma after modification years. Please, help to review its addition: http://cr.openjdk.java.net/~aefimov/8152927/9/00 lic_check.sh passes after this modification: ### Checking copyright notice in the file: corba/src/java.corba/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryDynamicBase.java ### SUCCESS: The license header for corba/src/java.corba/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryDynamicBase.java has been verified. ### With Best Regards, Aleksej JBS: https://bugs.openjdk.java.net/browse/JDK-8152927 From Alan.Bateman at oracle.com Thu May 5 13:10:05 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 May 2016 14:10:05 +0100 Subject: Review Request JDK-8155977: Update ObjectInputStream::resolveClass and resolveProxyClass to work with platform class loader In-Reply-To: References: Message-ID: <572B462D.1080103@oracle.com> On 04/05/2016 20:29, Mandy Chung wrote: > The default implementation of ObjectInputStream::resolveClass and resolveProxyClass finds the user-defined class loader on the stack and assumes that only system classes are loaded by null loader. As JDK modules are deprivileged, classes on the stack defined by the platform class loader. > > These methods should be updated to prepare if any system class are defined by the platform class loader and its ancestors instead. > > As for the implementation, I fix JVM_LatestUserDefinedLoader to returns the first non-null class loader on the stack that is not platform class loader. This is so fragile and would be really nice if this could go away while the past work shows that it?s unlikely - Alan may say more on this. If this stays, I?d like this to be replaced with StackWalker API and remove such built-in logic in the VM in the future. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155977/webrev.00/ > > In resolveClass then "is class loader corresponding to the closest .." should probably be "is the class loader ...". You didn't introduce this of course, just noticed it while reading the complete paragraph. The rest looks okay to me, no objection to Chris's suggestion to re-word resolveProxyClass. -Alan From Alan.Bateman at oracle.com Thu May 5 13:13:13 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 May 2016 14:13:13 +0100 Subject: [9] RFR: 8152927: Incorrect GPL header in StubFactoryDynamicBase.java reported In-Reply-To: <572B42F8.1000903@oracle.com> References: <572B42F8.1000903@oracle.com> Message-ID: <572B46E9.50202@oracle.com> On 05/05/2016 13:56, Aleks Efimov wrote: > Hello, > > corba/src/java.corba/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryDynamicBase.java > file contains incorrect GPL header which fails > make/scripts/lic_check.sh script check with such error: > ### Checking copyright notice in the file: > corba/src/java.corba/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryDynamicBase.java > ### > ERROR: Copyright string is not correct or missing in > 9/corba/src/java.corba/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryDynamicBase.java > ### > > Failure is caused by missing comma after modification years. Please, > help to review its addition: > http://cr.openjdk.java.net/~aefimov/8152927/9/00 > Looks fine. From markt at apache.org Thu May 5 13:23:54 2016 From: markt at apache.org (Mark Thomas) Date: Thu, 5 May 2016 14:23:54 +0100 Subject: TCCL memory leak in RMI registry creation In-Reply-To: References: <5715043B.4090901@apache.org> <57164DDA.9070806@Oracle.com> <5718C04D.1080002@apache.org> <5718DB6B.6000103@apache.org> <571954E5.50004@oracle.com> <5719F6E9.9040203@apache.org> Message-ID: On 25/04/2016 22:26, Stuart Marks wrote: > On 4/22/16 3:03 AM, Mark Thomas wrote: Sorry for the delayed reply. I got distracted on other things. >> The good news is that, with the information above, this leak is >> something that modules/applications can and should do something about. > > I think the general rule has to be that, if an application has exported > a remote object, that object should be unexported when the application > shuts down. This applies equally well to registry objects created by the > application. I agree completely. That hard part will be getting web application developers to do this. Hence my desire to be able to detect, report and (if possible) fix this. >> This moves the problem to how to detect when modules/applications fail >> to clean up an RMI Registry they created. I'd like to be able to provide >> nice loud error messages when this happens. Open questions are: >> - How to get a list of RMI registries? >> - How to determine the TCCL for a registry (held in the ccl field of the >> associated sun.rmi.transport.Target object) so I can figure out if a >> module/application created it? > > I don't have a good answer for this. > > I do think that talking about registries is a bit of a distraction. As I > mentioned above, the general problem can occur with any remote object, > and a registry is mostly an ordinary remote object. Fair point. > All remote objects in this JVM are kept in the ObjectTable, and the > cleanup code you have looks through this for Target objects with the > right ccl etc. already. > > If you want the cleanup function to continue to be active in production > use of Tomcat, then you'll probably need to explore the JVM command-line > options that enable the reflective access to continue, e.g. -XaddExports > or -Xpatch. I can confirm that -XaddExports with appropriate settings does allow the current code to work correctly. I'd like to be able to avoid reflection and -XaddExports if possible. Is there any chance at all of the RMI API being extended support this sort of clean-up without reflection? > A variant of this is to get one's hands on the remote object itself and > then call unexportObject() on it, instead of directly removing things > from the various maps. This probably does the cleanup in a more robust > fashion, though it doesn't help with the main problem of getting > reflective access. > > If this doesn't need to run in production, and can be run only in, say, > some "diagnostic mode," (not sure if such a thing exists) then there are > some other possibilities. For example, one might load an agent, or use > the debugger interface, to track remote objects being exported and > unexported. If, after shutting down an application, remote objects > remain exported, this could cause some errors to be issued. Unfortunately, this needs to run in production. Thanks again for all your help. Mark From chris.hegarty at oracle.com Thu May 5 13:42:23 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 5 May 2016 14:42:23 +0100 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: <1e526249-7706-350f-4fce-f01865ceb8de@oracle.com> References: <8939214f-7974-c50b-8fe0-bfe24f05b77c@oracle.com> <1e526249-7706-350f-4fce-f01865ceb8de@oracle.com> Message-ID: <33BB7D2A-E4F2-400B-A34F-04E12B564AC0@oracle.com> On 5 May 2016, at 01:21, Stuart Marks wrote: > Hi Daniel, > > On 5/4/16 3:08 AM, Daniel Fuchs wrote: >> I wonder about serial interoperability with earlier >> versions of the JDK. For instance it will not be possible to >> send a Set created with Set.of(...) in JDK 9 to a JDK 8 VM. >> I wonder if there is any good solution to that. >> You could of course use writeReplace() to return a plain >> HashSet - but then you would only get a plain HashSet on >> the other end. That might be fine if that other end >> is JDK 8, but maybe not so good if it's actually JDK 9. > > Right, in general, you can't serialize a "new" class in a JDK release and deserialize it on an older JDK. If backward serialization compatibility were a goal, one could serialize them as a HashSet within an unmodifiable wrapper. But yes, deserializing that would increase the space consumption considerably. I have some sympathy for this. Since we are specifying that these Collections are serializable, it would be nice for them to deserialize on an older release, but I don?t think we should compromise the serial form to achieve that. In fact, I agree with Stephen, I think we should go the same way as that of the serial form of 310 classes. So is there anything we can do for serial interoperability? What if, we agree the serial form and the private supporting implementation types in 9 ( say, some time this month ). Backport these to, at least, 8u, where they do not impact spec and are benign. JDK 9 is not scheduled to ship until March 2017, with the regular Critical Patch Updates that most vendors provide, I?d bet that a large number of 8u?s in production at that time would contain the required types to deserialize these collections. There?s no guarantee of course, but in practical terms at least we made a reasonable effort. -Chris. From chris.hegarty at oracle.com Thu May 5 13:42:23 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 5 May 2016 14:42:23 +0100 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: <1e526249-7706-350f-4fce-f01865ceb8de@oracle.com> References: <8939214f-7974-c50b-8fe0-bfe24f05b77c@oracle.com> <1e526249-7706-350f-4fce-f01865ceb8de@oracle.com> Message-ID: <58E810B5-B6BF-4020-B280-B40C03EA58D0@oracle.com> On 5 May 2016, at 01:21, Stuart Marks wrote: > Hi Daniel, > > On 5/4/16 3:08 AM, Daniel Fuchs wrote: >> I wonder about serial interoperability with earlier >> versions of the JDK. For instance it will not be possible to >> send a Set created with Set.of(...) in JDK 9 to a JDK 8 VM. >> I wonder if there is any good solution to that. >> You could of course use writeReplace() to return a plain >> HashSet - but then you would only get a plain HashSet on >> the other end. That might be fine if that other end >> is JDK 8, but maybe not so good if it's actually JDK 9. > > Right, in general, you can't serialize a "new" class in a JDK release and deserialize it on an older JDK. If backward serialization compatibility were a goal, one could serialize them as a HashSet within an unmodifiable wrapper. But yes, deserializing that would increase the space consumption considerably. I have some sympathy for this. Since we are specifying that these Collections are serializable, it would be nice for them to deserialize on an older release, but I don?t think we should compromise the serial form to achieve that. In fact, I agree with Stephen, I think we should go the same way as that of the serial form of 310 classes. So is there anything we can do for serial interoperability? What if, we agree the serial form and the private supporting implementation types in 9 ( say, some time this month ). Backport these to, at least, 8u, where they do not impact spec and are benign. JDK 9 is not scheduled to ship until March 2017, with the regular Critical Patch Updates that most vendors provide, I?d bet that a large number of 8u?s in production at that time would contain the required types to deserialize these collections. There?s no guarantee of course, but in practical terms at least we made a reasonable effort. -Chris. From Roger.Riggs at Oracle.com Thu May 5 14:23:08 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 5 May 2016 10:23:08 -0400 Subject: RFR 8066291: ZoneIdPrinterParser can be optimized In-Reply-To: References: Message-ID: <79c157ea-4b77-8e4a-444b-08a69ca4779b@Oracle.com> Hi Bhanu, Adding a trivial method to the public API used only for an optimization is not a good fix for this issue. A better fix was suggested to add a non-copying read-only version of ZoneRulesProvider.getAvailableZoneIds() Please revise the fix to instead implement and use: /** * Gets a readonly set of available zone IDs. *

* These IDs are the string form of a {@link ZoneId}. * * @return a unmodifiable copy of the set of zone IDs, not null */ public static Set getReadOnlyAvailableZoneIds() { return Collections.unmodifiableSet(ZONES.keySet()); } Roger On 5/5/2016 5:10 AM, Bhanu Gopularam wrote: > > Hi all, > > Please review fix following issue > > Bug Id : https://bugs.openjdk.java.net/browse/JDK-8066291 > > Solution: provided new method to get size of available zone ids > > webrev : > http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.00 > > > Thanks, > > Bhanu > From scolebourne at joda.org Thu May 5 15:27:36 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 5 May 2016 16:27:36 +0100 Subject: RFR 8066291: ZoneIdPrinterParser can be optimized In-Reply-To: <79c157ea-4b77-8e4a-444b-08a69ca4779b@Oracle.com> References: <79c157ea-4b77-8e4a-444b-08a69ca4779b@Oracle.com> Message-ID: I fail to see why adding a new read-only method alongside the existing method adds any more value to the API than adding a new size method. At least with the size method the API is still sensible - a mutable and immutable method alongside each other shouts out that a mistake was made. A size method is more subtle about the mistake (plenty of APIs have a size method alongside a collection method). Finally, a read-only method involves object creation, thus has worse performance than adding a size method. The only other alternative is perhaps to use SharedSecrets? I don't know what possibilities there are there. If not SharedSecrets, then no matter what, we are adding "a trivial method to the public API used only for an optimization". Stephen On 5 May 2016 at 15:23, Roger Riggs wrote: > Hi Bhanu, > > Adding a trivial method to the public API used only for an optimization is > not a good fix for this issue. > > A better fix was suggested to add a non-copying read-only version of > > ZoneRulesProvider.getAvailableZoneIds() > > Please revise the fix to instead implement and use: > > /** > * Gets a readonly set of available zone IDs. > *

> * These IDs are the string form of a {@link ZoneId}. > * > * @return a unmodifiable copy of the set of zone IDs, not null > */ > public static Set getReadOnlyAvailableZoneIds() { > return Collections.unmodifiableSet(ZONES.keySet()); > } > > Roger > > > > On 5/5/2016 5:10 AM, Bhanu Gopularam wrote: > > Hi all, > > > > Please review fix following issue > > > > Bug Id : https://bugs.openjdk.java.net/browse/JDK-8066291 > > > > Solution: provided new method to get size of available zone ids > > > > webrev : http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.00 > > > > Thanks, > > Bhanu > > From xueming.shen at oracle.com Thu May 5 15:42:40 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 5 May 2016 08:42:40 -0700 Subject: RFR: JDK-8150496,(zipfs) Fix performance issues in zip-fs In-Reply-To: <572B3A10.3050101@oracle.com> References: <5727E295.1000303@oracle.com> <57289BE4.1040605@oracle.com> <572907B4.1020305@oracle.com> <572A0DC3.4070306@oracle.com> <572A49F8.4050304@oracle.com> <572A4FA6.2030602@oracle.com> <572A538B.4090504@oracle.com> <572B3A10.3050101@oracle.com> Message-ID: <572B69F0.3060603@oracle.com> On 5/5/16 5:18 AM, Alan Bateman wrote: > On 04/05/2016 20:54, Xueming Shen wrote: >> Thanks Claes! fixed and webrev has been updated. >> >> http://cr.openjdk.java.net/~sherman/8150496/webrev >> >> sherman > I skimmed through this and it looks quite. I just wonder if we should > check in the micro benchmarks as it is likely we'll need those again > in the future. Will need to find an appropriate place to place it. Any idea? I can file an issue for this one. > > One thing that isn't clear (to me anyway) is the change to detecting > \u0000 in the normalization code. Do we have any cases where > IllegalPathException is thrown? > The change I did here is just to delay the IPE throwing later into normalize(byte[], int) (where we do the real normalization). The motivation here is to combine two checks into one "if" (with the hope it can speed thing up a little), given it is rare to have such Path in real world use scenario. > In checkAccess there is a comment about needing to read the CEN. It > this method needed? I would check that ZipFileSystemProvider should > just need to invoke exists (+ checks when w or x modes). This method is the real implementation for "exists/path.checkAccess". The only thing changed here is to not create an entry object (read the cen table for that particular entry and load in all the fields) on top of an inode (which is read from the cen already, only with the "name" and "offset" info), as we really are not using the entry (now as an "attributes" as well), the only thing we need to know here is if such Entry/Inode exists. The only benefit of creating such Entry is to verify that all the fields of this Entry are valid. The current implementation will create such entry and validate it later when go read the bytes of the entry(get an in/output stream), or try to obtain an "attributes". > > In cen then the versionMade-attrsEx is commented out, should they be > removed? > They can be removed. I keep them there is just for convenience that we might need them back, in the future. Thanks, -Sherman From bill.mair at web.de Thu May 5 15:47:49 2016 From: bill.mair at web.de (Bill Mair) Date: Thu, 5 May 2016 17:47:49 +0200 Subject: Bug 8149521 Message-ID: Hi, I've just ran in to the same problem described in this bug: https://bugs.openjdk.java.net/browse/JDK-8149521 I found it in java7u79 and I used java8u91 to confirm it still exists. The error is in "com.sun.jndi.ldap.ServiceLocator" at line 273 (http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/df209f221cca/src/share/classes/com/sun/jndi/ldap/ServiceLocator.java), The "Hostname" token always has a trailing "." (period). This doesn't normally matter for "normal" network operation but it is critical where working with Kerberos. If you use "ldap:///dc=example,dc=com" the the corresponding name might be something like "ldap1.example.com."(notice the trailing dot) Kerberos is then looking for "ldap/ldap1.example.com." instead of "ldap/ldap1.example.com" The first record simply doesn't exist in the kerberos DB. Regards, Bill Mair From Roger.Riggs at Oracle.com Thu May 5 15:53:31 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 5 May 2016 11:53:31 -0400 Subject: RFR 8066291: ZoneIdPrinterParser can be optimized In-Reply-To: References: <79c157ea-4b77-8e4a-444b-08a69ca4779b@Oracle.com> Message-ID: Hi Stephen, The aspect of the current implementation that is problematic is the copying of the set, its not just single object creation but an entry for every ZoneID. Adding a size method exposing some internal state increases the possibility that when it is used independently it will be out of sync. Not a big issue, but one to avoid when designing an API. Exposing a mutable Hashset was probably a mistake but one that cannot be corrected now. The optics aren't concerning to me. SharedSecrets are much messier and not appropriate. Adding a method to provide what was originally needed is a cleaner solution. Roger On 5/5/2016 11:27 AM, Stephen Colebourne wrote: > I fail to see why adding a new read-only method alongside the existing > method adds any more value to the API than adding a new size method. > At least with the size method the API is still sensible - a mutable > and immutable method alongside each other shouts out that a mistake > was made. A size method is more subtle about the mistake (plenty of > APIs have a size method alongside a collection method). > > Finally, a read-only method involves object creation, thus has worse > performance than adding a size method. > > The only other alternative is perhaps to use SharedSecrets? I don't > know what possibilities there are there. If not SharedSecrets, then no > matter what, we are adding "a trivial method to the public API used > only for an optimization". > > Stephen > > > On 5 May 2016 at 15:23, Roger Riggs wrote: >> Hi Bhanu, >> >> Adding a trivial method to the public API used only for an optimization is >> not a good fix for this issue. >> >> A better fix was suggested to add a non-copying read-only version of >> >> ZoneRulesProvider.getAvailableZoneIds() >> >> Please revise the fix to instead implement and use: >> >> /** >> * Gets a readonly set of available zone IDs. >> *

>> * These IDs are the string form of a {@link ZoneId}. >> * >> * @return a unmodifiable copy of the set of zone IDs, not null >> */ >> public static Set getReadOnlyAvailableZoneIds() { >> return Collections.unmodifiableSet(ZONES.keySet()); >> } >> >> Roger >> >> >> >> On 5/5/2016 5:10 AM, Bhanu Gopularam wrote: >> >> Hi all, >> >> >> >> Please review fix following issue >> >> >> >> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8066291 >> >> >> >> Solution: provided new method to get size of available zone ids >> >> >> >> webrev : http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.00 >> >> >> >> Thanks, >> >> Bhanu >> >> From peter.levart at gmail.com Thu May 5 16:27:09 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 5 May 2016 18:27:09 +0200 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: References: <252b8a3c-dea0-3785-37f7-e3d722136087@oracle.com> Message-ID: <8f6d9783-52c1-64b9-bc05-26820f588ce3@gmail.com> Hi, On 05/05/2016 02:54 PM, Stephen Colebourne wrote: > On 5 May 2016 at 02:30, Stuart Marks wrote: >>> I disagree with altering the iteration order. Guava's ImmutableSet and >>> ImmutableMap have reliable iteration specified to match creation >>> order. This aspect of the design is very useful. >> >> I think this is a reasonable thing to want, but it would be a different API. >> The current Set.of() and Map.of() APIs have unspecified iteration order, and >> I want to "enforce" that via randomizing the iteration order. Having >> unspecified iteration order, but with the implementation giving a stable >> order, is the worst of both worlds. It lets clients bake in inadvertent >> order dependencies, and then when we do change it, it breaks them. (This >> seems to happen every couple years with HashMap.) Randomizing iteration >> order helps preserve implementation freedom. >> >> That said, it's a fine thing to have a different API that gives a Set or Map >> with a stable iteration order. Several people have asked for this. I've >> filed JDK-8156070 to track this. > To be clear, I believe that the spec of Set.of() and Map.of() should > require iteration order matching insertion order (because the order is > very clearly defined in this case and anything else will be > surprising). > > Stephen So what if the API was specified to have iteration order matching construction order. Are you afraid that would impact implementations so that they would be less compact or less performant? At least for small number of elements, there is a possible implementation that keeps construction order and is even more compact and still has O(1) lookup performance. For example an implementation for up to 255 elements: public class Set0xFF extends AbstractSet implements Serializable { /** * A "salt" value used for randomizing iteration order. This is initialized once * and stays constant for the lifetime of the JVM. It need not be truly random, but * it needs to vary sufficiently from one run to the next so that iteration order * will vary between JVM runs. */ static final int SALT; static { SALT = new Random().nextInt(); } /** * The reciprocal of load factor. Given a number of elements * to store, multiply by this factor to get the table size. */ static final double EXPAND_FACTOR = 2.0; final E[] elements; final byte[] index; @SafeVarargs @SuppressWarnings("unchecked") Set0xFF(E... input) { if (input.length > 255) { throw new IllegalArgumentException("To many elements for this implementation"); } elements = input.clone(); index = new byte[(int) Math.ceil(EXPAND_FACTOR * elements.length)]; for (int i = 0; i < elements.length; i++) { E e = Objects.requireNonNull(elements[i]); int idx = probe(e); if (idx >= 0) { throw new IllegalArgumentException("duplicate element: " + e); } else { index[-(idx + 1)] = (byte) (i + 1); } } } @Override public int size() { return elements.length; } @Override @SuppressWarnings("unchecked") public boolean contains(Object o) { Objects.requireNonNull(o); return probe((E) o) >= 0; } @Override public Iterator iterator() { return new Iterator() { int idx = 0; @Override public boolean hasNext() { return idx < elements.length; } @Override public E next() { int i = idx; if (i >= elements.length) { throw new NoSuchElementException(); } idx = i + 1; return elements[i]; } }; } // returns index into index array at which element index + 1 is present; or if absent, // (-i - 1) where i is location where element index should be inserted private int probe(E pe) { int idx = Math.floorMod(pe.hashCode() ^ SALT, index.length); while (true) { int i = (int) index[idx] & 0xFF; if (i == 0) { return -idx - 1; } else if (elements[i - 1].equals(pe)) { return idx; } else if (++idx == index.length) { idx = 0; } } } } Your SetN occupies (without considering the elements themselves) the following number of bytes: 8 * size() (on 32 bit/compressed OOPS) or 16 * size() (on 64bit OOPS) (+ 2 object headers and alignments) Above Set0xFF occupies: 6 * size() (on 32 bit/compressed OOPS) or 10 * size() (on 64bit OOPS) (+ 3 object headers and alignments) An analogue Set0xFFFF for up to 65535 elements would occupy: 8 * size() (on 32 bit/compressed OOPS) or 12 * size() (on 64bit OOPS) (+ 3 object headers and alignments) An analogue Set0xFFFFFFFF for up to 2^31 - 1 elements that still keeps iteration order would occupy: 12 * size() (on 32 bit/compressed OOPS) or 16 * size() (on 64bit OOPS) (+ 3 object headers and alignments) So only on 32 bit/compressed OOPS for # of elements in range 2^16 ... 2^31 - 1 there is 1.5 x footprint increase. Worth considering? Regards, Peter From mandy.chung at oracle.com Thu May 5 16:59:21 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 5 May 2016 09:59:21 -0700 Subject: Review Request JDK-8155977: Update ObjectInputStream::resolveClass and resolveProxyClass to work with platform class loader In-Reply-To: <572B462D.1080103@oracle.com> References: <572B462D.1080103@oracle.com> Message-ID: > On May 5, 2016, at 6:10 AM, Alan Bateman wrote: > > In resolveClass then "is class loader corresponding to the closest .." should probably be "is the class loader ...". You didn't introduce this of course, just noticed it while reading the complete paragraph. > > The rest looks okay to me, no objection to Chris's suggestion to re-word resolveProxyClass. I was wondering why the resolveClass and resolveProxyClass methods are specified differently w.r.t. class loader search. I made only localized change as I didn?t have the history. I?m happy to clean up the spec. I?d also fix the spec ?user-defined class loader? which isn?t correct as it also includes built-in app class loader. * where loader is determined as follows: if there is a * method on the current thread's stack whose declaring class is not a * * platform class (and was not a generated to implement * reflective invocations), then loader is the class loader * of such class; otherwise, loader is the {@linkplain * ClassLoader#getPlatformClassLoader() platform class loader}. Revised webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155977/webrev.01/ Mandy From lowasser at google.com Thu May 5 17:04:00 2016 From: lowasser at google.com (Louis Wasserman) Date: Thu, 05 May 2016 17:04:00 +0000 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: <8f6d9783-52c1-64b9-bc05-26820f588ce3@gmail.com> References: <252b8a3c-dea0-3785-37f7-e3d722136087@oracle.com> <8f6d9783-52c1-64b9-bc05-26820f588ce3@gmail.com> Message-ID: Where is the current commitment to unspecified iteration order? Is that in Java 9? Generally speaking, I see no problem with going from unspecified to specified iteration order; if code had to be able to deal with *any* order previously they can certainly deal with an order that happens to be the obvious sensible order. Furthermore, the code that is easiest to use should be the simplest, most desirable use case, and I'd definitely say that means using the predictable order the elements were provided in. Providing that as another, more awkwardly named method seems deeply undesirable: Set.of and Map.of are the short, easy to use method names, and they should have the simplest, easiest-to-understand behavior: insertion order iteration. On Thu, May 5, 2016 at 9:27 AM Peter Levart wrote: > Hi, > > > On 05/05/2016 02:54 PM, Stephen Colebourne wrote: > > On 5 May 2016 at 02:30, Stuart Marks wrote: > >>> I disagree with altering the iteration order. Guava's ImmutableSet and > >>> ImmutableMap have reliable iteration specified to match creation > >>> order. This aspect of the design is very useful. > >> > >> I think this is a reasonable thing to want, but it would be a different > API. > >> The current Set.of() and Map.of() APIs have unspecified iteration > order, and > >> I want to "enforce" that via randomizing the iteration order. Having > >> unspecified iteration order, but with the implementation giving a stable > >> order, is the worst of both worlds. It lets clients bake in inadvertent > >> order dependencies, and then when we do change it, it breaks them. (This > >> seems to happen every couple years with HashMap.) Randomizing iteration > >> order helps preserve implementation freedom. > >> > >> That said, it's a fine thing to have a different API that gives a Set > or Map > >> with a stable iteration order. Several people have asked for this. I've > >> filed JDK-8156070 to track this. > > To be clear, I believe that the spec of Set.of() and Map.of() should > > require iteration order matching insertion order (because the order is > > very clearly defined in this case and anything else will be > > surprising). > > > > Stephen > > So what if the API was specified to have iteration order matching > construction order. Are you afraid that would impact implementations so > that they would be less compact or less performant? At least for small > number of elements, there is a possible implementation that keeps > construction order and is even more compact and still has O(1) lookup > performance. For example an implementation for up to 255 elements: > > public class Set0xFF extends AbstractSet implements Serializable { > > /** > * A "salt" value used for randomizing iteration order. This is > initialized once > * and stays constant for the lifetime of the JVM. It need not be > truly random, but > * it needs to vary sufficiently from one run to the next so that > iteration order > * will vary between JVM runs. > */ > static final int SALT; > > static { > SALT = new Random().nextInt(); > } > > /** > * The reciprocal of load factor. Given a number of elements > * to store, multiply by this factor to get the table size. > */ > static final double EXPAND_FACTOR = 2.0; > > final E[] elements; > final byte[] index; > > @SafeVarargs > @SuppressWarnings("unchecked") > Set0xFF(E... input) { > if (input.length > 255) { > throw new IllegalArgumentException("To many elements for > this implementation"); > } > elements = input.clone(); > index = new byte[(int) Math.ceil(EXPAND_FACTOR * > elements.length)]; > for (int i = 0; i < elements.length; i++) { > E e = Objects.requireNonNull(elements[i]); > int idx = probe(e); > if (idx >= 0) { > throw new IllegalArgumentException("duplicate element: > " + e); > } else { > index[-(idx + 1)] = (byte) (i + 1); > } > } > } > > @Override > public int size() { > return elements.length; > } > > @Override > @SuppressWarnings("unchecked") > public boolean contains(Object o) { > Objects.requireNonNull(o); > return probe((E) o) >= 0; > } > > @Override > public Iterator iterator() { > return new Iterator() { > int idx = 0; > > @Override > public boolean hasNext() { > return idx < elements.length; > } > > @Override > public E next() { > int i = idx; > if (i >= elements.length) { > throw new NoSuchElementException(); > } > idx = i + 1; > return elements[i]; > } > }; > } > > // returns index into index array at which element index + 1 is > present; or if absent, > // (-i - 1) where i is location where element index should be inserted > private int probe(E pe) { > int idx = Math.floorMod(pe.hashCode() ^ SALT, index.length); > while (true) { > int i = (int) index[idx] & 0xFF; > if (i == 0) { > return -idx - 1; > } else if (elements[i - 1].equals(pe)) { > return idx; > } else if (++idx == index.length) { > idx = 0; > } > } > } > } > > > Your SetN occupies (without considering the elements themselves) the > following number of bytes: > > 8 * size() (on 32 bit/compressed OOPS) or 16 * size() (on 64bit > OOPS) (+ 2 object headers and alignments) > > Above Set0xFF occupies: > > 6 * size() (on 32 bit/compressed OOPS) or 10 * size() (on 64bit > OOPS) (+ 3 object headers and alignments) > > An analogue Set0xFFFF for up to 65535 elements would occupy: > > 8 * size() (on 32 bit/compressed OOPS) or 12 * size() (on 64bit > OOPS) (+ 3 object headers and alignments) > > An analogue Set0xFFFFFFFF for up to 2^31 - 1 elements that still keeps > iteration order would occupy: > > 12 * size() (on 32 bit/compressed OOPS) or 16 * size() (on 64bit > OOPS) (+ 3 object headers and alignments) > > > So only on 32 bit/compressed OOPS for # of elements in range 2^16 ... > 2^31 - 1 there is 1.5 x footprint increase. > > > Worth considering? > > Regards, Peter > > From Alan.Bateman at oracle.com Thu May 5 17:28:31 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 May 2016 18:28:31 +0100 Subject: Review Request JDK-8155977: Update ObjectInputStream::resolveClass and resolveProxyClass to work with platform class loader In-Reply-To: References: <572B462D.1080103@oracle.com> Message-ID: <572B82BF.2080402@oracle.com> On 05/05/2016 17:59, Mandy Chung wrote: > : > I was wondering why the resolveClass and resolveProxyClass methods are specified differently w.r.t. class loader search. I made only localized change as I didn?t have the history. > > I?m happy to clean up the spec. I?d also fix the spec ?user-defined class loader? which isn?t correct as it also includes built-in app class loader. > > * where loader is determined as follows: if there is a > * method on the current thread's stack whose declaring class is not a > * > * platform class (and was not a generated to implement > * reflective invocations), then loader is the class loader > * of such class; otherwise, loader is the {@linkplain > * ClassLoader#getPlatformClassLoader() platform class loader}. > > Revised webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155977/webrev.01/ > This looks okay to me. I noticed the existing spec also methods "class loaders of generated reflection implementation classes" and not clear that this should be in the normative text. Anyway, not your doing and I'm suggesting we change it now. -Alan. From scolebourne at joda.org Thu May 5 17:43:23 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 5 May 2016 18:43:23 +0100 Subject: RFR 8066291: ZoneIdPrinterParser can be optimized In-Reply-To: References: <79c157ea-4b77-8e4a-444b-08a69ca4779b@Oracle.com> Message-ID: On reflection, both your and my solution have a race. the size method, is a clear check-then-act the read-only method uses Collections.unmodifiableSet() which only decorates the underlying set, thus is still check-thern-act (the current implementation does not have a race condition, as the data is copied, thus the size will match the data) There is no pleasant way to solve this that I can see. This is my best attempt: 1) Add a new field private static final CopyOnWriteArrayList ZONE_IDS; 2) At the end of registerProvider0() add all of the new IDs to the list (must be outside the loop as otherwise CopyOnWriteArrayList will be slow) 3) Add a new method getAvailableZoneIdList() that returns the list wrapped in Collections.unmodifiableList() 4) In the calling code, query the size, and then use subList(0, size) to lock the size from race conditions. A variation would be 1) Add a new field private static volatile Set ZONE_IDS; 2) Synchronize/lock registerProvider0() to ensure only one thread is in there at a time. 3) At the end of registerProvider0() add all of the new IDs to the set, storing Collections.unmodifiableSet(combinedSet) 4) Add a new method getAvailableZoneIdSet() that returns the unmodifiable set 5) Change the calling code to use the new method, but no other changes Stephen On 5 May 2016 at 16:53, Roger Riggs wrote: > Hi Stephen, > > The aspect of the current implementation that is problematic is the copying > of the set, > its not just single object creation but an entry for every ZoneID. > > Adding a size method exposing some internal state increases the possibility > that > when it is used independently it will be out of sync. Not a big issue, but > one to avoid > when designing an API. > > Exposing a mutable Hashset was probably a mistake but one that cannot be > corrected > now. The optics aren't concerning to me. > > SharedSecrets are much messier and not appropriate. > > Adding a method to provide what was originally needed is a cleaner solution. > > Roger > > > > > On 5/5/2016 11:27 AM, Stephen Colebourne wrote: >> >> I fail to see why adding a new read-only method alongside the existing >> method adds any more value to the API than adding a new size method. >> At least with the size method the API is still sensible - a mutable >> and immutable method alongside each other shouts out that a mistake >> was made. A size method is more subtle about the mistake (plenty of >> APIs have a size method alongside a collection method). >> >> Finally, a read-only method involves object creation, thus has worse >> performance than adding a size method. >> >> The only other alternative is perhaps to use SharedSecrets? I don't >> know what possibilities there are there. If not SharedSecrets, then no >> matter what, we are adding "a trivial method to the public API used >> only for an optimization". >> >> Stephen >> >> >> On 5 May 2016 at 15:23, Roger Riggs wrote: >>> >>> Hi Bhanu, >>> >>> Adding a trivial method to the public API used only for an optimization >>> is >>> not a good fix for this issue. >>> >>> A better fix was suggested to add a non-copying read-only version of >>> >>> ZoneRulesProvider.getAvailableZoneIds() >>> >>> Please revise the fix to instead implement and use: >>> >>> /** >>> * Gets a readonly set of available zone IDs. >>> *

>>> * These IDs are the string form of a {@link ZoneId}. >>> * >>> * @return a unmodifiable copy of the set of zone IDs, not null >>> */ >>> public static Set getReadOnlyAvailableZoneIds() { >>> return Collections.unmodifiableSet(ZONES.keySet()); >>> } >>> >>> Roger >>> >>> >>> >>> On 5/5/2016 5:10 AM, Bhanu Gopularam wrote: >>> >>> Hi all, >>> >>> >>> >>> Please review fix following issue >>> >>> >>> >>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8066291 >>> >>> >>> >>> Solution: provided new method to get size of available zone ids >>> >>> >>> >>> webrev : >>> http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.00 >>> >>> >>> >>> Thanks, >>> >>> Bhanu >>> >>> > From chris.hegarty at oracle.com Thu May 5 18:07:07 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 5 May 2016 19:07:07 +0100 Subject: Review Request JDK-8155977: Update ObjectInputStream::resolveClass and resolveProxyClass to work with platform class loader In-Reply-To: References: <572B462D.1080103@oracle.com> Message-ID: On 5 May 2016, at 17:59, Mandy Chung wrote: > >> On May 5, 2016, at 6:10 AM, Alan Bateman wrote: >> >> In resolveClass then "is class loader corresponding to the closest .." should probably be "is the class loader ...". You didn't introduce this of course, just noticed it while reading the complete paragraph. >> >> The rest looks okay to me, no objection to Chris's suggestion to re-word resolveProxyClass. > > I was wondering why the resolveClass and resolveProxyClass methods are specified differently w.r.t. class loader search. I made only localized change as I didn?t have the history. > > I?m happy to clean up the spec. I?d also fix the spec ?user-defined class loader? which isn?t correct as it also includes built-in app class loader. > > * where loader is determined as follows: if there is a > * method on the current thread's stack whose declaring class is not a > * > * platform class (and was not a generated to implement > * reflective invocations), then loader is the class loader > * of such class; otherwise, loader is the {@linkplain > * ClassLoader#getPlatformClassLoader() platform class loader}. > > Revised webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155977/webrev.01/ Thanks Mandy, this version looks good. -Chris. From alexandre.iline at oracle.com Thu May 5 18:42:26 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Thu, 5 May 2016 11:42:26 -0700 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: <907375E5-2BB6-42FF-9259-3CE8A2D06665@oracle.com> References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> <5729C9D1.5040506@oracle.com> <5729F9DE.4080909@oracle.com> <907375E5-2BB6-42FF-9259-3CE8A2D06665@oracle.com> Message-ID: <82FE24B5-351E-4962-9014-5AFB66FA9412@oracle.com> Chris, could you please take another look: http://cr.openjdk.java.net/~shurailine/8151914/webrev.02/ What I have discovered is that jdk.zipfs was used to access jars on the classpath, which were JTreg jars: jtreg.jar, testing.jar, etc. Cleaning the class path through the environment removed dependency on the zipfs. Whether the java.tools API behavior is correct is a separate matter. I am planning to create a standalone test case and take it with javac ppl. Thank you. Shura > On May 4, 2016, at 8:30 AM, Chris Hegarty wrote: > > On 4 May 2016, at 14:32, Alan Bateman wrote: >> >> On 04/05/2016 11:24, Chris Hegarty wrote: >>> : >>> The tests cause compilation of test library classes, but only some tests >>> actually use the methods that provoke compilation. Similar to above, tests >>> that don?t actually compile anything could depend on just java.compiler. >>> >>> This is all to fragile and may cause problems with future refactoring. I >>> think we should add the same set of @moduels to all these tests, rather >>> than an individual set determined by intimate knowledge of the inner >>> workings of the test. >>> >>> @modules java.compiler >>> jdk.compiler >>> jdk.zipfs >>> jdk.jartool >>> >>> with the addition of jdk.httpserver for MultiReleaseJarHttpProperties. >>> >> or we could move the tests into their own MultiRelease sub-directory and create a TEST.properties with a module key. That would allow these tests to drop @modules, except the test that uses the HTTP server. > > I think that would be better. > > -Chris. From Roger.Riggs at Oracle.com Thu May 5 18:48:21 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 5 May 2016 14:48:21 -0400 Subject: RFR 8066291: ZoneIdPrinterParser can be optimized In-Reply-To: References: <79c157ea-4b77-8e4a-444b-08a69ca4779b@Oracle.com> Message-ID: <3a769e0f-d551-0ea6-87ee-7bc1b0d0b39f@Oracle.com> Hi, Using the current number of ZoneIDs to avoid the recompilation of the cache is a bit weak anyway, though it seems unlikely that a ZoneID would be added and one deleted without being noticed. An alternative would be a API that returned a number that would change every time the set of ZoneIds changed. That would be more suitable both as a new API and as something to trigger updates to the cache. I'd rather see a localized implementation with a simple model. Roger On 5/5/2016 1:43 PM, Stephen Colebourne wrote: > On reflection, both your and my solution have a race. > > the size method, is a clear check-then-act > > the read-only method uses Collections.unmodifiableSet() which only > decorates the underlying set, thus is still check-thern-act > > (the current implementation does not have a race condition, as the > data is copied, thus the size will match the data) > > There is no pleasant way to solve this that I can see. This is my best attempt: > > 1) Add a new field > > private static final CopyOnWriteArrayList ZONE_IDS; > > 2) At the end of registerProvider0() add all of the new IDs to the > list (must be outside the loop as otherwise CopyOnWriteArrayList will > be slow) > > 3) Add a new method getAvailableZoneIdList() that returns the list > wrapped in Collections.unmodifiableList() > > 4) In the calling code, query the size, and then use subList(0, size) > to lock the size from race conditions. > > > A variation would be > > 1) Add a new field > > private static volatile Set ZONE_IDS; > > 2) Synchronize/lock registerProvider0() to ensure only one thread is > in there at a time. > > 3) At the end of registerProvider0() add all of the new IDs to the > set, storing Collections.unmodifiableSet(combinedSet) > > 4) Add a new method getAvailableZoneIdSet() that returns the unmodifiable set > > 5) Change the calling code to use the new method, but no other changes > > > Stephen > > > On 5 May 2016 at 16:53, Roger Riggs wrote: >> Hi Stephen, >> >> The aspect of the current implementation that is problematic is the copying >> of the set, >> its not just single object creation but an entry for every ZoneID. >> >> Adding a size method exposing some internal state increases the possibility >> that >> when it is used independently it will be out of sync. Not a big issue, but >> one to avoid >> when designing an API. >> >> Exposing a mutable Hashset was probably a mistake but one that cannot be >> corrected >> now. The optics aren't concerning to me. >> >> SharedSecrets are much messier and not appropriate. >> >> Adding a method to provide what was originally needed is a cleaner solution. >> >> Roger >> >> >> >> >> On 5/5/2016 11:27 AM, Stephen Colebourne wrote: >>> I fail to see why adding a new read-only method alongside the existing >>> method adds any more value to the API than adding a new size method. >>> At least with the size method the API is still sensible - a mutable >>> and immutable method alongside each other shouts out that a mistake >>> was made. A size method is more subtle about the mistake (plenty of >>> APIs have a size method alongside a collection method). >>> >>> Finally, a read-only method involves object creation, thus has worse >>> performance than adding a size method. >>> >>> The only other alternative is perhaps to use SharedSecrets? I don't >>> know what possibilities there are there. If not SharedSecrets, then no >>> matter what, we are adding "a trivial method to the public API used >>> only for an optimization". >>> >>> Stephen >>> >>> >>> On 5 May 2016 at 15:23, Roger Riggs wrote: >>>> Hi Bhanu, >>>> >>>> Adding a trivial method to the public API used only for an optimization >>>> is >>>> not a good fix for this issue. >>>> >>>> A better fix was suggested to add a non-copying read-only version of >>>> >>>> ZoneRulesProvider.getAvailableZoneIds() >>>> >>>> Please revise the fix to instead implement and use: >>>> >>>> /** >>>> * Gets a readonly set of available zone IDs. >>>> *

>>>> * These IDs are the string form of a {@link ZoneId}. >>>> * >>>> * @return a unmodifiable copy of the set of zone IDs, not null >>>> */ >>>> public static Set getReadOnlyAvailableZoneIds() { >>>> return Collections.unmodifiableSet(ZONES.keySet()); >>>> } >>>> >>>> Roger >>>> >>>> >>>> >>>> On 5/5/2016 5:10 AM, Bhanu Gopularam wrote: >>>> >>>> Hi all, >>>> >>>> >>>> >>>> Please review fix following issue >>>> >>>> >>>> >>>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8066291 >>>> >>>> >>>> >>>> Solution: provided new method to get size of available zone ids >>>> >>>> >>>> >>>> webrev : >>>> http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.00 >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Bhanu >>>> >>>> From alexandre.iline at oracle.com Thu May 5 19:01:57 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Thu, 5 May 2016 12:01:57 -0700 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: <82FE24B5-351E-4962-9014-5AFB66FA9412@oracle.com> References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> <5729C9D1.5040506@oracle.com> <5729F9DE.4080909@oracle.com> <907375E5-2BB6-42FF-9259-3CE8A2D06665@oracle.com> <82FE24B5-351E-4962-9014-5AFB66FA9412@oracle.com> Message-ID: > On May 5, 2016, at 11:42 AM, Alexandre (Shura) Iline wrote: > Whether the java.tools API behavior is correct is a separate matter. I am planning to create a standalone test case and take it with javac ppl. I take this ^^^^^^ back, as the error was there all along: "java.nio.file.ProviderNotFoundException: no provider found for .jar files? The fix is valid, then, is and waiting for a review. Shura > > Thank you. > > Shura > >> On May 4, 2016, at 8:30 AM, Chris Hegarty wrote: >> >> On 4 May 2016, at 14:32, Alan Bateman wrote: >>> >>> On 04/05/2016 11:24, Chris Hegarty wrote: >>>> : >>>> The tests cause compilation of test library classes, but only some tests >>>> actually use the methods that provoke compilation. Similar to above, tests >>>> that don?t actually compile anything could depend on just java.compiler. >>>> >>>> This is all to fragile and may cause problems with future refactoring. I >>>> think we should add the same set of @moduels to all these tests, rather >>>> than an individual set determined by intimate knowledge of the inner >>>> workings of the test. >>>> >>>> @modules java.compiler >>>> jdk.compiler >>>> jdk.zipfs >>>> jdk.jartool >>>> >>>> with the addition of jdk.httpserver for MultiReleaseJarHttpProperties. >>>> >>> or we could move the tests into their own MultiRelease sub-directory and create a TEST.properties with a module key. That would allow these tests to drop @modules, except the test that uses the HTTP server. >> >> I think that would be better. >> >> -Chris. > From huizhe.wang at oracle.com Thu May 5 19:16:36 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 05 May 2016 12:16:36 -0700 Subject: RFR (JAXP) JDK-8156119: Update ServiceProviderTest for XMLReaderFactory (tests for 8152912) In-Reply-To: <01a401d1a6bb$2c9d0c40$85d724c0$@oracle.com> References: <01a401d1a6bb$2c9d0c40$85d724c0$@oracle.com> Message-ID: <572B9C14.3090602@oracle.com> Thanks for providing test coverage for 8152912. The changes look good! Best, Joe On 5/5/2016 3:44 AM, Frank Yuan wrote: > Hi > > > > Would you like to review http://cr.openjdk.java.net/~fyuan/8156119/webrev.00/? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8156119 > > > > This change is to add/update some tests for verifying JDK-8152912: SAX XMLReaderFactory needs to be ServiceLoader compliant, see > Joe's RFR mail thread http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040731.html > > > > XMLReaderFactoryTest.java tests > > 1. XMLReaderFactory can create XMLReader as legacy way, and fix JDK-8015099 Classloading boundary crossing in Java 7 > > 2. XMLReaderFactory can load XMLReader impl by service resource > > > > I also updated existing tests to verify XMLReaderFactory can load XMLReader impl from provider module. > > > > > > Thanks, > > > > Frank > From stuart.marks at oracle.com Thu May 5 20:56:40 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 5 May 2016 13:56:40 -0700 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: <1116513937.1590215.1462448093838.JavaMail.zimbra@u-pem.fr> References: <1715865599.1253418.1462351091150.JavaMail.zimbra@u-pem.fr> <1116513937.1590215.1462448093838.JavaMail.zimbra@u-pem.fr> Message-ID: <1ecf5aa1-1f60-986c-d15a-0d74d3ca8ac5@oracle.com> On 5/5/16 4:34 AM, forax at univ-mlv.fr wrote: > The problem is that AbstractList is a public class, removing it from the hierarchy is not a backward compatible change, > so it's not something that can be changed as an after through. (and AbstractSet and AbstractMap) I disagree that removing those as superclasses would be backward incompatible, because it's not specified anywhere that they're superclasses. The usual problem comes from serialization, which exposes the superclass chain as well as apparently private classes; the serialization proxy stuff should avoid these problems. If somebody were to write if (Set.of(...) instanceof AbstractSet) the behavior of their code would change, but I'm not worried about that. >>> - in the constructor, you should use a local variable here, >>> @SafeVarargs >>> ListN(E... input) { >>> // copy and check manually to avoid TOCTOU >>> @SuppressWarnings("unchecked") >>> E[] elements = (E[])new Object[input.length]; // implicit >>> nullcheck of input >>> for (int i = 0; i < input.length; i++) { >>> elements[i] = Objects.requireNonNull(input[i]); >>> } >>> this.elements = elements; >>> } >> >> Nice. Will fix. It turns out that this works well for ListN, but not SetN or MapN. 307 SetN(E... input) { 308 Objects.requireNonNull(input); 309 310 size = input.length; 311 elements = (E[])new Object[(int)Math.ceil(EXPAND_FACTOR * input.length)]; 312 for (int i = 0; i < input.length; i++) { 313 E e = Objects.requireNonNull(input[i]); 314 int idx = probe(e); 315 if (idx >= 0) { 316 throw new IllegalArgumentException("duplicate element: " + e); 317 } else { 318 elements[-(idx + 1)] = e; 319 } 320 } 321 } The problem is that, during construction, probe() needs to see the elements array and the actual elements as they're inserted. Hoisting the array into a local variable and assigning elements only at the end causes probe() to NPE. I've set aside this change for SetN and MapN. >>> - the iterator should not be defined as inner class (with a reference to >>> Set2) but >>> be defined as a static class that contains a copy of e1 and e2, >>> this will save an indirection and avoid to keep a link on the Set if it >>> is transient. I started down this path. It was kind-of OK for Set2 and SetN. For MapN, it started to get hairy. Some of the Map's state needs to be passed to its entry set, and then it needs to be passed along to the entry set iterator. I started to hoist these into static nested classes, but the required new fields and constructors to initialize them started to clutter things up. We can revisit this if you really think this is an optimization, but for now I've set this aside. We can also revisit the restructuring of the iterator to advance the index in the constructor and in next(). s'marks From stuart.marks at oracle.com Thu May 5 21:00:02 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 5 May 2016 14:00:02 -0700 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: <33BB7D2A-E4F2-400B-A34F-04E12B564AC0@oracle.com> References: <8939214f-7974-c50b-8fe0-bfe24f05b77c@oracle.com> <1e526249-7706-350f-4fce-f01865ceb8de@oracle.com> <33BB7D2A-E4F2-400B-A34F-04E12B564AC0@oracle.com> Message-ID: <560f1682-c8de-3638-6819-de05fcfc3fe8@oracle.com> On 5/5/16 6:42 AM, Chris Hegarty wrote: > I have some sympathy for this. Since we are specifying that these > Collections are serializable, it would be nice for them to deserialize > on an older release, but I don?t think we should compromise the > serial form to achieve that. In fact, I agree with Stephen, I think we > should go the same way as that of the serial form of 310 classes. > > So is there anything we can do for serial interoperability? What if, > we agree the serial form and the private supporting implementation > types in 9 ( say, some time this month ). Backport these to, at least, > 8u, where they do not impact spec and are benign. JDK 9 is not > scheduled to ship until March 2017, with the regular Critical Patch > Updates that most vendors provide, I?d bet that a large number of > 8u?s in production at that time would contain the required types to > deserialize these collections. There?s no guarantee of course, but > in practical terms at least we made a reasonable effort. Interesting approach. One could backport just the serial proxy and then have its readResolve() instantiate its existing collections wrapped with unmodifiable wrappers. Or, one could just backport the immutable implementations. There's not much code to backport. I guess the question is whether this is worth it. Is this something we know will happen, or would it be done "just in case" ? s'marks From stuart.marks at oracle.com Thu May 5 21:04:16 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 5 May 2016 14:04:16 -0700 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: <572B3DC1.2080302@oracle.com> References: <5729F7AB.6050705@oracle.com> <2a2ae77b-09d2-db9c-d4b8-c7199e3c8cd3@oracle.com> <572B3DC1.2080302@oracle.com> Message-ID: On 5/5/16 5:34 AM, Alan Bateman wrote: > I understand the goal, just wondering if there is something less devious that > would make sense here. One idea is to use some portion of the Version, say the > build number, so that it at least changes each week or build. That would at > keeping the ordering consistent from run to run but it might change when someone > updates. Frankly I think we need to be more devious. We could change the iteration order on Wednesdays only, or perhaps only on full moons. :-) But really, if we're going to have randomized iteration order at all, we're better off doing it more frequently. That would flush out inadvertent order dependencies more quickly. If iteration order were to change, say, once per build, then order dependency bugs would masquerade as regressions. ("It works on b116 but fails on b117; what changed in b117?") I think that would be really confusing. s'marks From stuart.marks at oracle.com Thu May 5 21:19:37 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 5 May 2016 14:19:37 -0700 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: References: <252b8a3c-dea0-3785-37f7-e3d722136087@oracle.com> Message-ID: On 5/5/16 5:54 AM, Stephen Colebourne wrote: > To be clear, I believe that the spec of Set.of() and Map.of() should > require iteration order matching insertion order (because the order is > very clearly defined in this case and anything else will be > surprising). OK. This would be a spec change. The specification of the Set static factory methods contains the clause > The iteration order of set elements is unspecified and is subject to change. There is the corresponding clause for the Map static factory methods. [1] You can certainly propose or discuss spec changes, but if you do, I'd like it to be decoupled from this code review thread. Thanks, s'marks [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e6c3d2856593 From eaftan at google.com Thu May 5 21:22:24 2016 From: eaftan at google.com (Eddie Aftandilian) Date: Thu, 5 May 2016 14:22:24 -0700 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: References: <5729F7AB.6050705@oracle.com> <2a2ae77b-09d2-db9c-d4b8-c7199e3c8cd3@oracle.com> <572B3DC1.2080302@oracle.com> Message-ID: FWIW, at Google we have a patch against our JDK that randomizes hash iteration order. For test execution we randomize with a unique seed per JVM invocation. For production we force a specific seed for all executions. This approach catches most issues during automated testing, but reduces the likelihood of an issue in production. On Thu, May 5, 2016 at 2:04 PM, Stuart Marks wrote: > > > On 5/5/16 5:34 AM, Alan Bateman wrote: > >> I understand the goal, just wondering if there is something less devious >> that >> would make sense here. One idea is to use some portion of the Version, >> say the >> build number, so that it at least changes each week or build. That would >> at >> keeping the ordering consistent from run to run but it might change when >> someone >> updates. >> > > Frankly I think we need to be more devious. We could change the iteration > order on Wednesdays only, or perhaps only on full moons. :-) > > But really, if we're going to have randomized iteration order at all, > we're better off doing it more frequently. That would flush out inadvertent > order dependencies more quickly. If iteration order were to change, say, > once per build, then order dependency bugs would masquerade as regressions. > ("It works on b116 but fails on b117; what changed in b117?") I think that > would be really confusing. > > s'marks > From stuart.marks at oracle.com Thu May 5 21:43:20 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 5 May 2016 14:43:20 -0700 Subject: RFR(m): 8139233u1 add initial compact immutable collection implementations Message-ID: Hi all, Here's a revised webrev, incorporating some of the comments from Peter Levart, Stephen Colebourne, and R?mi Forax. http://cr.openjdk.java.net/~smarks/reviews/8139233/webrev.1/ I'd like to proceed with this changeset mostly as-is, and to allow discussion of other issues (such as spec changes regarding iteration order) to proceed asynchronously. Thanks, s'marks From jonathan.gibbons at oracle.com Thu May 5 22:08:07 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 05 May 2016 15:08:07 -0700 Subject: Review request: 8154190 & 8155513: Deprivilege java.compiler and jdk.charsets In-Reply-To: References: Message-ID: <572BC447.9040800@oracle.com> OK for java.compiler -- Jon On 04/29/2016 10:02 PM, Mandy Chung wrote: > JDK-8154190: Deprivilege java.compiler module > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8154190/webrev.00/ > > JDK-8155513: Deprivilege jdk.charsets module > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155513/webrev.00/ > > Very simple change. > > These patches move java.compiler and jdk.charsets module to be defined by the platform class loader and grant with AllPermissions initially. We could grant finer-grained permissions in the future. > > Mandy > From fguillaume at nuxeo.com Thu May 5 22:50:59 2016 From: fguillaume at nuxeo.com (Florent Guillaume) Date: Fri, 6 May 2016 00:50:59 +0200 Subject: Review Request JDK-8155977: Update ObjectInputStream::resolveClass and resolveProxyClass to work with platform class loader In-Reply-To: References: <572B462D.1080103@oracle.com> Message-ID: On Thu, May 5, 2016 at 6:59 PM, Mandy Chung wrote: > * where loader is determined as follows: if there is a > * method on the current thread's stack whose declaring class is not a > * > * platform class (and was not a generated to implement > * reflective invocations), then loader is the class loader > * of such class; otherwise, loader is the {@linkplain > * ClassLoader#getPlatformClassLoader() platform class loader}. > > Revised webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155977/webrev.01/ Hi, "a generated to implement" should probably be fixed. Regards Florent -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87 From mandy.chung at oracle.com Thu May 5 23:35:13 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 5 May 2016 16:35:13 -0700 Subject: Review Request JDK-8155977: Update ObjectInputStream::resolveClass and resolveProxyClass to work with platform class loader In-Reply-To: References: <572B462D.1080103@oracle.com> Message-ID: > On May 5, 2016, at 3:50 PM, Florent Guillaume wrote: > > On Thu, May 5, 2016 at 6:59 PM, Mandy Chung wrote: >> * where loader is determined as follows: if there is a >> * method on the current thread's stack whose declaring class is not a >> * >> * platform class (and was not a generated to implement >> * reflective invocations), then loader is the class loader >> * of such class; otherwise, loader is the {@linkplain >> * ClassLoader#getPlatformClassLoader() platform class loader}. >> >> Revised webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155977/webrev.01/ > > Hi, > > "a generated to implement" should probably be fixed. In fact, I took out "(and was not a generated to implement reflective invocations)? which is implementation details, followed up Alan?s comment. webrev.01 is now updated in place (I should have done that earlier). Mandy From steve.dohrmann at intel.com Fri May 6 01:50:04 2016 From: steve.dohrmann at intel.com (Dohrmann, Steve) Date: Fri, 6 May 2016 01:50:04 +0000 Subject: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory In-Reply-To: <5B9F9ACA-BCA9-455A-9EA5-59ECEFBFAF7F@oracle.com> References: <484C3956-9D94-4686-BDDE-03F821D58A33@intel.com> <7809D2A6-9665-458F-B9DB-37A3FD1451EB@intel.com> <5B9F9ACA-BCA9-455A-9EA5-59ECEFBFAF7F@oracle.com> Message-ID: <87476C19-3D74-4C82-B322-FA4378062249@intel.com> Hi Paul, I have to apologize. Due to an email error on my part, I just now saw your and Mark's responses (from 4/8/16). > On Apr 8, 2016, at 1:41 AM, Paul Sandoz wrote: > > Hi Steve, > >> On 8 Apr 2016, at 00:03, Dohrmann, Steve wrote: >> >> Hi Paul, >> >> We would like to have an an API for Intel's 3D XPoint memory sooner than the JDK 10 timeframe and proposed this API because it seems simple enough to consider for JDK 9. As you suggest, we will participate in the Panama discussions in this area. Any additional guidance you have would be appreciated. >> > > e.g. clone/build the panama forest, join the pamana-dev email list, and start asking questions :-) I can send you links etc. off-line if need be. > > >> Just to clarify, it is incidental that the proposed Memory interface has only one method. We see the value of the interface as nominative; a new type that can be passed around to abstract various sources of ByteBuffer memory. >> > > I suspected as much, but would prefer that we gain more experience on what this interface should be, and how it intersects with other efforts, rather than introducing a skeletal version now. The feedback is appreciated. > > I suppose it?s possible for such an interface to extend from IntFunction for compatibility if existing 8 or 9 dependent libraries use IntFunction for abstracting buffer allocation. I realize the memory interface we proposed is functional but can you describe where you are thinking the IntFunction type might be used to abstract allocation? > > FWIW at one point i did postulate and prototyped a MemoryRegion class but after some thought and feedback made a hasty retreat :-) > We did see MemoryRegion prototype code posted by Mikael on 4/22 and have been looking at that. > >> Regarding construction and allocation, our current Memory implementation allocates ByteBuffers by calling the NewDirectByteBuffer JNI function with a pointer to 3D XPoint memory allocated via a supporting native library. > > Ok, that?s what we thought when some of us had an off-line discussion about this. It slots in quite nicely, and can be easily abstracted by IntFunction i.e. i don?t think there is anything fundamentally stopping you providing something that would work on Java 8 or 9. > > > Is there any documentation on the memory ordering properties of 3D XPoint memory? how would it differ from say normal memory? can one access the memory using AVX instructions? does it support unaligned loads/stores? (i am guessing the latter is yes). > AVX use and alignment choices are the same as for DRAM. When accessed as volatile memory, as with our ByteBuffer proposal, 3D XPoint memory has the same ordering, visibility, and atomicity behavior as DRAM. Things can be a little more complicated for the programmer when persistence is used because visibility by other threads can precede persistence. We are working now on prototypes for Java use of persistent 3D XPoint memory and hope to contribute what we learn to Panama discussions on extended memory. > (Separately there is also the question of whether this kind of memory is something HotSpot itself could leverage.) > > >> The Linux libraries we have worked with are NVML (https://github.com/pmem/nvml/) and memkind (https://github.com/memkind/memkind). We recently also became aware of the NVM-Direct library (https://github.com/oracle/NVM-Direct). > > So do you create JNI bindings to NVML? > > Opportunistically perhaps this is also somewhere Panama might be able to help with, since it will provide good improvements over the current JNI experience. > Yes we have (partial) JNI bindings to both the NVML libvmem library and the memkind library. The access improvements you mention would be very welcome. Steve > Paul. > >> We currently don't need our own subclass and return the ByteBuffer returned by the JNI call. >> >> Thanks, >> Steve >> From steve.dohrmann at intel.com Fri May 6 01:50:12 2016 From: steve.dohrmann at intel.com (Dohrmann, Steve) Date: Fri, 6 May 2016 01:50:12 +0000 Subject: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory In-Reply-To: <5B9F9ACA-BCA9-455A-9EA5-59ECEFBFAF7F@oracle.com> References: <484C3956-9D94-4686-BDDE-03F821D58A33@intel.com> <7809D2A6-9665-458F-B9DB-37A3FD1451EB@intel.com> <5B9F9ACA-BCA9-455A-9EA5-59ECEFBFAF7F@oracle.com> Message-ID: Hi Paul, I have to apologize. Due to an email error on my part, I just now saw your and Mark's responses (from 4/8/16). > On Apr 8, 2016, at 1:41 AM, Paul Sandoz wrote: > > Hi Steve, > >> On 8 Apr 2016, at 00:03, Dohrmann, Steve wrote: >> >> Hi Paul, >> >> We would like to have an an API for Intel's 3D XPoint memory sooner than the JDK 10 timeframe and proposed this API because it seems simple enough to consider for JDK 9. As you suggest, we will participate in the Panama discussions in this area. Any additional guidance you have would be appreciated. >> > > e.g. clone/build the panama forest, join the pamana-dev email list, and start asking questions :-) I can send you links etc. off-line if need be. > > >> Just to clarify, it is incidental that the proposed Memory interface has only one method. We see the value of the interface as nominative; a new type that can be passed around to abstract various sources of ByteBuffer memory. >> > > I suspected as much, but would prefer that we gain more experience on what this interface should be, and how it intersects with other efforts, rather than introducing a skeletal version now. The feedback is appreciated. > > I suppose it?s possible for such an interface to extend from IntFunction for compatibility if existing 8 or 9 dependent libraries use IntFunction for abstracting buffer allocation. I realize the memory interface we proposed is functional but can you describe where you are thinking the IntFunction type might be used to abstract allocation? > > FWIW at one point i did postulate and prototyped a MemoryRegion class but after some thought and feedback made a hasty retreat :-) > We did see MemoryRegion prototype code posted by Mikael on 4/22 and have been looking at that. > >> Regarding construction and allocation, our current Memory implementation allocates ByteBuffers by calling the NewDirectByteBuffer JNI function with a pointer to 3D XPoint memory allocated via a supporting native library. > > Ok, that?s what we thought when some of us had an off-line discussion about this. It slots in quite nicely, and can be easily abstracted by IntFunction i.e. i don?t think there is anything fundamentally stopping you providing something that would work on Java 8 or 9. > > > Is there any documentation on the memory ordering properties of 3D XPoint memory? how would it differ from say normal memory? can one access the memory using AVX instructions? does it support unaligned loads/stores? (i am guessing the latter is yes). > AVX use and alignment choices are the same as for DRAM. When accessed as volatile memory, as with our ByteBuffer proposal, 3D XPoint memory has the same ordering, visibility, and atomicity behavior as DRAM. Things can be a little more complicated for the programmer when persistence is used because visibility by other threads can precede persistence. We are working now on prototypes for Java use of persistent 3D XPoint memory and hope to contribute what we learn to Panama discussions on extended memory. > (Separately there is also the question of whether this kind of memory is something HotSpot itself could leverage.) > > >> The Linux libraries we have worked with are NVML (https://github.com/pmem/nvml/) and memkind (https://github.com/memkind/memkind). We recently also became aware of the NVM-Direct library (https://github.com/oracle/NVM-Direct). > > So do you create JNI bindings to NVML? > > Opportunistically perhaps this is also somewhere Panama might be able to help with, since it will provide good improvements over the current JNI experience. > Yes we have (partial) JNI bindings to both the NVML libvmem library and the memkind library. The access improvements you mention would be very welcome. Steve > Paul. > >> We currently don't need our own subclass and return the ByteBuffer returned by the JNI call. >> >> Thanks, >> Steve >> From michael.hixson at gmail.com Fri May 6 03:51:42 2016 From: michael.hixson at gmail.com (Michael Hixson) Date: Thu, 5 May 2016 20:51:42 -0700 Subject: RFR(m): 8139233u1 add initial compact immutable collection implementations In-Reply-To: References: Message-ID: Hi Stuart, In MapN.entrySet(), is the "int idx" being declared in the wrong place? It looks like it should be a field of the Iterator rather than the Set. @Override public Set> entrySet() { return new AbstractSet>() { int idx = 0; // <------ this... @Override public int size() { return MapN.this.size; } @Override public Iterator> iterator() { // <---- ... should be here? return new Iterator>() { @Override public boolean hasNext() { Here's a test program that is not printing what I'd expect: Map map = new MapN<>("a", "1", "b", "2", "c", "3"); Set> entrySet = map.entrySet(); Iterator> iterator = entrySet.iterator(); System.out.println(iterator.hasNext()); // true System.out.println(entrySet); // [c=3, b=2, a=1] System.out.println(iterator.hasNext()); // false System.out.println(entrySet); // [] -Michael On Thu, May 5, 2016 at 2:43 PM, Stuart Marks wrote: > Hi all, > > Here's a revised webrev, incorporating some of the comments from Peter > Levart, Stephen Colebourne, and R?mi Forax. > > http://cr.openjdk.java.net/~smarks/reviews/8139233/webrev.1/ > > I'd like to proceed with this changeset mostly as-is, and to allow > discussion of other issues (such as spec changes regarding iteration order) > to proceed asynchronously. > > Thanks, > > s'marks From mandy.chung at oracle.com Fri May 6 05:34:26 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 5 May 2016 22:34:26 -0700 Subject: JDK 9 RFR of JDK-8156176: Mark GenModuleInfo.java and ModuleTest.java as intermittently failing, demote to tier 2 In-Reply-To: <572C12D0.507@oracle.com> References: <572C12D0.507@oracle.com> Message-ID: <27C5EC78-FA96-4E92-80FB-2232414B48A8@oracle.com> Hi Hamlin, code-tools-dev is not the right group for jdeps. This can send to core-libs-dev. Can you put them in ProblemList instead? I?m working on jdeps fixes and will resolve these issues. Mandy > On May 5, 2016, at 8:43 PM, Hamlin Li wrote: > > tools/jdeps/modules/GenModuleInfo.java > tools/jdeps/modules/ModuleTest.java > (from langtools/test) > > These two tests are known to fail intermittently (JDK-8153481), they should be marked accordingly with @key intermittent jtreg tag in the test file, and should be demoted from tier 1 to tier 2 until mentioned issue resolved. > > bug: https://bugs.openjdk.java.net/browse/JDK-8156176 > webrev: http://cr.openjdk.java.net/~mli/8156176/webrev.00/ > > Thank you > -Hamlin > > diff -r eddb2c2a831d test/TEST.groups > --- a/test/TEST.groups Thu May 05 16:36:00 2016 -0700 > +++ b/test/TEST.groups Thu May 05 20:27:58 2016 -0700 > @@ -28,11 +28,15 @@ > jdk \ > lib \ > tools \ > - -jdk/jshell/ToolReloadTest.java > + -jdk/jshell/ToolReloadTest.java \ > + -tools/jdeps/modules/GenModuleInfo.java \ > + -tools/jdeps/modules/ModuleTest.java > > # (Almost) no langtools tests are tier 2. > tier2 = \ > - jdk/jshell/ToolReloadTest.java > + jdk/jshell/ToolReloadTest.java \ > + tools/jdeps/modules/GenModuleInfo.java \ > + tools/jdeps/modules/ModuleTest.java > > # No langtools tests are tier 3 either. > tier3 = > diff -r eddb2c2a831d test/tools/jdeps/modules/GenModuleInfo.java > --- a/test/tools/jdeps/modules/GenModuleInfo.java Thu May 05 16:36:00 2016 -0700 > +++ b/test/tools/jdeps/modules/GenModuleInfo.java Thu May 05 20:27:58 2016 -0700 > @@ -28,6 +28,7 @@ > * @build CompilerUtils > * @modules jdk.jdeps/com.sun.tools.jdeps > * @run testng GenModuleInfo > + * @key intermittent > */ > > import java.io.*; > diff -r eddb2c2a831d test/tools/jdeps/modules/ModuleTest.java > --- a/test/tools/jdeps/modules/ModuleTest.java Thu May 05 16:36:00 2016 -0700 > +++ b/test/tools/jdeps/modules/ModuleTest.java Thu May 05 20:27:58 2016 -0700 > @@ -28,6 +28,7 @@ > * @build CompilerUtils > * @modules jdk.jdeps/com.sun.tools.jdeps > * @run testng ModuleTest > + * @key intermittent > */ > > import java.io.PrintWriter; > From huaming.li at oracle.com Fri May 6 06:18:54 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 6 May 2016 14:18:54 +0800 Subject: JDK 9 RFR of JDK-8156189: Problem list tools/jdeps/modules/GenModuleInfo.java and ModuleTest.java until JDK-8153481 is resolved Message-ID: <572C374E.7000807@oracle.com> JDK-8153481 is being fixed, so put tools/jdeps/modules/GenModuleInfo.java and ModuleTest.java in Problem list. bug: https://bugs.openjdk.java.net/browse/JDK-8156189 webrev: http://cr.openjdk.java.net/~mli/8156189/webrev.00/ Thank you -Hamlin From scolebourne at joda.org Fri May 6 10:23:46 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 6 May 2016 11:23:46 +0100 Subject: RFR 8066291: ZoneIdPrinterParser can be optimized In-Reply-To: <3a769e0f-d551-0ea6-87ee-7bc1b0d0b39f@Oracle.com> References: <79c157ea-4b77-8e4a-444b-08a69ca4779b@Oracle.com> <3a769e0f-d551-0ea6-87ee-7bc1b0d0b39f@Oracle.com> Message-ID: The set of zones can only increase, it cannot decrease as there is no removal mechanism. As such, the size of the set is a proxy for the number you describe. One other point. The method that most users will call to get the set of ZoneIds is ZoneId.getAvailableZoneIds(). That method delegates to the one on ZoneRulesProvider. As such, we can change the method on ZoneRulesProvider to return an immutable set while still keeping the method commonly used by users returning a mutable set. The incompatibility impact caused by this would be vanishingly small. To me, this is by far the best way to address this problem, as it avoids a new method. Thus, I propose: 1) Add a new field private static volatile Set ZONE_IDS; 2) Synchronize/lock registerProvider0() to ensure only one thread is in there at a time. 3) At the end of registerProvider0() add all of the existing and new IDs to a new HashSet wrapped in Collections.unmodifiableSet(combinedSet) and change ZONE_IDS to point at the new set. 4) Change ZoneRulesProvider.getAvailableZoneIds() to return ZONE_IDS. Change the spec to indicate the result is unmodifiable. 5) Change ZoneId.getAvailableZoneIds() to return new HashSet(ZoneRulesProvider.getAvailableZoneIds()) Code changes: ZoneId: public static Set getAvailableZoneIds() { return new HashSet(ZoneRulesProvider.getAvailableZoneIds()); } ZoneRulesProvider: private static volatile Set ZONE_IDS; @return the unmodifiable set of zone IDs, not null public static Set getAvailableZoneIds() { return ZONE_IDS; } private static synchronized void registerProvider0(ZoneRulesProvider provider) { for (String zoneId : provider.provideZoneIds()) { Objects.requireNonNull(zoneId, "zoneId"); ZoneRulesProvider old = ZONES.putIfAbsent(zoneId, provider); if (old != null) { throw new ZoneRulesException( "Unable to register zone as one already registered with that ID: " + zoneId + ", currently loading from provider: " + provider); } } Set combinedSet = new HashSet(ZONES.keySet()); ZONE_IDS = Collections.unmodifiableSet(combinedSet); } Stephen On 5 May 2016 at 19:48, Roger Riggs wrote: > Hi, > > Using the current number of ZoneIDs to avoid the recompilation of the cache > is a bit weak anyway, > though it seems unlikely that a ZoneID would be added and one deleted > without being noticed. > > An alternative would be a API that returned a number that would change every > time the set of ZoneIds changed. > That would be more suitable both as a new API and as something to trigger > updates to the cache. > > I'd rather see a localized implementation with a simple model. > > Roger > > > On 5/5/2016 1:43 PM, Stephen Colebourne wrote: >> >> On reflection, both your and my solution have a race. >> >> the size method, is a clear check-then-act >> >> the read-only method uses Collections.unmodifiableSet() which only >> decorates the underlying set, thus is still check-thern-act >> >> (the current implementation does not have a race condition, as the >> data is copied, thus the size will match the data) >> >> There is no pleasant way to solve this that I can see. This is my best >> attempt: >> >> 1) Add a new field >> >> private static final CopyOnWriteArrayList ZONE_IDS; >> >> 2) At the end of registerProvider0() add all of the new IDs to the >> list (must be outside the loop as otherwise CopyOnWriteArrayList will >> be slow) >> >> 3) Add a new method getAvailableZoneIdList() that returns the list >> wrapped in Collections.unmodifiableList() >> >> 4) In the calling code, query the size, and then use subList(0, size) >> to lock the size from race conditions. >> >> >> A variation would be >> >> 1) Add a new field >> >> private static volatile Set ZONE_IDS; >> >> 2) Synchronize/lock registerProvider0() to ensure only one thread is >> in there at a time. >> >> 3) At the end of registerProvider0() add all of the new IDs to the >> set, storing Collections.unmodifiableSet(combinedSet) >> >> 4) Add a new method getAvailableZoneIdSet() that returns the unmodifiable >> set >> >> 5) Change the calling code to use the new method, but no other changes >> >> >> Stephen >> >> >> On 5 May 2016 at 16:53, Roger Riggs wrote: >>> >>> Hi Stephen, >>> >>> The aspect of the current implementation that is problematic is the >>> copying >>> of the set, >>> its not just single object creation but an entry for every ZoneID. >>> >>> Adding a size method exposing some internal state increases the >>> possibility >>> that >>> when it is used independently it will be out of sync. Not a big issue, >>> but >>> one to avoid >>> when designing an API. >>> >>> Exposing a mutable Hashset was probably a mistake but one that cannot be >>> corrected >>> now. The optics aren't concerning to me. >>> >>> SharedSecrets are much messier and not appropriate. >>> >>> Adding a method to provide what was originally needed is a cleaner >>> solution. >>> >>> Roger >>> >>> >>> >>> >>> On 5/5/2016 11:27 AM, Stephen Colebourne wrote: >>>> >>>> I fail to see why adding a new read-only method alongside the existing >>>> method adds any more value to the API than adding a new size method. >>>> At least with the size method the API is still sensible - a mutable >>>> and immutable method alongside each other shouts out that a mistake >>>> was made. A size method is more subtle about the mistake (plenty of >>>> APIs have a size method alongside a collection method). >>>> >>>> Finally, a read-only method involves object creation, thus has worse >>>> performance than adding a size method. >>>> >>>> The only other alternative is perhaps to use SharedSecrets? I don't >>>> know what possibilities there are there. If not SharedSecrets, then no >>>> matter what, we are adding "a trivial method to the public API used >>>> only for an optimization". >>>> >>>> Stephen >>>> >>>> >>>> On 5 May 2016 at 15:23, Roger Riggs wrote: >>>>> >>>>> Hi Bhanu, >>>>> >>>>> Adding a trivial method to the public API used only for an optimization >>>>> is >>>>> not a good fix for this issue. >>>>> >>>>> A better fix was suggested to add a non-copying read-only version of >>>>> >>>>> ZoneRulesProvider.getAvailableZoneIds() >>>>> >>>>> Please revise the fix to instead implement and use: >>>>> >>>>> /** >>>>> * Gets a readonly set of available zone IDs. >>>>> *

>>>>> * These IDs are the string form of a {@link ZoneId}. >>>>> * >>>>> * @return a unmodifiable copy of the set of zone IDs, not null >>>>> */ >>>>> public static Set getReadOnlyAvailableZoneIds() { >>>>> return Collections.unmodifiableSet(ZONES.keySet()); >>>>> } >>>>> >>>>> Roger >>>>> >>>>> >>>>> >>>>> On 5/5/2016 5:10 AM, Bhanu Gopularam wrote: >>>>> >>>>> Hi all, >>>>> >>>>> >>>>> >>>>> Please review fix following issue >>>>> >>>>> >>>>> >>>>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8066291 >>>>> >>>>> >>>>> >>>>> Solution: provided new method to get size of available zone ids >>>>> >>>>> >>>>> >>>>> webrev : >>>>> http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.00 >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Bhanu >>>>> >>>>> > From Alan.Bateman at oracle.com Fri May 6 10:59:45 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 6 May 2016 11:59:45 +0100 Subject: RFR: 8152084: Introduction of ssliop protocol to corbaloc In-Reply-To: <494597590.43598332.1462452692542.JavaMail.zimbra@redhat.com> References: <321794846.38762864.1461088691787.JavaMail.zimbra@redhat.com> <5728A7AC.8000103@redhat.com> <5728AF76.9020406@oracle.com> <63067504.43350431.1462372580193.JavaMail.zimbra@redhat.com> <572A0CE2.8020101@redhat.com> <572A1754.8000507@oracle.com> <494597590.43598332.1462452692542.JavaMail.zimbra@redhat.com> Message-ID: <572C7921.4040205@oracle.com> On 05/05/2016 13:51, Tomasz Adamski wrote: > Added classes are indeed generated from idl present in Security Server Specification which is part of Corba 3.3 specification. I can find no information about formal corba compliance process. Can you please point me to people who can help me regarding this? > I see that the CORBA specs have a section on Compliance but it's not something that I can really comment on. In the Oracle docs then the "Official Specifications for CORBA support" [1] has the references and details on what is supported in the Oracle JDK, which should match what is in OpenJDK. Note that it does says "J2SE 5.0", just a reflection that this has not been rev'ed in 12+ years, hence the nervousness about adding parts of CORBA 3.3. -Alan [1] https://docs.oracle.com/javase/8/docs/technotes/guides/idl/compatibility-CORBA.html#spec From bill.mair at web.de Fri May 6 11:29:42 2016 From: bill.mair at web.de (Bill Mair) Date: Fri, 6 May 2016 13:29:42 +0200 Subject: LDAP+Kerberos - JDK-8149521 also in JDK9 In-Reply-To: References: Message-ID: <53407560-07ff-3ece-4a32-78ba19370f65@web.de> Hi, Am I posting this to the correct list? If I am, would someone please tell me who to send this information to? I would like to confirm that this bug still indeed exists, as Balchandra Vaidya requested. From what I can see error hasn't been fixed in jdk9 either: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f38c0650a60f/src/java.naming/share/classes/com/sun/jndi/ldap/ServiceLocator.java Thanks and regards, Bill Mair -------- Forwarded Message -------- Subject: Bug 8149521 Date: Thu, 5 May 2016 17:47:49 +0200 From: Bill Mair To: core-libs-dev at openjdk.java.net Hi, I've just ran in to the same problem described in this bug: https://bugs.openjdk.java.net/browse/JDK-8149521 I found it in java7u79 and I used java8u91 to confirm it still exists. The error is in "com.sun.jndi.ldap.ServiceLocator" at line 273 (http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/df209f221cca/src/share/classes/com/sun/jndi/ldap/ServiceLocator.java), The "Hostname" token always has a trailing "." (period). This doesn't normally matter for "normal" network operation but it is critical where working with Kerberos. If you use "ldap:///dc=example,dc=com" the the corresponding name might be something like "ldap1.example.com."(notice the trailing dot) Kerberos is then looking for "ldap/ldap1.example.com." instead of "ldap/ldap1.example.com" The first record simply doesn't exist in the kerberos DB. Regards, Bill Mair From balchandra.vaidya at oracle.com Fri May 6 12:03:12 2016 From: balchandra.vaidya at oracle.com (Balchandra Vaidya) Date: Fri, 6 May 2016 17:33:12 +0530 Subject: LDAP+Kerberos - JDK-8149521 also in JDK9 In-Reply-To: <53407560-07ff-3ece-4a32-78ba19370f65@web.de> References: <53407560-07ff-3ece-4a32-78ba19370f65@web.de> Message-ID: Hi Bill, The bug has been updated with the additional information from you. Thanks Balchandra On 5/6/2016 4:59 PM, Bill Mair wrote: > Hi, > > Am I posting this to the correct list? If I am, would someone please > tell me who to send this information to? > > I would like to confirm that this bug still indeed exists, as Balchandra > Vaidya requested. > > From what I can see error hasn't been fixed in jdk9 either: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f38c0650a60f/src/java.naming/share/classes/com/sun/jndi/ldap/ServiceLocator.java > > Thanks and regards, > > Bill Mair > > -------- Forwarded Message -------- > Subject: Bug 8149521 > Date: Thu, 5 May 2016 17:47:49 +0200 > From: Bill Mair > To: core-libs-dev at openjdk.java.net > > > > Hi, > > I've just ran in to the same problem described in this bug: https://bugs.openjdk.java.net/browse/JDK-8149521 > > I found it in java7u79 and I used java8u91 to confirm it still exists. > > The error is in "com.sun.jndi.ldap.ServiceLocator" at line 273 (http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/df209f221cca/src/share/classes/com/sun/jndi/ldap/ServiceLocator.java), > > The "Hostname" token always has a trailing "." (period). This doesn't normally matter for "normal" network operation but it is critical where working with Kerberos. > > If you use "ldap:///dc=example,dc=com" the the corresponding name might be something like "ldap1.example.com."(notice the trailing dot) > > Kerberos is then looking for "ldap/ldap1.example.com." instead of "ldap/ldap1.example.com" > > The first record simply doesn't exist in the kerberos DB. > > Regards, > > Bill Mair > > From daniel.fuchs at oracle.com Fri May 6 14:22:13 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 6 May 2016 16:22:13 +0200 Subject: RFR: 8156153: java/lang/System/LoggerFinder/jdk/DefaultLoggerBridgeTest/DefaultLoggerBridgeTest.java fails with java.lang.RuntimeException Message-ID: <84bd7a46-09cb-24dd-0814-856a8218d8e6@oracle.com> Hi, This is a fix for a subtle test bug caused by a logger being GCed. bug id: https://bugs.openjdk.java.net/browse/JDK-8156153 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8156153/webrev/ This test has been seen failing in hs integration with the following error: ---------------------------------------- ... *** With Security Manager, without permissions ... ----------System.err:(24/1937)---------- java.lang.RuntimeException: identical backend loggers at DefaultLoggerBridgeTest.test(DefaultLoggerBridgeTest.java:404) ... ---------------------------------------- The main runs the same test sequentially in 3 different configurations: - without security manager, - with security manager and no permissions granted, - with security manager and permissions granted. The test attempts to first create a lazy logger for a system class, then a logger for an application class. It expects that the second concrete logger will be created first - because it should not be wrapped in a lazy logger. However, since the loggers are not referenced outside of the test method, then it can happen that the application logger gets garbage collected between one scenario and the next, which will invert the creation sequence (or more exactly pseudo-creation sequence in this case) in the next scenario. To fix this I propose to run each scenario in its own VM - by using three different @run main lines. This way each scenario will start with a clean slate. best regards, -- daniel From mandy.chung at oracle.com Fri May 6 15:51:48 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 6 May 2016 08:51:48 -0700 Subject: JDK 9 RFR of JDK-8156189: Problem list tools/jdeps/modules/GenModuleInfo.java and ModuleTest.java until JDK-8153481 is resolved In-Reply-To: <572C374E.7000807@oracle.com> References: <572C374E.7000807@oracle.com> Message-ID: <72F7919E-EC11-4BDA-B41C-06F27B7FB01B@oracle.com> > On May 5, 2016, at 11:18 PM, Hamlin Li wrote: > > JDK-8153481 is being fixed, so put tools/jdeps/modules/GenModuleInfo.java and ModuleTest.java in Problem list. > > bug: https://bugs.openjdk.java.net/browse/JDK-8156189 > webrev: http://cr.openjdk.java.net/~mli/8156189/webrev.00/ Looks okay. You can merge line 98 and 99 and change the second column to a comma-separated list of bug ids. You can fix it before you push. Mandy From markt at apache.org Fri May 6 17:03:39 2016 From: markt at apache.org (Mark Thomas) Date: Fri, 6 May 2016 18:03:39 +0100 Subject: Memory leak in sun.rmi.transport.GC Message-ID: While working my way through Tomcat's memory leak protection / detection / fixing code, I have found an issue that remains unresolved in the latest JDK 9 source. The thread created by the GC class does not explicitly set the context class loader so it inherits the current context class loader. Consider the following sequence where each module has a dedicated class loader (e.g. web applications in a Servlet container). Module A starts an RMIConnectorServer instance. Amongst other things it calls GC.requestLatency(long) which starts the Daemon thread. Module B starts another RMIConnectorServer instance. It also calls GC.requestLatency(long) and the Daemon thread continues. Module A shuts down the RMIConnectorServer and does all the right clean-up. The associated LatencyRequest is cancelled but the Daemon thread continues because of the LatencyRequest from Module B. At this point there is a memory leak because the class loader associated with module A is pinned in memory since a reference to it is held by the context class loader field of the Daemon thread. The fix looks to be trivial. Something along the lines of the following around line 146 of GC: d.setContextClassLoader(GC.class.getClassLoader()); It may appear contrived but I have seen exactly this memory leak occur in production systems where multiple web applications were using RMI. If I can provide any further information or if there is better place / way to submit this then please do let me know. Mark From Roger.Riggs at Oracle.com Fri May 6 17:15:16 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 6 May 2016 13:15:16 -0400 Subject: RFR 8066291: ZoneIdPrinterParser can be optimized In-Reply-To: References: <79c157ea-4b77-8e4a-444b-08a69ca4779b@Oracle.com> <3a769e0f-d551-0ea6-87ee-7bc1b0d0b39f@Oracle.com> Message-ID: Hi Stephen, It still seems pretty elaborate and duplicates the set; but it would be a bigger change to restructure the internal ZONES map to have an immutable map in the implementation and synchronize its update when a new Provider is added (very infrequently/never). ConcurrentHashMap is a pretty expensive datatype when concurrency is low/not existent. So, your proposal is a reasonable course of action. If there are any objections to the behavior change, we can fall back to a new method. Roger On 5/6/2016 6:23 AM, Stephen Colebourne wrote: > The set of zones can only increase, it cannot decrease as there is no > removal mechanism. As such, the size of the set is a proxy for the > number you describe. > > One other point. The method that most users will call to get the set > of ZoneIds is ZoneId.getAvailableZoneIds(). That method delegates to > the one on ZoneRulesProvider. As such, we can change the method on > ZoneRulesProvider to return an immutable set while still keeping the > method commonly used by users returning a mutable set. The > incompatibility impact caused by this would be vanishingly small. To > me, this is by far the best way to address this problem, as it avoids > a new method. > > Thus, I propose: > > 1) Add a new field private static volatile Set ZONE_IDS; > > 2) Synchronize/lock registerProvider0() to ensure only one thread is > in there at a time. > > 3) At the end of registerProvider0() add all of the existing and new > IDs to a new HashSet wrapped in > Collections.unmodifiableSet(combinedSet) and change ZONE_IDS to point > at the new set. > > 4) Change ZoneRulesProvider.getAvailableZoneIds() to return ZONE_IDS. > Change the spec to indicate the result is unmodifiable. > > 5) Change ZoneId.getAvailableZoneIds() to return new > HashSet(ZoneRulesProvider.getAvailableZoneIds()) > > Code changes: > > ZoneId: > > public static Set getAvailableZoneIds() { > return new HashSet(ZoneRulesProvider.getAvailableZoneIds()); > } > > > ZoneRulesProvider: > > private static volatile Set ZONE_IDS; > > @return the unmodifiable set of zone IDs, not null > public static Set getAvailableZoneIds() { > return ZONE_IDS; > } > > private static synchronized void registerProvider0(ZoneRulesProvider provider) { > for (String zoneId : provider.provideZoneIds()) { > Objects.requireNonNull(zoneId, "zoneId"); > ZoneRulesProvider old = ZONES.putIfAbsent(zoneId, provider); > if (old != null) { > throw new ZoneRulesException( > "Unable to register zone as one already registered with that > ID: " + zoneId + > ", currently loading from provider: " + provider); > } > } > Set combinedSet = new HashSet(ZONES.keySet()); > ZONE_IDS = Collections.unmodifiableSet(combinedSet); > } > > Stephen > > > On 5 May 2016 at 19:48, Roger Riggs wrote: >> Hi, >> >> Using the current number of ZoneIDs to avoid the recompilation of the cache >> is a bit weak anyway, >> though it seems unlikely that a ZoneID would be added and one deleted >> without being noticed. >> >> An alternative would be a API that returned a number that would change every >> time the set of ZoneIds changed. >> That would be more suitable both as a new API and as something to trigger >> updates to the cache. >> >> I'd rather see a localized implementation with a simple model. >> >> Roger >> >> >> On 5/5/2016 1:43 PM, Stephen Colebourne wrote: >>> On reflection, both your and my solution have a race. >>> >>> the size method, is a clear check-then-act >>> >>> the read-only method uses Collections.unmodifiableSet() which only >>> decorates the underlying set, thus is still check-thern-act >>> >>> (the current implementation does not have a race condition, as the >>> data is copied, thus the size will match the data) >>> >>> There is no pleasant way to solve this that I can see. This is my best >>> attempt: >>> >>> 1) Add a new field >>> >>> private static final CopyOnWriteArrayList ZONE_IDS; >>> >>> 2) At the end of registerProvider0() add all of the new IDs to the >>> list (must be outside the loop as otherwise CopyOnWriteArrayList will >>> be slow) >>> >>> 3) Add a new method getAvailableZoneIdList() that returns the list >>> wrapped in Collections.unmodifiableList() >>> >>> 4) In the calling code, query the size, and then use subList(0, size) >>> to lock the size from race conditions. >>> >>> >>> A variation would be >>> >>> 1) Add a new field >>> >>> private static volatile Set ZONE_IDS; >>> >>> 2) Synchronize/lock registerProvider0() to ensure only one thread is >>> in there at a time. >>> >>> 3) At the end of registerProvider0() add all of the new IDs to the >>> set, storing Collections.unmodifiableSet(combinedSet) >>> >>> 4) Add a new method getAvailableZoneIdSet() that returns the unmodifiable >>> set >>> >>> 5) Change the calling code to use the new method, but no other changes >>> >>> >>> Stephen >>> >>> >>> On 5 May 2016 at 16:53, Roger Riggs wrote: >>>> Hi Stephen, >>>> >>>> The aspect of the current implementation that is problematic is the >>>> copying >>>> of the set, >>>> its not just single object creation but an entry for every ZoneID. >>>> >>>> Adding a size method exposing some internal state increases the >>>> possibility >>>> that >>>> when it is used independently it will be out of sync. Not a big issue, >>>> but >>>> one to avoid >>>> when designing an API. >>>> >>>> Exposing a mutable Hashset was probably a mistake but one that cannot be >>>> corrected >>>> now. The optics aren't concerning to me. >>>> >>>> SharedSecrets are much messier and not appropriate. >>>> >>>> Adding a method to provide what was originally needed is a cleaner >>>> solution. >>>> >>>> Roger >>>> >>>> >>>> >>>> >>>> On 5/5/2016 11:27 AM, Stephen Colebourne wrote: >>>>> I fail to see why adding a new read-only method alongside the existing >>>>> method adds any more value to the API than adding a new size method. >>>>> At least with the size method the API is still sensible - a mutable >>>>> and immutable method alongside each other shouts out that a mistake >>>>> was made. A size method is more subtle about the mistake (plenty of >>>>> APIs have a size method alongside a collection method). >>>>> >>>>> Finally, a read-only method involves object creation, thus has worse >>>>> performance than adding a size method. >>>>> >>>>> The only other alternative is perhaps to use SharedSecrets? I don't >>>>> know what possibilities there are there. If not SharedSecrets, then no >>>>> matter what, we are adding "a trivial method to the public API used >>>>> only for an optimization". >>>>> >>>>> Stephen >>>>> >>>>> >>>>> On 5 May 2016 at 15:23, Roger Riggs wrote: >>>>>> Hi Bhanu, >>>>>> >>>>>> Adding a trivial method to the public API used only for an optimization >>>>>> is >>>>>> not a good fix for this issue. >>>>>> >>>>>> A better fix was suggested to add a non-copying read-only version of >>>>>> >>>>>> ZoneRulesProvider.getAvailableZoneIds() >>>>>> >>>>>> Please revise the fix to instead implement and use: >>>>>> >>>>>> /** >>>>>> * Gets a readonly set of available zone IDs. >>>>>> *

>>>>>> * These IDs are the string form of a {@link ZoneId}. >>>>>> * >>>>>> * @return a unmodifiable copy of the set of zone IDs, not null >>>>>> */ >>>>>> public static Set getReadOnlyAvailableZoneIds() { >>>>>> return Collections.unmodifiableSet(ZONES.keySet()); >>>>>> } >>>>>> >>>>>> Roger >>>>>> >>>>>> >>>>>> >>>>>> On 5/5/2016 5:10 AM, Bhanu Gopularam wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> >>>>>> >>>>>> Please review fix following issue >>>>>> >>>>>> >>>>>> >>>>>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8066291 >>>>>> >>>>>> >>>>>> >>>>>> Solution: provided new method to get size of available zone ids >>>>>> >>>>>> >>>>>> >>>>>> webrev : >>>>>> http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.00 >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Bhanu >>>>>> >>>>>> From stuart.marks at oracle.com Fri May 6 17:57:58 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 6 May 2016 10:57:58 -0700 Subject: RFR(m): 8139233u1 add initial compact immutable collection implementations In-Reply-To: References: Message-ID: <9622a280-f29a-820c-00e9-74f41964141f@oracle.com> On 5/5/16 8:51 PM, Michael Hixson wrote: > In MapN.entrySet(), is the "int idx" being declared in the wrong > place? It looks like it should be a field of the Iterator rather than > the Set. Hi Michael, Well spotted! You're quite correct. I've been doing too much last-minute refactoring. I note that no tests failed because of this bug. I'll rework your test case into a regression test and include it in the changeset. Thanks a lot! This was very helpful. s'marks From stuart.marks at oracle.com Fri May 6 18:04:27 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 6 May 2016 11:04:27 -0700 Subject: RFR(m): 8139233u1 add initial compact immutable collection implementations In-Reply-To: <9622a280-f29a-820c-00e9-74f41964141f@oracle.com> References: <9622a280-f29a-820c-00e9-74f41964141f@oracle.com> Message-ID: <192fcb16-aa51-5662-e38b-1efb2a68937e@oracle.com> On 5/6/16 10:57 AM, Stuart Marks wrote: > I've been doing too much last-minute refactoring. Actually that's wasn't the cause of this bug. The bug was in the previous webrev and also in the prototype from my branch in the sandbox, so it's been in there quite a while. Again, thanks for spotting it. s'marks From martinrb at google.com Fri May 6 18:48:44 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 6 May 2016 11:48:44 -0700 Subject: RFR 8066291: ZoneIdPrinterParser can be optimized In-Reply-To: References: <79c157ea-4b77-8e4a-444b-08a69ca4779b@Oracle.com> <3a769e0f-d551-0ea6-87ee-7bc1b0d0b39f@Oracle.com> Message-ID: ConcurrentHashMap is (probably!) cheaper than it used to be. For read-mostly operations there won't be a lock. But yes, even better for read-mostly use is to keep an immutable map and CAS-loop whenever you need to update. The VarHandle work and the immutable collections work should make that better in the future. Perhaps adding something in j.u.c. is worthwhile, but until then it's not too hard to write your own CAS-loop to update the map (but wait for VarHandles to be fully baked). On Fri, May 6, 2016 at 10:15 AM, Roger Riggs wrote: > Hi Stephen, > > It still seems pretty elaborate and duplicates the set; but it would be a > bigger change > to restructure the internal ZONES map to have an immutable map in the > implementation > and synchronize its update when a new Provider is added (very > infrequently/never). > ConcurrentHashMap is a pretty expensive datatype when concurrency is low/not > existent. > > So, your proposal is a reasonable course of action. > > If there are any objections to the behavior change, we can fall back to a > new method. > > Roger > > > > > On 5/6/2016 6:23 AM, Stephen Colebourne wrote: >> >> The set of zones can only increase, it cannot decrease as there is no >> removal mechanism. As such, the size of the set is a proxy for the >> number you describe. >> >> One other point. The method that most users will call to get the set >> of ZoneIds is ZoneId.getAvailableZoneIds(). That method delegates to >> the one on ZoneRulesProvider. As such, we can change the method on >> ZoneRulesProvider to return an immutable set while still keeping the >> method commonly used by users returning a mutable set. The >> incompatibility impact caused by this would be vanishingly small. To >> me, this is by far the best way to address this problem, as it avoids >> a new method. >> >> Thus, I propose: >> >> 1) Add a new field private static volatile Set ZONE_IDS; >> >> 2) Synchronize/lock registerProvider0() to ensure only one thread is >> in there at a time. >> >> 3) At the end of registerProvider0() add all of the existing and new >> IDs to a new HashSet wrapped in >> Collections.unmodifiableSet(combinedSet) and change ZONE_IDS to point >> at the new set. >> >> 4) Change ZoneRulesProvider.getAvailableZoneIds() to return ZONE_IDS. >> Change the spec to indicate the result is unmodifiable. >> >> 5) Change ZoneId.getAvailableZoneIds() to return new >> HashSet(ZoneRulesProvider.getAvailableZoneIds()) >> >> Code changes: >> >> ZoneId: >> >> public static Set getAvailableZoneIds() { >> return new HashSet(ZoneRulesProvider.getAvailableZoneIds()); >> } >> >> >> ZoneRulesProvider: >> >> private static volatile Set ZONE_IDS; >> >> @return the unmodifiable set of zone IDs, not null >> public static Set getAvailableZoneIds() { >> return ZONE_IDS; >> } >> >> private static synchronized void registerProvider0(ZoneRulesProvider >> provider) { >> for (String zoneId : provider.provideZoneIds()) { >> Objects.requireNonNull(zoneId, "zoneId"); >> ZoneRulesProvider old = ZONES.putIfAbsent(zoneId, provider); >> if (old != null) { >> throw new ZoneRulesException( >> "Unable to register zone as one already registered with that >> ID: " + zoneId + >> ", currently loading from provider: " + provider); >> } >> } >> Set combinedSet = new HashSet(ZONES.keySet()); >> ZONE_IDS = Collections.unmodifiableSet(combinedSet); >> } >> >> Stephen >> >> >> On 5 May 2016 at 19:48, Roger Riggs wrote: >>> >>> Hi, >>> >>> Using the current number of ZoneIDs to avoid the recompilation of the >>> cache >>> is a bit weak anyway, >>> though it seems unlikely that a ZoneID would be added and one deleted >>> without being noticed. >>> >>> An alternative would be a API that returned a number that would change >>> every >>> time the set of ZoneIds changed. >>> That would be more suitable both as a new API and as something to trigger >>> updates to the cache. >>> >>> I'd rather see a localized implementation with a simple model. >>> >>> Roger >>> >>> >>> On 5/5/2016 1:43 PM, Stephen Colebourne wrote: >>>> >>>> On reflection, both your and my solution have a race. >>>> >>>> the size method, is a clear check-then-act >>>> >>>> the read-only method uses Collections.unmodifiableSet() which only >>>> decorates the underlying set, thus is still check-thern-act >>>> >>>> (the current implementation does not have a race condition, as the >>>> data is copied, thus the size will match the data) >>>> >>>> There is no pleasant way to solve this that I can see. This is my best >>>> attempt: >>>> >>>> 1) Add a new field >>>> >>>> private static final CopyOnWriteArrayList ZONE_IDS; >>>> >>>> 2) At the end of registerProvider0() add all of the new IDs to the >>>> list (must be outside the loop as otherwise CopyOnWriteArrayList will >>>> be slow) >>>> >>>> 3) Add a new method getAvailableZoneIdList() that returns the list >>>> wrapped in Collections.unmodifiableList() >>>> >>>> 4) In the calling code, query the size, and then use subList(0, size) >>>> to lock the size from race conditions. >>>> >>>> >>>> A variation would be >>>> >>>> 1) Add a new field >>>> >>>> private static volatile Set ZONE_IDS; >>>> >>>> 2) Synchronize/lock registerProvider0() to ensure only one thread is >>>> in there at a time. >>>> >>>> 3) At the end of registerProvider0() add all of the new IDs to the >>>> set, storing Collections.unmodifiableSet(combinedSet) >>>> >>>> 4) Add a new method getAvailableZoneIdSet() that returns the >>>> unmodifiable >>>> set >>>> >>>> 5) Change the calling code to use the new method, but no other changes >>>> >>>> >>>> Stephen >>>> >>>> >>>> On 5 May 2016 at 16:53, Roger Riggs wrote: >>>>> >>>>> Hi Stephen, >>>>> >>>>> The aspect of the current implementation that is problematic is the >>>>> copying >>>>> of the set, >>>>> its not just single object creation but an entry for every ZoneID. >>>>> >>>>> Adding a size method exposing some internal state increases the >>>>> possibility >>>>> that >>>>> when it is used independently it will be out of sync. Not a big issue, >>>>> but >>>>> one to avoid >>>>> when designing an API. >>>>> >>>>> Exposing a mutable Hashset was probably a mistake but one that cannot >>>>> be >>>>> corrected >>>>> now. The optics aren't concerning to me. >>>>> >>>>> SharedSecrets are much messier and not appropriate. >>>>> >>>>> Adding a method to provide what was originally needed is a cleaner >>>>> solution. >>>>> >>>>> Roger >>>>> >>>>> >>>>> >>>>> >>>>> On 5/5/2016 11:27 AM, Stephen Colebourne wrote: >>>>>> >>>>>> I fail to see why adding a new read-only method alongside the existing >>>>>> method adds any more value to the API than adding a new size method. >>>>>> At least with the size method the API is still sensible - a mutable >>>>>> and immutable method alongside each other shouts out that a mistake >>>>>> was made. A size method is more subtle about the mistake (plenty of >>>>>> APIs have a size method alongside a collection method). >>>>>> >>>>>> Finally, a read-only method involves object creation, thus has worse >>>>>> performance than adding a size method. >>>>>> >>>>>> The only other alternative is perhaps to use SharedSecrets? I don't >>>>>> know what possibilities there are there. If not SharedSecrets, then no >>>>>> matter what, we are adding "a trivial method to the public API used >>>>>> only for an optimization". >>>>>> >>>>>> Stephen >>>>>> >>>>>> >>>>>> On 5 May 2016 at 15:23, Roger Riggs wrote: >>>>>>> >>>>>>> Hi Bhanu, >>>>>>> >>>>>>> Adding a trivial method to the public API used only for an >>>>>>> optimization >>>>>>> is >>>>>>> not a good fix for this issue. >>>>>>> >>>>>>> A better fix was suggested to add a non-copying read-only version of >>>>>>> >>>>>>> ZoneRulesProvider.getAvailableZoneIds() >>>>>>> >>>>>>> Please revise the fix to instead implement and use: >>>>>>> >>>>>>> /** >>>>>>> * Gets a readonly set of available zone IDs. >>>>>>> *

>>>>>>> * These IDs are the string form of a {@link ZoneId}. >>>>>>> * >>>>>>> * @return a unmodifiable copy of the set of zone IDs, not >>>>>>> null >>>>>>> */ >>>>>>> public static Set getReadOnlyAvailableZoneIds() { >>>>>>> return Collections.unmodifiableSet(ZONES.keySet()); >>>>>>> } >>>>>>> >>>>>>> Roger >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 5/5/2016 5:10 AM, Bhanu Gopularam wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please review fix following issue >>>>>>> >>>>>>> >>>>>>> >>>>>>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8066291 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Solution: provided new method to get size of available zone ids >>>>>>> >>>>>>> >>>>>>> >>>>>>> webrev : >>>>>>> http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.00 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Bhanu >>>>>>> >>>>>>> > From tadamski at redhat.com Fri May 6 19:59:42 2016 From: tadamski at redhat.com (Tomasz Adamski) Date: Fri, 6 May 2016 15:59:42 -0400 (EDT) Subject: RFR: 8152084: Introduction of ssliop protocol to corbaloc In-Reply-To: <572C7921.4040205@oracle.com> References: <321794846.38762864.1461088691787.JavaMail.zimbra@redhat.com> <5728A7AC.8000103@redhat.com> <5728AF76.9020406@oracle.com> <63067504.43350431.1462372580193.JavaMail.zimbra@redhat.com> <572A0CE2.8020101@redhat.com> <572A1754.8000507@oracle.com> <494597590.43598332.1462452692542.JavaMail.zimbra@redhat.com> <572C7921.4040205@oracle.com> Message-ID: <915665453.44565919.1462564782474.JavaMail.zimbra@redhat.com> Thanks for information. I'm looking at it. I'm also in contact with JacORB team regarding the compatibility issues. I should be able to present more elaborate opinion about 2.3.1 vs 3.3 compatibility (especially regarding Security Service) at the beginning of the next week. Regards, Tomek -- Tomasz Adamski Software Engineer JBoss by Red Hat ----- Original Message ----- > From: "Alan Bateman" > To: "Tomasz Adamski" > Cc: "Andrew Dinn" , core-libs-dev at openjdk.java.net > Sent: Friday, May 6, 2016 12:59:45 PM > Subject: Re: RFR: 8152084: Introduction of ssliop protocol to corbaloc > > > > On 05/05/2016 13:51, Tomasz Adamski wrote: > > Added classes are indeed generated from idl present in Security Server > > Specification which is part of Corba 3.3 specification. I can find no > > information about formal corba compliance process. Can you please point me > > to people who can help me regarding this? > > > I see that the CORBA specs have a section on Compliance but it's not > something that I can really comment on. In the Oracle docs then the > "Official Specifications for CORBA support" [1] has the references and > details on what is supported in the Oracle JDK, which should match what > is in OpenJDK. Note that it does says "J2SE 5.0", just a reflection that > this has not been rev'ed in 12+ years, hence the nervousness about > adding parts of CORBA 3.3. > > -Alan > > [1] > https://docs.oracle.com/javase/8/docs/technotes/guides/idl/compatibility-CORBA.html#spec > From andrey.dyachkov at gmail.com Sun May 8 18:47:05 2016 From: andrey.dyachkov at gmail.com (Andrey Dyachkov) Date: Sun, 08 May 2016 18:47:05 +0000 Subject: [PATCH] JDK-8155102: Process.toString could include pid, isAlive, exitStatus In-Reply-To: References: Message-ID: Hello, I have added toString() method in Process.java. diff --git a/src/java.base/share/classes/java/lang/Process.java b/src/java.base/share/classes/java/lang/Process.java --- a/src/java.base/share/classes/java/lang/Process.java +++ b/src/java.base/share/classes/java/lang/Process.java @@ -548,5 +548,16 @@ return toHandle().descendants(); } + @Override + public String toString() { + boolean isAlive = this.isAlive(); + return new StringBuilder(this.getClass().getSimpleName()).append("[") + .append("running=").append(isAlive).append(", ") + .append(isAlive ? "pid=" : "exitCode=") + .append(isAlive ? this.getPid() : this.exitValue()) + .append("]") + .toString(); + } + } -- With great enthusiasm, Andrey From jan.lahoda at oracle.com Sun May 8 21:07:35 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Sun, 8 May 2016 23:07:35 +0200 Subject: RFR 8147984: WindowsTerminal should support function keys In-Reply-To: References: <56A21578.5080105@oracle.com> <5726F9E0.4000801@oracle.com> <8e47a023-b313-d40e-7ed7-c91428f2d700@oracle.com> <5729F92C.4030201@oracle.com> Message-ID: <572FAA97.20903@oracle.com> Thanks - I've included both links and pushed. Jan On 4.5.2016 16:12, Florent Guillaume wrote: > On Wed, May 4, 2016 at 3:29 PM, Jan Lahoda wrote: >> On 3.5.2016 14:58, Florent Guillaume wrote: >>> http://www.x.org/docs/xterm/ctlseqs.pdf is probably a more canonical >>> reference. >> >> It seems that this version of the document unfortunately does not specify >> the codes the terminal sends for the function keys? > > Apologies, it's an old doc indeed. > http://xorg.freedesktop.org/releases/X11R6.8.1/PDF/ctlseqs.pdf seems > to contain it. > Note that later release of X11 (7.x) don't seem to have this doc > included, it seems that 6.8.1 is the last one with it. > > Florent > > >> Jan >>> >>> Florent >>> >>> On Mon, May 2, 2016 at 8:31 PM, Stuart Marks >>> wrote: >>>> >>>> Hi Jan, >>>> >>>> Thanks for the update. Including the link is fine, but I'm a bit >>>> suspicious >>>> of the durability of that website -- it appears to be the personal >>>> website >>>> of the current maintainer. Who knows if it'll be around in a couple >>>> years. >>>> >>>> I'd suggest including in the comment the official title of the document, >>>> "XTerm Control Sequences" along with a mention of the authors (Moy, >>>> Gildea, >>>> Dickey) so that if the link were to go bad, it would be possible to do a >>>> web >>>> search to find some version of the document. >>>> >>>> No need for an updated webrev. >>>> >>>> Thanks, >>>> >>>> s'marks >>>> >>>> >>>> On 5/1/16 11:55 PM, Jan Lahoda wrote: >>>>> >>>>> >>>>> Hi Stuart, >>>>> >>>>> Thanks for the comments and the link! >>>>> >>>>> A webrev which includes the link is here: >>>>> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.01/ >>>>> >>>>> Delta webrev to the last iteration is here: >>>>> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.01/delta/webrev >>>>> >>>>> Thanks, >>>>> Jan >>>>> >>>>> On 29.4.2016 23:49, Stuart Marks wrote: >>>>>> >>>>>> >>>>>> Hi Jan, >>>>>> >>>>>> I finally got a chance to take a look at this. The change looks fine. >>>>>> >>>>>> It would be nice to have a reference to where the escape sequences are >>>>>> documented. There are links to the Windows VK_ codes there, which is >>>>>> great. But there's no reference for the escape sequences that each >>>>>> keypress is mapped to, e.g. F4 is "ESC O S", and F5 is "ESC [ 1 5 ~" >>>>>> (and what happened to "ESC [ 1 6 ~"??) >>>>>> >>>>>> I did some searching, and it seems really hard to find a definitive >>>>>> reference. Perhaps the best reference is "XTerm Control Sequences" [1] >>>>>> which seems to document xterm pretty thoroughly, which is what >>>>>> everybody >>>>>> seems to follow nowadays. It even looks like it's being kept up to date >>>>>> (last modified 2016-02-21). >>>>>> >>>>>> Anyway I'd suggest adding a comment with a reference to this document. >>>>>> >>>>>> As a cross-check, these sequences match what my Mac's Terminal.app >>>>>> emits, at least for unshifted F1-F12. (The Terminal app was probably >>>>>> copied from xterm.) >>>>>> >>>>>> Thanks, >>>>>> >>>>>> s'marks >>>>>> >>>>>> >>>>>> [1] http://invisible-island.net/xterm/ctlseqs/ctlseqs.html >>>>>> >>>>>> >>>>>> On 1/22/16 3:41 AM, Jan Lahoda wrote: >>>>>>> >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I'd like to enhance the WindowsTerminal in jdk.internal.le with >>>>>>> function keys >>>>>>> handling. The intent is so that jshell can bind actions for shortcuts >>>>>>> including >>>>>>> function keys. >>>>>>> >>>>>>> The patch for adding the function keys support is here: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8147984/webrev.00/ >>>>>>> >>>>>>> An example of a feature that uses/may use this support is here: >>>>>>> >>>>>>> >>>>>>> http://mail.openjdk.java.net/pipermail/kulla-dev/2016-January/001226.html >>>>>>> >>>>>>> Any comments are welcome! >>>>>>> >>>>>>> Thanks, >>>>>>> Jan >>> >>> >>> >>> >> > > > From Sunny.Chan at gs.com Mon May 9 03:27:06 2016 From: Sunny.Chan at gs.com (Chan, Sunny) Date: Mon, 9 May 2016 03:27:06 +0000 Subject: Proposed patch: further wrapping of FileInputStream's native method Message-ID: <364f2cd3c8c3406abe014f056b4a1d35@gsdghkp03etn1.firmwide.corp.gs.com> Previously in JDK-8054720, a number of native methods has been wrapped in order to allow instrumentation. We would like to propose to wrap a number of other methods (available(), skip()) so that we can perform further instrumentation. I have attached the patch with this email for review. 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. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From amy.lu at oracle.com Mon May 9 05:14:34 2016 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 9 May 2016 13:14:34 +0800 Subject: RFR (JAXP) JDK-8156513: Problem list javax/xml/jaxp/unittest/stream/FactoryFindTest.java Message-ID: <57301CBA.3070404@oracle.com> javax/xml/jaxp/unittest/stream/FactoryFindTest.java This jaxp test creates and may left over file under testing jdk (jdk/lib/stax.properties) and other tests being affected. (JDK-8156508) This patch is to add this test to ProblemList.txt until mentioned issue resolved. bug: https://bugs.openjdk.java.net/browse/JDK-8156513 webrev: http://cr.openjdk.java.net/~amlu/8156513/webrev.00/ Thanks, Amy --- old/test/ProblemList.txt 2016-05-09 13:04:09.000000000 +0800 +++ new/test/ProblemList.txt 2016-05-09 13:04:09.000000000 +0800 @@ -29,3 +29,5 @@ # 8150145 javax/xml/jaxp/unittest/common/TransformationWarningsTest.java generic-all +# 8156508 +javax/xml/jaxp/unittest/stream/FactoryFindTest.java generic-all From amy.lu at oracle.com Mon May 9 09:25:59 2016 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 9 May 2016 17:25:59 +0800 Subject: JDK 9 RFR of JDK-8156512: Mark several tests from java/nio as intermittently failing Message-ID: <573057A7.4090502@oracle.com> java/nio/file/WatchService/DeleteInterference.java java/nio/channels/AsynchronousSocketChannel/Basic.java java/nio/file/FileSystem/Basic.java java/nio/channels/FileChannel/InterruptMapDeadlock.java Above nio tests are known to fail intermittently. This patch is to mark the test accordingly with keyword 'intermittent? until issue resolved. bug: https://bugs.openjdk.java.net/browse/JDK-8156512 webrev: http://cr.openjdk.java.net/~amlu/8156512/webrev.00/ Thanks, Amy --- old/test/java/nio/channels/AsynchronousSocketChannel/Basic.java 2016-05-09 17:15:14.000000000 +0800 +++ new/test/java/nio/channels/AsynchronousSocketChannel/Basic.java 2016-05-09 17:15:14.000000000 +0800 @@ -25,7 +25,7 @@ * @bug 4607272 6842687 6878369 6944810 7023403 * @summary Unit test for AsynchronousSocketChannel * @run main Basic -skipSlowConnectTest - * @key randomness + * @key randomness intermittent */ import java.nio.ByteBuffer; --- old/test/java/nio/channels/FileChannel/InterruptMapDeadlock.java 2016-05-09 17:15:15.000000000 +0800 +++ new/test/java/nio/channels/FileChannel/InterruptMapDeadlock.java 2016-05-09 17:15:14.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -23,6 +23,7 @@ /* @test * @bug 8024833 + * @key intermittent * @summary Tests interruption of threads mapping sections of a file channel in * an attempt to deadlock due to nesting of begin calls. */ --- old/test/java/nio/file/FileSystem/Basic.java 2016-05-09 17:15:15.000000000 +0800 +++ new/test/java/nio/file/FileSystem/Basic.java 2016-05-09 17:15:15.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2008, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -23,6 +23,7 @@ /* @test * @bug 4313887 6838333 8132497 + * @key intermittent * @summary Unit test for java.nio.file.FileSystem * @library .. /lib/testlibrary * @build jdk.testlibrary.FileUtils --- old/test/java/nio/file/WatchService/DeleteInterference.java 2016-05-09 17:15:16.000000000 +0800 +++ new/test/java/nio/file/WatchService/DeleteInterference.java 2016-05-09 17:15:16.000000000 +0800 @@ -20,6 +20,7 @@ /** * @test * @bug 8153925 + * @key intermittent * @summary Tests potential interference between a thread creating and closing * a WatchService with another thread that is deleting and re-creating the * directory at around the same time. This scenario tickled a timing bug From Alan.Bateman at oracle.com Mon May 9 09:31:02 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 9 May 2016 10:31:02 +0100 Subject: JDK 9 RFR of JDK-8156512: Mark several tests from java/nio as intermittently failing In-Reply-To: <573057A7.4090502@oracle.com> References: <573057A7.4090502@oracle.com> Message-ID: <573058D6.8060500@oracle.com> Amy, I think we should put DeleteInterference.java on the exclude list (linux-all) until the issue is tracked down. Also FileSystem/Basic.java seems to be an infrastructure/environment issue so `@key intermittent` doesn't seem right. The rest look okay. -Alan From amy.lu at oracle.com Mon May 9 10:00:47 2016 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 9 May 2016 18:00:47 +0800 Subject: JDK 9 RFR of JDK-8156512: Mark several tests from java/nio as intermittently failing In-Reply-To: <573058D6.8060500@oracle.com> References: <573057A7.4090502@oracle.com> <573058D6.8060500@oracle.com> Message-ID: <57305FCF.1010709@oracle.com> On 5/9/16 5:31 PM, Alan Bateman wrote: > Amy, > > I think we should put DeleteInterference.java on the exclude list > (linux-all) until the issue is tracked down. > > Also FileSystem/Basic.java seems to be an infrastructure/environment > issue so `@key intermittent` doesn't seem right. > > The rest look okay. > > -Alan Thank you Alan. I reverted the change of DeleteInterference.java and FileSystem/Basic.java. webrev updated for JDK-8156512: http://cr.openjdk.java.net/~amlu/8156512/webrev.01/ Created JDK-8156529 for problem list DeleteInterference.java, please also review the patch: --- old/test/ProblemList.txt 2016-05-09 17:57:19.000000000 +0800 +++ new/test/ProblemList.txt 2016-05-09 17:57:19.000000000 +0800 @@ -181,6 +181,8 @@ java/nio/charset/coders/BashStreams.java 8149712 generic-all +java/nio/file/WatchService/DeleteInterference.java 8156511 linux-all + ############################################################################ # jdk_rmi Thanks, Amy From Alan.Bateman at oracle.com Mon May 9 10:01:36 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 9 May 2016 11:01:36 +0100 Subject: JDK 9 RFR of JDK-8156512: Mark several tests from java/nio as intermittently failing In-Reply-To: <57305FCF.1010709@oracle.com> References: <573057A7.4090502@oracle.com> <573058D6.8060500@oracle.com> <57305FCF.1010709@oracle.com> Message-ID: <57306000.4060800@oracle.com> On 09/05/2016 11:00, Amy Lu wrote: > On 5/9/16 5:31 PM, Alan Bateman wrote: >> Amy, >> >> I think we should put DeleteInterference.java on the exclude list >> (linux-all) until the issue is tracked down. >> >> Also FileSystem/Basic.java seems to be an infrastructure/environment >> issue so `@key intermittent` doesn't seem right. >> >> The rest look okay. >> >> -Alan > Thank you Alan. > > Thanks Amy, looks fine. From bhanu.prakash.gopularam at oracle.com Mon May 9 10:58:37 2016 From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam) Date: Mon, 9 May 2016 03:58:37 -0700 (PDT) Subject: RFR 8066291: ZoneIdPrinterParser can be optimized In-Reply-To: References: <79c157ea-4b77-8e4a-444b-08a69ca4779b@Oracle.com> <3a769e0f-d551-0ea6-87ee-7bc1b0d0b39f@Oracle.com> Message-ID: Hi all, Here is the updated webrev: http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.02/ I have included newly suggested changes. On test side, I had to cleanup test java/time/zone/TCKZoneRulesProvider.java (test_getAvailableGroupIds) as ZoneRulesProvider.getAvailableZoneIds() returns a non-modifiable list, the tests for ZoneId.getAvailableZoneIds() is present in java/time/tck/java/time/TCKZoneId.java (). Thanks, Bhanu -----Original Message----- From: Stephen Colebourne [mailto:scolebourne at joda.org] Sent: Friday, May 06, 2016 3:54 PM To: core-libs-dev Subject: Re: RFR 8066291: ZoneIdPrinterParser can be optimized The set of zones can only increase, it cannot decrease as there is no removal mechanism. As such, the size of the set is a proxy for the number you describe. One other point. The method that most users will call to get the set of ZoneIds is ZoneId.getAvailableZoneIds(). That method delegates to the one on ZoneRulesProvider. As such, we can change the method on ZoneRulesProvider to return an immutable set while still keeping the method commonly used by users returning a mutable set. The incompatibility impact caused by this would be vanishingly small. To me, this is by far the best way to address this problem, as it avoids a new method. Thus, I propose: 1) Add a new field private static volatile Set ZONE_IDS; 2) Synchronize/lock registerProvider0() to ensure only one thread is in there at a time. 3) At the end of registerProvider0() add all of the existing and new IDs to a new HashSet wrapped in Collections.unmodifiableSet(combinedSet) and change ZONE_IDS to point at the new set. 4) Change ZoneRulesProvider.getAvailableZoneIds() to return ZONE_IDS. Change the spec to indicate the result is unmodifiable. 5) Change ZoneId.getAvailableZoneIds() to return new HashSet(ZoneRulesProvider.getAvailableZoneIds()) Code changes: ZoneId: public static Set getAvailableZoneIds() { return new HashSet(ZoneRulesProvider.getAvailableZoneIds()); } ZoneRulesProvider: private static volatile Set ZONE_IDS; @return the unmodifiable set of zone IDs, not null public static Set getAvailableZoneIds() { return ZONE_IDS; } private static synchronized void registerProvider0(ZoneRulesProvider provider) { for (String zoneId : provider.provideZoneIds()) { Objects.requireNonNull(zoneId, "zoneId"); ZoneRulesProvider old = ZONES.putIfAbsent(zoneId, provider); if (old != null) { throw new ZoneRulesException( "Unable to register zone as one already registered with that ID: " + zoneId + ", currently loading from provider: " + provider); } } Set combinedSet = new HashSet(ZONES.keySet()); ZONE_IDS = Collections.unmodifiableSet(combinedSet); } Stephen On 5 May 2016 at 19:48, Roger Riggs wrote: > Hi, > > Using the current number of ZoneIDs to avoid the recompilation of the > cache is a bit weak anyway, though it seems unlikely that a ZoneID > would be added and one deleted without being noticed. > > An alternative would be a API that returned a number that would change > every time the set of ZoneIds changed. > That would be more suitable both as a new API and as something to > trigger updates to the cache. > > I'd rather see a localized implementation with a simple model. > > Roger > > > On 5/5/2016 1:43 PM, Stephen Colebourne wrote: >> >> On reflection, both your and my solution have a race. >> >> the size method, is a clear check-then-act >> >> the read-only method uses Collections.unmodifiableSet() which only >> decorates the underlying set, thus is still check-thern-act >> >> (the current implementation does not have a race condition, as the >> data is copied, thus the size will match the data) >> >> There is no pleasant way to solve this that I can see. This is my >> best >> attempt: >> >> 1) Add a new field >> >> private static final CopyOnWriteArrayList ZONE_IDS; >> >> 2) At the end of registerProvider0() add all of the new IDs to the >> list (must be outside the loop as otherwise CopyOnWriteArrayList will >> be slow) >> >> 3) Add a new method getAvailableZoneIdList() that returns the list >> wrapped in Collections.unmodifiableList() >> >> 4) In the calling code, query the size, and then use subList(0, size) >> to lock the size from race conditions. >> >> >> A variation would be >> >> 1) Add a new field >> >> private static volatile Set ZONE_IDS; >> >> 2) Synchronize/lock registerProvider0() to ensure only one thread is >> in there at a time. >> >> 3) At the end of registerProvider0() add all of the new IDs to the >> set, storing Collections.unmodifiableSet(combinedSet) >> >> 4) Add a new method getAvailableZoneIdSet() that returns the >> unmodifiable set >> >> 5) Change the calling code to use the new method, but no other >> changes >> >> >> Stephen >> >> >> On 5 May 2016 at 16:53, Roger Riggs wrote: >>> >>> Hi Stephen, >>> >>> The aspect of the current implementation that is problematic is the >>> copying of the set, its not just single object creation but an entry >>> for every ZoneID. >>> >>> Adding a size method exposing some internal state increases the >>> possibility that when it is used independently it will be out of >>> sync. Not a big issue, but one to avoid when designing an API. >>> >>> Exposing a mutable Hashset was probably a mistake but one that >>> cannot be corrected now. The optics aren't concerning to me. >>> >>> SharedSecrets are much messier and not appropriate. >>> >>> Adding a method to provide what was originally needed is a cleaner >>> solution. >>> >>> Roger >>> >>> >>> >>> >>> On 5/5/2016 11:27 AM, Stephen Colebourne wrote: >>>> >>>> I fail to see why adding a new read-only method alongside the >>>> existing method adds any more value to the API than adding a new size method. >>>> At least with the size method the API is still sensible - a mutable >>>> and immutable method alongside each other shouts out that a mistake >>>> was made. A size method is more subtle about the mistake (plenty of >>>> APIs have a size method alongside a collection method). >>>> >>>> Finally, a read-only method involves object creation, thus has >>>> worse performance than adding a size method. >>>> >>>> The only other alternative is perhaps to use SharedSecrets? I don't >>>> know what possibilities there are there. If not SharedSecrets, then >>>> no matter what, we are adding "a trivial method to the public API >>>> used only for an optimization". >>>> >>>> Stephen >>>> >>>> >>>> On 5 May 2016 at 15:23, Roger Riggs wrote: >>>>> >>>>> Hi Bhanu, >>>>> >>>>> Adding a trivial method to the public API used only for an >>>>> optimization is not a good fix for this issue. >>>>> >>>>> A better fix was suggested to add a non-copying read-only version >>>>> of >>>>> >>>>> ZoneRulesProvider.getAvailableZoneIds() >>>>> >>>>> Please revise the fix to instead implement and use: >>>>> >>>>> /** >>>>> * Gets a readonly set of available zone IDs. >>>>> *

>>>>> * These IDs are the string form of a {@link ZoneId}. >>>>> * >>>>> * @return a unmodifiable copy of the set of zone IDs, not null >>>>> */ >>>>> public static Set getReadOnlyAvailableZoneIds() { >>>>> return Collections.unmodifiableSet(ZONES.keySet()); >>>>> } >>>>> >>>>> Roger >>>>> >>>>> >>>>> >>>>> On 5/5/2016 5:10 AM, Bhanu Gopularam wrote: >>>>> >>>>> Hi all, >>>>> >>>>> >>>>> >>>>> Please review fix following issue >>>>> >>>>> >>>>> >>>>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8066291 >>>>> >>>>> >>>>> >>>>> Solution: provided new method to get size of available zone ids >>>>> >>>>> >>>>> >>>>> webrev : >>>>> http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.00 >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Bhanu >>>>> >>>>> > From daniel.fuchs at oracle.com Mon May 9 11:05:23 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 9 May 2016 13:05:23 +0200 Subject: RFR (JAXP) 8152912: SAX XMLReaderFactory needs to be ServiceLoader compliant In-Reply-To: <572940DB.10003@oracle.com> References: <57279CDE.7070207@oracle.com> <6ed137e8-2651-7f6f-50b9-143b00286355@oracle.com> <572940DB.10003@oracle.com> Message-ID: <712af5bd-7ba4-266a-c32e-afd35d8434b4@oracle.com> Hi Joe, This looks much better to me. I just wonder about the @Deprecated("5") vs @Deprecated("1.5") We started dropping the 1. for Java 5 - so I guess @Deprecated("5") is OK. Hopefully Joe Darcy will be able to confirm :-) best regards, -- daniel On 04/05/16 02:22, huizhe wang wrote: > > On 5/3/2016 3:36 AM, Daniel Fuchs wrote: >> Hi Joe, >> >> This look good but the implementation might be overly complex, >> which makes it difficult to read. > > It was basically the existing code with some cleanup. What's in > jarLookup was a copy of the original code. As you can see I was eager to > add ServiceLoader support and forget about it (deprecated) :-) >> >> First: >> 141 ClassLoader cl = ss.getContextClassLoader(); >> is misnamed, because as far as I can see this method returns >> the context class loader if not null, otherwise the system >> class loader. > > Make sense. That method was changed. I now renamed it to getClassLoader > with javadoc. >> >> So cl is either the context class loader or the system class >> loader and is guaranteed to be non null. >> I would suggest adding a comment to make it clear. >> >> This means in turn that the new jarLookup(ClassLoader) >> method can be greatly simplified - you can do: >> final ClassLoader cl = Objects.requiresNonNull(loader); >> and then simplify the if (cl != null) else ... logic, >> because you now know that cl cannot be null. > > The cl-null checks in both jarLookup and findServiceProvider are removed. > > The new webrev also includes some cleanup of warnings, deprecation with > javadocs (since Java SE 5) but without the annotation. I limited the > patch to the sax package only. > > New webrev: > http://cr.openjdk.java.net/~joehw/jdk9/8152912/webrev01/ > > Best, > Joe > >> >> Best regards, >> >> -- daniel >> >> >> >> On 02/05/16 20:30, huizhe wang wrote: >>> Hi, >>> >>> Please review a change that adds a step using the ServiceLoader to >>> XMLReaderFactory's provider-lookup process. Meanwhile, XMLReaderFactory >>> is deprecated in favor of javax.xml.parsers.SAXParserFactory. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8152912 >>> Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8152912/webrev/ >>> >>> The change has been verified by SQE test that Frank will submit soon for >>> review (that is, when he starts to work at his local time). >>> >>> Thanks, >>> Joe >> >> > From scolebourne at joda.org Mon May 9 11:13:12 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 9 May 2016 12:13:12 +0100 Subject: RFR 8066291: ZoneIdPrinterParser can be optimized In-Reply-To: References: <79c157ea-4b77-8e4a-444b-08a69ca4779b@Oracle.com> <3a769e0f-d551-0ea6-87ee-7bc1b0d0b39f@Oracle.com> Message-ID: One point - the Javadoc for the method on ZoneRulesProvider @return a modifiable copy of the set of zone IDs, not null needs to change to @return the unmodifiable set of zone IDs, not null I'd welcome a second review on the volatile / thread-safety aspects, although I think it is pretty simple and safe. Stephen On 9 May 2016 at 11:58, Bhanu Gopularam wrote: > Hi all, > > Here is the updated webrev: > > http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.02/ > > I have included newly suggested changes. On test side, I had to cleanup test java/time/zone/TCKZoneRulesProvider.java (test_getAvailableGroupIds) as ZoneRulesProvider.getAvailableZoneIds() returns a non-modifiable list, the tests for ZoneId.getAvailableZoneIds() is present in java/time/tck/java/time/TCKZoneId.java (). > > Thanks, > Bhanu > > -----Original Message----- > From: Stephen Colebourne [mailto:scolebourne at joda.org] > Sent: Friday, May 06, 2016 3:54 PM > To: core-libs-dev > Subject: Re: RFR 8066291: ZoneIdPrinterParser can be optimized > > The set of zones can only increase, it cannot decrease as there is no removal mechanism. As such, the size of the set is a proxy for the number you describe. > > One other point. The method that most users will call to get the set of ZoneIds is ZoneId.getAvailableZoneIds(). That method delegates to the one on ZoneRulesProvider. As such, we can change the method on ZoneRulesProvider to return an immutable set while still keeping the method commonly used by users returning a mutable set. The incompatibility impact caused by this would be vanishingly small. To me, this is by far the best way to address this problem, as it avoids a new method. > > Thus, I propose: > > 1) Add a new field private static volatile Set ZONE_IDS; > > 2) Synchronize/lock registerProvider0() to ensure only one thread is in there at a time. > > 3) At the end of registerProvider0() add all of the existing and new IDs to a new HashSet wrapped in > Collections.unmodifiableSet(combinedSet) and change ZONE_IDS to point at the new set. > > 4) Change ZoneRulesProvider.getAvailableZoneIds() to return ZONE_IDS. > Change the spec to indicate the result is unmodifiable. > > 5) Change ZoneId.getAvailableZoneIds() to return new > HashSet(ZoneRulesProvider.getAvailableZoneIds()) > > Code changes: > > ZoneId: > > public static Set getAvailableZoneIds() { > return new HashSet(ZoneRulesProvider.getAvailableZoneIds()); > } > > > ZoneRulesProvider: > > private static volatile Set ZONE_IDS; > > @return the unmodifiable set of zone IDs, not null public static Set getAvailableZoneIds() { > return ZONE_IDS; > } > > private static synchronized void registerProvider0(ZoneRulesProvider provider) { > for (String zoneId : provider.provideZoneIds()) { > Objects.requireNonNull(zoneId, "zoneId"); > ZoneRulesProvider old = ZONES.putIfAbsent(zoneId, provider); > if (old != null) { > throw new ZoneRulesException( > "Unable to register zone as one already registered with that > ID: " + zoneId + > ", currently loading from provider: " + provider); > } > } > Set combinedSet = new HashSet(ZONES.keySet()); > ZONE_IDS = Collections.unmodifiableSet(combinedSet); > } > > Stephen > > > On 5 May 2016 at 19:48, Roger Riggs wrote: >> Hi, >> >> Using the current number of ZoneIDs to avoid the recompilation of the >> cache is a bit weak anyway, though it seems unlikely that a ZoneID >> would be added and one deleted without being noticed. >> >> An alternative would be a API that returned a number that would change >> every time the set of ZoneIds changed. >> That would be more suitable both as a new API and as something to >> trigger updates to the cache. >> >> I'd rather see a localized implementation with a simple model. >> >> Roger >> >> >> On 5/5/2016 1:43 PM, Stephen Colebourne wrote: >>> >>> On reflection, both your and my solution have a race. >>> >>> the size method, is a clear check-then-act >>> >>> the read-only method uses Collections.unmodifiableSet() which only >>> decorates the underlying set, thus is still check-thern-act >>> >>> (the current implementation does not have a race condition, as the >>> data is copied, thus the size will match the data) >>> >>> There is no pleasant way to solve this that I can see. This is my >>> best >>> attempt: >>> >>> 1) Add a new field >>> >>> private static final CopyOnWriteArrayList ZONE_IDS; >>> >>> 2) At the end of registerProvider0() add all of the new IDs to the >>> list (must be outside the loop as otherwise CopyOnWriteArrayList will >>> be slow) >>> >>> 3) Add a new method getAvailableZoneIdList() that returns the list >>> wrapped in Collections.unmodifiableList() >>> >>> 4) In the calling code, query the size, and then use subList(0, size) >>> to lock the size from race conditions. >>> >>> >>> A variation would be >>> >>> 1) Add a new field >>> >>> private static volatile Set ZONE_IDS; >>> >>> 2) Synchronize/lock registerProvider0() to ensure only one thread is >>> in there at a time. >>> >>> 3) At the end of registerProvider0() add all of the new IDs to the >>> set, storing Collections.unmodifiableSet(combinedSet) >>> >>> 4) Add a new method getAvailableZoneIdSet() that returns the >>> unmodifiable set >>> >>> 5) Change the calling code to use the new method, but no other >>> changes >>> >>> >>> Stephen >>> >>> >>> On 5 May 2016 at 16:53, Roger Riggs wrote: >>>> >>>> Hi Stephen, >>>> >>>> The aspect of the current implementation that is problematic is the >>>> copying of the set, its not just single object creation but an entry >>>> for every ZoneID. >>>> >>>> Adding a size method exposing some internal state increases the >>>> possibility that when it is used independently it will be out of >>>> sync. Not a big issue, but one to avoid when designing an API. >>>> >>>> Exposing a mutable Hashset was probably a mistake but one that >>>> cannot be corrected now. The optics aren't concerning to me. >>>> >>>> SharedSecrets are much messier and not appropriate. >>>> >>>> Adding a method to provide what was originally needed is a cleaner >>>> solution. >>>> >>>> Roger >>>> >>>> >>>> >>>> >>>> On 5/5/2016 11:27 AM, Stephen Colebourne wrote: >>>>> >>>>> I fail to see why adding a new read-only method alongside the >>>>> existing method adds any more value to the API than adding a new size method. >>>>> At least with the size method the API is still sensible - a mutable >>>>> and immutable method alongside each other shouts out that a mistake >>>>> was made. A size method is more subtle about the mistake (plenty of >>>>> APIs have a size method alongside a collection method). >>>>> >>>>> Finally, a read-only method involves object creation, thus has >>>>> worse performance than adding a size method. >>>>> >>>>> The only other alternative is perhaps to use SharedSecrets? I don't >>>>> know what possibilities there are there. If not SharedSecrets, then >>>>> no matter what, we are adding "a trivial method to the public API >>>>> used only for an optimization". >>>>> >>>>> Stephen >>>>> >>>>> >>>>> On 5 May 2016 at 15:23, Roger Riggs wrote: >>>>>> >>>>>> Hi Bhanu, >>>>>> >>>>>> Adding a trivial method to the public API used only for an >>>>>> optimization is not a good fix for this issue. >>>>>> >>>>>> A better fix was suggested to add a non-copying read-only version >>>>>> of >>>>>> >>>>>> ZoneRulesProvider.getAvailableZoneIds() >>>>>> >>>>>> Please revise the fix to instead implement and use: >>>>>> >>>>>> /** >>>>>> * Gets a readonly set of available zone IDs. >>>>>> *

>>>>>> * These IDs are the string form of a {@link ZoneId}. >>>>>> * >>>>>> * @return a unmodifiable copy of the set of zone IDs, not null >>>>>> */ >>>>>> public static Set getReadOnlyAvailableZoneIds() { >>>>>> return Collections.unmodifiableSet(ZONES.keySet()); >>>>>> } >>>>>> >>>>>> Roger >>>>>> >>>>>> >>>>>> >>>>>> On 5/5/2016 5:10 AM, Bhanu Gopularam wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> >>>>>> >>>>>> Please review fix following issue >>>>>> >>>>>> >>>>>> >>>>>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8066291 >>>>>> >>>>>> >>>>>> >>>>>> Solution: provided new method to get size of available zone ids >>>>>> >>>>>> >>>>>> >>>>>> webrev : >>>>>> http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.00 >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Bhanu >>>>>> >>>>>> >> From bhanu.prakash.gopularam at oracle.com Mon May 9 11:42:57 2016 From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam) Date: Mon, 9 May 2016 04:42:57 -0700 (PDT) Subject: RFR 8066291: ZoneIdPrinterParser can be optimized In-Reply-To: References: <79c157ea-4b77-8e4a-444b-08a69ca4779b@Oracle.com> <3a769e0f-d551-0ea6-87ee-7bc1b0d0b39f@Oracle.com> Message-ID: <7757463a-9fe4-4880-a7dc-5c920461e796@default> Here is the updated webrev: http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.03/ Please review the changes. Thanks, Bhanu -----Original Message----- From: Stephen Colebourne [mailto:scolebourne at joda.org] Sent: Monday, May 09, 2016 4:43 PM To: core-libs-dev Subject: Re: RFR 8066291: ZoneIdPrinterParser can be optimized One point - the Javadoc for the method on ZoneRulesProvider @return a modifiable copy of the set of zone IDs, not null needs to change to @return the unmodifiable set of zone IDs, not null I'd welcome a second review on the volatile / thread-safety aspects, although I think it is pretty simple and safe. Stephen On 9 May 2016 at 11:58, Bhanu Gopularam wrote: > Hi all, > > Here is the updated webrev: > > http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.02/ > > I have included newly suggested changes. On test side, I had to cleanup test java/time/zone/TCKZoneRulesProvider.java (test_getAvailableGroupIds) as ZoneRulesProvider.getAvailableZoneIds() returns a non-modifiable list, the tests for ZoneId.getAvailableZoneIds() is present in java/time/tck/java/time/TCKZoneId.java (). > > Thanks, > Bhanu > > -----Original Message----- > From: Stephen Colebourne [mailto:scolebourne at joda.org] > Sent: Friday, May 06, 2016 3:54 PM > To: core-libs-dev > Subject: Re: RFR 8066291: ZoneIdPrinterParser can be optimized > > The set of zones can only increase, it cannot decrease as there is no removal mechanism. As such, the size of the set is a proxy for the number you describe. > > One other point. The method that most users will call to get the set of ZoneIds is ZoneId.getAvailableZoneIds(). That method delegates to the one on ZoneRulesProvider. As such, we can change the method on ZoneRulesProvider to return an immutable set while still keeping the method commonly used by users returning a mutable set. The incompatibility impact caused by this would be vanishingly small. To me, this is by far the best way to address this problem, as it avoids a new method. > > Thus, I propose: > > 1) Add a new field private static volatile Set ZONE_IDS; > > 2) Synchronize/lock registerProvider0() to ensure only one thread is in there at a time. > > 3) At the end of registerProvider0() add all of the existing and new > IDs to a new HashSet wrapped in > Collections.unmodifiableSet(combinedSet) and change ZONE_IDS to point at the new set. > > 4) Change ZoneRulesProvider.getAvailableZoneIds() to return ZONE_IDS. > Change the spec to indicate the result is unmodifiable. > > 5) Change ZoneId.getAvailableZoneIds() to return new > HashSet(ZoneRulesProvider.getAvailableZoneIds()) > > Code changes: > > ZoneId: > > public static Set getAvailableZoneIds() { > return new HashSet(ZoneRulesProvider.getAvailableZoneIds()); > } > > > ZoneRulesProvider: > > private static volatile Set ZONE_IDS; > > @return the unmodifiable set of zone IDs, not null public static Set getAvailableZoneIds() { > return ZONE_IDS; > } > > private static synchronized void registerProvider0(ZoneRulesProvider provider) { > for (String zoneId : provider.provideZoneIds()) { > Objects.requireNonNull(zoneId, "zoneId"); > ZoneRulesProvider old = ZONES.putIfAbsent(zoneId, provider); > if (old != null) { > throw new ZoneRulesException( > "Unable to register zone as one already registered with that > ID: " + zoneId + > ", currently loading from provider: " + provider); > } > } > Set combinedSet = new HashSet(ZONES.keySet()); > ZONE_IDS = Collections.unmodifiableSet(combinedSet); > } > > Stephen > > > On 5 May 2016 at 19:48, Roger Riggs wrote: >> Hi, >> >> Using the current number of ZoneIDs to avoid the recompilation of the >> cache is a bit weak anyway, though it seems unlikely that a ZoneID >> would be added and one deleted without being noticed. >> >> An alternative would be a API that returned a number that would >> change every time the set of ZoneIds changed. >> That would be more suitable both as a new API and as something to >> trigger updates to the cache. >> >> I'd rather see a localized implementation with a simple model. >> >> Roger >> >> >> On 5/5/2016 1:43 PM, Stephen Colebourne wrote: >>> >>> On reflection, both your and my solution have a race. >>> >>> the size method, is a clear check-then-act >>> >>> the read-only method uses Collections.unmodifiableSet() which only >>> decorates the underlying set, thus is still check-thern-act >>> >>> (the current implementation does not have a race condition, as the >>> data is copied, thus the size will match the data) >>> >>> There is no pleasant way to solve this that I can see. This is my >>> best >>> attempt: >>> >>> 1) Add a new field >>> >>> private static final CopyOnWriteArrayList ZONE_IDS; >>> >>> 2) At the end of registerProvider0() add all of the new IDs to the >>> list (must be outside the loop as otherwise CopyOnWriteArrayList >>> will be slow) >>> >>> 3) Add a new method getAvailableZoneIdList() that returns the list >>> wrapped in Collections.unmodifiableList() >>> >>> 4) In the calling code, query the size, and then use subList(0, >>> size) to lock the size from race conditions. >>> >>> >>> A variation would be >>> >>> 1) Add a new field >>> >>> private static volatile Set ZONE_IDS; >>> >>> 2) Synchronize/lock registerProvider0() to ensure only one thread is >>> in there at a time. >>> >>> 3) At the end of registerProvider0() add all of the new IDs to the >>> set, storing Collections.unmodifiableSet(combinedSet) >>> >>> 4) Add a new method getAvailableZoneIdSet() that returns the >>> unmodifiable set >>> >>> 5) Change the calling code to use the new method, but no other >>> changes >>> >>> >>> Stephen >>> >>> >>> On 5 May 2016 at 16:53, Roger Riggs wrote: >>>> >>>> Hi Stephen, >>>> >>>> The aspect of the current implementation that is problematic is the >>>> copying of the set, its not just single object creation but an >>>> entry for every ZoneID. >>>> >>>> Adding a size method exposing some internal state increases the >>>> possibility that when it is used independently it will be out of >>>> sync. Not a big issue, but one to avoid when designing an API. >>>> >>>> Exposing a mutable Hashset was probably a mistake but one that >>>> cannot be corrected now. The optics aren't concerning to me. >>>> >>>> SharedSecrets are much messier and not appropriate. >>>> >>>> Adding a method to provide what was originally needed is a cleaner >>>> solution. >>>> >>>> Roger >>>> >>>> >>>> >>>> >>>> On 5/5/2016 11:27 AM, Stephen Colebourne wrote: >>>>> >>>>> I fail to see why adding a new read-only method alongside the >>>>> existing method adds any more value to the API than adding a new size method. >>>>> At least with the size method the API is still sensible - a >>>>> mutable and immutable method alongside each other shouts out that >>>>> a mistake was made. A size method is more subtle about the mistake >>>>> (plenty of APIs have a size method alongside a collection method). >>>>> >>>>> Finally, a read-only method involves object creation, thus has >>>>> worse performance than adding a size method. >>>>> >>>>> The only other alternative is perhaps to use SharedSecrets? I >>>>> don't know what possibilities there are there. If not >>>>> SharedSecrets, then no matter what, we are adding "a trivial >>>>> method to the public API used only for an optimization". >>>>> >>>>> Stephen >>>>> >>>>> >>>>> On 5 May 2016 at 15:23, Roger Riggs wrote: >>>>>> >>>>>> Hi Bhanu, >>>>>> >>>>>> Adding a trivial method to the public API used only for an >>>>>> optimization is not a good fix for this issue. >>>>>> >>>>>> A better fix was suggested to add a non-copying read-only version >>>>>> of >>>>>> >>>>>> ZoneRulesProvider.getAvailableZoneIds() >>>>>> >>>>>> Please revise the fix to instead implement and use: >>>>>> >>>>>> /** >>>>>> * Gets a readonly set of available zone IDs. >>>>>> *

>>>>>> * These IDs are the string form of a {@link ZoneId}. >>>>>> * >>>>>> * @return a unmodifiable copy of the set of zone IDs, not null >>>>>> */ >>>>>> public static Set getReadOnlyAvailableZoneIds() { >>>>>> return Collections.unmodifiableSet(ZONES.keySet()); >>>>>> } >>>>>> >>>>>> Roger >>>>>> >>>>>> >>>>>> >>>>>> On 5/5/2016 5:10 AM, Bhanu Gopularam wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> >>>>>> >>>>>> Please review fix following issue >>>>>> >>>>>> >>>>>> >>>>>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8066291 >>>>>> >>>>>> >>>>>> >>>>>> Solution: provided new method to get size of available zone ids >>>>>> >>>>>> >>>>>> >>>>>> webrev : >>>>>> http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.0 >>>>>> 0 >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Bhanu >>>>>> >>>>>> >> From scolebourne at joda.org Mon May 9 11:47:01 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 9 May 2016 12:47:01 +0100 Subject: RFR 8066291: ZoneIdPrinterParser can be optimized In-Reply-To: <7757463a-9fe4-4880-a7dc-5c920461e796@default> References: <79c157ea-4b77-8e4a-444b-08a69ca4779b@Oracle.com> <3a769e0f-d551-0ea6-87ee-7bc1b0d0b39f@Oracle.com> <7757463a-9fe4-4880-a7dc-5c920461e796@default> Message-ID: Fine by me, just awaiting an additional reviewer. Stephen On 9 May 2016 at 12:42, Bhanu Gopularam wrote: > Here is the updated webrev: > > http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.03/ > > Please review the changes. > > Thanks, > Bhanu > > -----Original Message----- > From: Stephen Colebourne [mailto:scolebourne at joda.org] > Sent: Monday, May 09, 2016 4:43 PM > To: core-libs-dev > Subject: Re: RFR 8066291: ZoneIdPrinterParser can be optimized > > One point - the Javadoc for the method on ZoneRulesProvider > > @return a modifiable copy of the set of zone IDs, not null > > needs to change to > > @return the unmodifiable set of zone IDs, not null > > I'd welcome a second review on the volatile / thread-safety aspects, although I think it is pretty simple and safe. > > Stephen > > > On 9 May 2016 at 11:58, Bhanu Gopularam > wrote: >> Hi all, >> >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.02/ >> >> I have included newly suggested changes. On test side, I had to cleanup test java/time/zone/TCKZoneRulesProvider.java (test_getAvailableGroupIds) as ZoneRulesProvider.getAvailableZoneIds() returns a non-modifiable list, the tests for ZoneId.getAvailableZoneIds() is present in java/time/tck/java/time/TCKZoneId.java (). >> >> Thanks, >> Bhanu >> >> -----Original Message----- >> From: Stephen Colebourne [mailto:scolebourne at joda.org] >> Sent: Friday, May 06, 2016 3:54 PM >> To: core-libs-dev >> Subject: Re: RFR 8066291: ZoneIdPrinterParser can be optimized >> >> The set of zones can only increase, it cannot decrease as there is no removal mechanism. As such, the size of the set is a proxy for the number you describe. >> >> One other point. The method that most users will call to get the set of ZoneIds is ZoneId.getAvailableZoneIds(). That method delegates to the one on ZoneRulesProvider. As such, we can change the method on ZoneRulesProvider to return an immutable set while still keeping the method commonly used by users returning a mutable set. The incompatibility impact caused by this would be vanishingly small. To me, this is by far the best way to address this problem, as it avoids a new method. >> >> Thus, I propose: >> >> 1) Add a new field private static volatile Set ZONE_IDS; >> >> 2) Synchronize/lock registerProvider0() to ensure only one thread is in there at a time. >> >> 3) At the end of registerProvider0() add all of the existing and new >> IDs to a new HashSet wrapped in >> Collections.unmodifiableSet(combinedSet) and change ZONE_IDS to point at the new set. >> >> 4) Change ZoneRulesProvider.getAvailableZoneIds() to return ZONE_IDS. >> Change the spec to indicate the result is unmodifiable. >> >> 5) Change ZoneId.getAvailableZoneIds() to return new >> HashSet(ZoneRulesProvider.getAvailableZoneIds()) >> >> Code changes: >> >> ZoneId: >> >> public static Set getAvailableZoneIds() { >> return new HashSet(ZoneRulesProvider.getAvailableZoneIds()); >> } >> >> >> ZoneRulesProvider: >> >> private static volatile Set ZONE_IDS; >> >> @return the unmodifiable set of zone IDs, not null public static Set getAvailableZoneIds() { >> return ZONE_IDS; >> } >> >> private static synchronized void registerProvider0(ZoneRulesProvider provider) { >> for (String zoneId : provider.provideZoneIds()) { >> Objects.requireNonNull(zoneId, "zoneId"); >> ZoneRulesProvider old = ZONES.putIfAbsent(zoneId, provider); >> if (old != null) { >> throw new ZoneRulesException( >> "Unable to register zone as one already registered with that >> ID: " + zoneId + >> ", currently loading from provider: " + provider); >> } >> } >> Set combinedSet = new HashSet(ZONES.keySet()); >> ZONE_IDS = Collections.unmodifiableSet(combinedSet); >> } >> >> Stephen >> >> >> On 5 May 2016 at 19:48, Roger Riggs wrote: >>> Hi, >>> >>> Using the current number of ZoneIDs to avoid the recompilation of the >>> cache is a bit weak anyway, though it seems unlikely that a ZoneID >>> would be added and one deleted without being noticed. >>> >>> An alternative would be a API that returned a number that would >>> change every time the set of ZoneIds changed. >>> That would be more suitable both as a new API and as something to >>> trigger updates to the cache. >>> >>> I'd rather see a localized implementation with a simple model. >>> >>> Roger >>> >>> >>> On 5/5/2016 1:43 PM, Stephen Colebourne wrote: >>>> >>>> On reflection, both your and my solution have a race. >>>> >>>> the size method, is a clear check-then-act >>>> >>>> the read-only method uses Collections.unmodifiableSet() which only >>>> decorates the underlying set, thus is still check-thern-act >>>> >>>> (the current implementation does not have a race condition, as the >>>> data is copied, thus the size will match the data) >>>> >>>> There is no pleasant way to solve this that I can see. This is my >>>> best >>>> attempt: >>>> >>>> 1) Add a new field >>>> >>>> private static final CopyOnWriteArrayList ZONE_IDS; >>>> >>>> 2) At the end of registerProvider0() add all of the new IDs to the >>>> list (must be outside the loop as otherwise CopyOnWriteArrayList >>>> will be slow) >>>> >>>> 3) Add a new method getAvailableZoneIdList() that returns the list >>>> wrapped in Collections.unmodifiableList() >>>> >>>> 4) In the calling code, query the size, and then use subList(0, >>>> size) to lock the size from race conditions. >>>> >>>> >>>> A variation would be >>>> >>>> 1) Add a new field >>>> >>>> private static volatile Set ZONE_IDS; >>>> >>>> 2) Synchronize/lock registerProvider0() to ensure only one thread is >>>> in there at a time. >>>> >>>> 3) At the end of registerProvider0() add all of the new IDs to the >>>> set, storing Collections.unmodifiableSet(combinedSet) >>>> >>>> 4) Add a new method getAvailableZoneIdSet() that returns the >>>> unmodifiable set >>>> >>>> 5) Change the calling code to use the new method, but no other >>>> changes >>>> >>>> >>>> Stephen >>>> >>>> >>>> On 5 May 2016 at 16:53, Roger Riggs wrote: >>>>> >>>>> Hi Stephen, >>>>> >>>>> The aspect of the current implementation that is problematic is the >>>>> copying of the set, its not just single object creation but an >>>>> entry for every ZoneID. >>>>> >>>>> Adding a size method exposing some internal state increases the >>>>> possibility that when it is used independently it will be out of >>>>> sync. Not a big issue, but one to avoid when designing an API. >>>>> >>>>> Exposing a mutable Hashset was probably a mistake but one that >>>>> cannot be corrected now. The optics aren't concerning to me. >>>>> >>>>> SharedSecrets are much messier and not appropriate. >>>>> >>>>> Adding a method to provide what was originally needed is a cleaner >>>>> solution. >>>>> >>>>> Roger >>>>> >>>>> >>>>> >>>>> >>>>> On 5/5/2016 11:27 AM, Stephen Colebourne wrote: >>>>>> >>>>>> I fail to see why adding a new read-only method alongside the >>>>>> existing method adds any more value to the API than adding a new size method. >>>>>> At least with the size method the API is still sensible - a >>>>>> mutable and immutable method alongside each other shouts out that >>>>>> a mistake was made. A size method is more subtle about the mistake >>>>>> (plenty of APIs have a size method alongside a collection method). >>>>>> >>>>>> Finally, a read-only method involves object creation, thus has >>>>>> worse performance than adding a size method. >>>>>> >>>>>> The only other alternative is perhaps to use SharedSecrets? I >>>>>> don't know what possibilities there are there. If not >>>>>> SharedSecrets, then no matter what, we are adding "a trivial >>>>>> method to the public API used only for an optimization". >>>>>> >>>>>> Stephen >>>>>> >>>>>> >>>>>> On 5 May 2016 at 15:23, Roger Riggs wrote: >>>>>>> >>>>>>> Hi Bhanu, >>>>>>> >>>>>>> Adding a trivial method to the public API used only for an >>>>>>> optimization is not a good fix for this issue. >>>>>>> >>>>>>> A better fix was suggested to add a non-copying read-only version >>>>>>> of >>>>>>> >>>>>>> ZoneRulesProvider.getAvailableZoneIds() >>>>>>> >>>>>>> Please revise the fix to instead implement and use: >>>>>>> >>>>>>> /** >>>>>>> * Gets a readonly set of available zone IDs. >>>>>>> *

>>>>>>> * These IDs are the string form of a {@link ZoneId}. >>>>>>> * >>>>>>> * @return a unmodifiable copy of the set of zone IDs, not null >>>>>>> */ >>>>>>> public static Set getReadOnlyAvailableZoneIds() { >>>>>>> return Collections.unmodifiableSet(ZONES.keySet()); >>>>>>> } >>>>>>> >>>>>>> Roger >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 5/5/2016 5:10 AM, Bhanu Gopularam wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please review fix following issue >>>>>>> >>>>>>> >>>>>>> >>>>>>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8066291 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Solution: provided new method to get size of available zone ids >>>>>>> >>>>>>> >>>>>>> >>>>>>> webrev : >>>>>>> http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.0 >>>>>>> 0 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Bhanu >>>>>>> >>>>>>> >>> From chris.hegarty at oracle.com Mon May 9 13:05:15 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 9 May 2016 14:05:15 +0100 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: <82FE24B5-351E-4962-9014-5AFB66FA9412@oracle.com> References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> <5729C9D1.5040506@oracle.com> <5729F9DE.4080909@oracle.com> <907375E5-2BB6-42FF-9259-3CE8A2D06665@oracle.com> <82FE24B5-351E-4962-9014-5AFB66FA9412@oracle.com> Message-ID: <57308B0B.9040202@oracle.com> On 05/05/16 19:42, Alexandre (Shura) Iline wrote: > Chris, could you please take another look: > http://cr.openjdk.java.net/~shurailine/8151914/webrev.02/ This looks ok to me Shura, maybe just 'mrjar' for the directory name? Since there are file moves can you please prepare the changeset, and I will push it for you. -Chris. > What I have discovered is that jdk.zipfs was used to access jars on the classpath, which were JTreg jars: jtreg.jar, testing.jar, etc. Cleaning the class path through the environment removed dependency on the zipfs. > > Whether the java.tools API behavior is correct is a separate matter. I am planning to create a standalone test case and take it with javac ppl. > > Thank you. > > Shura > >> On May 4, 2016, at 8:30 AM, Chris Hegarty wrote: >> >> On 4 May 2016, at 14:32, Alan Bateman wrote: >>> >>> On 04/05/2016 11:24, Chris Hegarty wrote: >>>> : >>>> The tests cause compilation of test library classes, but only some tests >>>> actually use the methods that provoke compilation. Similar to above, tests >>>> that don?t actually compile anything could depend on just java.compiler. >>>> >>>> This is all to fragile and may cause problems with future refactoring. I >>>> think we should add the same set of @moduels to all these tests, rather >>>> than an individual set determined by intimate knowledge of the inner >>>> workings of the test. >>>> >>>> @modules java.compiler >>>> jdk.compiler >>>> jdk.zipfs >>>> jdk.jartool >>>> >>>> with the addition of jdk.httpserver for MultiReleaseJarHttpProperties. >>>> >>> or we could move the tests into their own MultiRelease sub-directory and create a TEST.properties with a module key. That would allow these tests to drop @modules, except the test that uses the HTTP server. >> >> I think that would be better. >> >> -Chris. > From chris.hegarty at oracle.com Mon May 9 13:26:21 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 9 May 2016 14:26:21 +0100 Subject: Proposed patch: further wrapping of FileInputStream's native method In-Reply-To: <364f2cd3c8c3406abe014f056b4a1d35@gsdghkp03etn1.firmwide.corp.gs.com> References: <364f2cd3c8c3406abe014f056b4a1d35@gsdghkp03etn1.firmwide.corp.gs.com> Message-ID: <57308FFD.3000700@oracle.com> The changes in your patch look ok. It is not clear, at least to me, why these methods are all that interesting, or even why they were not covered by 8054720. Maybe Brian Burkhalter, or others may know. -Chris. On 09/05/16 04:27, Chan, Sunny wrote: > Previously in JDK-8054720, a number of native methods has been wrapped in order to allow instrumentation. We would like to propose to wrap a number of other methods (available(), skip()) so that we can perform further instrumentation. > > I have attached the patch with this email for review. > > 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 Alan.Bateman at oracle.com Mon May 9 13:38:26 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 9 May 2016 14:38:26 +0100 Subject: Proposed patch: further wrapping of FileInputStream's native method In-Reply-To: <57308FFD.3000700@oracle.com> References: <364f2cd3c8c3406abe014f056b4a1d35@gsdghkp03etn1.firmwide.corp.gs.com> <57308FFD.3000700@oracle.com> Message-ID: <573092D2.3020701@oracle.com> On 09/05/2016 14:26, Chris Hegarty wrote: > The changes in your patch look ok. > > It is not clear, at least to me, why these methods are all that > interesting, or even why they were not covered by 8054720. Maybe > Brian Burkhalter, or others may know. > The changes look okay to me but just to mention that both JVM TI and java.lang.instrument have supported a means for agents to instrument native methods since Java SE 6. I can't tell which tool is being used here but it may be that it is doing dynamic (as opposed to load time) instrumentation or maybe it's a java agent and so can't do load time instrumentation or classes loaded early in the VM startup. -Alan. From Roger.Riggs at Oracle.com Mon May 9 14:14:20 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 9 May 2016 10:14:20 -0400 Subject: RFR 8066291: ZoneIdPrinterParser can be optimized In-Reply-To: References: <79c157ea-4b77-8e4a-444b-08a69ca4779b@Oracle.com> <3a769e0f-d551-0ea6-87ee-7bc1b0d0b39f@Oracle.com> Message-ID: <7139ab2e-b3f2-9b53-79c7-fd23d8005de5@Oracle.com> Hi, The behavioral change to getAvailableZoneIds will get the greatest attention by the folks concerned with compatibility. Be prepared to make the case that the change will not affect existing applications. Having to modify an existing compatibility test is a warning that it is likely to be an issue. Especially when compared to the alternative to introduce a new method with the desired behavior. Roger On 5/9/2016 6:58 AM, Bhanu Gopularam wrote: > Hi all, > > Here is the updated webrev: > > http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.02/ > > I have included newly suggested changes. On test side, I had to cleanup test java/time/zone/TCKZoneRulesProvider.java (test_getAvailableGroupIds) as ZoneRulesProvider.getAvailableZoneIds() returns a non-modifiable list, the tests for ZoneId.getAvailableZoneIds() is present in java/time/tck/java/time/TCKZoneId.java (). > > Thanks, > Bhanu > > -----Original Message----- > From: Stephen Colebourne [mailto:scolebourne at joda.org] > Sent: Friday, May 06, 2016 3:54 PM > To: core-libs-dev > Subject: Re: RFR 8066291: ZoneIdPrinterParser can be optimized > > The set of zones can only increase, it cannot decrease as there is no removal mechanism. As such, the size of the set is a proxy for the number you describe. > > One other point. The method that most users will call to get the set of ZoneIds is ZoneId.getAvailableZoneIds(). That method delegates to the one on ZoneRulesProvider. As such, we can change the method on ZoneRulesProvider to return an immutable set while still keeping the method commonly used by users returning a mutable set. The incompatibility impact caused by this would be vanishingly small. To me, this is by far the best way to address this problem, as it avoids a new method. > > Thus, I propose: > > 1) Add a new field private static volatile Set ZONE_IDS; > > 2) Synchronize/lock registerProvider0() to ensure only one thread is in there at a time. > > 3) At the end of registerProvider0() add all of the existing and new IDs to a new HashSet wrapped in > Collections.unmodifiableSet(combinedSet) and change ZONE_IDS to point at the new set. > > 4) Change ZoneRulesProvider.getAvailableZoneIds() to return ZONE_IDS. > Change the spec to indicate the result is unmodifiable. > > 5) Change ZoneId.getAvailableZoneIds() to return new > HashSet(ZoneRulesProvider.getAvailableZoneIds()) > > Code changes: > > ZoneId: > > public static Set getAvailableZoneIds() { > return new HashSet(ZoneRulesProvider.getAvailableZoneIds()); > } > > > ZoneRulesProvider: > > private static volatile Set ZONE_IDS; > > @return the unmodifiable set of zone IDs, not null public static Set getAvailableZoneIds() { > return ZONE_IDS; > } > > private static synchronized void registerProvider0(ZoneRulesProvider provider) { > for (String zoneId : provider.provideZoneIds()) { > Objects.requireNonNull(zoneId, "zoneId"); > ZoneRulesProvider old = ZONES.putIfAbsent(zoneId, provider); > if (old != null) { > throw new ZoneRulesException( > "Unable to register zone as one already registered with that > ID: " + zoneId + > ", currently loading from provider: " + provider); > } > } > Set combinedSet = new HashSet(ZONES.keySet()); > ZONE_IDS = Collections.unmodifiableSet(combinedSet); > } > > Stephen > > > On 5 May 2016 at 19:48, Roger Riggs wrote: >> Hi, >> >> Using the current number of ZoneIDs to avoid the recompilation of the >> cache is a bit weak anyway, though it seems unlikely that a ZoneID >> would be added and one deleted without being noticed. >> >> An alternative would be a API that returned a number that would change >> every time the set of ZoneIds changed. >> That would be more suitable both as a new API and as something to >> trigger updates to the cache. >> >> I'd rather see a localized implementation with a simple model. >> >> Roger >> >> >> On 5/5/2016 1:43 PM, Stephen Colebourne wrote: >>> On reflection, both your and my solution have a race. >>> >>> the size method, is a clear check-then-act >>> >>> the read-only method uses Collections.unmodifiableSet() which only >>> decorates the underlying set, thus is still check-thern-act >>> >>> (the current implementation does not have a race condition, as the >>> data is copied, thus the size will match the data) >>> >>> There is no pleasant way to solve this that I can see. This is my >>> best >>> attempt: >>> >>> 1) Add a new field >>> >>> private static final CopyOnWriteArrayList ZONE_IDS; >>> >>> 2) At the end of registerProvider0() add all of the new IDs to the >>> list (must be outside the loop as otherwise CopyOnWriteArrayList will >>> be slow) >>> >>> 3) Add a new method getAvailableZoneIdList() that returns the list >>> wrapped in Collections.unmodifiableList() >>> >>> 4) In the calling code, query the size, and then use subList(0, size) >>> to lock the size from race conditions. >>> >>> >>> A variation would be >>> >>> 1) Add a new field >>> >>> private static volatile Set ZONE_IDS; >>> >>> 2) Synchronize/lock registerProvider0() to ensure only one thread is >>> in there at a time. >>> >>> 3) At the end of registerProvider0() add all of the new IDs to the >>> set, storing Collections.unmodifiableSet(combinedSet) >>> >>> 4) Add a new method getAvailableZoneIdSet() that returns the >>> unmodifiable set >>> >>> 5) Change the calling code to use the new method, but no other >>> changes >>> >>> >>> Stephen >>> >>> >>> On 5 May 2016 at 16:53, Roger Riggs wrote: >>>> Hi Stephen, >>>> >>>> The aspect of the current implementation that is problematic is the >>>> copying of the set, its not just single object creation but an entry >>>> for every ZoneID. >>>> >>>> Adding a size method exposing some internal state increases the >>>> possibility that when it is used independently it will be out of >>>> sync. Not a big issue, but one to avoid when designing an API. >>>> >>>> Exposing a mutable Hashset was probably a mistake but one that >>>> cannot be corrected now. The optics aren't concerning to me. >>>> >>>> SharedSecrets are much messier and not appropriate. >>>> >>>> Adding a method to provide what was originally needed is a cleaner >>>> solution. >>>> >>>> Roger >>>> >>>> >>>> >>>> >>>> On 5/5/2016 11:27 AM, Stephen Colebourne wrote: >>>>> I fail to see why adding a new read-only method alongside the >>>>> existing method adds any more value to the API than adding a new size method. >>>>> At least with the size method the API is still sensible - a mutable >>>>> and immutable method alongside each other shouts out that a mistake >>>>> was made. A size method is more subtle about the mistake (plenty of >>>>> APIs have a size method alongside a collection method). >>>>> >>>>> Finally, a read-only method involves object creation, thus has >>>>> worse performance than adding a size method. >>>>> >>>>> The only other alternative is perhaps to use SharedSecrets? I don't >>>>> know what possibilities there are there. If not SharedSecrets, then >>>>> no matter what, we are adding "a trivial method to the public API >>>>> used only for an optimization". >>>>> >>>>> Stephen >>>>> >>>>> >>>>> On 5 May 2016 at 15:23, Roger Riggs wrote: >>>>>> Hi Bhanu, >>>>>> >>>>>> Adding a trivial method to the public API used only for an >>>>>> optimization is not a good fix for this issue. >>>>>> >>>>>> A better fix was suggested to add a non-copying read-only version >>>>>> of >>>>>> >>>>>> ZoneRulesProvider.getAvailableZoneIds() >>>>>> >>>>>> Please revise the fix to instead implement and use: >>>>>> >>>>>> /** >>>>>> * Gets a readonly set of available zone IDs. >>>>>> *

>>>>>> * These IDs are the string form of a {@link ZoneId}. >>>>>> * >>>>>> * @return a unmodifiable copy of the set of zone IDs, not null >>>>>> */ >>>>>> public static Set getReadOnlyAvailableZoneIds() { >>>>>> return Collections.unmodifiableSet(ZONES.keySet()); >>>>>> } >>>>>> >>>>>> Roger >>>>>> >>>>>> >>>>>> >>>>>> On 5/5/2016 5:10 AM, Bhanu Gopularam wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> >>>>>> >>>>>> Please review fix following issue >>>>>> >>>>>> >>>>>> >>>>>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8066291 >>>>>> >>>>>> >>>>>> >>>>>> Solution: provided new method to get size of available zone ids >>>>>> >>>>>> >>>>>> >>>>>> webrev : >>>>>> http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.00 >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Bhanu >>>>>> >>>>>> From nadeesh.tv at oracle.com Mon May 9 14:15:39 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Mon, 09 May 2016 19:45:39 +0530 Subject: Add date-time patterns 'v' and 'vvvv' Message-ID: <57309B8B.5000600@oracle.com> Hi all, Bug Id : https://bugs.openjdk.java.net/browse/JDK-8155823 Issue: Add date-time patterns 'v' and 'vvvv' webrev: http://cr.openjdk.java.net/~ntv/8155823/webrev.03/ This webrev also contain the fix of related bug https://bugs.openjdk.java.net/browse/JDK-8154567 as part of this. -- Thanks and Regards, Nadeesh TV From forax at univ-mlv.fr Mon May 9 14:25:23 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 9 May 2016 16:25:23 +0200 (CEST) Subject: RFR(m): 8139233u1 add initial compact immutable collection implementations In-Reply-To: <192fcb16-aa51-5662-e38b-1efb2a68937e@oracle.com> References: <9622a280-f29a-820c-00e9-74f41964141f@oracle.com> <192fcb16-aa51-5662-e38b-1efb2a68937e@oracle.com> Message-ID: <394584297.477564.1462803923948.JavaMail.zimbra@u-pem.fr> Hi Stuart, I still think that the code of hasNext of the iterator of SetN and MapN should not do any side effect. otherwise, in the constructor of MapN, you can declare k and v as Object (the table is an array of Object and probe() now takes an Object) also instead of InternalError, i think AssertionError is a better exception, the javadoc of InternalError says that InternalError is thrown by the VM. in MapN.probe, you can remove the cast to K (and the corresponding @SuppressWarnings). Set2.e0 and Set2.e1 should be declared as package-private otherwise, the compiler generates an accessor in the iterator. Same thing for SetN.elements, MapN.table and MapN.size CollSer implementation can be improved to avoid the ugly switch/case by replacing the constant list by an enum, something like the code below. In that case, creating a CollSer for a Map will be done like this, return new CollSer(CollSer.Kind.MAP, array); final class CollSer implements Serializable { private static final long serialVersionUID = 6309168927139932177L; //static final int IMM_LIST = 1; //static final int IMM_SET = 2; //static final int IMM_MAP = 3; enum Kind { LIST(List::of), SET(Set::of), MAP(Kind::mapFromArray); final Function factory; private Kind(Function factory) { this.factory = factory; } private static Map mapFromArray(Object[] array) { if (array.length == 0) { return new ImmutableCollections.Map0<>(); } if (array.length == 2) { return new ImmutableCollections.Map1<>(array[0], array[1]); } return new ImmutableCollections.MapN<>(array); } } private static final Kind[] KINDS = Kind.values(); private final int kind; private final Object[] array; CollSer(Kind kind, Object... array) { this.kind = kind.ordinal(); this.array = array; } private Object readResolve() throws ObjectStreamException { if (array == null) { throw new InvalidObjectException("null array"); } try { return KINDS[kind].factory.apply(array); } catch (NullPointerException|IllegalArgumentException|ArrayIndexOutOfBoundsException ex) { InvalidObjectException ioe = new InvalidObjectException("invalid object"); ioe.initCause(ex); throw ioe; } } } R?mi ----- Mail original ----- > De: "Stuart Marks" > ?: "Michael Hixson" > Cc: "core-libs-dev" > Envoy?: Vendredi 6 Mai 2016 20:04:27 > Objet: Re: RFR(m): 8139233u1 add initial compact immutable collection implementations > > On 5/6/16 10:57 AM, Stuart Marks wrote: > > I've been doing too much last-minute refactoring. > > Actually that's wasn't the cause of this bug. The bug was in the previous > webrev > and also in the prototype from my branch in the sandbox, so it's been in > there > quite a while. > > Again, thanks for spotting it. > > s'marks > From Roger.Riggs at Oracle.com Mon May 9 14:35:13 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 9 May 2016 10:35:13 -0400 Subject: RFR 8066291: ZoneIdPrinterParser can be optimized In-Reply-To: References: <79c157ea-4b77-8e4a-444b-08a69ca4779b@Oracle.com> <3a769e0f-d551-0ea6-87ee-7bc1b0d0b39f@Oracle.com> <7757463a-9fe4-4880-a7dc-5c920461e796@default> Message-ID: Hi, It may be useful to include a description of the set as being a 'snapshot'. Now that registerProvider0 is synchronized, there seems little point to having ZONES be a ConcurrentHashMap. An unmodifiable map that is replaced when a new provider is added would have the benefits of immutability and not having make a copy of the zoneids. Getting the map and adding a new provider would need to be synchronized but no other operations. Maybe I'm just overthinking this simple function. Roger On 5/9/2016 7:47 AM, Stephen Colebourne wrote: > Fine by me, just awaiting an additional reviewer. > Stephen > > On 9 May 2016 at 12:42, Bhanu Gopularam > wrote: >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.03/ >> >> Please review the changes. >> >> Thanks, >> Bhanu >> >> -----Original Message----- >> From: Stephen Colebourne [mailto:scolebourne at joda.org] >> Sent: Monday, May 09, 2016 4:43 PM >> To: core-libs-dev >> Subject: Re: RFR 8066291: ZoneIdPrinterParser can be optimized >> >> One point - the Javadoc for the method on ZoneRulesProvider >> >> @return a modifiable copy of the set of zone IDs, not null >> >> needs to change to >> >> @return the unmodifiable set of zone IDs, not null >> >> I'd welcome a second review on the volatile / thread-safety aspects, although I think it is pretty simple and safe. >> >> Stephen >> >> >> On 9 May 2016 at 11:58, Bhanu Gopularam >> wrote: >>> Hi all, >>> >>> Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.02/ >>> >>> I have included newly suggested changes. On test side, I had to cleanup test java/time/zone/TCKZoneRulesProvider.java (test_getAvailableGroupIds) as ZoneRulesProvider.getAvailableZoneIds() returns a non-modifiable list, the tests for ZoneId.getAvailableZoneIds() is present in java/time/tck/java/time/TCKZoneId.java (). >>> >>> Thanks, >>> Bhanu >>> >>> -----Original Message----- >>> From: Stephen Colebourne [mailto:scolebourne at joda.org] >>> Sent: Friday, May 06, 2016 3:54 PM >>> To: core-libs-dev >>> Subject: Re: RFR 8066291: ZoneIdPrinterParser can be optimized >>> >>> The set of zones can only increase, it cannot decrease as there is no removal mechanism. As such, the size of the set is a proxy for the number you describe. >>> >>> One other point. The method that most users will call to get the set of ZoneIds is ZoneId.getAvailableZoneIds(). That method delegates to the one on ZoneRulesProvider. As such, we can change the method on ZoneRulesProvider to return an immutable set while still keeping the method commonly used by users returning a mutable set. The incompatibility impact caused by this would be vanishingly small. To me, this is by far the best way to address this problem, as it avoids a new method. >>> >>> Thus, I propose: >>> >>> 1) Add a new field private static volatile Set ZONE_IDS; >>> >>> 2) Synchronize/lock registerProvider0() to ensure only one thread is in there at a time. >>> >>> 3) At the end of registerProvider0() add all of the existing and new >>> IDs to a new HashSet wrapped in >>> Collections.unmodifiableSet(combinedSet) and change ZONE_IDS to point at the new set. >>> >>> 4) Change ZoneRulesProvider.getAvailableZoneIds() to return ZONE_IDS. >>> Change the spec to indicate the result is unmodifiable. >>> >>> 5) Change ZoneId.getAvailableZoneIds() to return new >>> HashSet(ZoneRulesProvider.getAvailableZoneIds()) >>> >>> Code changes: >>> >>> ZoneId: >>> >>> public static Set getAvailableZoneIds() { >>> return new HashSet(ZoneRulesProvider.getAvailableZoneIds()); >>> } >>> >>> >>> ZoneRulesProvider: >>> >>> private static volatile Set ZONE_IDS; >>> >>> @return the unmodifiable set of zone IDs, not null public static Set getAvailableZoneIds() { >>> return ZONE_IDS; >>> } >>> >>> private static synchronized void registerProvider0(ZoneRulesProvider provider) { >>> for (String zoneId : provider.provideZoneIds()) { >>> Objects.requireNonNull(zoneId, "zoneId"); >>> ZoneRulesProvider old = ZONES.putIfAbsent(zoneId, provider); >>> if (old != null) { >>> throw new ZoneRulesException( >>> "Unable to register zone as one already registered with that >>> ID: " + zoneId + >>> ", currently loading from provider: " + provider); >>> } >>> } >>> Set combinedSet = new HashSet(ZONES.keySet()); >>> ZONE_IDS = Collections.unmodifiableSet(combinedSet); >>> } >>> >>> Stephen >>> >>> >>> On 5 May 2016 at 19:48, Roger Riggs wrote: >>>> Hi, >>>> >>>> Using the current number of ZoneIDs to avoid the recompilation of the >>>> cache is a bit weak anyway, though it seems unlikely that a ZoneID >>>> would be added and one deleted without being noticed. >>>> >>>> An alternative would be a API that returned a number that would >>>> change every time the set of ZoneIds changed. >>>> That would be more suitable both as a new API and as something to >>>> trigger updates to the cache. >>>> >>>> I'd rather see a localized implementation with a simple model. >>>> >>>> Roger >>>> >>>> >>>> On 5/5/2016 1:43 PM, Stephen Colebourne wrote: >>>>> On reflection, both your and my solution have a race. >>>>> >>>>> the size method, is a clear check-then-act >>>>> >>>>> the read-only method uses Collections.unmodifiableSet() which only >>>>> decorates the underlying set, thus is still check-thern-act >>>>> >>>>> (the current implementation does not have a race condition, as the >>>>> data is copied, thus the size will match the data) >>>>> >>>>> There is no pleasant way to solve this that I can see. This is my >>>>> best >>>>> attempt: >>>>> >>>>> 1) Add a new field >>>>> >>>>> private static final CopyOnWriteArrayList ZONE_IDS; >>>>> >>>>> 2) At the end of registerProvider0() add all of the new IDs to the >>>>> list (must be outside the loop as otherwise CopyOnWriteArrayList >>>>> will be slow) >>>>> >>>>> 3) Add a new method getAvailableZoneIdList() that returns the list >>>>> wrapped in Collections.unmodifiableList() >>>>> >>>>> 4) In the calling code, query the size, and then use subList(0, >>>>> size) to lock the size from race conditions. >>>>> >>>>> >>>>> A variation would be >>>>> >>>>> 1) Add a new field >>>>> >>>>> private static volatile Set ZONE_IDS; >>>>> >>>>> 2) Synchronize/lock registerProvider0() to ensure only one thread is >>>>> in there at a time. >>>>> >>>>> 3) At the end of registerProvider0() add all of the new IDs to the >>>>> set, storing Collections.unmodifiableSet(combinedSet) >>>>> >>>>> 4) Add a new method getAvailableZoneIdSet() that returns the >>>>> unmodifiable set >>>>> >>>>> 5) Change the calling code to use the new method, but no other >>>>> changes >>>>> >>>>> >>>>> Stephen >>>>> >>>>> >>>>> On 5 May 2016 at 16:53, Roger Riggs wrote: >>>>>> Hi Stephen, >>>>>> >>>>>> The aspect of the current implementation that is problematic is the >>>>>> copying of the set, its not just single object creation but an >>>>>> entry for every ZoneID. >>>>>> >>>>>> Adding a size method exposing some internal state increases the >>>>>> possibility that when it is used independently it will be out of >>>>>> sync. Not a big issue, but one to avoid when designing an API. >>>>>> >>>>>> Exposing a mutable Hashset was probably a mistake but one that >>>>>> cannot be corrected now. The optics aren't concerning to me. >>>>>> >>>>>> SharedSecrets are much messier and not appropriate. >>>>>> >>>>>> Adding a method to provide what was originally needed is a cleaner >>>>>> solution. >>>>>> >>>>>> Roger >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 5/5/2016 11:27 AM, Stephen Colebourne wrote: >>>>>>> I fail to see why adding a new read-only method alongside the >>>>>>> existing method adds any more value to the API than adding a new size method. >>>>>>> At least with the size method the API is still sensible - a >>>>>>> mutable and immutable method alongside each other shouts out that >>>>>>> a mistake was made. A size method is more subtle about the mistake >>>>>>> (plenty of APIs have a size method alongside a collection method). >>>>>>> >>>>>>> Finally, a read-only method involves object creation, thus has >>>>>>> worse performance than adding a size method. >>>>>>> >>>>>>> The only other alternative is perhaps to use SharedSecrets? I >>>>>>> don't know what possibilities there are there. If not >>>>>>> SharedSecrets, then no matter what, we are adding "a trivial >>>>>>> method to the public API used only for an optimization". >>>>>>> >>>>>>> Stephen >>>>>>> >>>>>>> >>>>>>> On 5 May 2016 at 15:23, Roger Riggs wrote: >>>>>>>> Hi Bhanu, >>>>>>>> >>>>>>>> Adding a trivial method to the public API used only for an >>>>>>>> optimization is not a good fix for this issue. >>>>>>>> >>>>>>>> A better fix was suggested to add a non-copying read-only version >>>>>>>> of >>>>>>>> >>>>>>>> ZoneRulesProvider.getAvailableZoneIds() >>>>>>>> >>>>>>>> Please revise the fix to instead implement and use: >>>>>>>> >>>>>>>> /** >>>>>>>> * Gets a readonly set of available zone IDs. >>>>>>>> *

>>>>>>>> * These IDs are the string form of a {@link ZoneId}. >>>>>>>> * >>>>>>>> * @return a unmodifiable copy of the set of zone IDs, not null >>>>>>>> */ >>>>>>>> public static Set getReadOnlyAvailableZoneIds() { >>>>>>>> return Collections.unmodifiableSet(ZONES.keySet()); >>>>>>>> } >>>>>>>> >>>>>>>> Roger >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 5/5/2016 5:10 AM, Bhanu Gopularam wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please review fix following issue >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8066291 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Solution: provided new method to get size of available zone ids >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> webrev : >>>>>>>> http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8066291/webrev.0 >>>>>>>> 0 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Bhanu >>>>>>>> >>>>>>>> From Roger.Riggs at Oracle.com Mon May 9 14:49:30 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 9 May 2016 10:49:30 -0400 Subject: [PATCH] JDK-8155102: Process.toString could include pid, isAlive, exitStatus In-Reply-To: References: Message-ID: <9066d1a2-4a7d-bff4-60d8-d62ff559272d@Oracle.com> Hi Andrey, Since toString is a public method it needs to provide complete javadoc specification as providing values for debugging information. ToString methods typically directly reflect the state of the fields of the object. Why should the exitValue have the value of the pid if the process is not alive? Also, the if toString is providing the exitValue then it should be identified as "exitValue", not exitCode. the isAlive value should be identified as "isAlive". The implementation class should not be exposed. (remove this.getClass().getSimpleName()). The performance of what seems like a simple toString method is not going to be great because of the native calls necessary to determine if the process is alive (called twice) and in the case of exitValue to handle the IllegalStateException. Some of the overhead could be avoided, by implementing toString in each of the ProcessImpl.java files where the current state is known more conveniently with less overhead. $.02, Roger On 5/8/2016 2:47 PM, Andrey Dyachkov wrote: > Hello, > > I have added toString() method in Process.java. > > diff --git a/src/java.base/share/classes/java/lang/Process.java > b/src/java.base/share/classes/java/lang/Process.java > --- a/src/java.base/share/classes/java/lang/Process.java > +++ b/src/java.base/share/classes/java/lang/Process.java > @@ -548,5 +548,16 @@ > return toHandle().descendants(); > } > > + @Override > + public String toString() { > + boolean isAlive = this.isAlive(); > + return new > StringBuilder(this.getClass().getSimpleName()).append("[") > + .append("running=").append(isAlive).append(", ") > + .append(isAlive ? "pid=" : "exitCode=") > + .append(isAlive ? this.getPid() : this.exitValue()) > + .append("]") > + .toString(); > + } > + > > } From nadeesh.tv at oracle.com Mon May 9 14:59:11 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Mon, 09 May 2016 20:29:11 +0530 Subject: Add date-time patterns 'v' and 'vvvv' Message-ID: <5730A5BF.50503@oracle.com> Hi all, Bug Id : https://bugs.openjdk.java.net/browse/JDK-8155823 Issue: Add date-time patterns 'v' and 'vvvv' webrev: http://cr.openjdk.java.net/~ntv/8155823/webrev.03/ This webrev also contain the fix of related bug https://bugs.openjdk.java.net/browse/JDK-8154567 as part of this. Special thanks for Stephen for his help in writing the spec. -- Thanks and Regards, Nadeesh TV From felix.yang at oracle.com Mon May 9 15:29:25 2016 From: felix.yang at oracle.com (Felix Yang) Date: Mon, 9 May 2016 23:29:25 +0800 Subject: RFR 8155088, Fix module dependencies in java/sql/* and javax/* tests In-Reply-To: <0ef38c22-33a8-8a2b-bc46-7cfaba1bb15e@oracle.com> References: <8a466652-c0da-1f0c-8272-d1b51bea6c73@oracle.com> <57230C62.7010607@oracle.com> <136f5ce3-e751-c062-f486-6cd18fb4809e@oracle.com> <572A0B04.5000502@oracle.com> <0ef38c22-33a8-8a2b-bc46-7cfaba1bb15e@oracle.com> Message-ID: <831ec300-2c35-e36c-27af-0c29c52f1228@oracle.com> Hi Alan, updated the fix. Divide into two webrevs for https://bugs.openjdk.java.net/browse/CODETOOLS-7901671 Webrevs: http://cr.openjdk.java.net/~xiaofeya/8155088/webrev.02_se/ http://cr.openjdk.java.net/~xiaofeya/8155088/webrev.02_ee/ I suggest to push the first one currently. And file another issue to track latter one. Because without fix for CODETOOLS-7901671( in next jtreg promotion ), those tests with EE modules in @modules will be skipped by default. Thanks, Felix On 2016/5/4 23:44, Felix Yang wrote: > Hi Alan, > > > On 2016/5/4 22:45, Alan Bateman wrote: >> >> >> On 04/05/2016 15:39, Felix Yang wrote: >>> Hi Alan, >>> >>> please review the updated webrev. Reverted changes for those >>> tests with "-addmods". >>> >>> http://cr.openjdk.java.net/~xiaofeya/8155088/webrev.01/ >> For the javax.transaction test then don't you also add >> "java.transaction" in the @modules value? The rest looks fine. > I'm a bit confused here. There is "-addmods java.transaction" for > @compile. Is it still necessary to declare in @modules? > Actually, if add java.transaction in the @modules, the test will be > skipped by jtreg. Filed > https://bugs.openjdk.java.net/browse/CODETOOLS-7901671 for jtreg, > because it looks to be not a good practice for either situation. > > -Felix >> >> -Alan > From Roger.Riggs at Oracle.com Mon May 9 15:46:57 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 9 May 2016 11:46:57 -0400 Subject: RFR (JAXP) JDK-8156513: Problem list javax/xml/jaxp/unittest/stream/FactoryFindTest.java In-Reply-To: <57301CBA.3070404@oracle.com> References: <57301CBA.3070404@oracle.com> Message-ID: Hi Amy, Looks fine to add to the problem list. It looks like that ProblemList.txt has not been converted to use the new format with the bug number as the second field. Roger On 5/9/2016 1:14 AM, Amy Lu wrote: > javax/xml/jaxp/unittest/stream/FactoryFindTest.java > > This jaxp test creates and may left over file under testing jdk > (jdk/lib/stax.properties) and other tests being affected. (JDK-8156508) > This patch is to add this test to ProblemList.txt until mentioned > issue resolved. > > bug: https://bugs.openjdk.java.net/browse/JDK-8156513 > webrev: http://cr.openjdk.java.net/~amlu/8156513/webrev.00/ > > Thanks, > Amy > > > --- old/test/ProblemList.txt 2016-05-09 13:04:09.000000000 +0800 > +++ new/test/ProblemList.txt 2016-05-09 13:04:09.000000000 +0800 > @@ -29,3 +29,5 @@ > # 8150145 > javax/xml/jaxp/unittest/common/TransformationWarningsTest.java > generic-all > > +# 8156508 > +javax/xml/jaxp/unittest/stream/FactoryFindTest.java generic-all > > From martinrb at google.com Mon May 9 16:34:55 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 9 May 2016 09:34:55 -0700 Subject: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more In-Reply-To: <570514C1.5000507@Oracle.com> References: <56B72242.7050102@gmail.com> <56C43817.7060805@gmail.com> <7BA56B2F-C1C6-4EAF-B900-A825C6B602EF@oracle.com> <56CA080F.6010308@gmail.com> <56CB83FF.4010808@Oracle.com> <56CC8A4A.9080303@gmail.com> <56CEAC28.80802@gmail.com> <56CEB49A.4090000@oracle.com> <56CEC6A5.3070202@gmail.com> <56D0C5F5.7060509@Oracle.com> <56DC29DE.4040006@gmail.com> <059F3798-66D4-4300-B618-09868A04E3DC@oracle.com> <56E09299.2050900@gmail.com> <8EDD817B-F124-4613-9EEE-7865EE67037D@oracle.com> <56F96778.5020202@gmail.com> <56FE914E.2070804@gmail.com> <56FE9D14.8010404@gmail.com> <56FEA5FF.4060801@gmail.com> <56FEED59.7090906@Oracle.com> <56FF04B5.2030507@oracle.com> <56FFABED.2060708@gmail.com> <5702E18D.7010807@Oracle.com> <5703CE96.4040001@gmail.com> <5704B01F.4070406@gmail.com> <570514C1.5000507@Oracle.com> Message-ID: I haven't been following along with the long review thread, but I took a look at the new Cleaner stuff and have some belated comments: --- Please add missing semicolon: * private final Cleaner.Cleanable cleanable --- The below looks non-sensical; maybe should return EV_CLEAR if some clearing, not cleaning, should occur? * @return EV_CLEAR if the cleanup should occur; * EV_CLEAN if the cleanup should occur; --- private final int hash; private final ConcurrentHashMap, ?> map; Cleaner.Cleanable cleanable; Why isn't cleanable also private final? --- Assert.assertEquals(map.get(k2), data, "value should be found in the map"); key = null; System.gc(); Assert.assertNotEquals(map.get(k2), data, "value should not be found in the map"); I initially expected this to fail at least intermittently because a cleaner may not yet have removed the entry from the map. Why aren't we calling whitebox.fullGC() everywhere where System.gc() is being called? What's particularly confusing here is that the WeakKey is not actually surely removed from the map, but instead two WeakKeys that may have been equal become non-equal when they get cleared by the gc. Which is generally bad practice. Which suggests we wouldn't implement a real public concurrent map of weak keys this way. --- WeakCleanable and friends are defined in jdk.internal, don't appear to be used at all, and since there are fields in CleanerImpl, they impose a hidden tax on all users of Cleaner. I don't see why there is both WeakCleanable (using subclassing) and WeakCleanableRef (using a provided Runnable). Is a compelling use case for WeakCleanables forthcoming? --- I keep vaguely hoping to see a CompletableFuture-based API for cleanup actions. From nadeesh.tv at oracle.com Mon May 9 16:35:41 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Mon, 09 May 2016 22:05:41 +0530 Subject: RFR:JDK-8155823: Add date-time patterns 'v' and 'vvvv' Message-ID: <5730BC5D.7050807@oracle.com> Hi all, Reposting because subject line did not follow the format. Bug Id : https://bugs.openjdk.java.net/browse/JDK-8155823 Issue: Add date-time patterns 'v' and 'vvvv' webrev: http://cr.openjdk.java.net/~ntv/8155823/webrev.03/ This webrev also contain the fix of related bug https://bugs.openjdk.java.net/browse/JDK-8154567 as part of this. Special thanks for Stephen for his help in writing the spec. -- Thanks and Regards, Nadeesh TV From andrey.dyachkov at gmail.com Sat May 7 06:03:45 2016 From: andrey.dyachkov at gmail.com (Andrey Dyachkov) Date: Sat, 7 May 2016 09:03:45 +0300 Subject: [PATCH] JDK-8155102: Process.toString could include pid, isAlive, exitStatus Message-ID: Hello, I have added toString() method in Process.java. diff --git a/src/java.base/share/classes/java/lang/Process.java b/src/java.base/share/classes/java/lang/Process.java --- a/src/java.base/share/classes/java/lang/Process.java +++ b/src/java.base/share/classes/java/lang/Process.java @@ -548,5 +548,16 @@ return toHandle().descendants(); } + @Override + public String toString() { + boolean isAlive = this.isAlive(); + return new StringBuilder(this.getClass().getSimpleName()).append("[") + .append("running=").append(isAlive).append(", ") + .append(isAlive ? "pid=" : "exitCode=") + .append(isAlive ? this.getPid() : this.exitValue()) + .append("]") + .toString(); + } + } From scolebourne at joda.org Mon May 9 17:49:15 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 9 May 2016 18:49:15 +0100 Subject: RFR(m): 8139233u1 add initial compact immutable collection implementations In-Reply-To: <394584297.477564.1462803923948.JavaMail.zimbra@u-pem.fr> References: <9622a280-f29a-820c-00e9-74f41964141f@oracle.com> <192fcb16-aa51-5662-e38b-1efb2a68937e@oracle.com> <394584297.477564.1462803923948.JavaMail.zimbra@u-pem.fr> Message-ID: On 9 May 2016 at 15:25, Remi Forax wrote: > CollSer implementation can be improved to avoid the ugly switch/case by replacing the constant list by an enum, CollSer is modelled on JSR-310 code which uses an int. An enum would be a huge overkill for this use case. Stephen From scolebourne at joda.org Mon May 9 18:08:01 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 9 May 2016 19:08:01 +0100 Subject: RFR:JDK-8155823: Add date-time patterns 'v' and 'vvvv' In-Reply-To: <5730BC5D.7050807@oracle.com> References: <5730BC5D.7050807@oracle.com> Message-ID: This line: * v generic time-zone name zone-name Pacific Standard Time; PT should be * v generic time-zone name zone-name Pacific Time; PT Missing space before "false" at line 1226: appendInternal(new ZoneTextPrinterParser(textStyle, preferredZones,false)); This code: if (zone.getRules().getTransition(ldt) == null) { type = zone.getRules().isDaylightSavings(Instant.from(ldt)) ? DST : STD; } won't work. It needs to be: if (zone.getRules().getTransition(ldt) == null) { type = zone.getRules().isDaylightSavings(ldt.atZone(zone).toInstant()) ? DST : STD; } This suggests JDK-8154567 needs an additional test case. In the parsing test case, the input should be "Pacific Time", not "Pacific Standard Time" thanks Stephen On 9 May 2016 at 17:35, nadeesh tv wrote: > > Hi all, > > Reposting because subject line did not follow the format. > > Bug Id : https://bugs.openjdk.java.net/browse/JDK-8155823 > Issue: Add date-time patterns 'v' and 'vvvv' > webrev: http://cr.openjdk.java.net/~ntv/8155823/webrev.03/ > > This webrev also contain the fix of related bug > https://bugs.openjdk.java.net/browse/JDK-8154567 as part of this. > > Special thanks for Stephen for his help in writing the spec. > > -- > Thanks and Regards, > Nadeesh TV > From Roger.Riggs at Oracle.com Mon May 9 18:10:45 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 9 May 2016 14:10:45 -0400 Subject: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more In-Reply-To: References: <56B72242.7050102@gmail.com> <7BA56B2F-C1C6-4EAF-B900-A825C6B602EF@oracle.com> <56CA080F.6010308@gmail.com> <56CB83FF.4010808@Oracle.com> <56CC8A4A.9080303@gmail.com> <56CEAC28.80802@gmail.com> <56CEB49A.4090000@oracle.com> <56CEC6A5.3070202@gmail.com> <56D0C5F5.7060509@Oracle.com> <56DC29DE.4040006@gmail.com> <059F3798-66D4-4300-B618-09868A04E3DC@oracle.com> <56E09299.2050900@gmail.com> <8EDD817B-F124-4613-9EEE-7865EE67037D@oracle.com> <56F96778.5020202@gmail.com> <56FE914E.2070804@gmail.com> <56FE9D14.8010404@gmail.com> <56FEA5FF.4060801@gmail.com> <56FEED59.7090906@Oracle.com> <56FF04B5.2030507@oracle.com> <56FFABED.2060708@gmail.com> <5702E18D.7010807@Oracle.com> <5703CE96.4040001@gmail.com> <5704B01F.4070406@gmail.com> <570514C1.5000507@Oracle.com> Message-ID: <9ca3444f-2d5d-6895-5f07-b8b1f23e844f@Oracle.com> Hi Martin, I added a link to these notes to the JDK-8144531 Cleanup of Cleaner implementation. I'm not sure I understand what "a CompletableFuture-based API for cleanup actions." would look like or how it would be used. Thanks, Roger On 5/9/2016 12:34 PM, Martin Buchholz wrote: > I haven't been following along with the long review thread, but I took > a look at the new Cleaner stuff and have some belated comments: > > --- > > Please add missing semicolon: > * private final Cleaner.Cleanable cleanable > > --- > > The below looks non-sensical; maybe should return EV_CLEAR if some > clearing, not cleaning, should occur? > > * @return EV_CLEAR if the cleanup should occur; > * EV_CLEAN if the cleanup should occur; > > --- > > private final int hash; > private final ConcurrentHashMap, ?> map; > Cleaner.Cleanable cleanable; > > Why isn't cleanable also private final? > > --- > > Assert.assertEquals(map.get(k2), data, "value should be found > in the map"); > key = null; > System.gc(); > Assert.assertNotEquals(map.get(k2), data, "value should not be > found in the map"); > > I initially expected this to fail at least intermittently because a > cleaner may not yet have removed the entry from the map. > > Why aren't we calling whitebox.fullGC() everywhere where System.gc() > is being called? > > What's particularly confusing here is that the WeakKey is not actually > surely removed from the map, but instead two WeakKeys that may have > been equal become non-equal when they get cleared by the gc. Which is > generally bad practice. Which suggests we wouldn't implement a real > public concurrent map of weak keys this way. > > --- > > WeakCleanable and friends are defined in jdk.internal, don't appear to > be used at all, and since there are fields in CleanerImpl, they impose > a hidden tax on all users of Cleaner. I don't see why there is both > WeakCleanable (using subclassing) and WeakCleanableRef (using a > provided Runnable). Is a compelling use case for WeakCleanables > forthcoming? > > --- > > I keep vaguely hoping to see a CompletableFuture-based API for cleanup actions. From martinrb at google.com Mon May 9 19:01:12 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 9 May 2016 12:01:12 -0700 Subject: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more In-Reply-To: <9ca3444f-2d5d-6895-5f07-b8b1f23e844f@Oracle.com> References: <56B72242.7050102@gmail.com> <7BA56B2F-C1C6-4EAF-B900-A825C6B602EF@oracle.com> <56CA080F.6010308@gmail.com> <56CB83FF.4010808@Oracle.com> <56CC8A4A.9080303@gmail.com> <56CEAC28.80802@gmail.com> <56CEB49A.4090000@oracle.com> <56CEC6A5.3070202@gmail.com> <56D0C5F5.7060509@Oracle.com> <56DC29DE.4040006@gmail.com> <059F3798-66D4-4300-B618-09868A04E3DC@oracle.com> <56E09299.2050900@gmail.com> <8EDD817B-F124-4613-9EEE-7865EE67037D@oracle.com> <56F96778.5020202@gmail.com> <56FE914E.2070804@gmail.com> <56FE9D14.8010404@gmail.com> <56FEA5FF.4060801@gmail.com> <56FEED59.7090906@Oracle.com> <56FF04B5.2030507@oracle.com> <56FFABED.2060708@gmail.com> <5702E18D.7010807@Oracle.com> <5703CE96.4040001@gmail.com> <5704B01F.4070406@gmail.com> <570514C1.5000507@Oracle.com> <9ca3444f-2d5d-6895-5f07-b8b1f23e844f@Oracle.com> Message-ID: On Mon, May 9, 2016 at 11:10 AM, Roger Riggs wrote: > I'm not sure I understand what > > "a CompletableFuture-based API for cleanup actions." > > would look like or how it would be used. I'm fuzzy myself, but the idea is that any asynchronous action that will be completed in the future should be represented by a CompletableFuture. In this case, the asynchronous actions are performed by the GC. I imagine an API on e.g. WeakReference CompletableFuture whenCleared() and then a user can schedule follow-on actions in the executor of their choice. WeakReference r = ... r.whenCleared().thenRunAsync(...) One idea is to throw away as much Cleaner machinery as possible to reuse CompletableFuture machinery. Or build on top... All concurrency machinery is hard for humans to understand. From forax at univ-mlv.fr Mon May 9 19:17:05 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 9 May 2016 21:17:05 +0200 (CEST) Subject: RFR(m): 8139233u1 add initial compact immutable collection implementations In-Reply-To: References: <9622a280-f29a-820c-00e9-74f41964141f@oracle.com> <192fcb16-aa51-5662-e38b-1efb2a68937e@oracle.com> <394584297.477564.1462803923948.JavaMail.zimbra@u-pem.fr> Message-ID: <663479067.594910.1462821425057.JavaMail.zimbra@u-pem.fr> Hi Stephen, you may right :) First note that the Enum values are used as an ephemeral state, the serialized form still uses an integer as the original code. You can also note that the enum is not loaded if no immutable collection is serialized (because CollSer is not initialized). It's just a good old OOP trick that transforms a switch to a dispatch that will be used when de-serializing. In my opinion, if there are several other immutable collections (like the ordered set/map proposed by Stuart), the code with an enum is easier to modify that the current code, otherwise, as you said, it's an overkill. R?mi ----- Mail original ----- > De: "Stephen Colebourne" > ?: "core-libs-dev" > Envoy?: Lundi 9 Mai 2016 19:49:15 > Objet: Re: RFR(m): 8139233u1 add initial compact immutable collection implementations > > On 9 May 2016 at 15:25, Remi Forax wrote: > > CollSer implementation can be improved to avoid the ugly switch/case by > > replacing the constant list by an enum, > > CollSer is modelled on JSR-310 code which uses an int. An enum would > be a huge overkill for this use case. > > Stephen > From Roger.Riggs at Oracle.com Mon May 9 19:24:15 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 9 May 2016 15:24:15 -0400 Subject: RFR:JDK-8155823: Add date-time patterns 'v' and 'vvvv' In-Reply-To: <5730BC5D.7050807@oracle.com> References: <5730BC5D.7050807@oracle.com> Message-ID: Hi Nadeesh, java/time/format/DateTimeFormatter.java: line 312 - Move 'v' up 1 line so it is after 'V' and before 'z'. Also in DateTimeFormatterBuilder.java: line 1415+ - the description of the number of letters does not need to be repeated; put one copy before the specifics of 'z' and 'v'. "If the count of letters is one, then the short name is output. + * If the count of letters is four, then the full name is output. + * Two, three and five or more letters throw {@code IllegalArgumentException}." DateTimeFormatterBuilder.java - line 1625/1626: should include what happens with vv and vvv to be consistent with DateTimeFormatter doc for ZoneId names. - line 1647: The description in DateTimeFormatter says that count = 2 and 3 should also produce the short value but the code will throw IAE. -line 1988: "almost" --- can this be more specific about what matches or does not match In the test it is a bit bothersome that the tests have to rely on timezone specific data. Thanks, Roger On 5/9/2016 12:35 PM, nadeesh tv wrote: > > Hi all, > > Reposting because subject line did not follow the format. > > Bug Id : https://bugs.openjdk.java.net/browse/JDK-8155823 > Issue: Add date-time patterns 'v' and 'vvvv' > webrev: http://cr.openjdk.java.net/~ntv/8155823/webrev.03/ > > This webrev also contain the fix of related bug > https://bugs.openjdk.java.net/browse/JDK-8154567 as part of this. > > Special thanks for Stephen for his help in writing the spec. > From Roger.Riggs at Oracle.com Mon May 9 19:42:22 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 9 May 2016 15:42:22 -0400 Subject: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds In-Reply-To: References: Message-ID: <29a10b5a-9a23-f839-8cf7-71fd8cc0a86c@Oracle.com> Hi Brian, In the @throws IndexOutOfBounds I think it is easier to understand to say * or {@code off + len} is greater than {@code cbuf.length} It matches the code more closely. - Is not clear why the form of the added @throws is different between the methods (other than len = string.size() line 214: add a spaces in "off+len" Most/All files have the same pattern. It would be nice to be consistent. Thanks, Roger On 5/4/2016 7:17 PM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8130679 > Patch: http://cr.openjdk.java.net/~bpb/8130679/webrev.00/ > > Summary: Add ?@throws IndexOutOfBoundsException [?]? to all write() methods which accept an index parameter and for which no such throws tag is already present. > > Thanks, > > Brian From ropalka at redhat.com Mon May 9 19:43:54 2016 From: ropalka at redhat.com (Richard Opalka) Date: Mon, 9 May 2016 21:43:54 +0200 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <5028AF86-C8DD-431E-8499-0022B8D90C85@oracle.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> <13C89E01-3396-4EFE-BC35-C289E59DBEED@oracle.com> <5707CFBB.8020809@oracle.com> <5028AF86-C8DD-431E-8499-0022B8D90C85@oracle.com> Message-ID: <1d3d6b24-5168-cc5c-942b-2bbda7f2d257@redhat.com> Fixed in JBoss Marshalling upstream. Thanks, Rio On 04/27/2016 11:54 PM, Chris Hegarty wrote: > Hi Rio, > > >> We are missing sun/reflect/ReflectionFactory$GetReflectionFactoryAction inner class >> >> in jdk.unsupported module: >> >> java.lang.NoClassDefFoundError: sun/reflect/ReflectionFactory$GetReflectionFactoryAction >> at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base at 9-internal/BuiltinClassLoader.java:366) >> at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base at 9-internal/ClassLoaders.java:184) >> at java.lang.ClassLoader.loadClass(java.base at 9-internal/ClassLoader.java:419) >> at org.jboss.marshalling.reflect.SerializableClass.(SerializableClass.java:47) > GetReflectionFactoryAction is a convenience class for acquiring > the capability to instantiate reflective objects. It?s code is: > > As part of JEP 260, we retained the single getReflectionFactory > accessor. You can replace your usage with the following: > > PrivilegedAction pa = new PrivilegedAction() { > @Override > public ReflectionFactory run() { > return ReflectionFactory.getReflectionFactory(); > } > }; > > -Chris. > From jaroslav at kamenik.cz Mon May 9 19:50:51 2016 From: jaroslav at kamenik.cz (=?UTF-8?Q?Jaroslav_Kamen=C3=ADk?=) Date: Mon, 9 May 2016 21:50:51 +0200 Subject: RFR: 8155795: Optimize Integer/Long.reverse by using reverseBytes In-Reply-To: References: <57275F3E.6000709@oracle.com> <572768A4.6010105@oracle.com> <57276B7E.80006@oracle.com> Message-ID: Hi guys, I have looked at generated asm, it does not seem there is problem, only little different order of shifts and ands.. Plus, at haswell, times do not differ so much. Here are different parts: Slower version: 057 sall R10, #24 05b movl R11, RAX # spill 05e sall R11, #8 062 movl R8, RAX # spill 065 shrl R8, #8 069 andl R11, #16711680 # int 070 andl R8, #65280 # int 077 shrl RAX, #24 Faster version: 057 shrl R10, #24 05b movl R11, RAX # spill 05e shrl R11, #8 062 movl R8, RAX # spill 065 andl R8, #65280 # int 06c andl R11, #65280 # int 073 sall R8, #8 077 sall RAX, #24 Full code: ORIGINAL - 5,169 ? 0,377 ns/op =============================== 000 B1: # N1 <- BLOCK HEAD IS JUNK Freq: 1 000 # stack bang (96 bytes) pushq rbp # Save rbp subq rsp, #16 # Create frame 00c movl RAX, RSI # spill 00e andl RAX, #1431655765 # int 014 shrl RSI, #1 016 sall RAX, #1 018 andl RSI, #1431655765 # int 01e orl RAX, RSI # int 020 movl R10, RAX # spill 023 shrl R10, #2 027 andl RAX, #858993459 # int 02d andl R10, #858993459 # int 034 sall RAX, #2 037 orl RAX, R10 # int 03a movl R10, RAX # spill 03d shrl R10, #4 041 andl RAX, #252645135 # int 047 andl R10, #252645135 # int 04e sall RAX, #4 051 orl RAX, R10 # int 054 movl R10, RAX # spill 057 shrl R10, #24 05b movl R11, RAX # spill 05e shrl R11, #8 062 movl R8, RAX # spill 065 andl R8, #65280 # int 06c andl R11, #65280 # int 073 sall R8, #8 077 sall RAX, #24 07a orl RAX, R8 # int 07d orl RAX, R11 # int 080 orl RAX, R10 # int 083 addq rsp, 16 # Destroy frame USED INTRINSIC - 4,093 ? 0,100 ns/op ===================================== 000 B1: # N1 <- BLOCK HEAD IS JUNK Freq: 1 000 # stack bang (96 bytes) pushq rbp # Save rbp subq rsp, #16 # Create frame 00c movl RAX, RSI # spill 00e andl RAX, #1431655765 # int 014 shrl RSI, #1 016 sall RAX, #1 018 andl RSI, #1431655765 # int 01e orl RAX, RSI # int 020 movl R10, RAX # spill 023 shrl R10, #2 027 andl RAX, #858993459 # int 02d andl R10, #858993459 # int 034 sall RAX, #2 037 orl RAX, R10 # int 03a movl R10, RAX # spill 03d shrl R10, #4 041 andl RAX, #252645135 # int 047 andl R10, #252645135 # int 04e sall RAX, #4 051 orl RAX, R10 # int 054 bswapl RAX 056 addq rsp, 16 # Destroy frame INTRINSICS DISABLED - 5,173 ? 0,096 ns/op ========================================== 000 B1: # N1 <- BLOCK HEAD IS JUNK Freq: 1 000 # stack bang (96 bytes) pushq rbp # Save rbp subq rsp, #16 # Create frame 00c movl RAX, RSI # spill 00e andl RAX, #1431655765 # int 014 shrl RSI, #1 016 sall RAX, #1 018 andl RSI, #1431655765 # int 01e orl RAX, RSI # int 020 movl R10, RAX # spill 023 shrl R10, #2 027 andl RAX, #858993459 # int 02d andl R10, #858993459 # int 034 sall RAX, #2 037 orl RAX, R10 # int 03a movl R10, RAX # spill 03d shrl R10, #4 041 andl RAX, #252645135 # int 047 andl R10, #252645135 # int 04e sall RAX, #4 051 orl RAX, R10 # int 054 movl R10, RAX # spill 057 sall R10, #24 05b movl R11, RAX # spill 05e sall R11, #8 062 movl R8, RAX # spill 065 shrl R8, #8 069 andl R11, #16711680 # int 070 andl R8, #65280 # int 077 shrl RAX, #24 07a orl RAX, R8 # int 07d orl RAX, R11 # int 080 orl RAX, R10 # int 083 addq rsp, 16 # Destroy frame INTRINSICS DISABLED 2 - 5,081 ? 0,092 ns/op =========================================== 000 B1: # N1 <- BLOCK HEAD IS JUNK Freq: 1 000 # stack bang (96 bytes) pushq rbp # Save rbp subq rsp, #16 # Create frame 00c movl RAX, RSI # spill 00e andl RAX, #1431655765 # int 014 shrl RSI, #1 016 sall RAX, #1 018 andl RSI, #1431655765 # int 01e orl RAX, RSI # int 020 movl R10, RAX # spill 023 shrl R10, #2 027 andl RAX, #858993459 # int 02d andl R10, #858993459 # int 034 sall RAX, #2 037 orl RAX, R10 # int 03a movl R10, RAX # spill 03d shrl R10, #4 041 andl RAX, #252645135 # int 047 andl R10, #252645135 # int 04e sall RAX, #4 051 orl RAX, R10 # int 054 movl R10, RAX # spill 057 shrl R10, #24 05b movl R11, RAX # spill 05e shrl R11, #8 062 movl R8, RAX # spill 065 andl R8, #65280 # int 06c andl R11, #65280 # int 073 sall R8, #8 077 sall RAX, #24 07a orl RAX, R8 # int 07d orl RAX, R11 # int 080 orl RAX, R10 # int 083 addq rsp, 16 # Destroy frame Jaroslav From brian.burkhalter at oracle.com Mon May 9 20:11:39 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 9 May 2016 13:11:39 -0700 Subject: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds In-Reply-To: <29a10b5a-9a23-f839-8cf7-71fd8cc0a86c@Oracle.com> References: <29a10b5a-9a23-f839-8cf7-71fd8cc0a86c@Oracle.com> Message-ID: <1F6EC53A-3913-48AC-81A9-4CC5B699DDB0@oracle.com> Hi Roger, Thanks for taking a close look at this. On May 9, 2016, at 12:42 PM, Roger Riggs wrote: > In the @throws IndexOutOfBounds I think it is easier to understand to say > > * or {@code off + len} is greater than {@code cbuf.length} > > It matches the code more closely. The reason for the verbiage is that it matches (module removal of a redundant ?or? in the throws verbiage) Reader.read(char[],int,int) with which I thought it would good to be consistent in an operation-symmetric sense: http://download.java.net/java/jdk9/docs/api/java/io/Reader.html#read-char:A-int-int- > - Is not clear why the form of the added @throws is different between the methods (other than len = string.size() Writer.write(String,int,int) already had a throws exception for IOOBEs so I was trying to be consistent with that: http://download.java.net/java/jdk9/docs/api/java/io/Writer.html#write-java.lang.String-int-int- > line 214: add a spaces in "off+len" > > Most/All files have the same pattern. It would be nice to be consistent. Again, this is the same as in the extent Writer.write(String,int,int). Thanks, Brian From christian.thalinger at oracle.com Mon May 9 20:24:27 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 9 May 2016 10:24:27 -1000 Subject: [9] RFR: 8152207: Perform array bound checks while getting a length of bytecode instructions In-Reply-To: <572A8A57.5080907@oracle.com> References: <572A8A57.5080907@oracle.com> Message-ID: > On May 4, 2016, at 1:48 PM, Artem Smotrakov wrote: > > Hello, > > Please review two small patches for jdk and hotspot repos which add array bound checks to functions which return a length of bytecode instruction. > > Please see details in https://bugs.openjdk.java.net/browse/JDK-8152207 > > http://cr.openjdk.java.net/~asmotrak/8152207/jdk/webrev.00/ > http://cr.openjdk.java.net/~asmotrak/8152207/hotspot/webrev.00/ static bool is_defined (int code) { return 0 <= code && code < number_of_codes && flags(code, false) != 0; } + static int length_for (Code code) { return 0 <= code && code < number_of_codes ? _lengths[code] & 0xF : -1; } + static int wide_length_for(Code code) { return 0 <= code && code < number_of_codes ? _lengths[code] >> 4 : -1; } You should factor the bound check into a separate method. > > Artem From pbenedict at apache.org Mon May 9 20:26:09 2016 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 9 May 2016 15:26:09 -0500 Subject: outOfBoundsExceptionFormatter needs @since 9 Message-ID: As subject line says. It's not present in 9b116 Cheers, Paul From Roger.Riggs at Oracle.com Mon May 9 21:04:24 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 9 May 2016 17:04:24 -0400 Subject: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds In-Reply-To: <1F6EC53A-3913-48AC-81A9-4CC5B699DDB0@oracle.com> References: <29a10b5a-9a23-f839-8cf7-71fd8cc0a86c@Oracle.com> <1F6EC53A-3913-48AC-81A9-4CC5B699DDB0@oracle.com> Message-ID: <2a520081-bd5a-360f-b04a-31c5e63b4596@Oracle.com> Hi Brian, On 5/9/2016 4:11 PM, Brian Burkhalter wrote: > Hi Roger, > > Thanks for taking a close look at this. > > On May 9, 2016, at 12:42 PM, Roger Riggs > wrote: > >> In the @throws IndexOutOfBounds I think it is easier to understand to say >> >> * or {@code off + len} is greater than {@code cbuf.length} >> >> It matches the code more closely. > > The reason for the verbiage is that it matches (module removal of a > redundant ?or? in the throws verbiage) Reader.read(char[],int,int) > with which I thought it would good to be consistent in an > operation-symmetric sense: > > http://download.java.net/java/jdk9/docs/api/java/io/Reader.html#read-char:A-int-int- It better to propagate the best practices, not something that can be improved. Since you are updating the writing classes, I think it ok to put a lower priority on the Reader classes. > >> - Is not clear why the form of the added @throws is different between >> the methods (other than len = string.size() > > Writer.write(String,int,int) already had a throws exception for IOOBEs > so I was trying to be consistent with that: > > http://download.java.net/java/jdk9/docs/api/java/io/Writer.html#write-java.lang.String-int-int- I just think that {@code cbuf.length - off}, is not an intuitive way to talk about the out of range condition. The write(string, off, len) uses a better form and I think its more important that the methods in a class use the similar form. It is much more noticeable comparing two methods in a class than methods in different classes. (Fixing up Reader would be a different request). > >> line 214: add a spaces in "off+len" >> >> Most/All files have the same pattern. It would be nice to be consistent. > > Again, this is the same as in the extent Writer.write(String,int,int). This uses the form I think is more readable: 178 * or {@code off + len} is negative or greater than the length Thanks, Roger > > Thanks, > > Brian From brian.burkhalter at oracle.com Mon May 9 21:15:52 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 9 May 2016 14:15:52 -0700 Subject: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds In-Reply-To: <2a520081-bd5a-360f-b04a-31c5e63b4596@Oracle.com> References: <29a10b5a-9a23-f839-8cf7-71fd8cc0a86c@Oracle.com> <1F6EC53A-3913-48AC-81A9-4CC5B699DDB0@oracle.com> <2a520081-bd5a-360f-b04a-31c5e63b4596@Oracle.com> Message-ID: Hi Roger, So do you think that this form for example: (common prefix) * @throws IndexOutOfBoundsException * If {@code off} is negative, or {@code len} is negative, * or {@code off + len} is negative or greater than the length (array suffix) * of the given array (string suffix) * of the given string could be applied to both the array- and String-based write() variants? Thanks, Brian On May 9, 2016, at 2:04 PM, Roger Riggs wrote: >>> In the @throws IndexOutOfBounds I think it is easier to understand to say >>> >>> * or {@code off + len} is greater than {@code cbuf.length} >>> >>> It matches the code more closely. >> >> The reason for the verbiage is that it matches (module removal of a redundant ?or? in the throws verbiage) Reader.read(char[],int,int) with which I thought it would good to be consistent in an operation-symmetric sense: >> >> http://download.java.net/java/jdk9/docs/api/java/io/Reader.html#read-char:A-int-int- > > It better to propagate the best practices, not something that can be improved. > Since you are updating the writing classes, I think it ok to put a lower priority on the Reader classes. > >> >>> - Is not clear why the form of the added @throws is different between the methods (other than len = string.size() >> >> Writer.write(String,int,int) already had a throws exception for IOOBEs so I was trying to be consistent with that: >> >> http://download.java.net/java/jdk9/docs/api/java/io/Writer.html#write-java.lang.String-int-int- > > I just think that {@code cbuf.length - off}, is not an intuitive way to talk about the out of range condition. > > The write(string, off, len) uses a better form and I think its more important that the methods in a > class use the similar form. It is much more noticeable comparing two methods in a class > than methods in different classes. (Fixing up Reader would be a different request). > >> >>> line 214: add a spaces in "off+len" >>> >>> Most/All files have the same pattern. It would be nice to be consistent. >> >> Again, this is the same as in the extent Writer.write(String,int,int). > This uses the form I think is more readable: > 178 * or {@code off + len} is negative or greater than the length From roger.riggs at oracle.com Mon May 9 21:56:16 2016 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 9 May 2016 17:56:16 -0400 Subject: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds In-Reply-To: References: <29a10b5a-9a23-f839-8cf7-71fd8cc0a86c@Oracle.com> <1F6EC53A-3913-48AC-81A9-4CC5B699DDB0@oracle.com> <2a520081-bd5a-360f-b04a-31c5e63b4596@Oracle.com> Message-ID: <08424057-6035-0a08-2150-2eaaa013f8e4@oracle.com> Hi Brian, Yes, I think that works well. Roger On 5/9/16 5:15 PM, Brian Burkhalter wrote: > Hi Roger, > > So do you think that this form for example: > > (common prefix) > * @throws IndexOutOfBoundsException > * If {@code off} is negative, or {@code len} is negative, > * or {@code off + len} is negative or greater than the length > > (array suffix) > * of the given array > (string suffix) > * of the given string > could be applied to both the array- and String-based write() variants? > > Thanks, > > Brian > > On May 9, 2016, at 2:04 PM, Roger Riggs > wrote: > >>>> In the @throws IndexOutOfBounds I think it is easier to understand >>>> to say >>>> >>>> * or {@code off + len} is greater than {@code cbuf.length} >>>> >>>> It matches the code more closely. >>> >>> The reason for the verbiage is that it matches (module removal of a >>> redundant ?or? in the throws verbiage) Reader.read(char[],int,int) >>> with which I thought it would good to be consistent in an >>> operation-symmetric sense: >>> >>> http://download.java.net/java/jdk9/docs/api/java/io/Reader.html#read-char:A-int-int- >> >> It better to propagate the best practices, not something that can be >> improved. >> Since you are updating the writing classes, I think it ok to put a >> lower priority on the Reader classes. >> >>> >>>> - Is not clear why the form of the added @throws is different >>>> between the methods (other than len = string.size() >>> >>> Writer.write(String,int,int) already had a throws exception for >>> IOOBEs so I was trying to be consistent with that: >>> >>> http://download.java.net/java/jdk9/docs/api/java/io/Writer.html#write-java.lang.String-int-int- >> >> I just think that {@code cbuf.length - off}, is not an intuitive way >> to talk about the out of range condition. >> >> The write(string, off, len) uses a better form and I think its more >> important that the methods in a >> class use the similar form. It is much more noticeable comparing two >> methods in a class >> than methods in different classes. (Fixing up Reader would be a >> different request). >> >>> >>>> line 214: add a spaces in "off+len" >>>> >>>> Most/All files have the same pattern. It would be nice to be >>>> consistent. >>> >>> Again, this is the same as in the extent Writer.write(String,int,int). >> This uses the form I think is more readable: >> 178 * or {@code off + len} is negative or greater than the length > From huizhe.wang at oracle.com Mon May 9 21:59:39 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 09 May 2016 14:59:39 -0700 Subject: RFR (JAXP) 8152912: SAX XMLReaderFactory needs to be ServiceLoader compliant In-Reply-To: <712af5bd-7ba4-266a-c32e-afd35d8434b4@oracle.com> References: <57279CDE.7070207@oracle.com> <6ed137e8-2651-7f6f-50b9-143b00286355@oracle.com> <572940DB.10003@oracle.com> <712af5bd-7ba4-266a-c32e-afd35d8434b4@oracle.com> Message-ID: <5731084B.7040902@oracle.com> Thanks Daniel! On 5/9/2016 4:05 AM, Daniel Fuchs wrote: > Hi Joe, > > This looks much better to me. > I just wonder about the @Deprecated("5") vs @Deprecated("1.5") Yes, the compiler accepted it just fine and produced javadocs similar to that of XMLReaderFactory where since="9". Best, Joe > We started dropping the 1. for Java 5 - so I guess > @Deprecated("5") is OK. Hopefully Joe Darcy will be able > to confirm :-) > > best regards, > > -- daniel > > On 04/05/16 02:22, huizhe wang wrote: >> >> On 5/3/2016 3:36 AM, Daniel Fuchs wrote: >>> Hi Joe, >>> >>> This look good but the implementation might be overly complex, >>> which makes it difficult to read. >> >> It was basically the existing code with some cleanup. What's in >> jarLookup was a copy of the original code. As you can see I was eager to >> add ServiceLoader support and forget about it (deprecated) :-) >>> >>> First: >>> 141 ClassLoader cl = ss.getContextClassLoader(); >>> is misnamed, because as far as I can see this method returns >>> the context class loader if not null, otherwise the system >>> class loader. >> >> Make sense. That method was changed. I now renamed it to getClassLoader >> with javadoc. >>> >>> So cl is either the context class loader or the system class >>> loader and is guaranteed to be non null. >>> I would suggest adding a comment to make it clear. >>> >>> This means in turn that the new jarLookup(ClassLoader) >>> method can be greatly simplified - you can do: >>> final ClassLoader cl = Objects.requiresNonNull(loader); >>> and then simplify the if (cl != null) else ... logic, >>> because you now know that cl cannot be null. >> >> The cl-null checks in both jarLookup and findServiceProvider are >> removed. >> >> The new webrev also includes some cleanup of warnings, deprecation with >> javadocs (since Java SE 5) but without the annotation. I limited the >> patch to the sax package only. >> >> New webrev: >> http://cr.openjdk.java.net/~joehw/jdk9/8152912/webrev01/ >> >> Best, >> Joe >> >>> >>> Best regards, >>> >>> -- daniel >>> >>> >>> >>> On 02/05/16 20:30, huizhe wang wrote: >>>> Hi, >>>> >>>> Please review a change that adds a step using the ServiceLoader to >>>> XMLReaderFactory's provider-lookup process. Meanwhile, >>>> XMLReaderFactory >>>> is deprecated in favor of javax.xml.parsers.SAXParserFactory. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8152912 >>>> Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8152912/webrev/ >>>> >>>> The change has been verified by SQE test that Frank will submit >>>> soon for >>>> review (that is, when he starts to work at his local time). >>>> >>>> Thanks, >>>> Joe >>> >>> >> > From huizhe.wang at oracle.com Mon May 9 22:36:33 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 09 May 2016 15:36:33 -0700 Subject: RFR (JAXP) JDK-8156513: Problem list javax/xml/jaxp/unittest/stream/FactoryFindTest.java In-Reply-To: References: <57301CBA.3070404@oracle.com> Message-ID: <573110F1.6090004@oracle.com> I assume this is an intermittent failure. It looks like the newly added module tests were interfering with this test. -Joe On 5/9/2016 8:46 AM, Roger Riggs wrote: > Hi Amy, > > Looks fine to add to the problem list. > > It looks like that ProblemList.txt has not been converted to use the > new format with the bug number as the > second field. > > Roger > > > On 5/9/2016 1:14 AM, Amy Lu wrote: >> javax/xml/jaxp/unittest/stream/FactoryFindTest.java >> >> This jaxp test creates and may left over file under testing jdk >> (jdk/lib/stax.properties) and other tests being affected. (JDK-8156508) >> This patch is to add this test to ProblemList.txt until mentioned >> issue resolved. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8156513 >> webrev: http://cr.openjdk.java.net/~amlu/8156513/webrev.00/ >> >> Thanks, >> Amy >> >> >> --- old/test/ProblemList.txt 2016-05-09 13:04:09.000000000 +0800 >> +++ new/test/ProblemList.txt 2016-05-09 13:04:09.000000000 +0800 >> @@ -29,3 +29,5 @@ >> # 8150145 >> javax/xml/jaxp/unittest/common/TransformationWarningsTest.java >> generic-all >> >> +# 8156508 >> +javax/xml/jaxp/unittest/stream/FactoryFindTest.java generic-all >> >> > From brian.burkhalter at oracle.com Mon May 9 23:29:52 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 9 May 2016 16:29:52 -0700 Subject: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds In-Reply-To: <08424057-6035-0a08-2150-2eaaa013f8e4@oracle.com> References: <29a10b5a-9a23-f839-8cf7-71fd8cc0a86c@Oracle.com> <1F6EC53A-3913-48AC-81A9-4CC5B699DDB0@oracle.com> <2a520081-bd5a-360f-b04a-31c5e63b4596@Oracle.com> <08424057-6035-0a08-2150-2eaaa013f8e4@oracle.com> Message-ID: <04DA3578-E41F-41F7-84DC-B9BBB410281F@oracle.com> Hi Roger, So modified: http://cr.openjdk.java.net/~bpb/8130679/webrev.01/ Thanks, Brian On May 9, 2016, at 2:56 PM, Roger Riggs wrote: > Yes, I think that works well. > > On 5/9/16 5:15 PM, Brian Burkhalter wrote: >> >> So do you think that this form for example: >> >> (common prefix) >> * @throws IndexOutOfBoundsException >> * If {@code off} is negative, or {@code len} is negative, >> * or {@code off + len} is negative or greater than the length From amy.lu at oracle.com Tue May 10 02:03:16 2016 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 10 May 2016 10:03:16 +0800 Subject: RFR (JAXP) JDK-8156513: Problem list javax/xml/jaxp/unittest/stream/FactoryFindTest.java In-Reply-To: References: <57301CBA.3070404@oracle.com> Message-ID: <57314164.8040203@oracle.com> On 5/9/16 11:46 PM, Roger Riggs wrote: > Hi Amy, > > Looks fine to add to the problem list. > > It looks like that ProblemList.txt has not been converted to use the > new format with the bug number as the > second field. Yes, noticed. I created RFE JDK-8156598 to track the format change. Thank you for reviewing. Thanks, Amy > > Roger > > > On 5/9/2016 1:14 AM, Amy Lu wrote: >> javax/xml/jaxp/unittest/stream/FactoryFindTest.java >> >> This jaxp test creates and may left over file under testing jdk >> (jdk/lib/stax.properties) and other tests being affected. (JDK-8156508) >> This patch is to add this test to ProblemList.txt until mentioned >> issue resolved. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8156513 >> webrev: http://cr.openjdk.java.net/~amlu/8156513/webrev.00/ >> >> Thanks, >> Amy >> >> >> --- old/test/ProblemList.txt 2016-05-09 13:04:09.000000000 +0800 >> +++ new/test/ProblemList.txt 2016-05-09 13:04:09.000000000 +0800 >> @@ -29,3 +29,5 @@ >> # 8150145 >> javax/xml/jaxp/unittest/common/TransformationWarningsTest.java >> generic-all >> >> +# 8156508 >> +javax/xml/jaxp/unittest/stream/FactoryFindTest.java generic-all >> >> > From amy.lu at oracle.com Tue May 10 02:16:10 2016 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 10 May 2016 10:16:10 +0800 Subject: RFR (JAXP) JDK-8156513: Problem list javax/xml/jaxp/unittest/stream/FactoryFindTest.java In-Reply-To: <573110F1.6090004@oracle.com> References: <57301CBA.3070404@oracle.com> <573110F1.6090004@oracle.com> Message-ID: <5731446A.8070505@oracle.com> On 5/10/16 6:36 AM, huizhe wang wrote: > I assume this is an intermittent failure. It looks like the newly > added module tests were interfering with this test. Hi, Joe If jdk/lib/stax.properties exist (created by FactoryFindTest.java), BasicModularXMLParserTest.java and LayerModularXMLParserTest.java will fail (reproducible). FactoryFindTest.java changes the "jdk" under testing, this is in question. If it have to do that, maybe could do change on a copy and testing the copied jdk. Or, at least, it should make sure to clean up the change. Thanks, Amy > > -Joe > > On 5/9/2016 8:46 AM, Roger Riggs wrote: >> Hi Amy, >> >> Looks fine to add to the problem list. >> >> It looks like that ProblemList.txt has not been converted to use the >> new format with the bug number as the >> second field. >> >> Roger >> >> >> On 5/9/2016 1:14 AM, Amy Lu wrote: >>> javax/xml/jaxp/unittest/stream/FactoryFindTest.java >>> >>> This jaxp test creates and may left over file under testing jdk >>> (jdk/lib/stax.properties) and other tests being affected. (JDK-8156508) >>> This patch is to add this test to ProblemList.txt until mentioned >>> issue resolved. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8156513 >>> webrev: http://cr.openjdk.java.net/~amlu/8156513/webrev.00/ >>> >>> Thanks, >>> Amy >>> >>> >>> --- old/test/ProblemList.txt 2016-05-09 13:04:09.000000000 +0800 >>> +++ new/test/ProblemList.txt 2016-05-09 13:04:09.000000000 +0800 >>> @@ -29,3 +29,5 @@ >>> # 8150145 >>> javax/xml/jaxp/unittest/common/TransformationWarningsTest.java >>> generic-all >>> >>> +# 8156508 >>> +javax/xml/jaxp/unittest/stream/FactoryFindTest.java generic-all >>> >>> >> > From huizhe.wang at oracle.com Tue May 10 04:31:11 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 09 May 2016 21:31:11 -0700 Subject: RFR (JAXP) JDK-8156513: Problem list javax/xml/jaxp/unittest/stream/FactoryFindTest.java In-Reply-To: <5731446A.8070505@oracle.com> References: <57301CBA.3070404@oracle.com> <573110F1.6090004@oracle.com> <5731446A.8070505@oracle.com> Message-ID: <5731640F.1040604@oracle.com> On 5/9/2016 7:16 PM, Amy Lu wrote: > On 5/10/16 6:36 AM, huizhe wang wrote: >> I assume this is an intermittent failure. It looks like the newly >> added module tests were interfering with this test. > Hi, Joe > > If jdk/lib/stax.properties exist (created by FactoryFindTest.java), > BasicModularXMLParserTest.java and LayerModularXMLParserTest.java will > fail (reproducible). > > FactoryFindTest.java changes the "jdk" under testing, this is in > question. If it have to do that, maybe could do change on a copy and > testing the copied jdk. Or, at least, it should make sure to clean up > the change. FactoryFindTest wasn't thread safe. It was fine / it would have removed the properties file before the module tests were added. I haven't observed such failures locally, or in JPRT testing, that's why I was saying this is intermittent. I suspect the module tests were trying to read the file, which prevented FactoryFindTest from deleting it. You may modify FactoryFindTest so that it runs in an isolated JDK, unfortunately, that had issue as well (JDK-8147431). The other option is to disable the particular test case within FactoryFindTest that generated the file and leave it to the JCK. Thanks, Joe > > Thanks, > Amy > >> >> -Joe >> >> On 5/9/2016 8:46 AM, Roger Riggs wrote: >>> Hi Amy, >>> >>> Looks fine to add to the problem list. >>> >>> It looks like that ProblemList.txt has not been converted to use the >>> new format with the bug number as the >>> second field. >>> >>> Roger >>> >>> >>> On 5/9/2016 1:14 AM, Amy Lu wrote: >>>> javax/xml/jaxp/unittest/stream/FactoryFindTest.java >>>> >>>> This jaxp test creates and may left over file under testing jdk >>>> (jdk/lib/stax.properties) and other tests being affected. >>>> (JDK-8156508) >>>> This patch is to add this test to ProblemList.txt until mentioned >>>> issue resolved. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8156513 >>>> webrev: http://cr.openjdk.java.net/~amlu/8156513/webrev.00/ >>>> >>>> Thanks, >>>> Amy >>>> >>>> >>>> --- old/test/ProblemList.txt 2016-05-09 13:04:09.000000000 +0800 >>>> +++ new/test/ProblemList.txt 2016-05-09 13:04:09.000000000 +0800 >>>> @@ -29,3 +29,5 @@ >>>> # 8150145 >>>> javax/xml/jaxp/unittest/common/TransformationWarningsTest.java >>>> generic-all >>>> >>>> +# 8156508 >>>> +javax/xml/jaxp/unittest/stream/FactoryFindTest.java generic-all >>>> >>>> >>> >> > From amy.lu at oracle.com Tue May 10 04:49:03 2016 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 10 May 2016 12:49:03 +0800 Subject: RFR (JAXP) JDK-8156513: Problem list javax/xml/jaxp/unittest/stream/FactoryFindTest.java In-Reply-To: <5731640F.1040604@oracle.com> References: <57301CBA.3070404@oracle.com> <573110F1.6090004@oracle.com> <5731446A.8070505@oracle.com> <5731640F.1040604@oracle.com> Message-ID: <5731683F.8030203@oracle.com> On 5/10/16 12:31 PM, huizhe wang wrote: > On 5/9/2016 7:16 PM, Amy Lu wrote: >> On 5/10/16 6:36 AM, huizhe wang wrote: >>> I assume this is an intermittent failure. It looks like the newly >>> added module tests were interfering with this test. >> Hi, Joe >> >> If jdk/lib/stax.properties exist (created by FactoryFindTest.java), >> BasicModularXMLParserTest.java and LayerModularXMLParserTest.java >> will fail (reproducible). >> >> FactoryFindTest.java changes the "jdk" under testing, this is in >> question. If it have to do that, maybe could do change on a copy and >> testing the copied jdk. Or, at least, it should make sure to clean up >> the change. > > FactoryFindTest wasn't thread safe. It was fine / it would have > removed the properties file before the module tests were added. I > haven't observed such failures locally, or in JPRT testing, that's why > I was saying this is intermittent. I suspect the module tests were > trying to read the file, which prevented FactoryFindTest from deleting it. > > You may modify FactoryFindTest so that it runs in an isolated JDK, > unfortunately, that had issue as well (JDK-8147431). The other option > is to disable the particular test case within FactoryFindTest that > generated the file and leave it to the JCK. > > Thanks, > Joe Thank you Joe! I added this to JDK-8156508 comment as suggestion on the fix. Thanks, Amy From paul.sandoz at oracle.com Tue May 10 05:16:04 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 10 May 2016 07:16:04 +0200 Subject: outOfBoundsExceptionFormatter needs @since 9 In-Reply-To: References: Message-ID: <83ADF963-0D06-4E9D-8BFC-C9B25D987DEF@oracle.com> > On 9 May 2016, at 22:26, Paul Benedict wrote: > > As subject line says. It's not present in 9b116 > It was recently moved to an internal package: http://hg.openjdk.java.net/jdk9/hs/jdk/file/tip/src/java.base/share/classes/jdk/internal/util/Preconditions.java making it?s way to jdk9/dev via jdk9/hs-comp due to renaming of intrinsic methods. Paul. From xueming.shen at oracle.com Tue May 10 05:36:29 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 9 May 2016 22:36:29 -0700 Subject: RFR: regex changes -- sun.security.util.Debug issue In-Reply-To: <56EC5F76.4080106@oracle.com> References: <56EC5F76.4080106@oracle.com> Message-ID: <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> Hi, While testing for the attached regex changes, a fatal vm init error was triggered for test case with -Djava.security.debug=xyz turned on, as showed in following stacktrace. It appears sun.security.util.Debug is being initialized even before the lambda is ready for use, and unfortunately it uses j.u.regex (for its args parsing), which is being migrated to use lambda function in the proposed regex change. Since Debug is the only class now triggers j.u.regex -> lambda during initialization, it is suggested to update/rewrite the related method in Debug to NOT use j.u.regex to solve/workaround this specific initialization issue. The webrev below has been updated to include such a change. http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ The sun.security.util.Debug related change is at http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/src/java.base/share/classes/sun/security/util/Debug.java.sdiff.html Can security-dev guys help take a look if this is an acceptable/reasonable approach. Thanks, Sherman ----------------------------------------------------------------------------- Caused by: java.lang.ExceptionInInitializerError at jdk.internal.loader.BootLoader.loadClassOrNull(java.base/BootLoader.java:110) at java.lang.invoke.BoundMethodHandle$Factory$1.apply(java.base/BoundMethodHandle.java:497) at java.lang.invoke.BoundMethodHandle$Factory$1.apply(java.base/BoundMethodHandle.java:492) ... at java.lang.invoke.MethodHandleNatives.linkCallSite(java.base/MethodHandleNatives.java:240) at java.util.regex.Pattern.(java.base/Pattern.java:5682) at sun.security.util.Debug.marshal(java.base/Debug.java:247) at sun.security.util.Debug.(java.base/Debug.java:59) at java.security.ProtectionDomain.(java.base/ProtectionDomain.java:142) at jdk.internal.misc.InnocuousThread.(java.base/InnocuousThread.java:129) at jdk.internal.ref.CleanerFactory$1$1.run(java.base/CleanerFactory.java:48) at jdk.internal.ref.CleanerFactory$1$1.run(java.base/CleanerFactory.java:45) at java.security.AccessController.doPrivileged(java.base/Native Method) at jdk.internal.ref.CleanerFactory$1.newThread(java.base/CleanerFactory.java:45) at jdk.internal.ref.CleanerImpl.start(java.base/CleanerImpl.java:116) at java.lang.ref.Cleaner.create(java.base/Cleaner.java:203) at jdk.internal.ref.CleanerFactory.(java.base/CleanerFactory.java:42) at sun.nio.fs.NativeBuffer.(java.base/NativeBuffer.java:60) at sun.nio.fs.NativeBuffers.allocNativeBuffer(java.base/NativeBuffers.java:49) at sun.nio.fs.UnixNativeDispatcher.copyToNativeBuffer(java.base/UnixNativeDispatcher.java:44) at sun.nio.fs.UnixNativeDispatcher.stat(java.base/UnixNativeDispatcher.java:306) at sun.nio.fs.UnixFileSystemProvider.isRegularFile(java.base/UnixFileSystemProvider.java:514) at java.nio.file.Files.isRegularFile(java.base/Files.java:2244) at java.lang.module.ModuleFinder.ofSystem(java.base/ModuleFinder.java:165) at jdk.internal.module.ModuleBootstrap.boot(java.base/ModuleBootstrap.java:105) at java.lang.System.initPhase2(java.base/System.java:1924) --------------------------------------------------------------------------------- On 3/18/16 1:05 PM, Xueming Shen wrote: > Hi, > > There are couple regex related changes waiting for review. I have pull > them > together here (with the notes) to make it easy to review. > > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ > > (1) Exponential backtracking > > Note: > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/backtracking > > https://bugs.openjdk.java.net/browse/JDK-6328855 > https://bugs.openjdk.java.net/browse/JDK-6192895 > https://bugs.openjdk.java.net/browse/JDK-6345469 > https://bugs.openjdk.java.net/browse/JDK-6988218 > https://bugs.openjdk.java.net/browse/JDK-6693451 > https://bugs.openjdk.java.net/browse/JDK-7006761 > https://bugs.openjdk.java.net/browse/JDK-8140212 > > (2) Anonymous class to lambda function cleanup > > Note: > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/lambdafunction > > https://bugs.openjdk.java.net/browse/JDK-8151481 > https://bugs.openjdk.java.net/browse/JDK-6609854 > > (3) Canonical Equivalents > > Note: > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/canonEQ > > https://bugs.openjdk.java.net/browse/JDK-4916384 > https://bugs.openjdk.java.net/browse/JDK-4867170 > https://bugs.openjdk.java.net/browse/JDK-6995635 > https://bugs.openjdk.java.net/browse/JDK-6728861 > https://bugs.openjdk.java.net/browse/JDK-6736245 > https://bugs.openjdk.java.net/browse/JDK-7080302 > > Thanks > Sherman From weijun.wang at oracle.com Tue May 10 06:33:45 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 10 May 2016 14:33:45 +0800 Subject: RFR: regex changes -- sun.security.util.Debug issue In-Reply-To: <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> References: <56EC5F76.4080106@oracle.com> <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> Message-ID: <58DED32A-5F2B-4DA2-ABFD-523049922EDE@oracle.com> Security-dev, If we can live with "engine=keystore" happily, why not just make the whole string lowercase and search for "permission=java.io.filepermission"? I don't think there are permission types or URL names that are only different in cases. Although file names are case-sensitive in Unix, I doubt if any customer will complain if we show him info on /ETC even if what he sets is "codebase=/etc". We can add new methods like hasCodebase(URL) and hasPermission(Class) to hide the search details inside Debug. Thanks Max > On May 10, 2016, at 1:36 PM, Xueming Shen wrote: > > Hi, > > While testing for the attached regex changes, a fatal vm init error was triggered for test > case with -Djava.security.debug=xyz turned on, as showed in following stacktrace. > > It appears sun.security.util.Debug is being initialized even before the lambda is ready > for use, and unfortunately it uses j.u.regex (for its args parsing), which is being migrated > to use lambda function in the proposed regex change. > > Since Debug is the only class now triggers j.u.regex -> lambda during initialization, it > is suggested to update/rewrite the related method in Debug to NOT use j.u.regex to > solve/workaround this specific initialization issue. > > The webrev below has been updated to include such a change. > > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ > > The sun.security.util.Debug related change is at > > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/src/java.base/share/classes/sun/security/util/Debug.java.sdiff.html > > Can security-dev guys help take a look if this is an acceptable/reasonable approach. > > Thanks, > Sherman > > ----------------------------------------------------------------------------- > Caused by: java.lang.ExceptionInInitializerError > > > at jdk.internal.loader.BootLoader.loadClassOrNull(java.base/BootLoader.java:110) > at java.lang.invoke.BoundMethodHandle$Factory$1.apply(java.base/BoundMethodHandle.java:497) > at java.lang.invoke.BoundMethodHandle$Factory$1.apply(java.base/BoundMethodHandle.java:492) > ... > at java.lang.invoke.MethodHandleNatives.linkCallSite(java.base/MethodHandleNatives.java:240) > at java.util.regex.Pattern.(java.base/Pattern.java:5682) > at sun.security.util.Debug.marshal(java.base/Debug.java:247) > at sun.security.util.Debug.(java.base/Debug.java:59) > at java.security.ProtectionDomain.(java.base/ProtectionDomain.java:142) > at jdk.internal.misc.InnocuousThread.(java.base/InnocuousThread.java:129) > at jdk.internal.ref.CleanerFactory$1$1.run(java.base/CleanerFactory.java:48) > at jdk.internal.ref.CleanerFactory$1$1.run(java.base/CleanerFactory.java:45) > at java.security.AccessController.doPrivileged(java.base/Native Method) > at jdk.internal.ref.CleanerFactory$1.newThread(java.base/CleanerFactory.java:45) > at jdk.internal.ref.CleanerImpl.start(java.base/CleanerImpl.java:116) > at java.lang.ref.Cleaner.create(java.base/Cleaner.java:203) > at jdk.internal.ref.CleanerFactory.(java.base/CleanerFactory.java:42) > at sun.nio.fs.NativeBuffer.(java.base/NativeBuffer.java:60) > at sun.nio.fs.NativeBuffers.allocNativeBuffer(java.base/NativeBuffers.java:49) > at sun.nio.fs.UnixNativeDispatcher.copyToNativeBuffer(java.base/UnixNativeDispatcher.java:44) > at sun.nio.fs.UnixNativeDispatcher.stat(java.base/UnixNativeDispatcher.java:306) > at sun.nio.fs.UnixFileSystemProvider.isRegularFile(java.base/UnixFileSystemProvider.java:514) > at java.nio.file.Files.isRegularFile(java.base/Files.java:2244) > at java.lang.module.ModuleFinder.ofSystem(java.base/ModuleFinder.java:165) > at jdk.internal.module.ModuleBootstrap.boot(java.base/ModuleBootstrap.java:105) > at java.lang.System.initPhase2(java.base/System.java:1924) > > --------------------------------------------------------------------------------- > > > On 3/18/16 1:05 PM, Xueming Shen wrote: >> Hi, >> >> There are couple regex related changes waiting for review. I have pull them >> together here (with the notes) to make it easy to review. >> >> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ >> >> (1) Exponential backtracking >> >> Note: http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/backtracking >> >> https://bugs.openjdk.java.net/browse/JDK-6328855 >> https://bugs.openjdk.java.net/browse/JDK-6192895 >> https://bugs.openjdk.java.net/browse/JDK-6345469 >> https://bugs.openjdk.java.net/browse/JDK-6988218 >> https://bugs.openjdk.java.net/browse/JDK-6693451 >> https://bugs.openjdk.java.net/browse/JDK-7006761 >> https://bugs.openjdk.java.net/browse/JDK-8140212 >> >> (2) Anonymous class to lambda function cleanup >> >> Note: http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/lambdafunction >> >> https://bugs.openjdk.java.net/browse/JDK-8151481 >> https://bugs.openjdk.java.net/browse/JDK-6609854 >> >> (3) Canonical Equivalents >> >> Note: http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/canonEQ >> >> https://bugs.openjdk.java.net/browse/JDK-4916384 >> https://bugs.openjdk.java.net/browse/JDK-4867170 >> https://bugs.openjdk.java.net/browse/JDK-6995635 >> https://bugs.openjdk.java.net/browse/JDK-6728861 >> https://bugs.openjdk.java.net/browse/JDK-6736245 >> https://bugs.openjdk.java.net/browse/JDK-7080302 >> >> Thanks >> Sherman > From Sunny.Chan at gs.com Tue May 10 07:13:27 2016 From: Sunny.Chan at gs.com (Chan, Sunny) Date: Tue, 10 May 2016 07:13:27 +0000 Subject: Proposed patch: further wrapping of FileInputStream's native method In-Reply-To: <57308FFD.3000700@oracle.com> References: <364f2cd3c8c3406abe014f056b4a1d35@gsdghkp03etn1.firmwide.corp.gs.com> <57308FFD.3000700@oracle.com> Message-ID: <1d41bbda269d44729cf01fbafda4b821@gsdghkp03etn1.firmwide.corp.gs.com> The available() and sync() are the only native methods in the FileInputStream that has not been "wrapped". Our use case is that we have an internal storage implementation and we would like to be able to provide support for older applications that use java.io api without modify the apps to use our NIO.2 Filesystem implementation. Without these method wrapped it is difficult to instrument them and redirect calls as needed. A longer term goal is to investigate and see whether we can find a way to divert all the old java.io APIs to an NIO.2 filesystem implementation. However this is more complex and will involve a much bigger change and we will propose a JEP once we are confident that can be done. -----Original Message----- From: Chris Hegarty [mailto:chris.hegarty at oracle.com] Sent: 09 May 2016 21:26 To: Chan, Sunny [Tech]; 'core-libs-dev at openjdk.java.net'; Brian Burkhalter Subject: Re: Proposed patch: further wrapping of FileInputStream's native method The changes in your patch look ok. It is not clear, at least to me, why these methods are all that interesting, or even why they were not covered by 8054720. Maybe Brian Burkhalter, or others may know. -Chris. On 09/05/16 04:27, Chan, Sunny wrote: > Previously in JDK-8054720, a number of native methods has been wrapped in order to allow instrumentation. We would like to propose to wrap a number of other methods (available(), skip()) so that we can perform further instrumentation. > > I have attached the patch with this email for review. > > 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 din.com_company_goldman-2Dsachs_careers&d=CwIC-g&c=7563p3e2zaQw0AB1wrF > Vgyagb2IE5rTZOYPxLxfZlX4&r=e-nMYEAYoRWWms8SM-H97SgyQYsz-xaiLmQPYwZ3m5E > &m=G8UmhcMufoGaZD0iiU4Hf4QJHS9mwZVT4AdR3_fPJag&s=ZALJij0E_VXVArh5_UUN6 > KaxOgRAfwJt3c6knN9VhiQ&e= > | > YouTube e.com_goldmansachs&d=CwIC-g&c=7563p3e2zaQw0AB1wrFVgyagb2IE5rTZOYPxLxfZ > lX4&r=e-nMYEAYoRWWms8SM-H97SgyQYsz-xaiLmQPYwZ3m5E&m=G8UmhcMufoGaZD0iiU > 4Hf4QJHS9mwZVT4AdR3_fPJag&s=STP6W4Xg7OT1W0Xe6KAMXiiDbB99x1bY5FD9sltWA9 > w&e= > | > Twitter r.com_goldmansachs&d=CwIC-g&c=7563p3e2zaQw0AB1wrFVgyagb2IE5rTZOYPxLxfZ > lX4&r=e-nMYEAYoRWWms8SM-H97SgyQYsz-xaiLmQPYwZ3m5E&m=G8UmhcMufoGaZD0iiU > 4Hf4QJHS9mwZVT4AdR3_fPJag&s=s3sqRhvYPmAYbqdkOYZuyv72FdMWlWTcLMTioPkF1j > c&e= > > > 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 bhanu.prakash.gopularam at oracle.com Tue May 10 07:56:36 2016 From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam) Date: Tue, 10 May 2016 00:56:36 -0700 (PDT) Subject: RFR 8062804: IsoFields WEEK_BASED_YEAR and QUARTER_OF_YEAR too lenient Message-ID: <805cd535-929f-4687-bbe0-d19516d3737c@default> Hi all, Please review fix following issue Bug Id : https://bugs.openjdk.java.net/browse/JDK-8062804 Solution: Added check for unsupported fields in IsoFields rangeRefinedBy methods Webrev : http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8062804/webrev.00 Thanks, Bhanu From Alan.Bateman at oracle.com Tue May 10 08:30:04 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 May 2016 09:30:04 +0100 Subject: RFR: regex changes -- sun.security.util.Debug issue In-Reply-To: <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> References: <56EC5F76.4080106@oracle.com> <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> Message-ID: <57319C0C.8070702@oracle.com> On 10/05/2016 06:36, Xueming Shen wrote: > Hi, > > While testing for the attached regex changes, a fatal vm init error > was triggered for test > case with -Djava.security.debug=xyz turned on, as showed in following > stacktrace. > > It appears sun.security.util.Debug is being initialized even before > the lambda is ready > for use, and unfortunately it uses j.u.regex (for its args parsing), > which is being migrated > to use lambda function in the proposed regex change. > > Since Debug is the only class now triggers j.u.regex -> lambda during > initialization, it > is suggested to update/rewrite the related method in Debug to NOT use > j.u.regex to > solve/workaround this specific initialization issue. This is always tricky but I wonder how far we could get by initializing ProtectionDomain.debug and SecureClassLoader.debug lazily. That is, move them to a holder class where I wouldn't expect they will be initialized until much later, esp. as the security manager won't be set until later in the initialization (or init phase 3 as we've come to name it). -Alan From Alan.Bateman at oracle.com Tue May 10 08:43:45 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 May 2016 09:43:45 +0100 Subject: Proposed patch: further wrapping of FileInputStream's native method In-Reply-To: <1d41bbda269d44729cf01fbafda4b821@gsdghkp03etn1.firmwide.corp.gs.com> References: <364f2cd3c8c3406abe014f056b4a1d35@gsdghkp03etn1.firmwide.corp.gs.com> <57308FFD.3000700@oracle.com> <1d41bbda269d44729cf01fbafda4b821@gsdghkp03etn1.firmwide.corp.gs.com> Message-ID: <57319F41.5080306@oracle.com> On 10/05/2016 08:13, Chan, Sunny wrote: > The available() and sync() are the only native methods in the FileInputStream that has not been "wrapped". > > Our use case is that we have an internal storage implementation and we would like to be able to provide support for older applications that use java.io api without modify the apps to use our NIO.2 Filesystem implementation. Without these method wrapped it is difficult to instrument them and redirect calls as needed. > > A longer term goal is to investigate and see whether we can find a way to divert all the old java.io APIs to an NIO.2 filesystem implementation. However this is more complex and will involve a much bigger change and we will propose a JEP once we are confident that can be done. > Just an FYI that back in JDK 7 then we had an initial prototype implementation of java.io.File/FIS/FOS/RAF that was based on the new file system API. As I recall, the concerns/issues at the time were: 1. Compatibility, esp. Windows, where the new API/implementation does the right thing and so results in changes in behavior. 2. Startup as the new API/implementation requires loading additional classes at startup. In JDK 9 then the jimage container and the module system use the new API and so we are loading them anywhere so this issue may have gone away. 3. FIS/FOS ctors/getFD which won't have an equivalent or it specific to the default provider. It would definitely be interesting to have another go at this. -Alan From chris.hegarty at oracle.com Tue May 10 08:50:42 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 10 May 2016 09:50:42 +0100 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <1d3d6b24-5168-cc5c-942b-2bbda7f2d257@redhat.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> <13C89E01-3396-4EFE-BC35-C289E59DBEED@oracle.com> <5707CFBB.8020809@oracle.com> <5028AF86-C8DD-431E-8499-0022B8D90C85@oracle.com> <1d3d6b24-5168-cc5c-942b-2bbda7f2d257@redhat.com> Message-ID: On 9 May 2016, at 20:43, Richard Opalka wrote: > Fixed in JBoss Marshalling upstream. Thanks for fixing this, and getting back to us on the list. I assume then that, at least, this part of JBoss is working on JDK 9 b115, right? -Chris. > Thanks, > > Rio > > On 04/27/2016 11:54 PM, Chris Hegarty wrote: >> Hi Rio, >> >> >>> We are missing sun/reflect/ReflectionFactory$GetReflectionFactoryAction inner class >>> >>> in jdk.unsupported module: >>> >>> java.lang.NoClassDefFoundError: sun/reflect/ReflectionFactory$GetReflectionFactoryAction >>> at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base at 9-internal/BuiltinClassLoader.java:366) >>> at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base at 9-internal/ClassLoaders.java:184) >>> at java.lang.ClassLoader.loadClass(java.base at 9-internal/ClassLoader.java:419) >>> at org.jboss.marshalling.reflect.SerializableClass.(SerializableClass.java:47) >> GetReflectionFactoryAction is a convenience class for acquiring >> the capability to instantiate reflective objects. >> >> As part of JEP 260, we retained the single getReflectionFactory >> accessor. You can replace your usage with the following: >> >> PrivilegedAction pa = new PrivilegedAction() { >> @Override >> public ReflectionFactory run() { >> return ReflectionFactory.getReflectionFactory(); >> } >> }; >> >> -Chris. >> > From chris.hegarty at oracle.com Tue May 10 09:36:06 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 10 May 2016 10:36:06 +0100 Subject: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds In-Reply-To: <04DA3578-E41F-41F7-84DC-B9BBB410281F@oracle.com> References: <29a10b5a-9a23-f839-8cf7-71fd8cc0a86c@Oracle.com> <1F6EC53A-3913-48AC-81A9-4CC5B699DDB0@oracle.com> <2a520081-bd5a-360f-b04a-31c5e63b4596@Oracle.com> <08424057-6035-0a08-2150-2eaaa013f8e4@oracle.com> <04DA3578-E41F-41F7-84DC-B9BBB410281F@oracle.com> Message-ID: On 10 May 2016, at 00:29, Brian Burkhalter wrote: > Hi Roger, > > So modified: > > http://cr.openjdk.java.net/~bpb/8130679/webrev.01/ This looks good to me. I have to admit that I reviewed the current wording in Reader.read, but on reflection it would be better to update it to reflect this wording. But that is a separate, lower priority, issue. -Chris. > Thanks, > > Brian > > On May 9, 2016, at 2:56 PM, Roger Riggs wrote: >> Yes, I think that works well. >> >> On 5/9/16 5:15 PM, Brian Burkhalter wrote: >>> >>> So do you think that this form for example: >>> >>> (common prefix) >>> * @throws IndexOutOfBoundsException >>> * If {@code off} is negative, or {@code len} is negative, >>> * or {@code off + len} is negative or greater than the length > From christoph.langer at sap.com Tue May 10 09:48:36 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 10 May 2016 09:48:36 +0000 Subject: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c Message-ID: Hi all, can I please get a review for a change to NetworkInterface.c bugreport: https://bugs.openjdk.java.net/browse/JDK-8156521 webrev: http://cr.openjdk.java.net/~clanger/webrevs/8156521.0/ Apart from quite a few whitespace changes to clean up the coding, I went through and replaced all occurences of strcpy with strncpy as this was a finding of a code scanner that we used. Also in function "enumIPv6Interfaces" for Linux the local variable plen was changed from int to short. I ran builds on Linux, AIX, Solaris Sparc and Darwin to make sure nothing broke. Thanks in advance Christoph From scolebourne at joda.org Tue May 10 10:38:37 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 10 May 2016 11:38:37 +0100 Subject: RFR 8062804: IsoFields WEEK_BASED_YEAR and QUARTER_OF_YEAR too lenient In-Reply-To: <805cd535-929f-4687-bbe0-d19516d3737c@default> References: <805cd535-929f-4687-bbe0-d19516d3737c@default> Message-ID: Looks great thanks Stephen On 10 May 2016 at 08:56, Bhanu Gopularam wrote: > Hi all, > > Please review fix following issue > > Bug Id : https://bugs.openjdk.java.net/browse/JDK-8062804 > > Solution: Added check for unsupported fields in IsoFields rangeRefinedBy methods > > Webrev : http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8062804/webrev.00 > > Thanks, > Bhanu > > > > From claes.redestad at oracle.com Tue May 10 11:18:59 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 10 May 2016 13:18:59 +0200 Subject: RFR: 8155795: Optimize Integer/Long.reverse by using reverseBytes In-Reply-To: References: <57275F3E.6000709@oracle.com> <572768A4.6010105@oracle.com> <57276B7E.80006@oracle.com> Message-ID: <5731C3A3.50605@oracle.com> Hi, I think this shows the compiler isn't doing anything really strange; it'd be fun to know if it's the different instruction order or the use of one less constant that shows an effect, but it's not really significant either way. I think the latest patch is fine as it is and will push it soon. Thanks! /Claes On 2016-05-09 21:50, Jaroslav Kamen?k wrote: > Hi guys, > > I have looked at generated asm, it does not seem there is problem, > only little different order > of shifts and ands.. Plus, at haswell, times do not differ so much. > Here are different parts: > > Slower version: > > 057 sall R10, #24 > 05b movl R11, RAX # spill > 05e sall R11, #8 > 062 movl R8, RAX # spill > 065 shrl R8, #8 > 069 andl R11, #16711680 # int > 070 andl R8, #65280 # int > 077 shrl RAX, #24 > > Faster version: > > 057 shrl R10, #24 > 05b movl R11, RAX # spill > 05e shrl R11, #8 > 062 movl R8, RAX # spill > 065 andl R8, #65280 # int > 06c andl R11, #65280 # int > 073 sall R8, #8 > 077 sall RAX, #24 > > Full code: > > ORIGINAL - 5,169 ? 0,377 ns/op > =============================== > > 000 B1: # N1 <- BLOCK HEAD IS JUNK Freq: 1 > 000 # stack bang (96 bytes) > pushq rbp # Save rbp > subq rsp, #16 # Create frame > > 00c movl RAX, RSI # spill > 00e andl RAX, #1431655765 # int > 014 shrl RSI, #1 > 016 sall RAX, #1 > 018 andl RSI, #1431655765 # int > 01e orl RAX, RSI # int > 020 movl R10, RAX # spill > 023 shrl R10, #2 > 027 andl RAX, #858993459 # int > 02d andl R10, #858993459 # int > 034 sall RAX, #2 > 037 orl RAX, R10 # int > 03a movl R10, RAX # spill > 03d shrl R10, #4 > 041 andl RAX, #252645135 # int > 047 andl R10, #252645135 # int > 04e sall RAX, #4 > 051 orl RAX, R10 # int > 054 movl R10, RAX # spill > 057 shrl R10, #24 > 05b movl R11, RAX # spill > 05e shrl R11, #8 > 062 movl R8, RAX # spill > 065 andl R8, #65280 # int > 06c andl R11, #65280 # int > 073 sall R8, #8 > 077 sall RAX, #24 > 07a orl RAX, R8 # int > 07d orl RAX, R11 # int > 080 orl RAX, R10 # int > 083 addq rsp, 16 # Destroy frame > > > USED INTRINSIC - 4,093 ? 0,100 ns/op > ===================================== > > 000 B1: # N1 <- BLOCK HEAD IS JUNK Freq: 1 > 000 # stack bang (96 bytes) > pushq rbp # Save rbp > subq rsp, #16 # Create frame > > 00c movl RAX, RSI # spill > 00e andl RAX, #1431655765 # int > 014 shrl RSI, #1 > 016 sall RAX, #1 > 018 andl RSI, #1431655765 # int > 01e orl RAX, RSI # int > 020 movl R10, RAX # spill > 023 shrl R10, #2 > 027 andl RAX, #858993459 # int > 02d andl R10, #858993459 # int > 034 sall RAX, #2 > 037 orl RAX, R10 # int > 03a movl R10, RAX # spill > 03d shrl R10, #4 > 041 andl RAX, #252645135 # int > 047 andl R10, #252645135 # int > 04e sall RAX, #4 > 051 orl RAX, R10 # int > 054 bswapl RAX > 056 addq rsp, 16 # Destroy frame > > > INTRINSICS DISABLED - 5,173 ? 0,096 ns/op > ========================================== > > > 000 B1: # N1 <- BLOCK HEAD IS JUNK Freq: 1 > 000 # stack bang (96 bytes) > pushq rbp # Save rbp > subq rsp, #16 # Create frame > > 00c movl RAX, RSI # spill > 00e andl RAX, #1431655765 # int > 014 shrl RSI, #1 > 016 sall RAX, #1 > 018 andl RSI, #1431655765 # int > 01e orl RAX, RSI # int > 020 movl R10, RAX # spill > 023 shrl R10, #2 > 027 andl RAX, #858993459 # int > 02d andl R10, #858993459 # int > 034 sall RAX, #2 > 037 orl RAX, R10 # int > 03a movl R10, RAX # spill > 03d shrl R10, #4 > 041 andl RAX, #252645135 # int > 047 andl R10, #252645135 # int > 04e sall RAX, #4 > 051 orl RAX, R10 # int > 054 movl R10, RAX # spill > 057 sall R10, #24 > 05b movl R11, RAX # spill > 05e sall R11, #8 > 062 movl R8, RAX # spill > 065 shrl R8, #8 > 069 andl R11, #16711680 # int > 070 andl R8, #65280 # int > 077 shrl RAX, #24 > 07a orl RAX, R8 # int > 07d orl RAX, R11 # int > 080 orl RAX, R10 # int > 083 addq rsp, 16 # Destroy frame > > > INTRINSICS DISABLED 2 - 5,081 ? 0,092 ns/op > =========================================== > > 000 B1: # N1 <- BLOCK HEAD IS JUNK Freq: 1 > 000 # stack bang (96 bytes) > pushq rbp # Save rbp > subq rsp, #16 # Create frame > > 00c movl RAX, RSI # spill > 00e andl RAX, #1431655765 # int > 014 shrl RSI, #1 > 016 sall RAX, #1 > 018 andl RSI, #1431655765 # int > 01e orl RAX, RSI # int > 020 movl R10, RAX # spill > 023 shrl R10, #2 > 027 andl RAX, #858993459 # int > 02d andl R10, #858993459 # int > 034 sall RAX, #2 > 037 orl RAX, R10 # int > 03a movl R10, RAX # spill > 03d shrl R10, #4 > 041 andl RAX, #252645135 # int > 047 andl R10, #252645135 # int > 04e sall RAX, #4 > 051 orl RAX, R10 # int > 054 movl R10, RAX # spill > 057 shrl R10, #24 > 05b movl R11, RAX # spill > 05e shrl R11, #8 > 062 movl R8, RAX # spill > 065 andl R8, #65280 # int > 06c andl R11, #65280 # int > 073 sall R8, #8 > 077 sall RAX, #24 > 07a orl RAX, R8 # int > 07d orl RAX, R11 # int > 080 orl RAX, R10 # int > 083 addq rsp, 16 # Destroy frame > > > Jaroslav From ivan.gerasimov at oracle.com Tue May 10 13:07:54 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 10 May 2016 16:07:54 +0300 Subject: RFR [9] 8156661: Handful of typos in javadoc Message-ID: <4901acf5-db78-91ba-545d-fe040e48f468@oracle.com> Hello! A couple of dozens of typos has been collected, so it's time to fix them. Would you please help review this trivial fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8156661 WEBREV: http://cr.openjdk.java.net/~igerasim/8156661/00/webrev/ With kind regards, Ivan From pavel.rappo at oracle.com Tue May 10 13:28:10 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 10 May 2016 14:28:10 +0100 Subject: RFR [9] 8156661: Handful of typos in javadoc In-Reply-To: <4901acf5-db78-91ba-545d-fe040e48f468@oracle.com> References: <4901acf5-db78-91ba-545d-fe040e48f468@oracle.com> Message-ID: Hi Ivan, Looks good! // I'm not an Reviewer. > On 10 May 2016, at 14:07, Ivan Gerasimov wrote: > > Hello! > > A couple of dozens of typos has been collected, so it's time to fix them. > > Would you please help review this trivial fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8156661 > WEBREV: http://cr.openjdk.java.net/~igerasim/8156661/00/webrev/ > > > With kind regards, > > Ivan > From ivan.gerasimov at oracle.com Tue May 10 13:32:21 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 10 May 2016 16:32:21 +0300 Subject: RFR [9] 8156661: Handful of typos in javadoc In-Reply-To: References: <4901acf5-db78-91ba-545d-fe040e48f468@oracle.com> Message-ID: Thanks Pavel! On 10.05.2016 16:28, Pavel Rappo wrote: > Hi Ivan, Looks good! > > // I'm not an Reviewer. > >> On 10 May 2016, at 14:07, Ivan Gerasimov wrote: >> >> Hello! >> >> A couple of dozens of typos has been collected, so it's time to fix them. >> >> Would you please help review this trivial fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8156661 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8156661/00/webrev/ >> >> >> With kind regards, >> >> Ivan >> > From paul.sandoz at oracle.com Tue May 10 13:36:07 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 10 May 2016 15:36:07 +0200 Subject: RFR 8156485 MethodHandles.varHandleExactInvoker should perform exact checks Message-ID: <3CB67D61-5B26-4F05-BF30-45837D69812F@oracle.com> Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8156486-varHandleExactInvoker/webrev/ A bug slipped in with recent VarHandle implementation improvements, and this was not caught by relevant tests. The MethodHandle returned from MethodHandles.varHandleExactInvoker performed an incorrect match using erased signatures. Ooops. I fixed this by consolidating the lambda form generation for exact and generic VH invokers. The tests are also updated, primarily to VarHandleTestMethod* (changes to other areas are minor clean ups) to correctly test the 4 ways to obtain a MethodHandle to a VarHandle access mode method, and to correctly differentiate between testing exact and generic invocation. Thanks, Paul. From Roger.Riggs at Oracle.com Tue May 10 13:48:35 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 10 May 2016 09:48:35 -0400 Subject: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds In-Reply-To: References: <29a10b5a-9a23-f839-8cf7-71fd8cc0a86c@Oracle.com> <1F6EC53A-3913-48AC-81A9-4CC5B699DDB0@oracle.com> <2a520081-bd5a-360f-b04a-31c5e63b4596@Oracle.com> <08424057-6035-0a08-2150-2eaaa013f8e4@oracle.com> <04DA3578-E41F-41F7-84DC-B9BBB410281F@oracle.com> Message-ID: <05392e04-d971-1856-18b1-05cbca76fa20@Oracle.com> Looks good Brian, Thanks On 5/10/2016 5:36 AM, Chris Hegarty wrote: > On 10 May 2016, at 00:29, Brian Burkhalter wrote: > >> Hi Roger, >> >> So modified: >> >> http://cr.openjdk.java.net/~bpb/8130679/webrev.01/ > This looks good to me. > > I have to admit that I reviewed the current wording in Reader.read, but on > reflection it would be better to update it to reflect this wording. But that is a > separate, lower priority, issue. > > -Chris. > >> Thanks, >> >> Brian >> >> On May 9, 2016, at 2:56 PM, Roger Riggs wrote: >>> Yes, I think that works well. >>> >>> On 5/9/16 5:15 PM, Brian Burkhalter wrote: >>>> So do you think that this form for example: >>>> >>>> (common prefix) >>>> * @throws IndexOutOfBoundsException >>>> * If {@code off} is negative, or {@code len} is negative, >>>> * or {@code off + len} is negative or greater than the length From Roger.Riggs at Oracle.com Tue May 10 14:15:38 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 10 May 2016 10:15:38 -0400 Subject: RFR [9] 8156661: Handful of typos in javadoc In-Reply-To: References: <4901acf5-db78-91ba-545d-fe040e48f468@oracle.com> Message-ID: <750811d3-634a-0223-2f4e-b59e578fa712@Oracle.com> Looks good, Reviewed, Roger On 5/10/2016 9:32 AM, Ivan Gerasimov wrote: > Thanks Pavel! > > > On 10.05.2016 16:28, Pavel Rappo wrote: >> Hi Ivan, Looks good! >> >> // I'm not an Reviewer. >> >>> On 10 May 2016, at 14:07, Ivan Gerasimov >>> wrote: >>> >>> Hello! >>> >>> A couple of dozens of typos has been collected, so it's time to fix >>> them. >>> >>> Would you please help review this trivial fix? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8156661 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8156661/00/webrev/ >>> >>> >>> With kind regards, >>> >>> Ivan >>> >> > From Roger.Riggs at Oracle.com Tue May 10 14:25:46 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 10 May 2016 10:25:46 -0400 Subject: RFR 8062804: IsoFields WEEK_BASED_YEAR and QUARTER_OF_YEAR too lenient In-Reply-To: References: <805cd535-929f-4687-bbe0-d19516d3737c@default> Message-ID: <0d407eee-6fa9-7ab4-fcbd-8a29c2fb4e4f@Oracle.com> Looks fine, Roger p.s. I don't see existing tests of the getFrom method for unsupported non-Iso temporals but that would be a new issue. On 5/10/2016 6:38 AM, Stephen Colebourne wrote: > Looks great > thanks > Stephen > > > On 10 May 2016 at 08:56, Bhanu Gopularam > wrote: >> Hi all, >> >> Please review fix following issue >> >> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8062804 >> >> Solution: Added check for unsupported fields in IsoFields rangeRefinedBy methods >> >> Webrev : http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8062804/webrev.00 >> >> Thanks, >> Bhanu >> >> >> >> From pavel.rappo at oracle.com Tue May 10 14:28:27 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 10 May 2016 15:28:27 +0100 Subject: RFR [9] 8156661: Handful of typos in javadoc In-Reply-To: <750811d3-634a-0223-2f4e-b59e578fa712@Oracle.com> References: <4901acf5-db78-91ba-545d-fe040e48f468@oracle.com> <750811d3-634a-0223-2f4e-b59e578fa712@Oracle.com> Message-ID: <4F170BC6-9744-4DB7-839A-6F15C4F77FD2@oracle.com> Hold it right there :-) There's an open issue about BufferedWriter https://bugs.openjdk.java.net/browse/JDK-8029804 So in this case what we've added in the @throws for java.io.BufferedWriter#write(java.lang.String, int, int) directly contradicts what it states two paragraphs above, doesn't it? *

If the value of the {@code len} parameter is negative then no * characters are written. This is contrary to the specification of this * method in the {@linkplain java.io.Writer#write(java.lang.String,int,int) * superclass}, which requires that an {@link IndexOutOfBoundsException} be * thrown. That doesn't look good. > On 10 May 2016, at 15:15, Roger Riggs wrote: > > Looks good, Reviewed, > > Roger > > > On 5/10/2016 9:32 AM, Ivan Gerasimov wrote: >> Thanks Pavel! >> >> >> On 10.05.2016 16:28, Pavel Rappo wrote: >>> Hi Ivan, Looks good! >>> >>> // I'm not an Reviewer. >>> >>>> On 10 May 2016, at 14:07, Ivan Gerasimov wrote: >>>> >>>> Hello! >>>> >>>> A couple of dozens of typos has been collected, so it's time to fix them. >>>> >>>> Would you please help review this trivial fix? >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8156661 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8156661/00/webrev/ >>>> >>>> >>>> With kind regards, >>>> >>>> Ivan >>>> >>> >> > From pavel.rappo at oracle.com Tue May 10 14:31:39 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 10 May 2016 15:31:39 +0100 Subject: RFR [9] 8156661: Handful of typos in javadoc In-Reply-To: <4F170BC6-9744-4DB7-839A-6F15C4F77FD2@oracle.com> References: <4901acf5-db78-91ba-545d-fe040e48f468@oracle.com> <750811d3-634a-0223-2f4e-b59e578fa712@Oracle.com> <4F170BC6-9744-4DB7-839A-6F15C4F77FD2@oracle.com> Message-ID: Sorry for the incorrect subject field. Should've been Re: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds > On 10 May 2016, at 15:28, Pavel Rappo wrote: > > Hold it right there :-) > > There's an open issue about BufferedWriter > > https://bugs.openjdk.java.net/browse/JDK-8029804 > > So in this case what we've added in the @throws for > java.io.BufferedWriter#write(java.lang.String, int, int) directly contradicts > what it states two paragraphs above, doesn't it? > > *

If the value of the {@code len} parameter is negative then no > * characters are written. This is contrary to the specification of this > * method in the {@linkplain java.io.Writer#write(java.lang.String,int,int) > * superclass}, which requires that an {@link IndexOutOfBoundsException} be > * thrown. > > That doesn't look good. > >> On 10 May 2016, at 15:15, Roger Riggs wrote: >> >> Looks good, Reviewed, >> >> Roger >> >> >> On 5/10/2016 9:32 AM, Ivan Gerasimov wrote: >>> Thanks Pavel! >>> >>> >>> On 10.05.2016 16:28, Pavel Rappo wrote: >>>> Hi Ivan, Looks good! >>>> >>>> // I'm not an Reviewer. >>>> >>>>> On 10 May 2016, at 14:07, Ivan Gerasimov wrote: >>>>> >>>>> Hello! >>>>> >>>>> A couple of dozens of typos has been collected, so it's time to fix them. >>>>> >>>>> Would you please help review this trivial fix? >>>>> >>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8156661 >>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8156661/00/webrev/ >>>>> >>>>> >>>>> With kind regards, >>>>> >>>>> Ivan >>>>> >>>> >>> >> > From pavel.rappo at oracle.com Tue May 10 14:32:13 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 10 May 2016 15:32:13 +0100 Subject: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds In-Reply-To: <05392e04-d971-1856-18b1-05cbca76fa20@Oracle.com> References: <29a10b5a-9a23-f839-8cf7-71fd8cc0a86c@Oracle.com> <1F6EC53A-3913-48AC-81A9-4CC5B699DDB0@oracle.com> <2a520081-bd5a-360f-b04a-31c5e63b4596@Oracle.com> <08424057-6035-0a08-2150-2eaaa013f8e4@oracle.com> <04DA3578-E41F-41F7-84DC-B9BBB410281F@oracle.com> <05392e04-d971-1856-18b1-05cbca76fa20@Oracle.com> Message-ID: <8D563048-63B0-40EF-9736-CB1C43C9B5A5@oracle.com> Hold it right there :-) There's an open issue about BufferedWriter https://bugs.openjdk.java.net/browse/JDK-8029804 So in this case what we've added in the @throws for java.io.BufferedWriter#write(java.lang.String, int, int) directly contradicts what it states two paragraphs above, doesn't it? *

If the value of the {@code len} parameter is negative then no * characters are written. This is contrary to the specification of this * method in the {@linkplain java.io.Writer#write(java.lang.String,int,int) * superclass}, which requires that an {@link IndexOutOfBoundsException} be * thrown. That doesn't look good. > On 10 May 2016, at 14:48, Roger Riggs wrote: > > Looks good Brian, > > Thanks > > > On 5/10/2016 5:36 AM, Chris Hegarty wrote: >> On 10 May 2016, at 00:29, Brian Burkhalter wrote: >> >>> Hi Roger, >>> >>> So modified: >>> >>> http://cr.openjdk.java.net/~bpb/8130679/webrev.01/ >> This looks good to me. >> >> I have to admit that I reviewed the current wording in Reader.read, but on >> reflection it would be better to update it to reflect this wording. But that is a >> separate, lower priority, issue. >> >> -Chris. >> >>> Thanks, >>> >>> Brian >>> >>> On May 9, 2016, at 2:56 PM, Roger Riggs wrote: >>>> Yes, I think that works well. >>>> >>>> On 5/9/16 5:15 PM, Brian Burkhalter wrote: >>>>> So do you think that this form for example: >>>>> >>>>> (common prefix) >>>>> * @throws IndexOutOfBoundsException >>>>> * If {@code off} is negative, or {@code len} is negative, >>>>> * or {@code off + len} is negative or greater than the length > From ivan.gerasimov at oracle.com Tue May 10 14:35:19 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 10 May 2016 17:35:19 +0300 Subject: RFR [9] 8156661: Handful of typos in javadoc In-Reply-To: <750811d3-634a-0223-2f4e-b59e578fa712@Oracle.com> References: <4901acf5-db78-91ba-545d-fe040e48f468@oracle.com> <750811d3-634a-0223-2f4e-b59e578fa712@Oracle.com> Message-ID: Thanks! Pushed. On 10.05.2016 17:15, Roger Riggs wrote: > Looks good, Reviewed, > > Roger > > > On 5/10/2016 9:32 AM, Ivan Gerasimov wrote: >> Thanks Pavel! >> >> >> On 10.05.2016 16:28, Pavel Rappo wrote: >>> Hi Ivan, Looks good! >>> >>> // I'm not an Reviewer. >>> >>>> On 10 May 2016, at 14:07, Ivan Gerasimov >>>> wrote: >>>> >>>> Hello! >>>> >>>> A couple of dozens of typos has been collected, so it's time to fix >>>> them. >>>> >>>> Would you please help review this trivial fix? >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8156661 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8156661/00/webrev/ >>>> >>>> >>>> With kind regards, >>>> >>>> Ivan >>>> >>> >> > > From brian.burkhalter at oracle.com Tue May 10 14:38:20 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 10 May 2016 07:38:20 -0700 Subject: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds In-Reply-To: <8D563048-63B0-40EF-9736-CB1C43C9B5A5@oracle.com> References: <29a10b5a-9a23-f839-8cf7-71fd8cc0a86c@Oracle.com> <1F6EC53A-3913-48AC-81A9-4CC5B699DDB0@oracle.com> <2a520081-bd5a-360f-b04a-31c5e63b4596@Oracle.com> <08424057-6035-0a08-2150-2eaaa013f8e4@oracle.com> <04DA3578-E41F-41F7-84DC-B9BBB410281F@oracle.com> <05392e04-d971-1856-18b1-05cbca76fa20@Oracle.com> <8D563048-63B0-40EF-9736-CB1C43C9B5A5@oracle.com> Message-ID: <3BD370EA-C213-4217-9F29-58A1543C1C4A@oracle.com> Good catch, Pavel. I?ll update it again and refresh the webrev. Thanks, Brian On May 10, 2016, at 7:32 AM, Pavel Rappo wrote: > Hold it right there :-) > > There's an open issue about BufferedWriter > > https://bugs.openjdk.java.net/browse/JDK-8029804 > > So in this case what we've added in the @throws for > java.io.BufferedWriter#write(java.lang.String, int, int) directly contradicts > what it states two paragraphs above, doesn't it? > > *

If the value of the {@code len} parameter is negative then no > * characters are written. This is contrary to the specification of this > * method in the {@linkplain java.io.Writer#write(java.lang.String,int,int) > * superclass}, which requires that an {@link IndexOutOfBoundsException} be > * thrown. > > That doesn't look good. > >> On 10 May 2016, at 14:48, Roger Riggs wrote: >> >> Looks good Brian, >> >> Thanks >> >> >> On 5/10/2016 5:36 AM, Chris Hegarty wrote: >>> On 10 May 2016, at 00:29, Brian Burkhalter wrote: >>> >>>> Hi Roger, >>>> >>>> So modified: >>>> >>>> http://cr.openjdk.java.net/~bpb/8130679/webrev.01/ >>> This looks good to me. >>> >>> I have to admit that I reviewed the current wording in Reader.read, but on >>> reflection it would be better to update it to reflect this wording. But that is a >>> separate, lower priority, issue. >>> >>> -Chris. >>> >>>> Thanks, >>>> >>>> Brian >>>> >>>> On May 9, 2016, at 2:56 PM, Roger Riggs wrote: >>>>> Yes, I think that works well. >>>>> >>>>> On 5/9/16 5:15 PM, Brian Burkhalter wrote: >>>>>> So do you think that this form for example: >>>>>> >>>>>> (common prefix) >>>>>> * @throws IndexOutOfBoundsException >>>>>> * If {@code off} is negative, or {@code len} is negative, >>>>>> * or {@code off + len} is negative or greater than the length >> > From Roger.Riggs at Oracle.com Tue May 10 15:03:40 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 10 May 2016 11:03:40 -0400 Subject: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds In-Reply-To: <8D563048-63B0-40EF-9736-CB1C43C9B5A5@oracle.com> References: <29a10b5a-9a23-f839-8cf7-71fd8cc0a86c@Oracle.com> <1F6EC53A-3913-48AC-81A9-4CC5B699DDB0@oracle.com> <2a520081-bd5a-360f-b04a-31c5e63b4596@Oracle.com> <08424057-6035-0a08-2150-2eaaa013f8e4@oracle.com> <04DA3578-E41F-41F7-84DC-B9BBB410281F@oracle.com> <05392e04-d971-1856-18b1-05cbca76fa20@Oracle.com> <8D563048-63B0-40EF-9736-CB1C43C9B5A5@oracle.com> Message-ID: <4106036f-3958-4b6c-503e-26ff9c13a035@Oracle.com> Hi Pavel, Good catch, the javadoc needs to match the code and in this case the new language does not match the code. Some cases are harder to follow because they delegate to other classes for copying. It may also be the case that since Writer.write(char[], off, len) is abstract, it cannot enforce the contract consistently on all subclasses and something special will be needed for that javadoc. Roger On 5/10/2016 10:32 AM, Pavel Rappo wrote: > Hold it right there :-) > > There's an open issue about BufferedWriter > > https://bugs.openjdk.java.net/browse/JDK-8029804 > > So in this case what we've added in the @throws for > java.io.BufferedWriter#write(java.lang.String, int, int) directly contradicts > what it states two paragraphs above, doesn't it? > > *

If the value of the {@code len} parameter is negative then no > * characters are written. This is contrary to the specification of this > * method in the {@linkplain java.io.Writer#write(java.lang.String,int,int) > * superclass}, which requires that an {@link IndexOutOfBoundsException} be > * thrown. > > That doesn't look good. > >> On 10 May 2016, at 14:48, Roger Riggs wrote: >> >> Looks good Brian, >> >> Thanks >> >> >> On 5/10/2016 5:36 AM, Chris Hegarty wrote: >>> On 10 May 2016, at 00:29, Brian Burkhalter wrote: >>> >>>> Hi Roger, >>>> >>>> So modified: >>>> >>>> http://cr.openjdk.java.net/~bpb/8130679/webrev.01/ >>> This looks good to me. >>> >>> I have to admit that I reviewed the current wording in Reader.read, but on >>> reflection it would be better to update it to reflect this wording. But that is a >>> separate, lower priority, issue. >>> >>> -Chris. >>> >>>> Thanks, >>>> >>>> Brian >>>> >>>> On May 9, 2016, at 2:56 PM, Roger Riggs wrote: >>>>> Yes, I think that works well. >>>>> >>>>> On 5/9/16 5:15 PM, Brian Burkhalter wrote: >>>>>> So do you think that this form for example: >>>>>> >>>>>> (common prefix) >>>>>> * @throws IndexOutOfBoundsException >>>>>> * If {@code off} is negative, or {@code len} is negative, >>>>>> * or {@code off + len} is negative or greater than the length From brian.burkhalter at oracle.com Tue May 10 15:11:53 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 10 May 2016 08:11:53 -0700 Subject: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds In-Reply-To: <4106036f-3958-4b6c-503e-26ff9c13a035@Oracle.com> References: <29a10b5a-9a23-f839-8cf7-71fd8cc0a86c@Oracle.com> <1F6EC53A-3913-48AC-81A9-4CC5B699DDB0@oracle.com> <2a520081-bd5a-360f-b04a-31c5e63b4596@Oracle.com> <08424057-6035-0a08-2150-2eaaa013f8e4@oracle.com> <04DA3578-E41F-41F7-84DC-B9BBB410281F@oracle.com> <05392e04-d971-1856-18b1-05cbca76fa20@Oracle.com> <8D563048-63B0-40EF-9736-CB1C43C9B5A5@oracle.com> <4106036f-3958-4b6c-503e-26ff9c13a035@Oracle.com> Message-ID: <500F8362-2DD6-4B29-A786-CD425E284C1D@oracle.com> Hi Roger, On May 10, 2016, at 8:03 AM, Roger Riggs wrote: > Good catch, the javadoc needs to match the code and in this case the new language > does not match the code. Some cases are harder to follow because they delegate > to other classes for copying. I think I?ll drop BufferedWriter from this RFR and let Pavel handle it in 8029804. > It may also be the case that since Writer.write(char[], off, len) is abstract, it cannot enforce the contract > consistently on all subclasses and something special will be needed for that javadoc. I?ll see whether this needs changing before revving. Thanks, Brian From ralph.goers at dslextreme.com Tue May 10 16:49:43 2016 From: ralph.goers at dslextreme.com (Ralph Goers) Date: Tue, 10 May 2016 09:49:43 -0700 Subject: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed In-Reply-To: <90BF6135-B457-4BD4-8DFF-9DE94F6D8DC7@oracle.com> References: <5D245EC6-47C6-4BF1-A505-89934731A814@oracle.com> <360DDB44-FDFC-41DE-8DF9-9BBA3AF28581@oracle.com> <07C5EC23-C429-4961-B7D3-92B7C32FB535@dslextreme.com> <90BF6135-B457-4BD4-8DFF-9DE94F6D8DC7@oracle.com> Message-ID: I just ran one of the Log4j performance tests that specifically captures location information. To run the test I do java -jar log4j-perf/target/benchmarks.jar ".*AsyncAppenderLog4j2LocationBenchmark.*" -f 1 -wi 10 -i 20 -t 4 -si true And the results are: java version "1.7.0_80 Benchmark Mode Samples Score Error Units o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 124819.285 ? 3003.918 ops/s java version "1.8.0_65" Benchmark Mode Samples Score Error Units o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 123209.746 ? 3064.672 ops/s java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+116) Benchmark Mode Samples Score Error Units o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 96090.261 ? 4565.763 ops/s This tells me that Java 9 is about 23% slower than previous versions in walking the stack trace elements. Ralph > On Apr 13, 2016, at 12:03 PM, Mandy Chung wrote: > > If you record all stack frames, I can believe Throwable is faster because of a recent optimization JDK-8150778 that has been made in jdk9 to improve the Throwable::getStackTraceElements method. > > Mandy > >> On Apr 13, 2016, at 11:49 AM, Ralph Goers wrote: >> >> I did a raw test of StackWalker by itself and the performance was much better than using a Throwable to get the location information. However, I haven?t tested how it will be implemented in Log4j. We still support Java 7 (and will for some time) so we have to find a way to support using StackWalker when running on Java 9 even though we build with Java 7. >> >> Ralph >> >>> On Apr 13, 2016, at 10:27 AM, Mandy Chung wrote: >>> >>> It is good to know Log4J is planning to use StackWalker. >>> >>> Thanks for the feedback. I will reconsider. >>> >>> One thing to mention is the patch went in jdk9/hs-rt that will show up in jdk9/dev some time that changes the implementation to create StackTraceElement to get filename and line number. The object allocation should be cheap that does create short-lived objects. The main motivation of JDK-8153123 was to simplify the hotspot implementation that the runtime team had concern about. There is an open issue to follow up the performance (JDK-8153683). It?d be helpful to get your feedback on using StackWalker API and the performance data. >>> >>> Mandy >>> >>>> On Apr 13, 2016, at 6:51 AM, Ralph Goers wrote: >>>> >>>> I had planned on using StackWalker to generate the location information for every logging event. It seems that this change would thus cause the creation of a new StackTraceElement for every logger event. That seems wasteful. Log4j is currently in the process of trying to reduce the number of objects that are created while logging as it has a significant impact on garbage collection. So I am also in favor of getting the filename and line number directly from the StackFrame. >>>> >>>> Ralph >>>> >>>>> On Apr 12, 2016, at 5:15 PM, Mandy Chung wrote: >>>>> >>>>> >>>>>> On Apr 12, 2016, at 1:34 AM, R?mi Forax wrote: >>>>>> >>>>>> Hi Mandy, >>>>>> I really don't like this patch. >>>>>> >>>>>> Being forced to call toStackElement to get the line number is counter intuitive. >>>>>> I would prefer the two methods to not return Optional but an int and a String with the same convention as StackElement if the point of this patch is to remove the dependency to Optional. >>>>>> >>>>> >>>>> I was expecting the common usage of StackWalker API does not need file name and line number. I think it'd be useful to include StackFrame::getBci (in the future it might include live information like locals etc) and keep the optional stuff and uncommon usage to StackTraceElement. >>>>> >>>>> Mandy >>>>> >>>>> >>>>>> R?mi >>>>>> >>>>>> >>>>>> Le 11 avril 2016 23:22:39 CEST, Mandy Chung a ?crit : >>>>>>> Webrev at: >>>>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.00/index.html >>>>>>> >>>>>>> StackFrame::getFileName and StackFrame::getLineNumber are originally >>>>>>> proposed with the view of any stack walking code can migrate to the >>>>>>> StackWalker API without the use of StackTraceElement. >>>>>>> >>>>>>> File name and line number are useful for debugging and troubleshooting >>>>>>> purpose. It has additional overhead to map from a method and BCI to >>>>>>> look up the file name and line number. >>>>>>> >>>>>>> StackFrame::toStackTraceElement method returns StackTraceElement that >>>>>>> includes the file name and line number. There is no particular benefit >>>>>>> to duplicate getFileName and getLineNumber methods in StackFrame. It is >>>>>>> equivalently convenient to call >>>>>>> StackFrame.toStackTraceElement().getFileName() (or getLineNumber). >>>>>>> >>>>>>> This patch proposes to remove StackFrame::getFileName and >>>>>>> StackFrame::getLineNumber methods since such information can be >>>>>>> obtained from StackFrame.toStackTraceElement(). >>>>>>> >>>>>>> Mandy >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > From mandy.chung at oracle.com Tue May 10 16:57:31 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 10 May 2016 09:57:31 -0700 Subject: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed In-Reply-To: References: <5D245EC6-47C6-4BF1-A505-89934731A814@oracle.com> <360DDB44-FDFC-41DE-8DF9-9BBA3AF28581@oracle.com> <07C5EC23-C429-4961-B7D3-92B7C32FB535@dslextreme.com> <90BF6135-B457-4BD4-8DFF-9DE94F6D8DC7@oracle.com> Message-ID: <018AAA44-3689-4E79-B090-B0D1F0DD0CC1@oracle.com> What does your benchmark call? Mandy > On May 10, 2016, at 9:49 AM, Ralph Goers wrote: > > I just ran one of the Log4j performance tests that specifically captures location information. To run the test I do > > java -jar log4j-perf/target/benchmarks.jar ".*AsyncAppenderLog4j2LocationBenchmark.*" -f 1 -wi 10 -i 20 -t 4 -si true > > And the results are: > > java version "1.7.0_80 > > Benchmark Mode Samples Score Error Units > o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 124819.285 ? 3003.918 ops/s > > java version "1.8.0_65" > > Benchmark Mode Samples Score Error Units > o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 123209.746 ? 3064.672 ops/s > > > java version "9-ea" > Java(TM) SE Runtime Environment (build 9-ea+116) > > Benchmark Mode Samples Score Error Units > o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 96090.261 ? 4565.763 ops/s > > > This tells me that Java 9 is about 23% slower than previous versions in walking the stack trace elements. > > Ralph > >> On Apr 13, 2016, at 12:03 PM, Mandy Chung wrote: >> >> If you record all stack frames, I can believe Throwable is faster because of a recent optimization JDK-8150778 that has been made in jdk9 to improve the Throwable::getStackTraceElements method. >> >> Mandy >> >>> On Apr 13, 2016, at 11:49 AM, Ralph Goers wrote: >>> >>> I did a raw test of StackWalker by itself and the performance was much better than using a Throwable to get the location information. However, I haven?t tested how it will be implemented in Log4j. We still support Java 7 (and will for some time) so we have to find a way to support using StackWalker when running on Java 9 even though we build with Java 7. >>> >>> Ralph >>> >>>> On Apr 13, 2016, at 10:27 AM, Mandy Chung wrote: >>>> >>>> It is good to know Log4J is planning to use StackWalker. >>>> >>>> Thanks for the feedback. I will reconsider. >>>> >>>> One thing to mention is the patch went in jdk9/hs-rt that will show up in jdk9/dev some time that changes the implementation to create StackTraceElement to get filename and line number. The object allocation should be cheap that does create short-lived objects. The main motivation of JDK-8153123 was to simplify the hotspot implementation that the runtime team had concern about. There is an open issue to follow up the performance (JDK-8153683). It?d be helpful to get your feedback on using StackWalker API and the performance data. >>>> >>>> Mandy >>>> >>>>> On Apr 13, 2016, at 6:51 AM, Ralph Goers wrote: >>>>> >>>>> I had planned on using StackWalker to generate the location information for every logging event. It seems that this change would thus cause the creation of a new StackTraceElement for every logger event. That seems wasteful. Log4j is currently in the process of trying to reduce the number of objects that are created while logging as it has a significant impact on garbage collection. So I am also in favor of getting the filename and line number directly from the StackFrame. >>>>> >>>>> Ralph >>>>> >>>>>> On Apr 12, 2016, at 5:15 PM, Mandy Chung wrote: >>>>>> >>>>>> >>>>>>> On Apr 12, 2016, at 1:34 AM, R?mi Forax wrote: >>>>>>> >>>>>>> Hi Mandy, >>>>>>> I really don't like this patch. >>>>>>> >>>>>>> Being forced to call toStackElement to get the line number is counter intuitive. >>>>>>> I would prefer the two methods to not return Optional but an int and a String with the same convention as StackElement if the point of this patch is to remove the dependency to Optional. >>>>>>> >>>>>> >>>>>> I was expecting the common usage of StackWalker API does not need file name and line number. I think it'd be useful to include StackFrame::getBci (in the future it might include live information like locals etc) and keep the optional stuff and uncommon usage to StackTraceElement. >>>>>> >>>>>> Mandy >>>>>> >>>>>> >>>>>>> R?mi >>>>>>> >>>>>>> >>>>>>> Le 11 avril 2016 23:22:39 CEST, Mandy Chung a ?crit : >>>>>>>> Webrev at: >>>>>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.00/index.html >>>>>>>> >>>>>>>> StackFrame::getFileName and StackFrame::getLineNumber are originally >>>>>>>> proposed with the view of any stack walking code can migrate to the >>>>>>>> StackWalker API without the use of StackTraceElement. >>>>>>>> >>>>>>>> File name and line number are useful for debugging and troubleshooting >>>>>>>> purpose. It has additional overhead to map from a method and BCI to >>>>>>>> look up the file name and line number. >>>>>>>> >>>>>>>> StackFrame::toStackTraceElement method returns StackTraceElement that >>>>>>>> includes the file name and line number. There is no particular benefit >>>>>>>> to duplicate getFileName and getLineNumber methods in StackFrame. It is >>>>>>>> equivalently convenient to call >>>>>>>> StackFrame.toStackTraceElement().getFileName() (or getLineNumber). >>>>>>>> >>>>>>>> This patch proposes to remove StackFrame::getFileName and >>>>>>>> StackFrame::getLineNumber methods since such information can be >>>>>>>> obtained from StackFrame.toStackTraceElement(). >>>>>>>> >>>>>>>> Mandy >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > From huizhe.wang at oracle.com Tue May 10 17:15:33 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 10 May 2016 10:15:33 -0700 Subject: RFR (JAXP) : 8046274: Removing dependency on jakarta-regexp Message-ID: <57321735.60105@oracle.com> Hi, This change focuses purely on removing the dependency on jakarta-regexp. I'm leaving all other things in the bcel code to a future bcel update. All tests passed. JBS: https://bugs.openjdk.java.net/browse/JDK-8046274 Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8046274/webrev/ Thanks, Joe From sean.mullan at oracle.com Tue May 10 17:23:21 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 10 May 2016 10:23:21 -0700 Subject: RFR: regex changes -- sun.security.util.Debug issue In-Reply-To: <57319C0C.8070702@oracle.com> References: <56EC5F76.4080106@oracle.com> <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> <57319C0C.8070702@oracle.com> Message-ID: <57321909.5080804@oracle.com> On 5/10/16 1:30 AM, Alan Bateman wrote: > On 10/05/2016 06:36, Xueming Shen wrote: >> Hi, >> >> While testing for the attached regex changes, a fatal vm init error >> was triggered for test >> case with -Djava.security.debug=xyz turned on, as showed in following >> stacktrace. >> >> It appears sun.security.util.Debug is being initialized even before >> the lambda is ready >> for use, and unfortunately it uses j.u.regex (for its args parsing), >> which is being migrated >> to use lambda function in the proposed regex change. >> >> Since Debug is the only class now triggers j.u.regex -> lambda during >> initialization, it >> is suggested to update/rewrite the related method in Debug to NOT use >> j.u.regex to >> solve/workaround this specific initialization issue. > This is always tricky but I wonder how far we could get by initializing > ProtectionDomain.debug and SecureClassLoader.debug lazily. That is, move > them to a holder class where I wouldn't expect they will be initialized > until much later, esp. as the security manager won't be set until later > in the initialization (or init phase 3 as we've come to name it). Actually, ProtectionDomain already does something like this. It only writes to debug if the policy has been set. See toString(): PermissionCollection pc = Policy.isSet() && seeAllp() ? mergePermissions(): getPermissions(); So, a simpler fix is to extend that concept and not initialize the debug field until Policy.isSet is true. This should resolve this bootstrapping issue. --Sean From ralph.goers at dslextreme.com Tue May 10 17:40:10 2016 From: ralph.goers at dslextreme.com (Ralph Goers) Date: Tue, 10 May 2016 10:40:10 -0700 Subject: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed In-Reply-To: <018AAA44-3689-4E79-B090-B0D1F0DD0CC1@oracle.com> References: <5D245EC6-47C6-4BF1-A505-89934731A814@oracle.com> <360DDB44-FDFC-41DE-8DF9-9BBA3AF28581@oracle.com> <07C5EC23-C429-4961-B7D3-92B7C32FB535@dslextreme.com> <90BF6135-B457-4BD4-8DFF-9DE94F6D8DC7@oracle.com> <018AAA44-3689-4E79-B090-B0D1F0DD0CC1@oracle.com> Message-ID: <6A375668-62CA-47BE-B2AB-6BB3E7D3BEC0@dslextreme.com> The benchmark logs events using Log4j 2?s asynchronous loggers. In the process of doing that it captures the location information using the code below: // LOG4J2-1029 new Throwable().getStackTrace is faster than Thread.currentThread().getStackTrace(). final StackTraceElement[] stackTrace = new Throwable().getStackTrace(); StackTraceElement last = null; for (int i = stackTrace.length - 1; i > 0; i--) { final String className = stackTrace[i].getClassName(); if (fqcnOfLogger.equals(className)) { return last; } last = stackTrace[i]; } return null; Ralph > On May 10, 2016, at 9:57 AM, Mandy Chung wrote: > > What does your benchmark call? > > Mandy > >> On May 10, 2016, at 9:49 AM, Ralph Goers wrote: >> >> I just ran one of the Log4j performance tests that specifically captures location information. To run the test I do >> >> java -jar log4j-perf/target/benchmarks.jar ".*AsyncAppenderLog4j2LocationBenchmark.*" -f 1 -wi 10 -i 20 -t 4 -si true >> >> And the results are: >> >> java version "1.7.0_80 >> >> Benchmark Mode Samples Score Error Units >> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 124819.285 ? 3003.918 ops/s >> >> java version "1.8.0_65" >> >> Benchmark Mode Samples Score Error Units >> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 123209.746 ? 3064.672 ops/s >> >> >> java version "9-ea" >> Java(TM) SE Runtime Environment (build 9-ea+116) >> >> Benchmark Mode Samples Score Error Units >> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 96090.261 ? 4565.763 ops/s >> >> >> This tells me that Java 9 is about 23% slower than previous versions in walking the stack trace elements. >> >> Ralph >> >>> On Apr 13, 2016, at 12:03 PM, Mandy Chung wrote: >>> >>> If you record all stack frames, I can believe Throwable is faster because of a recent optimization JDK-8150778 that has been made in jdk9 to improve the Throwable::getStackTraceElements method. >>> >>> Mandy >>> >>>> On Apr 13, 2016, at 11:49 AM, Ralph Goers wrote: >>>> >>>> I did a raw test of StackWalker by itself and the performance was much better than using a Throwable to get the location information. However, I haven?t tested how it will be implemented in Log4j. We still support Java 7 (and will for some time) so we have to find a way to support using StackWalker when running on Java 9 even though we build with Java 7. >>>> >>>> Ralph >>>> >>>>> On Apr 13, 2016, at 10:27 AM, Mandy Chung wrote: >>>>> >>>>> It is good to know Log4J is planning to use StackWalker. >>>>> >>>>> Thanks for the feedback. I will reconsider. >>>>> >>>>> One thing to mention is the patch went in jdk9/hs-rt that will show up in jdk9/dev some time that changes the implementation to create StackTraceElement to get filename and line number. The object allocation should be cheap that does create short-lived objects. The main motivation of JDK-8153123 was to simplify the hotspot implementation that the runtime team had concern about. There is an open issue to follow up the performance (JDK-8153683). It?d be helpful to get your feedback on using StackWalker API and the performance data. >>>>> >>>>> Mandy >>>>> >>>>>> On Apr 13, 2016, at 6:51 AM, Ralph Goers wrote: >>>>>> >>>>>> I had planned on using StackWalker to generate the location information for every logging event. It seems that this change would thus cause the creation of a new StackTraceElement for every logger event. That seems wasteful. Log4j is currently in the process of trying to reduce the number of objects that are created while logging as it has a significant impact on garbage collection. So I am also in favor of getting the filename and line number directly from the StackFrame. >>>>>> >>>>>> Ralph >>>>>> >>>>>>> On Apr 12, 2016, at 5:15 PM, Mandy Chung wrote: >>>>>>> >>>>>>> >>>>>>>> On Apr 12, 2016, at 1:34 AM, R?mi Forax wrote: >>>>>>>> >>>>>>>> Hi Mandy, >>>>>>>> I really don't like this patch. >>>>>>>> >>>>>>>> Being forced to call toStackElement to get the line number is counter intuitive. >>>>>>>> I would prefer the two methods to not return Optional but an int and a String with the same convention as StackElement if the point of this patch is to remove the dependency to Optional. >>>>>>>> >>>>>>> >>>>>>> I was expecting the common usage of StackWalker API does not need file name and line number. I think it'd be useful to include StackFrame::getBci (in the future it might include live information like locals etc) and keep the optional stuff and uncommon usage to StackTraceElement. >>>>>>> >>>>>>> Mandy >>>>>>> >>>>>>> >>>>>>>> R?mi >>>>>>>> >>>>>>>> >>>>>>>> Le 11 avril 2016 23:22:39 CEST, Mandy Chung a ?crit : >>>>>>>>> Webrev at: >>>>>>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.00/index.html >>>>>>>>> >>>>>>>>> StackFrame::getFileName and StackFrame::getLineNumber are originally >>>>>>>>> proposed with the view of any stack walking code can migrate to the >>>>>>>>> StackWalker API without the use of StackTraceElement. >>>>>>>>> >>>>>>>>> File name and line number are useful for debugging and troubleshooting >>>>>>>>> purpose. It has additional overhead to map from a method and BCI to >>>>>>>>> look up the file name and line number. >>>>>>>>> >>>>>>>>> StackFrame::toStackTraceElement method returns StackTraceElement that >>>>>>>>> includes the file name and line number. There is no particular benefit >>>>>>>>> to duplicate getFileName and getLineNumber methods in StackFrame. It is >>>>>>>>> equivalently convenient to call >>>>>>>>> StackFrame.toStackTraceElement().getFileName() (or getLineNumber). >>>>>>>>> >>>>>>>>> This patch proposes to remove StackFrame::getFileName and >>>>>>>>> StackFrame::getLineNumber methods since such information can be >>>>>>>>> obtained from StackFrame.toStackTraceElement(). >>>>>>>>> >>>>>>>>> Mandy >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > From lance.andersen at oracle.com Tue May 10 17:56:48 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 10 May 2016 13:56:48 -0400 Subject: RFR (JAXP) : 8046274: Removing dependency on jakarta-regexp In-Reply-To: <57321735.60105@oracle.com> References: <57321735.60105@oracle.com> Message-ID: <2E8BFA4B-8B3E-4D25-84DE-A3D718D9C645@oracle.com> +1 > On May 10, 2016, at 1:15 PM, huizhe wang wrote: > > Hi, > > This change focuses purely on removing the dependency on jakarta-regexp. I'm leaving all other things in the bcel code to a future bcel update. All tests passed. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8046274 > Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8046274/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 xueming.shen at oracle.com Tue May 10 18:04:41 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 10 May 2016 11:04:41 -0700 Subject: RFR: regex changes -- sun.security.util.Debug issue In-Reply-To: <57321909.5080804@oracle.com> References: <56EC5F76.4080106@oracle.com> <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> <57319C0C.8070702@oracle.com> <57321909.5080804@oracle.com> Message-ID: <573222B9.4020503@oracle.com> Sean, Given the "debug" is a private field and it is used only for debug != null in toString() -> seeAllp(), can the following change be a valid update? with the assumption that (1) the toString() is really not performance critical here, as we are changing from debug != null to public static boolean isOn(String option) { if (args == null) return false; else { if (args.indexOf("all") != -1) return true; else return (args.indexOf(option) != -1); } } (2) the "debug" field is not being accessed via reflect --------------------------------------------------------------------------------------- src/java.base/share/classes/java/security/ProtectionDomain.java @@ -137,12 +137,10 @@ /* * An object used as a key when the ProtectionDomain is stored in a Map. */ final Key key = new Key(); - private static final Debug debug = Debug.getInstance("domain"); - /** * Creates a new ProtectionDomain with the given CodeSource and * Permissions. If the permissions object is not null, then * {@code setReadOnly())} will be called on the passed in * Permissions object. The only permissions granted to this domain @@ -357,11 +355,11 @@ SecurityManager sm = System.getSecurityManager(); if (sm == null) { return true; } else { - if (debug != null) { + if (Debug.isOn("domain")) { if (sm.getClass().getClassLoader() == null && Policy.getPolicyNoCheck().getClass().getClassLoader() == null) { return true; } -------------------------------------------------------------------------------------------------- On 05/10/2016 10:23 AM, Sean Mullan wrote: > > > On 5/10/16 1:30 AM, Alan Bateman wrote: >> On 10/05/2016 06:36, Xueming Shen wrote: >>> Hi, >>> >>> While testing for the attached regex changes, a fatal vm init error >>> was triggered for test >>> case with -Djava.security.debug=xyz turned on, as showed in following >>> stacktrace. >>> >>> It appears sun.security.util.Debug is being initialized even before >>> the lambda is ready >>> for use, and unfortunately it uses j.u.regex (for its args parsing), >>> which is being migrated >>> to use lambda function in the proposed regex change. >>> >>> Since Debug is the only class now triggers j.u.regex -> lambda during >>> initialization, it >>> is suggested to update/rewrite the related method in Debug to NOT use >>> j.u.regex to >>> solve/workaround this specific initialization issue. >> This is always tricky but I wonder how far we could get by initializing >> ProtectionDomain.debug and SecureClassLoader.debug lazily. That is, move >> them to a holder class where I wouldn't expect they will be initialized >> until much later, esp. as the security manager won't be set until later >> in the initialization (or init phase 3 as we've come to name it). > > Actually, ProtectionDomain already does something like this. It only writes to debug if the policy has been set. See toString(): > > PermissionCollection pc = Policy.isSet() && seeAllp() ? > mergePermissions(): > getPermissions(); > > So, a simpler fix is to extend that concept and not initialize the debug field until Policy.isSet is true. This should resolve this bootstrapping issue. > > --Sean From nadeesh.tv at oracle.com Tue May 10 18:25:59 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Tue, 10 May 2016 23:55:59 +0530 Subject: RFR:JDK-8155823: Add date-time patterns 'v' and 'vvvv' In-Reply-To: References: <5730BC5D.7050807@oracle.com> Message-ID: <573227B7.4090603@oracle.com> Hi, Stephen, Roger Thanks for the comments. Please see the updated webrev http://cr.openjdk.java.net/~ntv/8155823/webrev.04/ Apart from the fix, made a correction in the java doc of ZoneRules.java Thanks and Regards, Nadeesh On 5/10/2016 12:54 AM, Roger Riggs wrote: > > Hi Nadeesh, > > java/time/format/DateTimeFormatter.java: line 312 > > - Move 'v' up 1 line so it is after 'V' and before 'z'. > Also in DateTimeFormatterBuilder.java: line 1415+ > > - the description of the number of letters does not need to be repeated; > put one copy before the specifics of 'z' and 'v'. > "If the count of letters is one, then the short name is output. > + * If the count of letters is four, then the full name is output. > + * Two, three and five or more letters throw {@code IllegalArgumentException}." > > DateTimeFormatterBuilder.java > - line 1625/1626: should include what happens with vv and vvv to be > consistent with DateTimeFormatter doc for ZoneId names. > > - line 1647: The description in DateTimeFormatter says that count = 2 > and 3 should also produce the short value > but the code will throw IAE. > > -line 1988: "almost" --- can this be more specific about what > matches or does not match > > In the test it is a bit bothersome that the tests have to rely on > timezone specific data. > > Thanks, Roger > > On 5/9/2016 12:35 PM, nadeesh tv wrote: >> >> Hi all, >> >> Reposting because subject line did not follow the format. >> >> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8155823 >> Issue: Add date-time patterns 'v' and 'vvvv' >> webrev: http://cr.openjdk.java.net/~ntv/8155823/webrev.03/ >> >> This webrev also contain the fix of related bug >> https://bugs.openjdk.java.net/browse/JDK-8154567 as part of this. >> >> Special thanks for Stephen for his help in writing the spec. >> > -- Thanks and Regards, Nadeesh TV From xueming.shen at oracle.com Tue May 10 18:57:58 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 10 May 2016 11:57:58 -0700 Subject: RFR: regex changes -- sun.security.util.Debug issue In-Reply-To: <57319C0C.8070702@oracle.com> References: <56EC5F76.4080106@oracle.com> <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> <57319C0C.8070702@oracle.com> Message-ID: <57322F36.2060709@oracle.com> webrev has been updated as suggested, now the lazily-init-class-holder is used to delay the Debug initialization. Tests all passed locally. A jprt job is out to confirm. Here is the updated webrev http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ Thanks! Sherman On 05/10/2016 01:30 AM, Alan Bateman wrote: > On 10/05/2016 06:36, Xueming Shen wrote: >> Hi, >> >> While testing for the attached regex changes, a fatal vm init error was triggered for test >> case with -Djava.security.debug=xyz turned on, as showed in following stacktrace. >> >> It appears sun.security.util.Debug is being initialized even before the lambda is ready >> for use, and unfortunately it uses j.u.regex (for its args parsing), which is being migrated >> to use lambda function in the proposed regex change. >> >> Since Debug is the only class now triggers j.u.regex -> lambda during initialization, it >> is suggested to update/rewrite the related method in Debug to NOT use j.u.regex to >> solve/workaround this specific initialization issue. > This is always tricky but I wonder how far we could get by initializing ProtectionDomain.debug and SecureClassLoader.debug lazily. That is, move them to a holder class where I wouldn't expect they will be initialized until much later, esp. as the security manager won't be set until later in the initialization (or init phase 3 as we've come to name it). > > -Alan From Roger.Riggs at Oracle.com Tue May 10 19:58:13 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 10 May 2016 15:58:13 -0400 Subject: RFR: regex changes -- sun.security.util.Debug issue In-Reply-To: <57322F36.2060709@oracle.com> References: <56EC5F76.4080106@oracle.com> <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> <57319C0C.8070702@oracle.com> <57322F36.2060709@oracle.com> Message-ID: +1 On 5/10/2016 2:57 PM, Xueming Shen wrote: > webrev has been updated as suggested, now the lazily-init-class-holder > is used > to delay the Debug initialization. Tests all passed locally. A jprt > job is out to confirm. > > Here is the updated webrev > > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ > > Thanks! > Sherman > > On 05/10/2016 01:30 AM, Alan Bateman wrote: >> On 10/05/2016 06:36, Xueming Shen wrote: >>> Hi, >>> >>> While testing for the attached regex changes, a fatal vm init error >>> was triggered for test >>> case with -Djava.security.debug=xyz turned on, as showed in >>> following stacktrace. >>> >>> It appears sun.security.util.Debug is being initialized even before >>> the lambda is ready >>> for use, and unfortunately it uses j.u.regex (for its args parsing), >>> which is being migrated >>> to use lambda function in the proposed regex change. >>> >>> Since Debug is the only class now triggers j.u.regex -> lambda >>> during initialization, it >>> is suggested to update/rewrite the related method in Debug to NOT >>> use j.u.regex to >>> solve/workaround this specific initialization issue. >> This is always tricky but I wonder how far we could get by >> initializing ProtectionDomain.debug and SecureClassLoader.debug >> lazily. That is, move them to a holder class where I wouldn't expect >> they will be initialized until much later, esp. as the security >> manager won't be set until later in the initialization (or init phase >> 3 as we've come to name it). >> >> -Alan > > > From Alan.Bateman at oracle.com Tue May 10 20:10:24 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 May 2016 21:10:24 +0100 Subject: RFR: regex changes -- sun.security.util.Debug issue In-Reply-To: <57322F36.2060709@oracle.com> References: <56EC5F76.4080106@oracle.com> <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> <57319C0C.8070702@oracle.com> <57322F36.2060709@oracle.com> Message-ID: <57324030.6000509@oracle.com> On 10/05/2016 19:57, Xueming Shen wrote: > webrev has been updated as suggested, now the lazily-init-class-holder > is used > to delay the Debug initialization. Tests all passed locally. A jprt > job is out to confirm. > > Here is the updated webrev > > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ This looks okay, are exploded builds okay too? -Alan From xueming.shen at oracle.com Tue May 10 20:44:18 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 10 May 2016 13:44:18 -0700 Subject: RFR: regex changes -- sun.security.util.Debug issue In-Reply-To: <57324030.6000509@oracle.com> References: <56EC5F76.4080106@oracle.com> <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> <57319C0C.8070702@oracle.com> <57322F36.2060709@oracle.com> <57324030.6000509@oracle.com> Message-ID: On 5/10/16 1:10 PM, Alan Bateman wrote: > > > On 10/05/2016 19:57, Xueming Shen wrote: >> webrev has been updated as suggested, now the >> lazily-init-class-holder is used >> to delay the Debug initialization. Tests all passed locally. A jprt >> job is out to confirm. >> >> Here is the updated webrev >> >> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ >> > This looks okay, are exploded builds okay too? > > -Alan jprt job appears to be OK. exploded build failed here and there for various reasons, for example "access denied". but it has nothing to do with the regex change. a jdk9_dev build without any update fails as well with the same reason at same place. here is one example http://javaweb.us.oracle.com/~xueshen/JTreport2/html/failed.html sherman From artem.smotrakov at oracle.com Tue May 10 20:49:41 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 10 May 2016 13:49:41 -0700 Subject: [9] RFR: 8152207: Perform array bound checks while getting a length of bytecode instructions In-Reply-To: References: <572A8A57.5080907@oracle.com> Message-ID: <57324965.1090905@oracle.com> Hi Christian, Thank you for review. Here is updated webrev http://cr.openjdk.java.net/~asmotrak/8152207/hotspot/webrev.01/ Artem On 05/09/2016 01:24 PM, Christian Thalinger wrote: > >> On May 4, 2016, at 1:48 PM, Artem Smotrakov >> > wrote: >> >> Hello, >> >> Please review two small patches for jdk and hotspot repos which add >> array bound checks to functions which return a length of bytecode >> instruction. >> >> Please see details in https://bugs.openjdk.java.net/browse/JDK-8152207 >> >> http://cr.openjdk.java.net/~asmotrak/8152207/jdk/webrev.00/ >> >> http://cr.openjdk.java.net/~asmotrak/8152207/hotspot/webrev.00/ > > static bool is_defined (int code) { return 0 <= code && > code < number_of_codes && flags(code, false) != 0; } > + static int length_for (Code code) { return 0 <= code && code < > number_of_codes ? _lengths[code] & 0xF : -1; } > + static int wide_length_for(Code code) { return 0 <= code && code < > number_of_codes ? _lengths[code] >> 4 : -1; } > You should factor the bound check into a separate method. > >> >> Artem > From brent.christian at oracle.com Tue May 10 21:56:49 2016 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 10 May 2016 14:56:49 -0700 Subject: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival In-Reply-To: <8DD50D66-D2C1-43E4-B7C5-992FE785958B@oracle.com> References: <55479A4F.4060806@oracle.com> <5550FE5A.4070607@oracle.com> <55513EA7.1050700@oracle.com> <555192A4.3080305@gmail.com> <5551A0AA.6050800@gmail.com> <5552674E.4030009@oracle.com> <55526FF5.9000509@gmail.com> <55564473.3010704@oracle.com> <8DD50D66-D2C1-43E4-B7C5-992FE785958B@oracle.com> Message-ID: <57325921.9090100@oracle.com> Hi! Welcome back to 8029891, "Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java". Our previous discussion is at [1]. Briefly, java.util.Properties isa Hashtable, which synchronizes on itself for any access. System.getProperties() returns the Properties instance accessed by the system, which any application code might synchronize on (that's what the test is doing). System properties are a common way for changing default setting, so it's impractical to expect the class loading code path not to call System.getProperty. The fix is to change Properties to store its values in an internal ConcurrentHashMap, ignoring its Hashtable heritage. In this way, Properties can be (partly) "de-sychronized", and deadlocks avoided. While good progress was made during the original code review, all of the overridden methods in Properties caused an explosion of unnecessary JavaDoc (see specdiff at [2]). With the recent fix of 8073100 (new "@hidden" JavaDoc tag), we can now avoid the additional clutter. Highlights from the previous discussion: * Specifics of where to remove synchronization: generally, read methods will be de-synchronized, while write/bulk-read operations will stay synchronized. * We considered whether we might be able use special-case code just for system properties, instead of a general change to Properties. Because a user is able to supply their own Properties object to System.setProperties(), which is set as the system properties, and current behavior reflects changes made to original Properties object, it would be best to change the Properties class itself. * Don't leak extra add/remove functionality through returned Enumerations. * I said I would check on the synchronization of serialization. writeHashtable() looks okay to me; I expect this is not such a concern for readHashtable(). A new webrev is here: http://cr.openjdk.java.net/~bchristi/8029891/webrev.4/ Other changes since the last webrev I posted: * In readHashtable(), I added a check to validate 'elements', as is done in Hashtable. * I have indicated that Iterators from [keySet|entrySet|values].iterator() no longer fail-fast. While perhaps not strictly necessary, given the "no guarantees" nature of the Hashtable spec, my personal preference is to make it clear that Properties no longer makes a best (or any) effort to throw ConcurrentModificationException. This should not affect any working code (which would not see a CME anyway). Given that Properties are meant to be used as a collection of largely static values, adding additional code to maintain fail-fast behavior is not warranted. FWIW, the deadlock code path is now different than what is seen in the bug report (see [3]). We're now getting hung up on the Integer.getInteger() call to get MAX_ARITY on line 60 of MethodHandleImpl [4]. Thanks, -Brent 1. http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-May/033147.html 2. http://cr.openjdk.java.net/~bchristi/8029891/webrev.3/specdiff-plain/Properties.html 3. http://cr.openjdk.java.net/~bchristi/8029891/webrev.4/NewDeadlock.txt 4. http://hg.openjdk.java.net/jdk9/dev/jdk/file/1049321b86cb/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java From markt at apache.org Tue May 10 22:05:10 2016 From: markt at apache.org (Mark Thomas) Date: Tue, 10 May 2016 23:05:10 +0100 Subject: Memory leak in com.sun.jndi.ldap.pool.PoolCleaner Message-ID: Hi, While working my way through Tomcat's memory leak protection / detection / fixing code, I have found an issue that remains unresolved in the latest JDK 9 source. The PoolCleaner thread started by the LdapPoolManager when the idle timeout is positive does not explicitly set the context class loader so it inherits the current context class loader. If the current context class loader when this code is triggered happens to be one that is meant to be disposable (e.g. a web application class loader) the class loader will be pinned in memory until the Thread stops. This prevents the class loader from being GC'd when no longer required and triggers a mmeory leak. The fix looks to be trivial. Something along the lines of the following around line 45 of PoolCleaner: setContextClassLoader(PoolCleaner.class.getClassLoader()); If I can provide any further information or if there is better place / way to submit this then please do let me know. Mark From stuart.marks at oracle.com Tue May 10 23:21:15 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 10 May 2016 16:21:15 -0700 Subject: RFR (JAXP) 8152912: SAX XMLReaderFactory needs to be ServiceLoader compliant In-Reply-To: <5731084B.7040902@oracle.com> References: <57279CDE.7070207@oracle.com> <6ed137e8-2651-7f6f-50b9-143b00286355@oracle.com> <572940DB.10003@oracle.com> <712af5bd-7ba4-266a-c32e-afd35d8434b4@oracle.com> <5731084B.7040902@oracle.com> Message-ID: <0df05c88-3eb8-0a0c-4196-2136cb51d161@oracle.com> On 5/9/16 2:59 PM, huizhe wang wrote: >> This looks much better to me. >> I just wonder about the @Deprecated("5") vs @Deprecated("1.5") > > Yes, the compiler accepted it just fine and produced javadocs similar to that of > XMLReaderFactory where since="9". Hi Joe, Daniel, The namespace of the @Deprecated 'since' element is the same as the @since javadoc tag. APIs that were added in Java 5 have "@since 1.5" in their javadoc, so something that was deprecated in Java 5 should be annotated @Deprecated(since="1.5") It looks like we didn't go to single-digit versions until Java 9. Earlier versions are still listed as 1.8, 1.7, 1.6, 1.5, and so forth. s'marks From mandy.chung at oracle.com Wed May 11 00:01:28 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 10 May 2016 17:01:28 -0700 Subject: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed In-Reply-To: <6A375668-62CA-47BE-B2AB-6BB3E7D3BEC0@dslextreme.com> References: <5D245EC6-47C6-4BF1-A505-89934731A814@oracle.com> <360DDB44-FDFC-41DE-8DF9-9BBA3AF28581@oracle.com> <07C5EC23-C429-4961-B7D3-92B7C32FB535@dslextreme.com> <90BF6135-B457-4BD4-8DFF-9DE94F6D8DC7@oracle.com> <018AAA44-3689-4E79-B090-B0D1F0DD0CC1@oracle.com> <6A375668-62CA-47BE-B2AB-6BB3E7D3BEC0@dslextreme.com> Message-ID: <98CF502C-A96C-40AE-9CF0-E96A3909E517@oracle.com> This walks the stack to find a frame with a matching class. Throwable::getStackTrace is taking the entire stack trace. I suggest to try StackWalker and avoids the overhead of dumping the entire stack trace. Mandy > On May 10, 2016, at 10:40 AM, Ralph Goers wrote: > > The benchmark logs events using Log4j 2?s asynchronous loggers. In the process of doing that it captures the location information using the code below: > > > // LOG4J2-1029 new Throwable().getStackTrace is faster than Thread.currentThread().getStackTrace(). > final StackTraceElement[] stackTrace = new Throwable().getStackTrace(); > StackTraceElement last = null; > for (int i = stackTrace.length - 1; i > 0; i--) { > final String className = stackTrace[i].getClassName(); > if (fqcnOfLogger.equals(className)) { > return last; > } > last = stackTrace[i]; > } > return null; > > Ralph > > >> On May 10, 2016, at 9:57 AM, Mandy Chung wrote: >> >> What does your benchmark call? >> >> Mandy >> >>> On May 10, 2016, at 9:49 AM, Ralph Goers wrote: >>> >>> I just ran one of the Log4j performance tests that specifically captures location information. To run the test I do >>> >>> java -jar log4j-perf/target/benchmarks.jar ".*AsyncAppenderLog4j2LocationBenchmark.*" -f 1 -wi 10 -i 20 -t 4 -si true >>> >>> And the results are: >>> >>> java version "1.7.0_80 >>> >>> Benchmark Mode Samples Score Error Units >>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 124819.285 ? 3003.918 ops/s >>> >>> java version "1.8.0_65" >>> >>> Benchmark Mode Samples Score Error Units >>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 123209.746 ? 3064.672 ops/s >>> >>> >>> java version "9-ea" >>> Java(TM) SE Runtime Environment (build 9-ea+116) >>> >>> Benchmark Mode Samples Score Error Units >>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 96090.261 ? 4565.763 ops/s >>> >>> >>> This tells me that Java 9 is about 23% slower than previous versions in walking the stack trace elements. >>> >>> Ralph >>> >>>> On Apr 13, 2016, at 12:03 PM, Mandy Chung wrote: >>>> >>>> If you record all stack frames, I can believe Throwable is faster because of a recent optimization JDK-8150778 that has been made in jdk9 to improve the Throwable::getStackTraceElements method. >>>> >>>> Mandy >>>> >>>>> On Apr 13, 2016, at 11:49 AM, Ralph Goers wrote: >>>>> >>>>> I did a raw test of StackWalker by itself and the performance was much better than using a Throwable to get the location information. However, I haven?t tested how it will be implemented in Log4j. We still support Java 7 (and will for some time) so we have to find a way to support using StackWalker when running on Java 9 even though we build with Java 7. >>>>> >>>>> Ralph >>>>> >>>>>> On Apr 13, 2016, at 10:27 AM, Mandy Chung wrote: >>>>>> >>>>>> It is good to know Log4J is planning to use StackWalker. >>>>>> >>>>>> Thanks for the feedback. I will reconsider. >>>>>> >>>>>> One thing to mention is the patch went in jdk9/hs-rt that will show up in jdk9/dev some time that changes the implementation to create StackTraceElement to get filename and line number. The object allocation should be cheap that does create short-lived objects. The main motivation of JDK-8153123 was to simplify the hotspot implementation that the runtime team had concern about. There is an open issue to follow up the performance (JDK-8153683). It?d be helpful to get your feedback on using StackWalker API and the performance data. >>>>>> >>>>>> Mandy >>>>>> >>>>>>> On Apr 13, 2016, at 6:51 AM, Ralph Goers wrote: >>>>>>> >>>>>>> I had planned on using StackWalker to generate the location information for every logging event. It seems that this change would thus cause the creation of a new StackTraceElement for every logger event. That seems wasteful. Log4j is currently in the process of trying to reduce the number of objects that are created while logging as it has a significant impact on garbage collection. So I am also in favor of getting the filename and line number directly from the StackFrame. >>>>>>> >>>>>>> Ralph >>>>>>> >>>>>>>> On Apr 12, 2016, at 5:15 PM, Mandy Chung wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On Apr 12, 2016, at 1:34 AM, R?mi Forax wrote: >>>>>>>>> >>>>>>>>> Hi Mandy, >>>>>>>>> I really don't like this patch. >>>>>>>>> >>>>>>>>> Being forced to call toStackElement to get the line number is counter intuitive. >>>>>>>>> I would prefer the two methods to not return Optional but an int and a String with the same convention as StackElement if the point of this patch is to remove the dependency to Optional. >>>>>>>>> >>>>>>>> >>>>>>>> I was expecting the common usage of StackWalker API does not need file name and line number. I think it'd be useful to include StackFrame::getBci (in the future it might include live information like locals etc) and keep the optional stuff and uncommon usage to StackTraceElement. >>>>>>>> >>>>>>>> Mandy >>>>>>>> >>>>>>>> >>>>>>>>> R?mi >>>>>>>>> >>>>>>>>> >>>>>>>>> Le 11 avril 2016 23:22:39 CEST, Mandy Chung a ?crit : >>>>>>>>>> Webrev at: >>>>>>>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.00/index.html >>>>>>>>>> >>>>>>>>>> StackFrame::getFileName and StackFrame::getLineNumber are originally >>>>>>>>>> proposed with the view of any stack walking code can migrate to the >>>>>>>>>> StackWalker API without the use of StackTraceElement. >>>>>>>>>> >>>>>>>>>> File name and line number are useful for debugging and troubleshooting >>>>>>>>>> purpose. It has additional overhead to map from a method and BCI to >>>>>>>>>> look up the file name and line number. >>>>>>>>>> >>>>>>>>>> StackFrame::toStackTraceElement method returns StackTraceElement that >>>>>>>>>> includes the file name and line number. There is no particular benefit >>>>>>>>>> to duplicate getFileName and getLineNumber methods in StackFrame. It is >>>>>>>>>> equivalently convenient to call >>>>>>>>>> StackFrame.toStackTraceElement().getFileName() (or getLineNumber). >>>>>>>>>> >>>>>>>>>> This patch proposes to remove StackFrame::getFileName and >>>>>>>>>> StackFrame::getLineNumber methods since such information can be >>>>>>>>>> obtained from StackFrame.toStackTraceElement(). >>>>>>>>>> >>>>>>>>>> Mandy >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > From mandy.chung at oracle.com Wed May 11 00:12:42 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 10 May 2016 17:12:42 -0700 Subject: Review request for JDK-8156680: jdeps implementation refresh Message-ID: JDK-8156680: jdeps implementation refresh JDK-8153042: jdeps should continue to report JDK internal APIs that are removed/renamed in JDK 9 Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8156680/webrev.00/ This refactors the jdeps implementation that regression tests can be developed without the need to parse the output file. It also includes a list of the removed JDK internal APIs and provides the pointer where to look for more further information. JDK-8153481: tools/jdeps/modules/GenModuleInfo.java and ModuleTest.java fails intermittently Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153481/webrev.00/ Mandy From ralph.goers at dslextreme.com Wed May 11 00:17:10 2016 From: ralph.goers at dslextreme.com (Ralph Goers) Date: Tue, 10 May 2016 17:17:10 -0700 Subject: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed In-Reply-To: <98CF502C-A96C-40AE-9CF0-E96A3909E517@oracle.com> References: <5D245EC6-47C6-4BF1-A505-89934731A814@oracle.com> <360DDB44-FDFC-41DE-8DF9-9BBA3AF28581@oracle.com> <07C5EC23-C429-4961-B7D3-92B7C32FB535@dslextreme.com> <90BF6135-B457-4BD4-8DFF-9DE94F6D8DC7@oracle.com> <018AAA44-3689-4E79-B090-B0D1F0DD0CC1@oracle.com> <6A375668-62CA-47BE-B2AB-6BB3E7D3BEC0@dslextreme.com> <98CF502C-A96C-40AE-9CF0-E96A3909E517@oracle.com> Message-ID: OK - I try that. My earlier comparison had shown that StackWalker was much faster but since walking the Throwable is so much slower I?m now wondering how much better than Java 7 & 8 it will be. Any idea why walking the Throwable is so much slower? Ralph > On May 10, 2016, at 5:01 PM, Mandy Chung wrote: > > This walks the stack to find a frame with a matching class. Throwable::getStackTrace is taking the entire stack trace. I suggest to try StackWalker and avoids the overhead of dumping the entire stack trace. > > Mandy > >> On May 10, 2016, at 10:40 AM, Ralph Goers wrote: >> >> The benchmark logs events using Log4j 2?s asynchronous loggers. In the process of doing that it captures the location information using the code below: >> >> >> // LOG4J2-1029 new Throwable().getStackTrace is faster than Thread.currentThread().getStackTrace(). >> final StackTraceElement[] stackTrace = new Throwable().getStackTrace(); >> StackTraceElement last = null; >> for (int i = stackTrace.length - 1; i > 0; i--) { >> final String className = stackTrace[i].getClassName(); >> if (fqcnOfLogger.equals(className)) { >> return last; >> } >> last = stackTrace[i]; >> } >> return null; >> >> Ralph >> >> >>> On May 10, 2016, at 9:57 AM, Mandy Chung wrote: >>> >>> What does your benchmark call? >>> >>> Mandy >>> >>>> On May 10, 2016, at 9:49 AM, Ralph Goers wrote: >>>> >>>> I just ran one of the Log4j performance tests that specifically captures location information. To run the test I do >>>> >>>> java -jar log4j-perf/target/benchmarks.jar ".*AsyncAppenderLog4j2LocationBenchmark.*" -f 1 -wi 10 -i 20 -t 4 -si true >>>> >>>> And the results are: >>>> >>>> java version "1.7.0_80 >>>> >>>> Benchmark Mode Samples Score Error Units >>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 124819.285 ? 3003.918 ops/s >>>> >>>> java version "1.8.0_65" >>>> >>>> Benchmark Mode Samples Score Error Units >>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 123209.746 ? 3064.672 ops/s >>>> >>>> >>>> java version "9-ea" >>>> Java(TM) SE Runtime Environment (build 9-ea+116) >>>> >>>> Benchmark Mode Samples Score Error Units >>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 96090.261 ? 4565.763 ops/s >>>> >>>> >>>> This tells me that Java 9 is about 23% slower than previous versions in walking the stack trace elements. >>>> >>>> Ralph >>>> >>>>> On Apr 13, 2016, at 12:03 PM, Mandy Chung wrote: >>>>> >>>>> If you record all stack frames, I can believe Throwable is faster because of a recent optimization JDK-8150778 that has been made in jdk9 to improve the Throwable::getStackTraceElements method. >>>>> >>>>> Mandy >>>>> >>>>>> On Apr 13, 2016, at 11:49 AM, Ralph Goers wrote: >>>>>> >>>>>> I did a raw test of StackWalker by itself and the performance was much better than using a Throwable to get the location information. However, I haven?t tested how it will be implemented in Log4j. We still support Java 7 (and will for some time) so we have to find a way to support using StackWalker when running on Java 9 even though we build with Java 7. >>>>>> >>>>>> Ralph >>>>>> >>>>>>> On Apr 13, 2016, at 10:27 AM, Mandy Chung wrote: >>>>>>> >>>>>>> It is good to know Log4J is planning to use StackWalker. >>>>>>> >>>>>>> Thanks for the feedback. I will reconsider. >>>>>>> >>>>>>> One thing to mention is the patch went in jdk9/hs-rt that will show up in jdk9/dev some time that changes the implementation to create StackTraceElement to get filename and line number. The object allocation should be cheap that does create short-lived objects. The main motivation of JDK-8153123 was to simplify the hotspot implementation that the runtime team had concern about. There is an open issue to follow up the performance (JDK-8153683). It?d be helpful to get your feedback on using StackWalker API and the performance data. >>>>>>> >>>>>>> Mandy >>>>>>> >>>>>>>> On Apr 13, 2016, at 6:51 AM, Ralph Goers wrote: >>>>>>>> >>>>>>>> I had planned on using StackWalker to generate the location information for every logging event. It seems that this change would thus cause the creation of a new StackTraceElement for every logger event. That seems wasteful. Log4j is currently in the process of trying to reduce the number of objects that are created while logging as it has a significant impact on garbage collection. So I am also in favor of getting the filename and line number directly from the StackFrame. >>>>>>>> >>>>>>>> Ralph >>>>>>>> >>>>>>>>> On Apr 12, 2016, at 5:15 PM, Mandy Chung wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Apr 12, 2016, at 1:34 AM, R?mi Forax wrote: >>>>>>>>>> >>>>>>>>>> Hi Mandy, >>>>>>>>>> I really don't like this patch. >>>>>>>>>> >>>>>>>>>> Being forced to call toStackElement to get the line number is counter intuitive. >>>>>>>>>> I would prefer the two methods to not return Optional but an int and a String with the same convention as StackElement if the point of this patch is to remove the dependency to Optional. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I was expecting the common usage of StackWalker API does not need file name and line number. I think it'd be useful to include StackFrame::getBci (in the future it might include live information like locals etc) and keep the optional stuff and uncommon usage to StackTraceElement. >>>>>>>>> >>>>>>>>> Mandy >>>>>>>>> >>>>>>>>> >>>>>>>>>> R?mi >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Le 11 avril 2016 23:22:39 CEST, Mandy Chung a ?crit : >>>>>>>>>>> Webrev at: >>>>>>>>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.00/index.html >>>>>>>>>>> >>>>>>>>>>> StackFrame::getFileName and StackFrame::getLineNumber are originally >>>>>>>>>>> proposed with the view of any stack walking code can migrate to the >>>>>>>>>>> StackWalker API without the use of StackTraceElement. >>>>>>>>>>> >>>>>>>>>>> File name and line number are useful for debugging and troubleshooting >>>>>>>>>>> purpose. It has additional overhead to map from a method and BCI to >>>>>>>>>>> look up the file name and line number. >>>>>>>>>>> >>>>>>>>>>> StackFrame::toStackTraceElement method returns StackTraceElement that >>>>>>>>>>> includes the file name and line number. There is no particular benefit >>>>>>>>>>> to duplicate getFileName and getLineNumber methods in StackFrame. It is >>>>>>>>>>> equivalently convenient to call >>>>>>>>>>> StackFrame.toStackTraceElement().getFileName() (or getLineNumber). >>>>>>>>>>> >>>>>>>>>>> This patch proposes to remove StackFrame::getFileName and >>>>>>>>>>> StackFrame::getLineNumber methods since such information can be >>>>>>>>>>> obtained from StackFrame.toStackTraceElement(). >>>>>>>>>>> >>>>>>>>>>> Mandy >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From stuart.marks at oracle.com Wed May 11 00:44:00 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 10 May 2016 17:44:00 -0700 Subject: RFR(m): 8140281 deprecate Optional.get() In-Reply-To: References: <1282fc0c-2d92-be13-d95e-9486cd556146@oracle.com> <571EA9D8.3010702@oracle.com> <5dad068b-038e-591c-49a1-ffcc22ffebb8@oracle.com> Message-ID: <350f4ee8-e59a-1518-adda-1a52f3654b96@oracle.com> On 4/28/16 7:23 PM, Martin Buchholz wrote: > No opinion on Optional.get() itself, but here's an opinion on the high > cost of deprecation. > > If you deprecate the API today, and I have a library that is already > using the API, then I should add a @SuppressWarning("deprecation") > today and keep it there until the number of people using pre-jdk9 is > insignificant, when I can finally rename it. How long is that? These > days, I estimate at least 10 years. But even 20 years is quite > possible. Hi Martin, Finally getting back to this. Thanks for this observation on the cost of deprecation. I think there are several things going on here. One is how long such annotations need to live in the source base. I see the concern but I'm not sure where you're getting your lifetime numbers. Certainly there's a support lifetime for old JDK releases. I'm hearing about various systems migrating away from Java 7 now, and that's five years old. There are still various things that need to support Java 6 (ten years old), but I think this is exacerbated by the abnormally long gap between 6 and 7. But, continuing the scenario, suppose something is deprecated in JDK 9, and you add @SuppressWarnings to shut off the new warnings it generates. You can't migrate to the replacement API introduced in JDK 9, since you still have to support JDK 6, 7, and 8, so you have to leave @SW in until you drop support for 8, which might not be for many years. Is that the source of your concern? I'm kind of guessing here. An additional problem with @SuppressWarnings("deprecation"), and its companion command-line option -Xlint:-deprecation, is that it's too broad a brush. They shut of *all* deprecation warnings, at least, for the scope of code to which they're applied. If @SW is added to suppress deprecation warnings on X, and later on Y is deprecated, deprecation warnings on uses of Y will also get suppressed. That's likely a problem. It seems to me that when we're talking about costs of deprecation, the main issue is how to manage warnings, in code bases that support multiple releases, and when different things are deprecated in different releases. Is it really about warnings? Or is there some other cost that we should be thinking about as well? s'marks From stuart.marks at oracle.com Wed May 11 01:25:15 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 10 May 2016 18:25:15 -0700 Subject: RFR(m): 8139233u1 add initial compact immutable collection implementations In-Reply-To: <394584297.477564.1462803923948.JavaMail.zimbra@u-pem.fr> References: <9622a280-f29a-820c-00e9-74f41964141f@oracle.com> <192fcb16-aa51-5662-e38b-1efb2a68937e@oracle.com> <394584297.477564.1462803923948.JavaMail.zimbra@u-pem.fr> Message-ID: <90f900ae-d79b-341f-ea98-87ed18dadc89@oracle.com> On 5/9/16 7:25 AM, Remi Forax wrote: > I still think that the code of hasNext of the iterator of SetN and MapN should not do any side effect. Yes, I'm happy to consider further cleanups. I was starting to go off into the weeds with refactoring and cleanups, since they were introducing regressions, so I decided to check in a stable version and continue with cleanups later. You had suggested to gather the searching code into a nextIndex() method, which is called from the constructor and from next(), in order to simplify hasNext(). I see that HashMap's HashIterator is done this way, and in fact the search code isn't in a method -- it's replicated between the constructor and nextNode(). See HashMap.java lines 1477 and 1493. [1] [2] My question is, does this really buy anything? In a typical while(hasNext())/next() loop, the same work will get done, just in a different place. [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/4da0f73ce03a/src/java.base/share/classes/java/util/HashMap.java#l1477 [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/4da0f73ce03a/src/java.base/share/classes/java/util/HashMap.java#l1493 > otherwise, > in the constructor of MapN, you can declare k and v as Object > (the table is an array of Object and probe() now takes an Object) Yes, good point. > also instead of InternalError, i think AssertionError is a better exception, > the javadoc of InternalError says that InternalError is thrown by the VM. Hm. I agree that InternalError seems wrong since it's a subtype of VirtualMachineError. But it's used about 2x more frequently than AssertionError in the JDK. > in MapN.probe, you can remove the cast to K (and the corresponding @SuppressWarnings). Yes. > Set2.e0 and Set2.e1 should be declared as package-private otherwise, the compiler generates an accessor in the iterator. Same thing for SetN.elements, MapN.table and MapN.size I guess I privatized too many things. (But I'm no David Cameron.) > CollSer implementation can be improved to avoid the ugly switch/case by replacing the constant list by an enum, > something like the code below. In that case, creating a CollSer for a Map will be done like this, > return new CollSer(CollSer.Kind.MAP, array); I'll reply downthread after your exchange with Stephen Colebourne. s'marks From stuart.marks at oracle.com Wed May 11 01:33:06 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 10 May 2016 18:33:06 -0700 Subject: RFR(m): 8139233 add initial compact immutable collection implementations In-Reply-To: References: <5729F7AB.6050705@oracle.com> <2a2ae77b-09d2-db9c-d4b8-c7199e3c8cd3@oracle.com> <572B3DC1.2080302@oracle.com> Message-ID: On 5/5/16 2:22 PM, Eddie Aftandilian wrote: > FWIW, at Google we have a patch against our JDK that randomizes hash iteration > order. For test execution we randomize with a unique seed per JVM invocation. > For production we force a specific seed for all executions. This approach > catches most issues during automated testing, but reduces the likelihood of an > issue in production. Yes, I've heard of such a thing. From what I understand, this randomizes the iteration order of the *existing* collections like HashMap. It makes sense for this to be an opt-in feature for existing collections, since it seems pretty unwise to expose a behavioral change to large quantities of existing code. Unfortunately, from time to time the JDK does change the iteration order of the existing collections, and unsurprisingly, lots of things break. It would be interesting to see such a patch proposed for OpenJDK. It'd be good to enable it during test runs, for a start. s'marks From mandy.chung at oracle.com Wed May 11 02:26:03 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 10 May 2016 19:26:03 -0700 Subject: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed In-Reply-To: References: <5D245EC6-47C6-4BF1-A505-89934731A814@oracle.com> <360DDB44-FDFC-41DE-8DF9-9BBA3AF28581@oracle.com> <07C5EC23-C429-4961-B7D3-92B7C32FB535@dslextreme.com> <90BF6135-B457-4BD4-8DFF-9DE94F6D8DC7@oracle.com> <018AAA44-3689-4E79-B090-B0D1F0DD0CC1@oracle.com> <6A375668-62CA-47BE-B2AB-6BB3E7D3BEC0@dslextreme.com> <98CF502C-A96C-40AE-9CF0-E96A3909E517@oracle.com> Message-ID: <190DD091-23D6-4E74-AA7E-5B87EEE3998C@oracle.com> > On May 10, 2016, at 5:17 PM, Ralph Goers wrote: > > OK - I try that. My earlier comparison had shown that StackWalker was much faster but since walking the Throwable is so much slower I?m now wondering how much better than Java 7 & 8 it will be. > > Any idea why walking the Throwable is so much slower? > No idea yet. Can you share your benchmark so that we can understand what you measure? Mandy > Ralph > >> On May 10, 2016, at 5:01 PM, Mandy Chung wrote: >> >> This walks the stack to find a frame with a matching class. Throwable::getStackTrace is taking the entire stack trace. I suggest to try StackWalker and avoids the overhead of dumping the entire stack trace. >> >> Mandy >> >>> On May 10, 2016, at 10:40 AM, Ralph Goers wrote: >>> >>> The benchmark logs events using Log4j 2?s asynchronous loggers. In the process of doing that it captures the location information using the code below: >>> >>> >>> // LOG4J2-1029 new Throwable().getStackTrace is faster than Thread.currentThread().getStackTrace(). >>> final StackTraceElement[] stackTrace = new Throwable().getStackTrace(); >>> StackTraceElement last = null; >>> for (int i = stackTrace.length - 1; i > 0; i--) { >>> final String className = stackTrace[i].getClassName(); >>> if (fqcnOfLogger.equals(className)) { >>> return last; >>> } >>> last = stackTrace[i]; >>> } >>> return null; >>> >>> Ralph >>> >>> >>>> On May 10, 2016, at 9:57 AM, Mandy Chung wrote: >>>> >>>> What does your benchmark call? >>>> >>>> Mandy >>>> >>>>> On May 10, 2016, at 9:49 AM, Ralph Goers wrote: >>>>> >>>>> I just ran one of the Log4j performance tests that specifically captures location information. To run the test I do >>>>> >>>>> java -jar log4j-perf/target/benchmarks.jar ".*AsyncAppenderLog4j2LocationBenchmark.*" -f 1 -wi 10 -i 20 -t 4 -si true >>>>> >>>>> And the results are: >>>>> >>>>> java version "1.7.0_80 >>>>> >>>>> Benchmark Mode Samples Score Error Units >>>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 124819.285 ? 3003.918 ops/s >>>>> >>>>> java version "1.8.0_65" >>>>> >>>>> Benchmark Mode Samples Score Error Units >>>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 123209.746 ? 3064.672 ops/s >>>>> >>>>> >>>>> java version "9-ea" >>>>> Java(TM) SE Runtime Environment (build 9-ea+116) >>>>> >>>>> Benchmark Mode Samples Score Error Units >>>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 96090.261 ? 4565.763 ops/s >>>>> >>>>> >>>>> This tells me that Java 9 is about 23% slower than previous versions in walking the stack trace elements. >>>>> >>>>> Ralph >>>>> >>>>>> On Apr 13, 2016, at 12:03 PM, Mandy Chung wrote: >>>>>> >>>>>> If you record all stack frames, I can believe Throwable is faster because of a recent optimization JDK-8150778 that has been made in jdk9 to improve the Throwable::getStackTraceElements method. >>>>>> >>>>>> Mandy >>>>>> >>>>>>> On Apr 13, 2016, at 11:49 AM, Ralph Goers wrote: >>>>>>> >>>>>>> I did a raw test of StackWalker by itself and the performance was much better than using a Throwable to get the location information. However, I haven?t tested how it will be implemented in Log4j. We still support Java 7 (and will for some time) so we have to find a way to support using StackWalker when running on Java 9 even though we build with Java 7. >>>>>>> >>>>>>> Ralph >>>>>>> >>>>>>>> On Apr 13, 2016, at 10:27 AM, Mandy Chung wrote: >>>>>>>> >>>>>>>> It is good to know Log4J is planning to use StackWalker. >>>>>>>> >>>>>>>> Thanks for the feedback. I will reconsider. >>>>>>>> >>>>>>>> One thing to mention is the patch went in jdk9/hs-rt that will show up in jdk9/dev some time that changes the implementation to create StackTraceElement to get filename and line number. The object allocation should be cheap that does create short-lived objects. The main motivation of JDK-8153123 was to simplify the hotspot implementation that the runtime team had concern about. There is an open issue to follow up the performance (JDK-8153683). It?d be helpful to get your feedback on using StackWalker API and the performance data. >>>>>>>> >>>>>>>> Mandy >>>>>>>> >>>>>>>>> On Apr 13, 2016, at 6:51 AM, Ralph Goers wrote: >>>>>>>>> >>>>>>>>> I had planned on using StackWalker to generate the location information for every logging event. It seems that this change would thus cause the creation of a new StackTraceElement for every logger event. That seems wasteful. Log4j is currently in the process of trying to reduce the number of objects that are created while logging as it has a significant impact on garbage collection. So I am also in favor of getting the filename and line number directly from the StackFrame. >>>>>>>>> >>>>>>>>> Ralph >>>>>>>>> >>>>>>>>>> On Apr 12, 2016, at 5:15 PM, Mandy Chung wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Apr 12, 2016, at 1:34 AM, R?mi Forax wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Mandy, >>>>>>>>>>> I really don't like this patch. >>>>>>>>>>> >>>>>>>>>>> Being forced to call toStackElement to get the line number is counter intuitive. >>>>>>>>>>> I would prefer the two methods to not return Optional but an int and a String with the same convention as StackElement if the point of this patch is to remove the dependency to Optional. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I was expecting the common usage of StackWalker API does not need file name and line number. I think it'd be useful to include StackFrame::getBci (in the future it might include live information like locals etc) and keep the optional stuff and uncommon usage to StackTraceElement. >>>>>>>>>> >>>>>>>>>> Mandy >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> R?mi >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Le 11 avril 2016 23:22:39 CEST, Mandy Chung a ?crit : >>>>>>>>>>>> Webrev at: >>>>>>>>>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.00/index.html >>>>>>>>>>>> >>>>>>>>>>>> StackFrame::getFileName and StackFrame::getLineNumber are originally >>>>>>>>>>>> proposed with the view of any stack walking code can migrate to the >>>>>>>>>>>> StackWalker API without the use of StackTraceElement. >>>>>>>>>>>> >>>>>>>>>>>> File name and line number are useful for debugging and troubleshooting >>>>>>>>>>>> purpose. It has additional overhead to map from a method and BCI to >>>>>>>>>>>> look up the file name and line number. >>>>>>>>>>>> >>>>>>>>>>>> StackFrame::toStackTraceElement method returns StackTraceElement that >>>>>>>>>>>> includes the file name and line number. There is no particular benefit >>>>>>>>>>>> to duplicate getFileName and getLineNumber methods in StackFrame. It is >>>>>>>>>>>> equivalently convenient to call >>>>>>>>>>>> StackFrame.toStackTraceElement().getFileName() (or getLineNumber). >>>>>>>>>>>> >>>>>>>>>>>> This patch proposes to remove StackFrame::getFileName and >>>>>>>>>>>> StackFrame::getLineNumber methods since such information can be >>>>>>>>>>>> obtained from StackFrame.toStackTraceElement(). >>>>>>>>>>>> >>>>>>>>>>>> Mandy >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > > From ralph.goers at dslextreme.com Wed May 11 02:34:51 2016 From: ralph.goers at dslextreme.com (Ralph Goers) Date: Tue, 10 May 2016 19:34:51 -0700 Subject: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed In-Reply-To: <190DD091-23D6-4E74-AA7E-5B87EEE3998C@oracle.com> References: <5D245EC6-47C6-4BF1-A505-89934731A814@oracle.com> <360DDB44-FDFC-41DE-8DF9-9BBA3AF28581@oracle.com> <07C5EC23-C429-4961-B7D3-92B7C32FB535@dslextreme.com> <90BF6135-B457-4BD4-8DFF-9DE94F6D8DC7@oracle.com> <018AAA44-3689-4E79-B090-B0D1F0DD0CC1@oracle.com> <6A375668-62CA-47BE-B2AB-6BB3E7D3BEC0@dslextreme.com> <98CF502C-A96C-40AE-9CF0-E96A3909E517@oracle.com> <190DD091-23D6-4E74-AA7E-5B87EEE3998C@oracle.com> Message-ID: <198CBAA5-AC4E-42D4-B7A3-B4E1ECD68E3B@dslextreme.com> Here is the link to the source - https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;a=blob;f=log4j-perf/src/main/java/org/apache/logging/log4j/perf/jmh/AsyncAppenderLog4j2LocationBenchmark.java;h=c306ac1a0f475d772b6ccb8afa527dc037d7c646;hb=HEAD . You can check out all of Log4j 2 by doing git clone http://git-wip-us.apache.org/repos/asf/logging-log4j2.git Ralph > On May 10, 2016, at 7:26 PM, Mandy Chung wrote: > > >> On May 10, 2016, at 5:17 PM, Ralph Goers wrote: >> >> OK - I try that. My earlier comparison had shown that StackWalker was much faster but since walking the Throwable is so much slower I?m now wondering how much better than Java 7 & 8 it will be. >> >> Any idea why walking the Throwable is so much slower? >> > > No idea yet. Can you share your benchmark so that we can understand what you measure? > > Mandy > >> Ralph >> >>> On May 10, 2016, at 5:01 PM, Mandy Chung wrote: >>> >>> This walks the stack to find a frame with a matching class. Throwable::getStackTrace is taking the entire stack trace. I suggest to try StackWalker and avoids the overhead of dumping the entire stack trace. >>> >>> Mandy >>> >>>> On May 10, 2016, at 10:40 AM, Ralph Goers wrote: >>>> >>>> The benchmark logs events using Log4j 2?s asynchronous loggers. In the process of doing that it captures the location information using the code below: >>>> >>>> >>>> // LOG4J2-1029 new Throwable().getStackTrace is faster than Thread.currentThread().getStackTrace(). >>>> final StackTraceElement[] stackTrace = new Throwable().getStackTrace(); >>>> StackTraceElement last = null; >>>> for (int i = stackTrace.length - 1; i > 0; i--) { >>>> final String className = stackTrace[i].getClassName(); >>>> if (fqcnOfLogger.equals(className)) { >>>> return last; >>>> } >>>> last = stackTrace[i]; >>>> } >>>> return null; >>>> >>>> Ralph >>>> >>>> >>>>> On May 10, 2016, at 9:57 AM, Mandy Chung wrote: >>>>> >>>>> What does your benchmark call? >>>>> >>>>> Mandy >>>>> >>>>>> On May 10, 2016, at 9:49 AM, Ralph Goers wrote: >>>>>> >>>>>> I just ran one of the Log4j performance tests that specifically captures location information. To run the test I do >>>>>> >>>>>> java -jar log4j-perf/target/benchmarks.jar ".*AsyncAppenderLog4j2LocationBenchmark.*" -f 1 -wi 10 -i 20 -t 4 -si true >>>>>> >>>>>> And the results are: >>>>>> >>>>>> java version "1.7.0_80 >>>>>> >>>>>> Benchmark Mode Samples Score Error Units >>>>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 124819.285 ? 3003.918 ops/s >>>>>> >>>>>> java version "1.8.0_65" >>>>>> >>>>>> Benchmark Mode Samples Score Error Units >>>>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 123209.746 ? 3064.672 ops/s >>>>>> >>>>>> >>>>>> java version "9-ea" >>>>>> Java(TM) SE Runtime Environment (build 9-ea+116) >>>>>> >>>>>> Benchmark Mode Samples Score Error Units >>>>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 96090.261 ? 4565.763 ops/s >>>>>> >>>>>> >>>>>> This tells me that Java 9 is about 23% slower than previous versions in walking the stack trace elements. >>>>>> >>>>>> Ralph >>>>>> >>>>>>> On Apr 13, 2016, at 12:03 PM, Mandy Chung wrote: >>>>>>> >>>>>>> If you record all stack frames, I can believe Throwable is faster because of a recent optimization JDK-8150778 that has been made in jdk9 to improve the Throwable::getStackTraceElements method. >>>>>>> >>>>>>> Mandy >>>>>>> >>>>>>>> On Apr 13, 2016, at 11:49 AM, Ralph Goers wrote: >>>>>>>> >>>>>>>> I did a raw test of StackWalker by itself and the performance was much better than using a Throwable to get the location information. However, I haven?t tested how it will be implemented in Log4j. We still support Java 7 (and will for some time) so we have to find a way to support using StackWalker when running on Java 9 even though we build with Java 7. >>>>>>>> >>>>>>>> Ralph >>>>>>>> >>>>>>>>> On Apr 13, 2016, at 10:27 AM, Mandy Chung wrote: >>>>>>>>> >>>>>>>>> It is good to know Log4J is planning to use StackWalker. >>>>>>>>> >>>>>>>>> Thanks for the feedback. I will reconsider. >>>>>>>>> >>>>>>>>> One thing to mention is the patch went in jdk9/hs-rt that will show up in jdk9/dev some time that changes the implementation to create StackTraceElement to get filename and line number. The object allocation should be cheap that does create short-lived objects. The main motivation of JDK-8153123 was to simplify the hotspot implementation that the runtime team had concern about. There is an open issue to follow up the performance (JDK-8153683). It?d be helpful to get your feedback on using StackWalker API and the performance data. >>>>>>>>> >>>>>>>>> Mandy >>>>>>>>> >>>>>>>>>> On Apr 13, 2016, at 6:51 AM, Ralph Goers wrote: >>>>>>>>>> >>>>>>>>>> I had planned on using StackWalker to generate the location information for every logging event. It seems that this change would thus cause the creation of a new StackTraceElement for every logger event. That seems wasteful. Log4j is currently in the process of trying to reduce the number of objects that are created while logging as it has a significant impact on garbage collection. So I am also in favor of getting the filename and line number directly from the StackFrame. >>>>>>>>>> >>>>>>>>>> Ralph >>>>>>>>>> >>>>>>>>>>> On Apr 12, 2016, at 5:15 PM, Mandy Chung wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Apr 12, 2016, at 1:34 AM, R?mi Forax wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Mandy, >>>>>>>>>>>> I really don't like this patch. >>>>>>>>>>>> >>>>>>>>>>>> Being forced to call toStackElement to get the line number is counter intuitive. >>>>>>>>>>>> I would prefer the two methods to not return Optional but an int and a String with the same convention as StackElement if the point of this patch is to remove the dependency to Optional. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I was expecting the common usage of StackWalker API does not need file name and line number. I think it'd be useful to include StackFrame::getBci (in the future it might include live information like locals etc) and keep the optional stuff and uncommon usage to StackTraceElement. >>>>>>>>>>> >>>>>>>>>>> Mandy >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> R?mi >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Le 11 avril 2016 23:22:39 CEST, Mandy Chung a ?crit : >>>>>>>>>>>>> Webrev at: >>>>>>>>>>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.00/index.html >>>>>>>>>>>>> >>>>>>>>>>>>> StackFrame::getFileName and StackFrame::getLineNumber are originally >>>>>>>>>>>>> proposed with the view of any stack walking code can migrate to the >>>>>>>>>>>>> StackWalker API without the use of StackTraceElement. >>>>>>>>>>>>> >>>>>>>>>>>>> File name and line number are useful for debugging and troubleshooting >>>>>>>>>>>>> purpose. It has additional overhead to map from a method and BCI to >>>>>>>>>>>>> look up the file name and line number. >>>>>>>>>>>>> >>>>>>>>>>>>> StackFrame::toStackTraceElement method returns StackTraceElement that >>>>>>>>>>>>> includes the file name and line number. There is no particular benefit >>>>>>>>>>>>> to duplicate getFileName and getLineNumber methods in StackFrame. It is >>>>>>>>>>>>> equivalently convenient to call >>>>>>>>>>>>> StackFrame.toStackTraceElement().getFileName() (or getLineNumber). >>>>>>>>>>>>> >>>>>>>>>>>>> This patch proposes to remove StackFrame::getFileName and >>>>>>>>>>>>> StackFrame::getLineNumber methods since such information can be >>>>>>>>>>>>> obtained from StackFrame.toStackTraceElement(). >>>>>>>>>>>>> >>>>>>>>>>>>> Mandy >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> > > From ralph.goers at dslextreme.com Wed May 11 02:40:19 2016 From: ralph.goers at dslextreme.com (Ralph Goers) Date: Tue, 10 May 2016 19:40:19 -0700 Subject: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed In-Reply-To: <198CBAA5-AC4E-42D4-B7A3-B4E1ECD68E3B@dslextreme.com> References: <5D245EC6-47C6-4BF1-A505-89934731A814@oracle.com> <360DDB44-FDFC-41DE-8DF9-9BBA3AF28581@oracle.com> <07C5EC23-C429-4961-B7D3-92B7C32FB535@dslextreme.com> <90BF6135-B457-4BD4-8DFF-9DE94F6D8DC7@oracle.com> <018AAA44-3689-4E79-B090-B0D1F0DD0CC1@oracle.com> <6A375668-62CA-47BE-B2AB-6BB3E7D3BEC0@dslextreme.com> <98CF502C-A96C-40AE-9CF0-E96A3909E517@oracle.com> <190DD091-23D6-4E74-AA7E-5B87EEE3998C@oracle.com> <198CBAA5-AC4E-42D4-B7A3-B4E1ECD68E3B@dslextreme.com> Message-ID: <57DB20EB-AE44-43AE-894D-35E29FE1C386@dslextreme.com> I should mention - if you actually want to run the test you should checkout the source and then build it. Just run mvn clean install. Once you have done that the log4j-perf module has all the performance tests. Most of the tests have the command line you can use to run the test. Ralph > On May 10, 2016, at 7:34 PM, Ralph Goers wrote: > > Here is the link to the source - https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;a=blob;f=log4j-perf/src/main/java/org/apache/logging/log4j/perf/jmh/AsyncAppenderLog4j2LocationBenchmark.java;h=c306ac1a0f475d772b6ccb8afa527dc037d7c646;hb=HEAD . You can check out all of Log4j 2 by doing > > git clone http://git-wip-us.apache.org/repos/asf/logging-log4j2.git > > Ralph > > > >> On May 10, 2016, at 7:26 PM, Mandy Chung > wrote: >> >> >>> On May 10, 2016, at 5:17 PM, Ralph Goers > wrote: >>> >>> OK - I try that. My earlier comparison had shown that StackWalker was much faster but since walking the Throwable is so much slower I?m now wondering how much better than Java 7 & 8 it will be. >>> >>> Any idea why walking the Throwable is so much slower? >>> >> >> No idea yet. Can you share your benchmark so that we can understand what you measure? >> >> Mandy >> >>> Ralph >>> >>>> On May 10, 2016, at 5:01 PM, Mandy Chung > wrote: >>>> >>>> This walks the stack to find a frame with a matching class. Throwable::getStackTrace is taking the entire stack trace. I suggest to try StackWalker and avoids the overhead of dumping the entire stack trace. >>>> >>>> Mandy >>>> >>>>> On May 10, 2016, at 10:40 AM, Ralph Goers > wrote: >>>>> >>>>> The benchmark logs events using Log4j 2?s asynchronous loggers. In the process of doing that it captures the location information using the code below: >>>>> >>>>> >>>>> // LOG4J2-1029 new Throwable().getStackTrace is faster than Thread.currentThread().getStackTrace(). >>>>> final StackTraceElement[] stackTrace = new Throwable().getStackTrace(); >>>>> StackTraceElement last = null; >>>>> for (int i = stackTrace.length - 1; i > 0; i--) { >>>>> final String className = stackTrace[i].getClassName(); >>>>> if (fqcnOfLogger.equals(className)) { >>>>> return last; >>>>> } >>>>> last = stackTrace[i]; >>>>> } >>>>> return null; >>>>> >>>>> Ralph >>>>> >>>>> >>>>>> On May 10, 2016, at 9:57 AM, Mandy Chung > wrote: >>>>>> >>>>>> What does your benchmark call? >>>>>> >>>>>> Mandy >>>>>> >>>>>>> On May 10, 2016, at 9:49 AM, Ralph Goers > wrote: >>>>>>> >>>>>>> I just ran one of the Log4j performance tests that specifically captures location information. To run the test I do >>>>>>> >>>>>>> java -jar log4j-perf/target/benchmarks.jar ".*AsyncAppenderLog4j2LocationBenchmark.*" -f 1 -wi 10 -i 20 -t 4 -si true >>>>>>> >>>>>>> And the results are: >>>>>>> >>>>>>> java version "1.7.0_80 >>>>>>> >>>>>>> Benchmark Mode Samples Score Error Units >>>>>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 124819.285 ? 3003.918 ops/s >>>>>>> >>>>>>> java version "1.8.0_65" >>>>>>> >>>>>>> Benchmark Mode Samples Score Error Units >>>>>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 123209.746 ? 3064.672 ops/s >>>>>>> >>>>>>> >>>>>>> java version "9-ea" >>>>>>> Java(TM) SE Runtime Environment (build 9-ea+116) >>>>>>> >>>>>>> Benchmark Mode Samples Score Error Units >>>>>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 96090.261 ? 4565.763 ops/s >>>>>>> >>>>>>> >>>>>>> This tells me that Java 9 is about 23% slower than previous versions in walking the stack trace elements. >>>>>>> >>>>>>> Ralph >>>>>>> >>>>>>>> On Apr 13, 2016, at 12:03 PM, Mandy Chung > wrote: >>>>>>>> >>>>>>>> If you record all stack frames, I can believe Throwable is faster because of a recent optimization JDK-8150778 that has been made in jdk9 to improve the Throwable::getStackTraceElements method. >>>>>>>> >>>>>>>> Mandy >>>>>>>> >>>>>>>>> On Apr 13, 2016, at 11:49 AM, Ralph Goers > wrote: >>>>>>>>> >>>>>>>>> I did a raw test of StackWalker by itself and the performance was much better than using a Throwable to get the location information. However, I haven?t tested how it will be implemented in Log4j. We still support Java 7 (and will for some time) so we have to find a way to support using StackWalker when running on Java 9 even though we build with Java 7. >>>>>>>>> >>>>>>>>> Ralph >>>>>>>>> >>>>>>>>>> On Apr 13, 2016, at 10:27 AM, Mandy Chung > wrote: >>>>>>>>>> >>>>>>>>>> It is good to know Log4J is planning to use StackWalker. >>>>>>>>>> >>>>>>>>>> Thanks for the feedback. I will reconsider. >>>>>>>>>> >>>>>>>>>> One thing to mention is the patch went in jdk9/hs-rt that will show up in jdk9/dev some time that changes the implementation to create StackTraceElement to get filename and line number. The object allocation should be cheap that does create short-lived objects. The main motivation of JDK-8153123 was to simplify the hotspot implementation that the runtime team had concern about. There is an open issue to follow up the performance (JDK-8153683). It?d be helpful to get your feedback on using StackWalker API and the performance data. >>>>>>>>>> >>>>>>>>>> Mandy >>>>>>>>>> >>>>>>>>>>> On Apr 13, 2016, at 6:51 AM, Ralph Goers > wrote: >>>>>>>>>>> >>>>>>>>>>> I had planned on using StackWalker to generate the location information for every logging event. It seems that this change would thus cause the creation of a new StackTraceElement for every logger event. That seems wasteful. Log4j is currently in the process of trying to reduce the number of objects that are created while logging as it has a significant impact on garbage collection. So I am also in favor of getting the filename and line number directly from the StackFrame. >>>>>>>>>>> >>>>>>>>>>> Ralph >>>>>>>>>>> >>>>>>>>>>>> On Apr 12, 2016, at 5:15 PM, Mandy Chung > wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Apr 12, 2016, at 1:34 AM, R?mi Forax > wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Mandy, >>>>>>>>>>>>> I really don't like this patch. >>>>>>>>>>>>> >>>>>>>>>>>>> Being forced to call toStackElement to get the line number is counter intuitive. >>>>>>>>>>>>> I would prefer the two methods to not return Optional but an int and a String with the same convention as StackElement if the point of this patch is to remove the dependency to Optional. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I was expecting the common usage of StackWalker API does not need file name and line number. I think it'd be useful to include StackFrame::getBci (in the future it might include live information like locals etc) and keep the optional stuff and uncommon usage to StackTraceElement. >>>>>>>>>>>> >>>>>>>>>>>> Mandy >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> R?mi >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Le 11 avril 2016 23:22:39 CEST, Mandy Chung > a ?crit : >>>>>>>>>>>>>> Webrev at: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.00/index.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> StackFrame::getFileName and StackFrame::getLineNumber are originally >>>>>>>>>>>>>> proposed with the view of any stack walking code can migrate to the >>>>>>>>>>>>>> StackWalker API without the use of StackTraceElement. >>>>>>>>>>>>>> >>>>>>>>>>>>>> File name and line number are useful for debugging and troubleshooting >>>>>>>>>>>>>> purpose. It has additional overhead to map from a method and BCI to >>>>>>>>>>>>>> look up the file name and line number. >>>>>>>>>>>>>> >>>>>>>>>>>>>> StackFrame::toStackTraceElement method returns StackTraceElement that >>>>>>>>>>>>>> includes the file name and line number. There is no particular benefit >>>>>>>>>>>>>> to duplicate getFileName and getLineNumber methods in StackFrame. It is >>>>>>>>>>>>>> equivalently convenient to call >>>>>>>>>>>>>> StackFrame.toStackTraceElement().getFileName() (or getLineNumber). >>>>>>>>>>>>>> >>>>>>>>>>>>>> This patch proposes to remove StackFrame::getFileName and >>>>>>>>>>>>>> StackFrame::getLineNumber methods since such information can be >>>>>>>>>>>>>> obtained from StackFrame.toStackTraceElement(). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Mandy >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> >> > From martinrb at google.com Wed May 11 02:59:19 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 10 May 2016 19:59:19 -0700 Subject: RFR(m): 8140281 deprecate Optional.get() In-Reply-To: <350f4ee8-e59a-1518-adda-1a52f3654b96@oracle.com> References: <1282fc0c-2d92-be13-d95e-9486cd556146@oracle.com> <571EA9D8.3010702@oracle.com> <5dad068b-038e-591c-49a1-ffcc22ffebb8@oracle.com> <350f4ee8-e59a-1518-adda-1a52f3654b96@oracle.com> Message-ID: Consider a library like guava classic. It currently supports jdk 6+, and there's a good chance that library will do that until its end of life, which is likely to be around the time when EVERYBODY is using jdk 8+, which is still many years away. Even there, it would be nice to compile with javac 9 without any warnings. Proliferation of deprecation warnings in new JDK releases leave conscientious library maintainers with no choice but to spray @SuppressWarnings everywhere. They may even end up doing so preemptively. The deprecation warnings are pure pain; no benefit; the replacement API may never be an option for such a library. The older Java gets, the more players in the ecosystem, and the slower the adoption curve. Maybe if we were serious about the javac -release flag, we would have deprecation warnings only when the replacement API is actually available in the targeted release? That might be progress! On Tue, May 10, 2016 at 5:44 PM, Stuart Marks wrote: > On 4/28/16 7:23 PM, Martin Buchholz wrote: >> >> No opinion on Optional.get() itself, but here's an opinion on the high >> cost of deprecation. >> >> If you deprecate the API today, and I have a library that is already >> using the API, then I should add a @SuppressWarning("deprecation") >> today and keep it there until the number of people using pre-jdk9 is >> insignificant, when I can finally rename it. How long is that? These >> days, I estimate at least 10 years. But even 20 years is quite >> possible. > > > Hi Martin, > > Finally getting back to this. > > Thanks for this observation on the cost of deprecation. I think there are > several things going on here. > > One is how long such annotations need to live in the source base. I see the > concern but I'm not sure where you're getting your lifetime numbers. > Certainly there's a support lifetime for old JDK releases. I'm hearing about > various systems migrating away from Java 7 now, and that's five years old. > There are still various things that need to support Java 6 (ten years old), > but I think this is exacerbated by the abnormally long gap between 6 and 7. > > But, continuing the scenario, suppose something is deprecated in JDK 9, and > you add @SuppressWarnings to shut off the new warnings it generates. You > can't migrate to the replacement API introduced in JDK 9, since you still > have to support JDK 6, 7, and 8, so you have to leave @SW in until you drop > support for 8, which might not be for many years. Is that the source of your > concern? I'm kind of guessing here. > > An additional problem with @SuppressWarnings("deprecation"), and its > companion command-line option -Xlint:-deprecation, is that it's too broad a > brush. They shut of *all* deprecation warnings, at least, for the scope of > code to which they're applied. If @SW is added to suppress deprecation > warnings on X, and later on Y is deprecated, deprecation warnings on uses of > Y will also get suppressed. That's likely a problem. > > It seems to me that when we're talking about costs of deprecation, the main > issue is how to manage warnings, in code bases that support multiple > releases, and when different things are deprecated in different releases. Is > it really about warnings? Or is there some other cost that we should be > thinking about as well? > > s'marks From mandy.chung at oracle.com Wed May 11 03:24:35 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 10 May 2016 20:24:35 -0700 Subject: RFR: regex changes -- sun.security.util.Debug issue In-Reply-To: References: <56EC5F76.4080106@oracle.com> <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> <57319C0C.8070702@oracle.com> <57322F36.2060709@oracle.com> <57324030.6000509@oracle.com> Message-ID: <114F0626-D41B-41F2-A2A5-644D5C4A430D@oracle.com> > On May 10, 2016, at 1:44 PM, Xueming Shen wrote: > > On 5/10/16 1:10 PM, Alan Bateman wrote: >> >> >> On 10/05/2016 19:57, Xueming Shen wrote: >>> webrev has been updated as suggested, now the lazily-init-class-holder is used >>> to delay the Debug initialization. Tests all passed locally. A jprt job is out to confirm. >>> >>> Here is the updated webrev >>> >>> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ >> This looks okay, are exploded builds okay too? >> >> -Alan > > > jprt job appears to be OK. > > exploded build failed here and there for various reasons, for example "access denied". but it has > nothing to do with the regex change. a jdk9_dev build without any update fails as well with the same > reason at same place. here is one example > The security policy in the build only grants to jrt: code source and running with the exploded image won?t work with that. It?d be nice to avoid running with a different java.policy: https://bugs.openjdk.java.net/browse/JDK-8155858 Mandy From mandy.chung at oracle.com Wed May 11 03:52:32 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 10 May 2016 20:52:32 -0700 Subject: RFR: 8156153: java/lang/System/LoggerFinder/jdk/DefaultLoggerBridgeTest/DefaultLoggerBridgeTest.java fails with java.lang.RuntimeException In-Reply-To: <84bd7a46-09cb-24dd-0814-856a8218d8e6@oracle.com> References: <84bd7a46-09cb-24dd-0814-856a8218d8e6@oracle.com> Message-ID: > On May 6, 2016, at 7:22 AM, Daniel Fuchs wrote: > > Hi, > > This is a fix for a subtle test bug caused by a logger being GCed. > > bug id: > https://bugs.openjdk.java.net/browse/JDK-8156153 > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8156153/webrev/ > +1. This one is hard to analyze. Running them in othervm should help. Mandy From ropalka at redhat.com Wed May 11 06:40:47 2016 From: ropalka at redhat.com (Richard Opalka) Date: Wed, 11 May 2016 08:40:47 +0200 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> <13C89E01-3396-4EFE-BC35-C289E59DBEED@oracle.com> <5707CFBB.8020809@oracle.com> <5028AF86-C8DD-431E-8499-0022B8D90C85@oracle.com> <1d3d6b24-5168-cc5c-942b-2bbda7f2d257@redhat.com> Message-ID: <857c3a19-1969-b96d-63dc-bfb24d70cba6@redhat.com> On 05/10/2016 10:50 AM, Chris Hegarty wrote: > On 9 May 2016, at 20:43, Richard Opalka wrote: > >> Fixed in JBoss Marshalling upstream. > Thanks for fixing this, and getting back to us on the list. > > I assume then that, at least, this part of JBoss is working on JDK 9 b115, right? Yes. Rio > > -Chris. > >> Thanks, >> >> Rio >> >> On 04/27/2016 11:54 PM, Chris Hegarty wrote: >>> Hi Rio, >>> >>> >>>> We are missing sun/reflect/ReflectionFactory$GetReflectionFactoryAction inner class >>>> >>>> in jdk.unsupported module: >>>> >>>> java.lang.NoClassDefFoundError: sun/reflect/ReflectionFactory$GetReflectionFactoryAction >>>> at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base at 9-internal/BuiltinClassLoader.java:366) >>>> at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base at 9-internal/ClassLoaders.java:184) >>>> at java.lang.ClassLoader.loadClass(java.base at 9-internal/ClassLoader.java:419) >>>> at org.jboss.marshalling.reflect.SerializableClass.(SerializableClass.java:47) >>> GetReflectionFactoryAction is a convenience class for acquiring >>> the capability to instantiate reflective objects. >>> >>> As part of JEP 260, we retained the single getReflectionFactory >>> accessor. You can replace your usage with the following: >>> >>> PrivilegedAction pa = new PrivilegedAction() { >>> @Override >>> public ReflectionFactory run() { >>> return ReflectionFactory.getReflectionFactory(); >>> } >>> }; >>> >>> -Chris. >>> From peter.levart at gmail.com Wed May 11 07:05:47 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 11 May 2016 09:05:47 +0200 Subject: RFR(m): 8140281 deprecate Optional.get() In-Reply-To: <350f4ee8-e59a-1518-adda-1a52f3654b96@oracle.com> References: <1282fc0c-2d92-be13-d95e-9486cd556146@oracle.com> <571EA9D8.3010702@oracle.com> <5dad068b-038e-591c-49a1-ffcc22ffebb8@oracle.com> <350f4ee8-e59a-1518-adda-1a52f3654b96@oracle.com> Message-ID: <67663ca2-789f-043a-5060-a8e24e47b982@gmail.com> On 05/11/2016 02:44 AM, Stuart Marks wrote: > On 4/28/16 7:23 PM, Martin Buchholz wrote: >> No opinion on Optional.get() itself, but here's an opinion on the high >> cost of deprecation. >> >> If you deprecate the API today, and I have a library that is already >> using the API, then I should add a @SuppressWarning("deprecation") >> today and keep it there until the number of people using pre-jdk9 is >> insignificant, when I can finally rename it. How long is that? These >> days, I estimate at least 10 years. But even 20 years is quite >> possible. > > Hi Martin, > > Finally getting back to this. > > Thanks for this observation on the cost of deprecation. I think there > are several things going on here. > > One is how long such annotations need to live in the source base. I > see the concern but I'm not sure where you're getting your lifetime > numbers. Certainly there's a support lifetime for old JDK releases. > I'm hearing about various systems migrating away from Java 7 now, and > that's five years old. There are still various things that need to > support Java 6 (ten years old), but I think this is exacerbated by the > abnormally long gap between 6 and 7. > > But, continuing the scenario, suppose something is deprecated in JDK > 9, and you add @SuppressWarnings to shut off the new warnings it > generates. You can't migrate to the replacement API introduced in JDK > 9, since you still have to support JDK 6, 7, and 8, so you have to > leave @SW in until you drop support for 8, which might not be for many > years. Is that the source of your concern? I'm kind of guessing here. > > An additional problem with @SuppressWarnings("deprecation"), and its > companion command-line option -Xlint:-deprecation, is that it's too > broad a brush. They shut of *all* deprecation warnings, at least, for > the scope of code to which they're applied. If @SW is added to > suppress deprecation warnings on X, and later on Y is deprecated, > deprecation warnings on uses of Y will also get suppressed. That's > likely a problem. > > It seems to me that when we're talking about costs of deprecation, the > main issue is how to manage warnings, in code bases that support > multiple releases, and when different things are deprecated in > different releases. Is it really about warnings? Or is there some > other cost that we should be thinking about as well? Couldn't this new @Deprecated.since annotation attribute play a role here? For example, if you are building with JDK 9 javac, but specify -release 8 option, then you don't get deprecation warning for methods annotated with @Deprecated(since = "9"). Regards, Peter > > s'marks From Alan.Bateman at oracle.com Wed May 11 07:18:18 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 May 2016 08:18:18 +0100 Subject: Memory leak in com.sun.jndi.ldap.pool.PoolCleaner In-Reply-To: References: Message-ID: <5732DCBA.7010505@oracle.com> On 10/05/2016 23:05, Mark Thomas wrote: > Hi, > > While working my way through Tomcat's memory leak protection / detection > / fixing code, I have found an issue that remains unresolved in the > latest JDK 9 source. > > The PoolCleaner thread started by the LdapPoolManager when the idle > timeout is positive does not explicitly set the context class loader so > it inherits the current context class loader. If the current context > class loader when this code is triggered happens to be one that is meant > to be disposable (e.g. a web application class loader) the class loader > will be pinned in memory until the Thread stops. This prevents the class > loader from being GC'd when no longer required and triggers a mmeory leak. > > The fix looks to be trivial. Something along the lines of the following > around line 45 of PoolCleaner: > > setContextClassLoader(PoolCleaner.class.getClassLoader()); > > If I can provide any further information or if there is better place / > way to submit this then please do let me know. > This may be a case where it should be using an InnocuousThread but requires more study as it's very old code. Can you submit a bug for this? -Alan From huizhe.wang at oracle.com Wed May 11 07:20:04 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 11 May 2016 00:20:04 -0700 Subject: RFR (JAXP) 8152912: SAX XMLReaderFactory needs to be ServiceLoader compliant In-Reply-To: <0df05c88-3eb8-0a0c-4196-2136cb51d161@oracle.com> References: <57279CDE.7070207@oracle.com> <6ed137e8-2651-7f6f-50b9-143b00286355@oracle.com> <572940DB.10003@oracle.com> <712af5bd-7ba4-266a-c32e-afd35d8434b4@oracle.com> <5731084B.7040902@oracle.com> <0df05c88-3eb8-0a0c-4196-2136cb51d161@oracle.com> Message-ID: <5732DD24.9000205@oracle.com> On 5/10/2016 4:21 PM, Stuart Marks wrote: > On 5/9/16 2:59 PM, huizhe wang wrote: >>> This looks much better to me. >>> I just wonder about the @Deprecated("5") vs @Deprecated("1.5") >> >> Yes, the compiler accepted it just fine and produced javadocs similar >> to that of >> XMLReaderFactory where since="9". > > Hi Joe, Daniel, > > The namespace of the @Deprecated 'since' element is the same as the > @since javadoc tag. APIs that were added in Java 5 have "@since 1.5" > in their javadoc, so something that was deprecated in Java 5 should be > annotated > > @Deprecated(since="1.5") Make sense (to be consistent with that of javadocs). I'll use the next opportunity to get these fixed. > > It looks like we didn't go to single-digit versions until Java 9. > Earlier versions are still listed as 1.8, 1.7, 1.6, 1.5, and so forth. Interestingly the Java SE Naming and Versions [1] indicated that 5.0, 6, 7, 8 are "product versions", while 1.x are "developer" versions. [1] http://www.oracle.com/technetwork/java/javase/namechange-140185.html -Joe > > s'marks From scolebourne at joda.org Wed May 11 08:30:29 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 11 May 2016 09:30:29 +0100 Subject: RFR:JDK-8155823: Add date-time patterns 'v' and 'vvvv' In-Reply-To: <573227B7.4090603@oracle.com> References: <5730BC5D.7050807@oracle.com> <573227B7.4090603@oracle.com> Message-ID: This seems fine by me. Stephen On 10 May 2016 at 19:25, nadeesh tv wrote: > Hi, > > Stephen, Roger Thanks for the comments. > Please see the updated webrev > http://cr.openjdk.java.net/~ntv/8155823/webrev.04/ > > Apart from the fix, made a correction in the java doc of ZoneRules.java > > Thanks and Regards, > Nadeesh > > On 5/10/2016 12:54 AM, Roger Riggs wrote: > > Hi Nadeesh, > > java/time/format/DateTimeFormatter.java: line 312 > > - Move 'v' up 1 line so it is after 'V' and before 'z'. > Also in DateTimeFormatterBuilder.java: line 1415+ > > - the description of the number of letters does not need to be repeated; > put one copy before the specifics of 'z' and 'v'. > > "If the count of letters is one, then the short name is output. > + * If the count of letters is four, then the full name is output. > + * Two, three and five or more letters throw {@code > IllegalArgumentException}." > > DateTimeFormatterBuilder.java > - line 1625/1626: should include what happens with vv and vvv to be > consistent with DateTimeFormatter doc for ZoneId names. > > - line 1647: The description in DateTimeFormatter says that count = 2 and 3 > should also produce the short value > but the code will throw IAE. > > -line 1988: "almost" --- can this be more specific about what matches or > does not match > > In the test it is a bit bothersome that the tests have to rely on timezone > specific data. > > Thanks, Roger > > On 5/9/2016 12:35 PM, nadeesh tv wrote: > > > Hi all, > > Reposting because subject line did not follow the format. > > Bug Id : https://bugs.openjdk.java.net/browse/JDK-8155823 > Issue: Add date-time patterns 'v' and 'vvvv' > webrev: http://cr.openjdk.java.net/~ntv/8155823/webrev.03/ > > This webrev also contain the fix of related bug > https://bugs.openjdk.java.net/browse/JDK-8154567 as part of this. > > Special thanks for Stephen for his help in writing the spec. > > > > -- > Thanks and Regards, > Nadeesh TV > From Hiroshi.Ito at gs.com Wed May 11 09:25:11 2016 From: Hiroshi.Ito at gs.com (Ito, Hiroshi) Date: Wed, 11 May 2016 09:25:11 +0000 Subject: RFR: Implement RandomAccess spliterator Message-ID: <817c2727755b46bdbf71bc041c5855ea@gsdghkp03etn2.firmwide.corp.gs.com> Hi, Please kindly review the attached patch for RandomAccessSpliterator implementation. Currently default implementation of spliterator is an IteratorSpliterator which is not optimal for RandomAccess data structures (besides ArrayList and Vector). This patch is to provide a default RandomAccessSpliterator implementation for RandomAccess data structure. The figures below demonstrate the performance difference before and after the change. Note the significant performance improvement in test SelectTest.parallel_lazy_streams_gsc (parallel streams performance test for non-JDK Lists that implement RandomAccess but don't yet implement their own spliterators). Benchmark code: https://github.com/goldmansachs/gs-collections/blob/master/jmh-tests/src/main/java/com/gs/collections/impl/jmh/SelectTest.java With IteratorSpliterator as default: Benchmark Mode Cnt Score Error Units SelectTest.parallel_lazy_jdk thrpt 20 172.671 ? 14.231 ops/s SelectTest.parallel_lazy_streams_gsc thrpt 20 20.662 ? 0.493 ops/s SelectTest.serial_lazy_jdk thrpt 20 89.384 ? 4.431 ops/s SelectTest.serial_lazy_streams_gsc thrpt 20 80.831 ? 7.875 ops/s With RandomAccessSpliterator as default: Benchmark Mode Cnt Score Error Units SelectTest.parallel_lazy_jdk thrpt 20 174.190 ? 16.870 ops/s SelectTest.parallel_lazy_streams_gsc thrpt 20 180.740 ? 9.594 ops/s SelectTest.serial_lazy_jdk thrpt 20 85.719 ? 2.414 ops/s SelectTest.serial_lazy_streams_gsc thrpt 20 78.760 ? 1.029 ops/s Majority of the patch is contributed by Paul Sandoz and he should be credited in the Contributed-by field. Along with this patch submission, we have a question for SubList spliterator implementation that we retained old behavior for now (i.e. return IteratorSpliterator, refer to RandomAccessSubList#spliterator()). We have found that Vector's subList is wrapped by RandomAccessSubList, that is RandomAccess but not a Vector anymore, and it expects to use IteratorSpliterator. We were not sure what's the best approach to distinguish Vector from other RandomAccess data structure within RandomAccessSublist, so we kept it return IteratorSpliterator for now. One approach could be to introduce VectorSubList that returns IteratorSpliterator (or an implementation similar to VectorSpliterator?). Then we could revert the spliterator() override in RandomAccessSublist. What would be your suggestion to handle this? Depending on your suggestion, we might fix the subList spliterator in this patch, or submit a separate patch if the amount of the change is significant. Thanks, Hiroshi -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RandomAccessSpliterator.patch.txt URL: From markt at apache.org Wed May 11 11:18:55 2016 From: markt at apache.org (Mark Thomas) Date: Wed, 11 May 2016 12:18:55 +0100 Subject: Memory leak in com.sun.jndi.ldap.pool.PoolCleaner In-Reply-To: <5732DCBA.7010505@oracle.com> References: <5732DCBA.7010505@oracle.com> Message-ID: <0b3579c4-d3d5-ff77-68f0-d1e7749829aa@apache.org> On 11/05/2016 08:18, Alan Bateman wrote: > On 10/05/2016 23:05, Mark Thomas wrote: >> Hi, >> >> While working my way through Tomcat's memory leak protection / detection >> / fixing code, I have found an issue that remains unresolved in the >> latest JDK 9 source. >> >> The PoolCleaner thread started by the LdapPoolManager when the idle >> timeout is positive does not explicitly set the context class loader so >> it inherits the current context class loader. If the current context >> class loader when this code is triggered happens to be one that is meant >> to be disposable (e.g. a web application class loader) the class loader >> will be pinned in memory until the Thread stops. This prevents the class >> loader from being GC'd when no longer required and triggers a mmeory >> leak. >> >> The fix looks to be trivial. Something along the lines of the following >> around line 45 of PoolCleaner: >> >> setContextClassLoader(PoolCleaner.class.getClassLoader()); >> >> If I can provide any further information or if there is better place / >> way to submit this then please do let me know. >> > This may be a case where it should be using an InnocuousThread but > requires more study as it's very old code. > > Can you submit a bug for this? > > -Alan Sure. Done. Review ID: 9087338 Thanks, Mark From shilpi.rastogi at oracle.com Wed May 11 11:24:12 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Wed, 11 May 2016 16:54:12 +0530 Subject: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode Message-ID: <5733165C.6090305@oracle.com> Hi All, Please review one small fix for https://bugs.openjdk.java.net/browse/JDK-8155791 http://cr.openjdk.java.net/~srastogi/8155791/webrev.00/ Thanks, Shilpi From shilpi.rastogi at oracle.com Wed May 11 11:24:09 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Wed, 11 May 2016 16:54:09 +0530 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() Message-ID: <57331659.1030008@oracle.com> Hi All, Please review the following- https://bugs.openjdk.java.net/browse/JDK-8149574 Solution: Changed anonymous class package name with the package name of its host class. Two approaches to solve this- 1. Parse .class and get the class name index form constant pool and patch it with new name http://cr.openjdk.java.net/~srastogi/8149574/webrev.05/ 2. Create class with new name (With ASM) http://cr.openjdk.java.net/~srastogi/8149574/webrev.06/ Which approach is better? Thanks, Shilpi From forax at univ-mlv.fr Wed May 11 12:44:59 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 11 May 2016 14:44:59 +0200 (CEST) Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <57331659.1030008@oracle.com> References: <57331659.1030008@oracle.com> Message-ID: <1349119918.1331243.1462970699135.JavaMail.zimbra@u-pem.fr> Hi all, changing the behavior of defineAnonymousClass in 9 is huge burden for me and i believe for anybody that maintains a dynamic language runtime. As an implementer, being able to choose the package of an anonymous class is an important feature. I use to choose carefully the package name for: - filtering the stack trace element that will be shown or not to the user. This patch specifically broke the stack trace that my runtime will emit because it removes "java.lang.invoke". I'm not the only one to filter out stacktrace element that starts with "java.lang.invoke", Nashorn or JRuby do that too. I can modify the code to use the new StackWalking API if all the method handle form artifact are marked with an interface or something like this. - generate proxy in an existing package see https://github.com/forax/proxy2 - generate code specialization (specialization of an existing method for some primitive types) of an existing class in an existing package (for the specialization, i specialize the constant pool at runtime so i have no choice but to use defineAnonymousClass). I understand that being able to generate a class in any package do not work well with the jigsaw view of the world but that's why defineAnonymousClass is in Unsafe after all. regards, R?mi ----- Mail original ----- > De: "shilpi rastogi" > ?: core-libs-dev at openjdk.java.net, "John Rose" , "Michael Haupt" , > "paul sandoz" , "Vladimir Ivanov" > Envoy?: Mercredi 11 Mai 2016 13:24:09 > Objet: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() > > Hi All, > > Please review the following- > > https://bugs.openjdk.java.net/browse/JDK-8149574 > > Solution: Changed anonymous class package name with the package name of > its host class. > > Two approaches to solve this- > 1. Parse .class and get the class name index form constant pool and > patch it with new name > http://cr.openjdk.java.net/~srastogi/8149574/webrev.05/ > > 2. Create class with new name (With ASM) > http://cr.openjdk.java.net/~srastogi/8149574/webrev.06/ > > Which approach is better? > > Thanks, > Shilpi > > > > From vladimir.x.ivanov at oracle.com Wed May 11 12:50:25 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 11 May 2016 15:50:25 +0300 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <1349119918.1331243.1462970699135.JavaMail.zimbra@u-pem.fr> References: <57331659.1030008@oracle.com> <1349119918.1331243.1462970699135.JavaMail.zimbra@u-pem.fr> Message-ID: <4ec613e7-72ee-7152-3182-06d7abc26e16@oracle.com> Remi, I'm curious why doesn't @Hidden on the invoker method solve your problem? Best regards, Vladimir Ivanov On 5/11/16 3:44 PM, Remi Forax wrote: > Hi all, > changing the behavior of defineAnonymousClass in 9 is huge burden for me and i believe for anybody that maintains a dynamic language runtime. > > As an implementer, being able to choose the package of an anonymous class is an important feature. > I use to choose carefully the package name for: > - filtering the stack trace element that will be shown or not to the user. > This patch specifically broke the stack trace that my runtime will emit because it removes "java.lang.invoke". > I'm not the only one to filter out stacktrace element that starts with "java.lang.invoke", Nashorn or JRuby do that too. > I can modify the code to use the new StackWalking API if all the method handle form artifact are marked with an interface or something like this. > > - generate proxy in an existing package > see https://github.com/forax/proxy2 > > - generate code specialization (specialization of an existing method for some primitive types) of an existing class in an existing package > (for the specialization, i specialize the constant pool at runtime so i have no choice but to use defineAnonymousClass). > > > I understand that being able to generate a class in any package do not work well with the jigsaw view of the world but that's why defineAnonymousClass is in Unsafe after all. > > regards, > R?mi > > ----- Mail original ----- >> De: "shilpi rastogi" >> ?: core-libs-dev at openjdk.java.net, "John Rose" , "Michael Haupt" , >> "paul sandoz" , "Vladimir Ivanov" >> Envoy?: Mercredi 11 Mai 2016 13:24:09 >> Objet: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() >> >> Hi All, >> >> Please review the following- >> >> https://bugs.openjdk.java.net/browse/JDK-8149574 >> >> Solution: Changed anonymous class package name with the package name of >> its host class. >> >> Two approaches to solve this- >> 1. Parse .class and get the class name index form constant pool and >> patch it with new name >> http://cr.openjdk.java.net/~srastogi/8149574/webrev.05/ >> >> 2. Create class with new name (With ASM) >> http://cr.openjdk.java.net/~srastogi/8149574/webrev.06/ >> >> Which approach is better? >> >> Thanks, >> Shilpi >> >> >> >> From forax at univ-mlv.fr Wed May 11 12:59:41 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 11 May 2016 14:59:41 +0200 (CEST) Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <4ec613e7-72ee-7152-3182-06d7abc26e16@oracle.com> References: <57331659.1030008@oracle.com> <1349119918.1331243.1462970699135.JavaMail.zimbra@u-pem.fr> <4ec613e7-72ee-7152-3182-06d7abc26e16@oracle.com> Message-ID: <1127572292.1337220.1462971581724.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Vladimir Ivanov" > ?: "Remi Forax" , "shilpi rastogi" > Cc: core-libs-dev at openjdk.java.net, "John Rose" , "Michael Haupt" , > "paul sandoz" , "Da Vinci Machine Project" > Envoy?: Mercredi 11 Mai 2016 14:50:25 > Objet: Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() > > Remi, I'm curious why doesn't @Hidden on the invoker method solve your > problem? > > Best regards, > Vladimir Ivanov Hi Vladimir, as far as i know @Hidden only work on the stackframe that correspond to a method marked with @Hidden, not for the stackframe on top of the stackframe marked. So having the invoker marked with @Hidden is not enough, but maybe i'm wrong. R?mi > > On 5/11/16 3:44 PM, Remi Forax wrote: > > Hi all, > > changing the behavior of defineAnonymousClass in 9 is huge burden for me > > and i believe for anybody that maintains a dynamic language runtime. > > > > As an implementer, being able to choose the package of an anonymous class > > is an important feature. > > I use to choose carefully the package name for: > > - filtering the stack trace element that will be shown or not to the user. > > This patch specifically broke the stack trace that my runtime will emit > > because it removes "java.lang.invoke". > > I'm not the only one to filter out stacktrace element that starts with > > "java.lang.invoke", Nashorn or JRuby do that too. > > I can modify the code to use the new StackWalking API if all the method > > handle form artifact are marked with an interface or something like > > this. > > > > - generate proxy in an existing package > > see https://github.com/forax/proxy2 > > > > - generate code specialization (specialization of an existing method for > > some primitive types) of an existing class in an existing package > > (for the specialization, i specialize the constant pool at runtime so i > > have no choice but to use defineAnonymousClass). > > > > > > I understand that being able to generate a class in any package do not work > > well with the jigsaw view of the world but that's why defineAnonymousClass > > is in Unsafe after all. > > > > regards, > > R?mi > > > > ----- Mail original ----- > >> De: "shilpi rastogi" > >> ?: core-libs-dev at openjdk.java.net, "John Rose" , > >> "Michael Haupt" , > >> "paul sandoz" , "Vladimir Ivanov" > >> > >> Envoy?: Mercredi 11 Mai 2016 13:24:09 > >> Objet: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of > >> Unsafe.defineAnonymousClass() > >> > >> Hi All, > >> > >> Please review the following- > >> > >> https://bugs.openjdk.java.net/browse/JDK-8149574 > >> > >> Solution: Changed anonymous class package name with the package name of > >> its host class. > >> > >> Two approaches to solve this- > >> 1. Parse .class and get the class name index form constant pool and > >> patch it with new name > >> http://cr.openjdk.java.net/~srastogi/8149574/webrev.05/ > >> > >> 2. Create class with new name (With ASM) > >> http://cr.openjdk.java.net/~srastogi/8149574/webrev.06/ > >> > >> Which approach is better? > >> > >> Thanks, > >> Shilpi > >> > >> > >> > >> > From vladimir.x.ivanov at oracle.com Wed May 11 13:10:02 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 11 May 2016 16:10:02 +0300 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <1127572292.1337220.1462971581724.JavaMail.zimbra@u-pem.fr> References: <57331659.1030008@oracle.com> <1349119918.1331243.1462970699135.JavaMail.zimbra@u-pem.fr> <4ec613e7-72ee-7152-3182-06d7abc26e16@oracle.com> <1127572292.1337220.1462971581724.JavaMail.zimbra@u-pem.fr> Message-ID: <6be1985e-ea21-ca5a-a545-ec0928251c15@oracle.com> Let me clarify: both proposed patches move invoker class out of java.lang.invoke package, but add @Hidden on invoke_V instead. So, JVM should not list it in stack traces and you don't have to filter it out on your side. Moreover, I think the absence of @Hidden on j.l.i.MethodHandleImpl.T.invoke_V was an overlook. Best regards, Vladimir Ivanov On 5/11/16 3:59 PM, forax at univ-mlv.fr wrote: > ----- Mail original ----- >> De: "Vladimir Ivanov" >> ?: "Remi Forax" , "shilpi rastogi" >> Cc: core-libs-dev at openjdk.java.net, "John Rose" , "Michael Haupt" , >> "paul sandoz" , "Da Vinci Machine Project" >> Envoy?: Mercredi 11 Mai 2016 14:50:25 >> Objet: Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() >> >> Remi, I'm curious why doesn't @Hidden on the invoker method solve your >> problem? >> >> Best regards, >> Vladimir Ivanov > > Hi Vladimir, > as far as i know @Hidden only work on the stackframe that correspond to a method marked with @Hidden, > not for the stackframe on top of the stackframe marked. > So having the invoker marked with @Hidden is not enough, but maybe i'm wrong. > > R?mi > >> >> On 5/11/16 3:44 PM, Remi Forax wrote: >>> Hi all, >>> changing the behavior of defineAnonymousClass in 9 is huge burden for me >>> and i believe for anybody that maintains a dynamic language runtime. >>> >>> As an implementer, being able to choose the package of an anonymous class >>> is an important feature. >>> I use to choose carefully the package name for: >>> - filtering the stack trace element that will be shown or not to the user. >>> This patch specifically broke the stack trace that my runtime will emit >>> because it removes "java.lang.invoke". >>> I'm not the only one to filter out stacktrace element that starts with >>> "java.lang.invoke", Nashorn or JRuby do that too. >>> I can modify the code to use the new StackWalking API if all the method >>> handle form artifact are marked with an interface or something like >>> this. >>> >>> - generate proxy in an existing package >>> see https://github.com/forax/proxy2 >>> >>> - generate code specialization (specialization of an existing method for >>> some primitive types) of an existing class in an existing package >>> (for the specialization, i specialize the constant pool at runtime so i >>> have no choice but to use defineAnonymousClass). >>> >>> >>> I understand that being able to generate a class in any package do not work >>> well with the jigsaw view of the world but that's why defineAnonymousClass >>> is in Unsafe after all. >>> >>> regards, >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "shilpi rastogi" >>>> ?: core-libs-dev at openjdk.java.net, "John Rose" , >>>> "Michael Haupt" , >>>> "paul sandoz" , "Vladimir Ivanov" >>>> >>>> Envoy?: Mercredi 11 Mai 2016 13:24:09 >>>> Objet: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of >>>> Unsafe.defineAnonymousClass() >>>> >>>> Hi All, >>>> >>>> Please review the following- >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8149574 >>>> >>>> Solution: Changed anonymous class package name with the package name of >>>> its host class. >>>> >>>> Two approaches to solve this- >>>> 1. Parse .class and get the class name index form constant pool and >>>> patch it with new name >>>> http://cr.openjdk.java.net/~srastogi/8149574/webrev.05/ >>>> >>>> 2. Create class with new name (With ASM) >>>> http://cr.openjdk.java.net/~srastogi/8149574/webrev.06/ >>>> >>>> Which approach is better? >>>> >>>> Thanks, >>>> Shilpi >>>> >>>> >>>> >>>> >> From michael.haupt at oracle.com Wed May 11 13:17:13 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 11 May 2016 15:17:13 +0200 Subject: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode In-Reply-To: <5733165C.6090305@oracle.com> References: <5733165C.6090305@oracle.com> Message-ID: <94710EE3-E8C4-4B0D-A21C-4458B1E905C3@oracle.com> Hi Shilpi, not a review - the bug mentions that this issue is fixed in Jake already and that the bug should be closed once the fix from Jake propagates to dev. What is the status of that? Best, Michael > Am 11.05.2016 um 13:24 schrieb shilpi.rastogi at oracle.com: > > Hi All, > > Please review one small fix for > > https://bugs.openjdk.java.net/browse/JDK-8155791 > http://cr.openjdk.java.net/~srastogi/8155791/webrev.00/ > > Thanks, > Shilpi -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Wed May 11 13:23:27 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 11 May 2016 15:23:27 +0200 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <57331659.1030008@oracle.com> References: <57331659.1030008@oracle.com> Message-ID: <7A23323B-BCF8-4523-823F-F2E142ED7BE5@oracle.com> Hi Shilpi, thank you for preparing these patches. They both implement solution (A), which is to patch the package name. As it happens, most of the complexity in the solutions is due to the desire to make the solution tidy in terms of association of the anonymous class with the host class' package. As the bug description mentions, this is not necessary: the alternative solution (B), namely to have the anonymous class in the default package, appears to be more interesting due to the following reasons: 1. It does not require the excessive logic to find the right place in the constant pool to patch in the package name (your approach 1). 2. It does not require to go through ASM every time to generate the class in the right package (your approach 2). How about adopting the simpler scheme? Best, Michael > Am 11.05.2016 um 13:24 schrieb shilpi.rastogi at oracle.com: > > Hi All, > > Please review the following- > > https://bugs.openjdk.java.net/browse/JDK-8149574 > > Solution: Changed anonymous class package name with the package name of its host class. > > Two approaches to solve this- > 1. Parse .class and get the class name index form constant pool and patch it with new name > http://cr.openjdk.java.net/~srastogi/8149574/webrev.05/ > > 2. Create class with new name (With ASM) > http://cr.openjdk.java.net/~srastogi/8149574/webrev.06/ > > Which approach is better? > > Thanks, > Shilpi > > > -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From shilpi.rastogi at oracle.com Wed May 11 13:55:11 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Wed, 11 May 2016 19:25:11 +0530 Subject: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode In-Reply-To: <94710EE3-E8C4-4B0D-A21C-4458B1E905C3@oracle.com> References: <5733165C.6090305@oracle.com> <94710EE3-E8C4-4B0D-A21C-4458B1E905C3@oracle.com> Message-ID: <573339BF.4060107@oracle.com> Thank You Michael for comments! It was fixed for VarargsArrayTest.java but not fixed for java/lang/invoke/CustomizedLambdaFormTest.java. Boris Molodenkov added a comment -2016-05-02 02:37-Restricted toConfidential One more test RULE "java/lang/invoke/CustomizedLambdaFormTest.java" StatusError Parse Exception: [-esa]: vm option(s) found, need to specify /othervm Thanks, Shilpi On 5/11/2016 6:47 PM, Michael Haupt wrote: > Hi Shilpi, > > not a review - the bug mentions that this issue is fixed in Jake already and that the bug should be closed once the fix from Jake propagates to dev. What is the status of that? > > Best, > > Michael > >> Am 11.05.2016 um 13:24 schrieb shilpi.rastogi at oracle.com: >> >> Hi All, >> >> Please review one small fix for >> >> https://bugs.openjdk.java.net/browse/JDK-8155791 >> http://cr.openjdk.java.net/~srastogi/8155791/webrev.00/ >> >> Thanks, >> Shilpi From daniel.fuchs at oracle.com Wed May 11 14:22:46 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 11 May 2016 16:22:46 +0200 Subject: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed In-Reply-To: <6A375668-62CA-47BE-B2AB-6BB3E7D3BEC0@dslextreme.com> References: <5D245EC6-47C6-4BF1-A505-89934731A814@oracle.com> <360DDB44-FDFC-41DE-8DF9-9BBA3AF28581@oracle.com> <07C5EC23-C429-4961-B7D3-92B7C32FB535@dslextreme.com> <90BF6135-B457-4BD4-8DFF-9DE94F6D8DC7@oracle.com> <018AAA44-3689-4E79-B090-B0D1F0DD0CC1@oracle.com> <6A375668-62CA-47BE-B2AB-6BB3E7D3BEC0@dslextreme.com> Message-ID: <412730c6-fe73-88af-b80d-d8690f6721ee@oracle.com> Hi Ralph, On 10/05/16 19:40, Ralph Goers wrote: > The benchmark logs events using Log4j 2?s asynchronous loggers. In the process of doing that it captures the location information using the code below: > > > // LOG4J2-1029 new Throwable().getStackTrace is faster than Thread.currentThread().getStackTrace(). > final StackTraceElement[] stackTrace = new Throwable().getStackTrace(); > StackTraceElement last = null; > for (int i = stackTrace.length - 1; i > 0; i--) { > final String className = stackTrace[i].getClassName(); > if (fqcnOfLogger.equals(className)) { > return last; > } > last = stackTrace[i]; > } > return null; Your benchmark walks the stack backwards. To take the full benefits of only walking part of the stack you should consider changing your algorithm to walk from frame 0 instead. With the StackWalker API you get a chance to get the Class that declares the method on the frame - which makes it possible to use things like Class.isAssignableFrom etc..., which could make it now possible to implement different strategies. Hope this helps, -- daniel > > Ralph > > >> On May 10, 2016, at 9:57 AM, Mandy Chung wrote: >> >> What does your benchmark call? >> >> Mandy >> >>> On May 10, 2016, at 9:49 AM, Ralph Goers wrote: >>> >>> I just ran one of the Log4j performance tests that specifically captures location information. To run the test I do >>> >>> java -jar log4j-perf/target/benchmarks.jar ".*AsyncAppenderLog4j2LocationBenchmark.*" -f 1 -wi 10 -i 20 -t 4 -si true >>> >>> And the results are: >>> >>> java version "1.7.0_80 >>> >>> Benchmark Mode Samples Score Error Units >>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 124819.285 ? 3003.918 ops/s >>> >>> java version "1.8.0_65" >>> >>> Benchmark Mode Samples Score Error Units >>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 123209.746 ? 3064.672 ops/s >>> >>> >>> java version "9-ea" >>> Java(TM) SE Runtime Environment (build 9-ea+116) >>> >>> Benchmark Mode Samples Score Error Units >>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 96090.261 ? 4565.763 ops/s >>> >>> >>> This tells me that Java 9 is about 23% slower than previous versions in walking the stack trace elements. >>> >>> Ralph >>> >>>> On Apr 13, 2016, at 12:03 PM, Mandy Chung wrote: >>>> >>>> If you record all stack frames, I can believe Throwable is faster because of a recent optimization JDK-8150778 that has been made in jdk9 to improve the Throwable::getStackTraceElements method. >>>> >>>> Mandy >>>> >>>>> On Apr 13, 2016, at 11:49 AM, Ralph Goers wrote: >>>>> >>>>> I did a raw test of StackWalker by itself and the performance was much better than using a Throwable to get the location information. However, I haven?t tested how it will be implemented in Log4j. We still support Java 7 (and will for some time) so we have to find a way to support using StackWalker when running on Java 9 even though we build with Java 7. >>>>> >>>>> Ralph >>>>> >>>>>> On Apr 13, 2016, at 10:27 AM, Mandy Chung wrote: >>>>>> >>>>>> It is good to know Log4J is planning to use StackWalker. >>>>>> >>>>>> Thanks for the feedback. I will reconsider. >>>>>> >>>>>> One thing to mention is the patch went in jdk9/hs-rt that will show up in jdk9/dev some time that changes the implementation to create StackTraceElement to get filename and line number. The object allocation should be cheap that does create short-lived objects. The main motivation of JDK-8153123 was to simplify the hotspot implementation that the runtime team had concern about. There is an open issue to follow up the performance (JDK-8153683). It?d be helpful to get your feedback on using StackWalker API and the performance data. >>>>>> >>>>>> Mandy >>>>>> >>>>>>> On Apr 13, 2016, at 6:51 AM, Ralph Goers wrote: >>>>>>> >>>>>>> I had planned on using StackWalker to generate the location information for every logging event. It seems that this change would thus cause the creation of a new StackTraceElement for every logger event. That seems wasteful. Log4j is currently in the process of trying to reduce the number of objects that are created while logging as it has a significant impact on garbage collection. So I am also in favor of getting the filename and line number directly from the StackFrame. >>>>>>> >>>>>>> Ralph >>>>>>> >>>>>>>> On Apr 12, 2016, at 5:15 PM, Mandy Chung wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On Apr 12, 2016, at 1:34 AM, R?mi Forax wrote: >>>>>>>>> >>>>>>>>> Hi Mandy, >>>>>>>>> I really don't like this patch. >>>>>>>>> >>>>>>>>> Being forced to call toStackElement to get the line number is counter intuitive. >>>>>>>>> I would prefer the two methods to not return Optional but an int and a String with the same convention as StackElement if the point of this patch is to remove the dependency to Optional. >>>>>>>>> >>>>>>>> >>>>>>>> I was expecting the common usage of StackWalker API does not need file name and line number. I think it'd be useful to include StackFrame::getBci (in the future it might include live information like locals etc) and keep the optional stuff and uncommon usage to StackTraceElement. >>>>>>>> >>>>>>>> Mandy >>>>>>>> >>>>>>>> >>>>>>>>> R?mi >>>>>>>>> >>>>>>>>> >>>>>>>>> Le 11 avril 2016 23:22:39 CEST, Mandy Chung a ?crit : >>>>>>>>>> Webrev at: >>>>>>>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.00/index.html >>>>>>>>>> >>>>>>>>>> StackFrame::getFileName and StackFrame::getLineNumber are originally >>>>>>>>>> proposed with the view of any stack walking code can migrate to the >>>>>>>>>> StackWalker API without the use of StackTraceElement. >>>>>>>>>> >>>>>>>>>> File name and line number are useful for debugging and troubleshooting >>>>>>>>>> purpose. It has additional overhead to map from a method and BCI to >>>>>>>>>> look up the file name and line number. >>>>>>>>>> >>>>>>>>>> StackFrame::toStackTraceElement method returns StackTraceElement that >>>>>>>>>> includes the file name and line number. There is no particular benefit >>>>>>>>>> to duplicate getFileName and getLineNumber methods in StackFrame. It is >>>>>>>>>> equivalently convenient to call >>>>>>>>>> StackFrame.toStackTraceElement().getFileName() (or getLineNumber). >>>>>>>>>> >>>>>>>>>> This patch proposes to remove StackFrame::getFileName and >>>>>>>>>> StackFrame::getLineNumber methods since such information can be >>>>>>>>>> obtained from StackFrame.toStackTraceElement(). >>>>>>>>>> >>>>>>>>>> Mandy >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > From paul.sandoz at oracle.com Wed May 11 14:52:50 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 11 May 2016 16:52:50 +0200 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <57331659.1030008@oracle.com> References: <57331659.1030008@oracle.com> Message-ID: <8918541F-29FD-4AFD-AE9A-4B3F1CF32C4E@oracle.com> Hi Shilpi, What makes me slightly queasy about the constant pool patching of T is it?s quite fragile and it produces a class with a slightly inconsistent state regarding the InnerClasses structures. It?s probably mostly harmless but still bothers me. One solution is to combine ASM with constant pool patching. Use ASM to generate the class bytes, and query the constant pool in the ClassWriter, then remember the class bytes, the pool size, and index to patch (a cursory glance at ClassWriter suggests this is possible). But i think Michael raises an important point about simplification using the default package, if that is possible. However, if the default package is to be used ASM is still required to generate class bytes and define the class anonymously within the scope of the host class. Thus in this approach the addition of patching should not add much more complexity and i think would be more in sync with that of the host class. Paul. > On 11 May 2016, at 13:24, shilpi.rastogi at oracle.com wrote: > > Hi All, > > Please review the following- > > https://bugs.openjdk.java.net/browse/JDK-8149574 > > Solution: Changed anonymous class package name with the package name of its host class. > > Two approaches to solve this- > 1. Parse .class and get the class name index form constant pool and patch it with new name > http://cr.openjdk.java.net/~srastogi/8149574/webrev.05/ > > 2. Create class with new name (With ASM) > http://cr.openjdk.java.net/~srastogi/8149574/webrev.06/ > > Which approach is better? > > Thanks, > Shilpi > > > From forax at univ-mlv.fr Wed May 11 15:50:19 2016 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 11 May 2016 15:50:19 +0000 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <6be1985e-ea21-ca5a-a545-ec0928251c15@oracle.com> References: <57331659.1030008@oracle.com> <1349119918.1331243.1462970699135.JavaMail.zimbra@u-pem.fr> <4ec613e7-72ee-7152-3182-06d7abc26e16@oracle.com> <1127572292.1337220.1462971581724.JavaMail.zimbra@u-pem.fr> <6be1985e-ea21-ca5a-a545-ec0928251c15@oracle.com> Message-ID: yes, adding @Hidden solves the first item of my list, but nevertheless changing the behavior of defineAnonymousClass does not solve the other items. That said, i hijack this thread because i have not noticed that defineAnonymousClass behavior was changed. I should have started another thread about that. R?mi Le 11 mai 2016 15:10:02 CEST, Vladimir Ivanov a ?crit : >Let me clarify: both proposed patches move invoker class out of >java.lang.invoke package, but add @Hidden on invoke_V instead. > >So, JVM should not list it in stack traces and you don't have to filter > >it out on your side. > >Moreover, I think the absence of @Hidden on >j.l.i.MethodHandleImpl.T.invoke_V was an overlook. > >Best regards, >Vladimir Ivanov > >On 5/11/16 3:59 PM, forax at univ-mlv.fr wrote: >> ----- Mail original ----- >>> De: "Vladimir Ivanov" >>> ?: "Remi Forax" , "shilpi rastogi" > >>> Cc: core-libs-dev at openjdk.java.net, "John Rose" >, "Michael Haupt" , >>> "paul sandoz" , "Da Vinci Machine Project" > >>> Envoy?: Mercredi 11 Mai 2016 14:50:25 >>> Objet: Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of >Unsafe.defineAnonymousClass() >>> >>> Remi, I'm curious why doesn't @Hidden on the invoker method solve >your >>> problem? >>> >>> Best regards, >>> Vladimir Ivanov >> >> Hi Vladimir, >> as far as i know @Hidden only work on the stackframe that correspond >to a method marked with @Hidden, >> not for the stackframe on top of the stackframe marked. >> So having the invoker marked with @Hidden is not enough, but maybe >i'm wrong. >> >> R?mi >> >>> >>> On 5/11/16 3:44 PM, Remi Forax wrote: >>>> Hi all, >>>> changing the behavior of defineAnonymousClass in 9 is huge burden >for me >>>> and i believe for anybody that maintains a dynamic language >runtime. >>>> >>>> As an implementer, being able to choose the package of an anonymous >class >>>> is an important feature. >>>> I use to choose carefully the package name for: >>>> - filtering the stack trace element that will be shown or not to >the user. >>>> This patch specifically broke the stack trace that my runtime >will emit >>>> because it removes "java.lang.invoke". >>>> I'm not the only one to filter out stacktrace element that starts >with >>>> "java.lang.invoke", Nashorn or JRuby do that too. >>>> I can modify the code to use the new StackWalking API if all the >method >>>> handle form artifact are marked with an interface or something >like >>>> this. >>>> >>>> - generate proxy in an existing package >>>> see https://github.com/forax/proxy2 >>>> >>>> - generate code specialization (specialization of an existing >method for >>>> some primitive types) of an existing class in an existing package >>>> (for the specialization, i specialize the constant pool at >runtime so i >>>> have no choice but to use defineAnonymousClass). >>>> >>>> >>>> I understand that being able to generate a class in any package do >not work >>>> well with the jigsaw view of the world but that's why >defineAnonymousClass >>>> is in Unsafe after all. >>>> >>>> regards, >>>> R?mi >>>> >>>> ----- Mail original ----- >>>>> De: "shilpi rastogi" >>>>> ?: core-libs-dev at openjdk.java.net, "John Rose" >, >>>>> "Michael Haupt" , >>>>> "paul sandoz" , "Vladimir Ivanov" >>>>> >>>>> Envoy?: Mercredi 11 Mai 2016 13:24:09 >>>>> Objet: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of >>>>> Unsafe.defineAnonymousClass() >>>>> >>>>> Hi All, >>>>> >>>>> Please review the following- >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8149574 >>>>> >>>>> Solution: Changed anonymous class package name with the package >name of >>>>> its host class. >>>>> >>>>> Two approaches to solve this- >>>>> 1. Parse .class and get the class name index form constant pool >and >>>>> patch it with new name >>>>> http://cr.openjdk.java.net/~srastogi/8149574/webrev.05/ >>>>> >>>>> 2. Create class with new name (With ASM) >>>>> http://cr.openjdk.java.net/~srastogi/8149574/webrev.06/ >>>>> >>>>> Which approach is better? >>>>> >>>>> Thanks, >>>>> Shilpi >>>>> >>>>> >>>>> >>>>> >>> From martinrb at google.com Wed May 11 15:59:43 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 11 May 2016 08:59:43 -0700 Subject: RFR(m): 8140281 deprecate Optional.get() In-Reply-To: <67663ca2-789f-043a-5060-a8e24e47b982@gmail.com> References: <1282fc0c-2d92-be13-d95e-9486cd556146@oracle.com> <571EA9D8.3010702@oracle.com> <5dad068b-038e-591c-49a1-ffcc22ffebb8@oracle.com> <350f4ee8-e59a-1518-adda-1a52f3654b96@oracle.com> <67663ca2-789f-043a-5060-a8e24e47b982@gmail.com> Message-ID: On Wed, May 11, 2016 at 12:05 AM, Peter Levart wrote: > Couldn't this new @Deprecated.since annotation attribute play a role here? > For example, if you are building with JDK 9 javac, but specify -release 8 > option, then you don't get deprecation warning for methods annotated with > @Deprecated(since = "9"). It helps, but ... the library maintainer and the invoker of javac are not the same, so a conscientious (and omniscient and indefatigable) library maintainer will still add @SuppressWarnings to their jdk6+ library the day it is @Deprecated in jdk9. We could add something like @TargetedRelease, which java has historically been reluctant to do. Compare with API conformance macros in C #define _XOPEN_SOURCE 500 placed at the top of every source file. From ralph.goers at dslextreme.com Wed May 11 16:14:50 2016 From: ralph.goers at dslextreme.com (Ralph Goers) Date: Wed, 11 May 2016 09:14:50 -0700 Subject: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed In-Reply-To: <412730c6-fe73-88af-b80d-d8690f6721ee@oracle.com> References: <5D245EC6-47C6-4BF1-A505-89934731A814@oracle.com> <360DDB44-FDFC-41DE-8DF9-9BBA3AF28581@oracle.com> <07C5EC23-C429-4961-B7D3-92B7C32FB535@dslextreme.com> <90BF6135-B457-4BD4-8DFF-9DE94F6D8DC7@oracle.com> <018AAA44-3689-4E79-B090-B0D1F0DD0CC1@oracle.com> <6A375668-62CA-47BE-B2AB-6BB3E7D3BEC0@dslextreme.com> <412730c6-fe73-88af-b80d-d8690f6721ee@oracle.com> Message-ID: <39C2DFD7-C49D-490A-A804-0FA60C1B2719@dslextreme.com> Yes, we need the StakWalker API for other parts of our code where we need the Class so we can determine what ClassLoader to use. For creating a LogEvent with location information we primarily need the class name, method name and line number. However, the ?extended? Throwable also returns the name of the jar the class came from and the location of the jar, so in that case we would want to use the StackWalker API - so it probably makes more sense to always use it. You are correct that most of the time it would be faster to start from frame 0. However, the problem we have with walking the stack from frame 0 is that it is possible to have a situation like Foo::method1?>Logger.log?>BarAppender.append?>Foo::method2 (or even method1 again)?>Logger.log If we start from the top we will believe Foo::method 1 is where we were called from, which would be incorrect. If in the Logger.log method we were able to capture the current stack frame index from StackWalker we could then pass that on through and then when we actually need the StackElement we could just ask for index-1, but I don?t see any methods like that, which is unfortunate. Ralph > On May 11, 2016, at 7:22 AM, Daniel Fuchs wrote: > > Hi Ralph, > > On 10/05/16 19:40, Ralph Goers wrote: >> The benchmark logs events using Log4j 2?s asynchronous loggers. In the process of doing that it captures the location information using the code below: >> >> >> // LOG4J2-1029 new Throwable().getStackTrace is faster than Thread.currentThread().getStackTrace(). >> final StackTraceElement[] stackTrace = new Throwable().getStackTrace(); >> StackTraceElement last = null; >> for (int i = stackTrace.length - 1; i > 0; i--) { >> final String className = stackTrace[i].getClassName(); >> if (fqcnOfLogger.equals(className)) { >> return last; >> } >> last = stackTrace[i]; >> } >> return null; > > Your benchmark walks the stack backwards. > > To take the full benefits of only walking part of the stack > you should consider changing your algorithm to walk from > frame 0 instead. > > With the StackWalker API you get a chance to get the > Class that declares the method on the frame - which > makes it possible to use things like Class.isAssignableFrom > etc..., which could make it now possible to implement > different strategies. > > Hope this helps, > > -- daniel > >> >> Ralph >> >> >>> On May 10, 2016, at 9:57 AM, Mandy Chung wrote: >>> >>> What does your benchmark call? >>> >>> Mandy >>> >>>> On May 10, 2016, at 9:49 AM, Ralph Goers wrote: >>>> >>>> I just ran one of the Log4j performance tests that specifically captures location information. To run the test I do >>>> >>>> java -jar log4j-perf/target/benchmarks.jar ".*AsyncAppenderLog4j2LocationBenchmark.*" -f 1 -wi 10 -i 20 -t 4 -si true >>>> >>>> And the results are: >>>> >>>> java version "1.7.0_80 >>>> >>>> Benchmark Mode Samples Score Error Units >>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 124819.285 ? 3003.918 ops/s >>>> >>>> java version "1.8.0_65" >>>> >>>> Benchmark Mode Samples Score Error Units >>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 123209.746 ? 3064.672 ops/s >>>> >>>> >>>> java version "9-ea" >>>> Java(TM) SE Runtime Environment (build 9-ea+116) >>>> >>>> Benchmark Mode Samples Score Error Units >>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 96090.261 ? 4565.763 ops/s >>>> >>>> >>>> This tells me that Java 9 is about 23% slower than previous versions in walking the stack trace elements. >>>> >>>> Ralph >>>> >>>>> On Apr 13, 2016, at 12:03 PM, Mandy Chung wrote: >>>>> >>>>> If you record all stack frames, I can believe Throwable is faster because of a recent optimization JDK-8150778 that has been made in jdk9 to improve the Throwable::getStackTraceElements method. >>>>> >>>>> Mandy >>>>> >>>>>> On Apr 13, 2016, at 11:49 AM, Ralph Goers wrote: >>>>>> >>>>>> I did a raw test of StackWalker by itself and the performance was much better than using a Throwable to get the location information. However, I haven?t tested how it will be implemented in Log4j. We still support Java 7 (and will for some time) so we have to find a way to support using StackWalker when running on Java 9 even though we build with Java 7. >>>>>> >>>>>> Ralph >>>>>> >>>>>>> On Apr 13, 2016, at 10:27 AM, Mandy Chung wrote: >>>>>>> >>>>>>> It is good to know Log4J is planning to use StackWalker. >>>>>>> >>>>>>> Thanks for the feedback. I will reconsider. >>>>>>> >>>>>>> One thing to mention is the patch went in jdk9/hs-rt that will show up in jdk9/dev some time that changes the implementation to create StackTraceElement to get filename and line number. The object allocation should be cheap that does create short-lived objects. The main motivation of JDK-8153123 was to simplify the hotspot implementation that the runtime team had concern about. There is an open issue to follow up the performance (JDK-8153683). It?d be helpful to get your feedback on using StackWalker API and the performance data. >>>>>>> >>>>>>> Mandy >>>>>>> >>>>>>>> On Apr 13, 2016, at 6:51 AM, Ralph Goers wrote: >>>>>>>> >>>>>>>> I had planned on using StackWalker to generate the location information for every logging event. It seems that this change would thus cause the creation of a new StackTraceElement for every logger event. That seems wasteful. Log4j is currently in the process of trying to reduce the number of objects that are created while logging as it has a significant impact on garbage collection. So I am also in favor of getting the filename and line number directly from the StackFrame. >>>>>>>> >>>>>>>> Ralph >>>>>>>> >>>>>>>>> On Apr 12, 2016, at 5:15 PM, Mandy Chung wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Apr 12, 2016, at 1:34 AM, R?mi Forax wrote: >>>>>>>>>> >>>>>>>>>> Hi Mandy, >>>>>>>>>> I really don't like this patch. >>>>>>>>>> >>>>>>>>>> Being forced to call toStackElement to get the line number is counter intuitive. >>>>>>>>>> I would prefer the two methods to not return Optional but an int and a String with the same convention as StackElement if the point of this patch is to remove the dependency to Optional. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I was expecting the common usage of StackWalker API does not need file name and line number. I think it'd be useful to include StackFrame::getBci (in the future it might include live information like locals etc) and keep the optional stuff and uncommon usage to StackTraceElement. >>>>>>>>> >>>>>>>>> Mandy >>>>>>>>> >>>>>>>>> >>>>>>>>>> R?mi >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Le 11 avril 2016 23:22:39 CEST, Mandy Chung a ?crit : >>>>>>>>>>> Webrev at: >>>>>>>>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.00/index.html >>>>>>>>>>> >>>>>>>>>>> StackFrame::getFileName and StackFrame::getLineNumber are originally >>>>>>>>>>> proposed with the view of any stack walking code can migrate to the >>>>>>>>>>> StackWalker API without the use of StackTraceElement. >>>>>>>>>>> >>>>>>>>>>> File name and line number are useful for debugging and troubleshooting >>>>>>>>>>> purpose. It has additional overhead to map from a method and BCI to >>>>>>>>>>> look up the file name and line number. >>>>>>>>>>> >>>>>>>>>>> StackFrame::toStackTraceElement method returns StackTraceElement that >>>>>>>>>>> includes the file name and line number. There is no particular benefit >>>>>>>>>>> to duplicate getFileName and getLineNumber methods in StackFrame. It is >>>>>>>>>>> equivalently convenient to call >>>>>>>>>>> StackFrame.toStackTraceElement().getFileName() (or getLineNumber). >>>>>>>>>>> >>>>>>>>>>> This patch proposes to remove StackFrame::getFileName and >>>>>>>>>>> StackFrame::getLineNumber methods since such information can be >>>>>>>>>>> obtained from StackFrame.toStackTraceElement(). >>>>>>>>>>> >>>>>>>>>>> Mandy >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From peter.levart at gmail.com Wed May 11 16:17:42 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 11 May 2016 18:17:42 +0200 Subject: RFR(m): 8140281 deprecate Optional.get() In-Reply-To: References: <1282fc0c-2d92-be13-d95e-9486cd556146@oracle.com> <571EA9D8.3010702@oracle.com> <5dad068b-038e-591c-49a1-ffcc22ffebb8@oracle.com> <350f4ee8-e59a-1518-adda-1a52f3654b96@oracle.com> <67663ca2-789f-043a-5060-a8e24e47b982@gmail.com> Message-ID: <1533cecb-bdd2-cd47-7529-d2bf7a077b6e@gmail.com> Hi Martin, On 05/11/2016 05:59 PM, Martin Buchholz wrote: > On Wed, May 11, 2016 at 12:05 AM, Peter Levart wrote: >> Couldn't this new @Deprecated.since annotation attribute play a role here? >> For example, if you are building with JDK 9 javac, but specify -release 8 >> option, then you don't get deprecation warning for methods annotated with >> @Deprecated(since = "9"). > It helps, but ... the library maintainer and the invoker of javac are > not the same, so a conscientious (and omniscient and indefatigable) > library maintainer will still add @SuppressWarnings to their jdk6+ > library the day it is @Deprecated in jdk9. > > We could add something like @TargetedRelease, which java has > historically been reluctant to do. > Compare with API conformance macros in C > #define _XOPEN_SOURCE 500 > placed at the top of every source file. I don't think you are making sense. Are you saying that the library maintainer will not the be only person that will be compiling library sources to produce binary artifacts? That one guy may want to compile the library sources on the JDK 6 platform and some other guy may want to compile the same sources on the JDK 9 platform? Regards, Peter From ralph.goers at dslextreme.com Wed May 11 16:24:42 2016 From: ralph.goers at dslextreme.com (Ralph Goers) Date: Wed, 11 May 2016 09:24:42 -0700 Subject: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed In-Reply-To: <39C2DFD7-C49D-490A-A804-0FA60C1B2719@dslextreme.com> References: <5D245EC6-47C6-4BF1-A505-89934731A814@oracle.com> <360DDB44-FDFC-41DE-8DF9-9BBA3AF28581@oracle.com> <07C5EC23-C429-4961-B7D3-92B7C32FB535@dslextreme.com> <90BF6135-B457-4BD4-8DFF-9DE94F6D8DC7@oracle.com> <018AAA44-3689-4E79-B090-B0D1F0DD0CC1@oracle.com> <6A375668-62CA-47BE-B2AB-6BB3E7D3BEC0@dslextreme.com> <412730c6-fe73-88af-b80d-d8690f6721ee@oracle.com> <39C2DFD7-C49D-490A-A804-0FA60C1B2719@dslextreme.com> Message-ID: <5DD7029A-5C1B-4118-B452-104FA9C93659@dslextreme.com> Currently StackWalker has a getCallerClass method, but not a getCallerStackFrame. Having that method could also solve the problem, but only if it is efficient enough that it could be called for every log event, since when we would be calling it we wouldn?t even know if the user required it. In looking at getCallerClass it isn?t clear to me how fast it actually is. Ralph > On May 11, 2016, at 9:14 AM, Ralph Goers wrote: > > Yes, we need the StakWalker API for other parts of our code where we need the Class so we can determine what ClassLoader to use. For creating a LogEvent with location information we primarily need the class name, method name and line number. However, the ?extended? Throwable also returns the name of the jar the class came from and the location of the jar, so in that case we would want to use the StackWalker API - so it probably makes more sense to always use it. > > You are correct that most of the time it would be faster to start from frame 0. However, the problem we have with walking the stack from frame 0 is that it is possible to have a situation like > > Foo::method1?>Logger.log?>BarAppender.append?>Foo::method2 (or even method1 again)?>Logger.log > > If we start from the top we will believe Foo::method 1 is where we were called from, which would be incorrect. If in the Logger.log method we were able to capture the current stack frame index from StackWalker we could then pass that on through and then when we actually need the StackElement we could just ask for index-1, but I don?t see any methods like that, which is unfortunate. > > Ralph > >> On May 11, 2016, at 7:22 AM, Daniel Fuchs wrote: >> >> Hi Ralph, >> >> On 10/05/16 19:40, Ralph Goers wrote: >>> The benchmark logs events using Log4j 2?s asynchronous loggers. In the process of doing that it captures the location information using the code below: >>> >>> >>> // LOG4J2-1029 new Throwable().getStackTrace is faster than Thread.currentThread().getStackTrace(). >>> final StackTraceElement[] stackTrace = new Throwable().getStackTrace(); >>> StackTraceElement last = null; >>> for (int i = stackTrace.length - 1; i > 0; i--) { >>> final String className = stackTrace[i].getClassName(); >>> if (fqcnOfLogger.equals(className)) { >>> return last; >>> } >>> last = stackTrace[i]; >>> } >>> return null; >> >> Your benchmark walks the stack backwards. >> >> To take the full benefits of only walking part of the stack >> you should consider changing your algorithm to walk from >> frame 0 instead. >> >> With the StackWalker API you get a chance to get the >> Class that declares the method on the frame - which >> makes it possible to use things like Class.isAssignableFrom >> etc..., which could make it now possible to implement >> different strategies. >> >> Hope this helps, >> >> -- daniel >> >>> >>> Ralph >>> >>> >>>> On May 10, 2016, at 9:57 AM, Mandy Chung wrote: >>>> >>>> What does your benchmark call? >>>> >>>> Mandy >>>> >>>>> On May 10, 2016, at 9:49 AM, Ralph Goers wrote: >>>>> >>>>> I just ran one of the Log4j performance tests that specifically captures location information. To run the test I do >>>>> >>>>> java -jar log4j-perf/target/benchmarks.jar ".*AsyncAppenderLog4j2LocationBenchmark.*" -f 1 -wi 10 -i 20 -t 4 -si true >>>>> >>>>> And the results are: >>>>> >>>>> java version "1.7.0_80 >>>>> >>>>> Benchmark Mode Samples Score Error Units >>>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 124819.285 ? 3003.918 ops/s >>>>> >>>>> java version "1.8.0_65" >>>>> >>>>> Benchmark Mode Samples Score Error Units >>>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 123209.746 ? 3064.672 ops/s >>>>> >>>>> >>>>> java version "9-ea" >>>>> Java(TM) SE Runtime Environment (build 9-ea+116) >>>>> >>>>> Benchmark Mode Samples Score Error Units >>>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 96090.261 ? 4565.763 ops/s >>>>> >>>>> >>>>> This tells me that Java 9 is about 23% slower than previous versions in walking the stack trace elements. >>>>> >>>>> Ralph >>>>> >>>>>> On Apr 13, 2016, at 12:03 PM, Mandy Chung wrote: >>>>>> >>>>>> If you record all stack frames, I can believe Throwable is faster because of a recent optimization JDK-8150778 that has been made in jdk9 to improve the Throwable::getStackTraceElements method. >>>>>> >>>>>> Mandy >>>>>> >>>>>>> On Apr 13, 2016, at 11:49 AM, Ralph Goers wrote: >>>>>>> >>>>>>> I did a raw test of StackWalker by itself and the performance was much better than using a Throwable to get the location information. However, I haven?t tested how it will be implemented in Log4j. We still support Java 7 (and will for some time) so we have to find a way to support using StackWalker when running on Java 9 even though we build with Java 7. >>>>>>> >>>>>>> Ralph >>>>>>> >>>>>>>> On Apr 13, 2016, at 10:27 AM, Mandy Chung wrote: >>>>>>>> >>>>>>>> It is good to know Log4J is planning to use StackWalker. >>>>>>>> >>>>>>>> Thanks for the feedback. I will reconsider. >>>>>>>> >>>>>>>> One thing to mention is the patch went in jdk9/hs-rt that will show up in jdk9/dev some time that changes the implementation to create StackTraceElement to get filename and line number. The object allocation should be cheap that does create short-lived objects. The main motivation of JDK-8153123 was to simplify the hotspot implementation that the runtime team had concern about. There is an open issue to follow up the performance (JDK-8153683). It?d be helpful to get your feedback on using StackWalker API and the performance data. >>>>>>>> >>>>>>>> Mandy >>>>>>>> >>>>>>>>> On Apr 13, 2016, at 6:51 AM, Ralph Goers wrote: >>>>>>>>> >>>>>>>>> I had planned on using StackWalker to generate the location information for every logging event. It seems that this change would thus cause the creation of a new StackTraceElement for every logger event. That seems wasteful. Log4j is currently in the process of trying to reduce the number of objects that are created while logging as it has a significant impact on garbage collection. So I am also in favor of getting the filename and line number directly from the StackFrame. >>>>>>>>> >>>>>>>>> Ralph >>>>>>>>> >>>>>>>>>> On Apr 12, 2016, at 5:15 PM, Mandy Chung wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Apr 12, 2016, at 1:34 AM, R?mi Forax wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Mandy, >>>>>>>>>>> I really don't like this patch. >>>>>>>>>>> >>>>>>>>>>> Being forced to call toStackElement to get the line number is counter intuitive. >>>>>>>>>>> I would prefer the two methods to not return Optional but an int and a String with the same convention as StackElement if the point of this patch is to remove the dependency to Optional. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I was expecting the common usage of StackWalker API does not need file name and line number. I think it'd be useful to include StackFrame::getBci (in the future it might include live information like locals etc) and keep the optional stuff and uncommon usage to StackTraceElement. >>>>>>>>>> >>>>>>>>>> Mandy >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> R?mi >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Le 11 avril 2016 23:22:39 CEST, Mandy Chung a ?crit : >>>>>>>>>>>> Webrev at: >>>>>>>>>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.00/index.html >>>>>>>>>>>> >>>>>>>>>>>> StackFrame::getFileName and StackFrame::getLineNumber are originally >>>>>>>>>>>> proposed with the view of any stack walking code can migrate to the >>>>>>>>>>>> StackWalker API without the use of StackTraceElement. >>>>>>>>>>>> >>>>>>>>>>>> File name and line number are useful for debugging and troubleshooting >>>>>>>>>>>> purpose. It has additional overhead to map from a method and BCI to >>>>>>>>>>>> look up the file name and line number. >>>>>>>>>>>> >>>>>>>>>>>> StackFrame::toStackTraceElement method returns StackTraceElement that >>>>>>>>>>>> includes the file name and line number. There is no particular benefit >>>>>>>>>>>> to duplicate getFileName and getLineNumber methods in StackFrame. It is >>>>>>>>>>>> equivalently convenient to call >>>>>>>>>>>> StackFrame.toStackTraceElement().getFileName() (or getLineNumber). >>>>>>>>>>>> >>>>>>>>>>>> This patch proposes to remove StackFrame::getFileName and >>>>>>>>>>>> StackFrame::getLineNumber methods since such information can be >>>>>>>>>>>> obtained from StackFrame.toStackTraceElement(). >>>>>>>>>>>> >>>>>>>>>>>> Mandy >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > > > From shilpi.rastogi at oracle.com Wed May 11 16:31:48 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Wed, 11 May 2016 22:01:48 +0530 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <8918541F-29FD-4AFD-AE9A-4B3F1CF32C4E@oracle.com> References: <57331659.1030008@oracle.com> <8918541F-29FD-4AFD-AE9A-4B3F1CF32C4E@oracle.com> Message-ID: <57335E74.3090204@oracle.com> Hi All, Please review the updated webrev- http://cr.openjdk.java.net/~srastogi/8149574/webrev.07/ Changed the anonymous class package with no package name. Regards, Shilpi On 5/11/2016 8:22 PM, Paul Sandoz wrote: > Hi Shilpi, > > What makes me slightly queasy about the constant pool patching of T is it?s quite fragile and it produces a class with a slightly inconsistent state regarding the InnerClasses structures. It?s probably mostly harmless but still bothers me. > > One solution is to combine ASM with constant pool patching. Use ASM to generate the class bytes, and query the constant pool in the ClassWriter, then remember the class bytes, the pool size, and index to patch (a cursory glance at ClassWriter suggests this is possible). > > But i think Michael raises an important point about simplification using the default package, if that is possible. However, if the default package is to be used ASM is still required to generate class bytes and define the class anonymously within the scope of the host class. Thus in this approach the addition of patching should not add much more complexity and i think would be more in sync with that of the host class. > > Paul. > >> On 11 May 2016, at 13:24, shilpi.rastogi at oracle.com wrote: >> >> Hi All, >> >> Please review the following- >> >> https://bugs.openjdk.java.net/browse/JDK-8149574 >> >> Solution: Changed anonymous class package name with the package name of its host class. >> >> Two approaches to solve this- >> 1. Parse .class and get the class name index form constant pool and patch it with new name >> http://cr.openjdk.java.net/~srastogi/8149574/webrev.05/ >> >> 2. Create class with new name (With ASM) >> http://cr.openjdk.java.net/~srastogi/8149574/webrev.06/ >> >> Which approach is better? >> >> Thanks, >> Shilpi >> >> >> From martinrb at google.com Wed May 11 16:32:30 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 11 May 2016 09:32:30 -0700 Subject: RFR(m): 8140281 deprecate Optional.get() In-Reply-To: <1533cecb-bdd2-cd47-7529-d2bf7a077b6e@gmail.com> References: <1282fc0c-2d92-be13-d95e-9486cd556146@oracle.com> <571EA9D8.3010702@oracle.com> <5dad068b-038e-591c-49a1-ffcc22ffebb8@oracle.com> <350f4ee8-e59a-1518-adda-1a52f3654b96@oracle.com> <67663ca2-789f-043a-5060-a8e24e47b982@gmail.com> <1533cecb-bdd2-cd47-7529-d2bf7a077b6e@gmail.com> Message-ID: On Wed, May 11, 2016 at 9:17 AM, Peter Levart wrote: > Hi Martin, > > > > On 05/11/2016 05:59 PM, Martin Buchholz wrote: >> >> On Wed, May 11, 2016 at 12:05 AM, Peter Levart >> wrote: >>> >>> Couldn't this new @Deprecated.since annotation attribute play a role >>> here? >>> For example, if you are building with JDK 9 javac, but specify -release 8 >>> option, then you don't get deprecation warning for methods annotated with >>> @Deprecated(since = "9"). >> >> It helps, but ... the library maintainer and the invoker of javac are >> not the same, so a conscientious (and omniscient and indefatigable) >> library maintainer will still add @SuppressWarnings to their jdk6+ >> library the day it is @Deprecated in jdk9. >> >> We could add something like @TargetedRelease, which java has >> historically been reluctant to do. >> Compare with API conformance macros in C >> #define _XOPEN_SOURCE 500 >> placed at the top of every source file. > > > I don't think you are making sense. Are you saying that the library > maintainer will not the be only person that will be compiling library > sources to produce binary artifacts? That one guy may want to compile the > library sources on the JDK 6 platform and some other guy may want to compile > the same sources on the JDK 9 platform? It's surely possible to combine many jar files, each compiled for their own target platform, perhaps by their maintainer. But in my part of the world it's much more common to collect all the java sources for a java program and compile them all in a single javac invocation, with a single target release. In part because people don't trust "binary blobs". From daniel.fuchs at oracle.com Wed May 11 16:35:14 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 11 May 2016 18:35:14 +0200 Subject: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed In-Reply-To: <39C2DFD7-C49D-490A-A804-0FA60C1B2719@dslextreme.com> References: <5D245EC6-47C6-4BF1-A505-89934731A814@oracle.com> <360DDB44-FDFC-41DE-8DF9-9BBA3AF28581@oracle.com> <07C5EC23-C429-4961-B7D3-92B7C32FB535@dslextreme.com> <90BF6135-B457-4BD4-8DFF-9DE94F6D8DC7@oracle.com> <018AAA44-3689-4E79-B090-B0D1F0DD0CC1@oracle.com> <6A375668-62CA-47BE-B2AB-6BB3E7D3BEC0@dslextreme.com> <412730c6-fe73-88af-b80d-d8690f6721ee@oracle.com> <39C2DFD7-C49D-490A-A804-0FA60C1B2719@dslextreme.com> Message-ID: Hi Ralph, On 11/05/16 18:14, Ralph Goers wrote: > You are correct that most of the time it would be faster to start from frame 0. However, the problem we have with walking the stack from frame 0 is that it is possible to have a situation like > > Foo::method1?>Logger.log?>BarAppender.append?>Foo::method2 (or even method1 again)?>Logger.log The appender would call Logger.log? Is that a common situation? That sounds strange to me. I was kind of assuming that you could walk the stack until finding an instance of Logger (which would allow you to skip all the appender's infrastructure), then continue walking until you find something which is no longer a Logger. I'm not sure I understand your other comment about getCallerClass(). That just walks 2 frames (skipping reflection frame). You can do the same with StackWalker, that should enable you to get the calling frame easily. best regards, -- daniel From peter.levart at gmail.com Wed May 11 16:43:33 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 11 May 2016 18:43:33 +0200 Subject: RFR(m): 8140281 deprecate Optional.get() In-Reply-To: References: <1282fc0c-2d92-be13-d95e-9486cd556146@oracle.com> <571EA9D8.3010702@oracle.com> <5dad068b-038e-591c-49a1-ffcc22ffebb8@oracle.com> <350f4ee8-e59a-1518-adda-1a52f3654b96@oracle.com> <67663ca2-789f-043a-5060-a8e24e47b982@gmail.com> <1533cecb-bdd2-cd47-7529-d2bf7a077b6e@gmail.com> Message-ID: <9f27f8e1-c012-903f-61cf-f0b151efa36b@gmail.com> On 05/11/2016 06:32 PM, Martin Buchholz wrote: > On Wed, May 11, 2016 at 9:17 AM, Peter Levart wrote: >> Hi Martin, >> >> >> >> On 05/11/2016 05:59 PM, Martin Buchholz wrote: >>> On Wed, May 11, 2016 at 12:05 AM, Peter Levart >>> wrote: >>>> Couldn't this new @Deprecated.since annotation attribute play a role >>>> here? >>>> For example, if you are building with JDK 9 javac, but specify -release 8 >>>> option, then you don't get deprecation warning for methods annotated with >>>> @Deprecated(since = "9"). >>> It helps, but ... the library maintainer and the invoker of javac are >>> not the same, so a conscientious (and omniscient and indefatigable) >>> library maintainer will still add @SuppressWarnings to their jdk6+ >>> library the day it is @Deprecated in jdk9. >>> >>> We could add something like @TargetedRelease, which java has >>> historically been reluctant to do. >>> Compare with API conformance macros in C >>> #define _XOPEN_SOURCE 500 >>> placed at the top of every source file. >> >> I don't think you are making sense. Are you saying that the library >> maintainer will not the be only person that will be compiling library >> sources to produce binary artifacts? That one guy may want to compile the >> library sources on the JDK 6 platform and some other guy may want to compile >> the same sources on the JDK 9 platform? > It's surely possible to combine many jar files, each compiled for > their own target platform, perhaps by their maintainer. > But in my part of the world it's much more common to collect all the > java sources for a java program and compile them all in a single javac > invocation, with a single target release. In part because people > don't trust "binary blobs". Ok, that makes sense now. We seem to live in different parts of the world ;-) Regards, Peter From mandy.chung at oracle.com Wed May 11 16:43:57 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 11 May 2016 09:43:57 -0700 Subject: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed In-Reply-To: <5DD7029A-5C1B-4118-B452-104FA9C93659@dslextreme.com> References: <5D245EC6-47C6-4BF1-A505-89934731A814@oracle.com> <360DDB44-FDFC-41DE-8DF9-9BBA3AF28581@oracle.com> <07C5EC23-C429-4961-B7D3-92B7C32FB535@dslextreme.com> <90BF6135-B457-4BD4-8DFF-9DE94F6D8DC7@oracle.com> <018AAA44-3689-4E79-B090-B0D1F0DD0CC1@oracle.com> <6A375668-62CA-47BE-B2AB-6BB3E7D3BEC0@dslextreme.com> <412730c6-fe73-88af-b80d-d8690f6721ee@oracle.com> <39C2DFD7-C49D-490A-A804-0FA60C1B2719@dslextreme.com> <5DD7029A-5C1B-4118-B452-104FA9C93659@dslextreme.com> Message-ID: <7BE50964-ED62-4AC0-9E8F-82D595AEEDE9@oracle.com> > On May 11, 2016, at 9:24 AM, Ralph Goers wrote: > > Currently StackWalker has a getCallerClass method, but not a getCallerStackFrame. Having that method could also solve the problem, but only if it is efficient enough that it could be called for every log event, since when we would be calling it we wouldn?t even know if the user required it. In looking at getCallerClass it isn?t clear to me how fast it actually is. > You can implement getCallerStackFrame using StackWalker as follows: walker.walk(s -> s.skip(2).findFirst()); StackWalker::getCallerClass is implemented using StackWalker while it uses a smaller batch size as it knows it only interests in the top few frames. It?s smaller footprint since it only gets the Class object. Mandy > Ralph > >> On May 11, 2016, at 9:14 AM, Ralph Goers wrote: >> >> Yes, we need the StakWalker API for other parts of our code where we need the Class so we can determine what ClassLoader to use. For creating a LogEvent with location information we primarily need the class name, method name and line number. However, the ?extended? Throwable also returns the name of the jar the class came from and the location of the jar, so in that case we would want to use the StackWalker API - so it probably makes more sense to always use it. >> >> You are correct that most of the time it would be faster to start from frame 0. However, the problem we have with walking the stack from frame 0 is that it is possible to have a situation like >> >> Foo::method1?>Logger.log?>BarAppender.append?>Foo::method2 (or even method1 again)?>Logger.log >> >> If we start from the top we will believe Foo::method 1 is where we were called from, which would be incorrect. If in the Logger.log method we were able to capture the current stack frame index from StackWalker we could then pass that on through and then when we actually need the StackElement we could just ask for index-1, but I don?t see any methods like that, which is unfortunate. >> >> Ralph >> >>> On May 11, 2016, at 7:22 AM, Daniel Fuchs wrote: >>> >>> Hi Ralph, >>> >>> On 10/05/16 19:40, Ralph Goers wrote: >>>> The benchmark logs events using Log4j 2?s asynchronous loggers. In the process of doing that it captures the location information using the code below: >>>> >>>> >>>> // LOG4J2-1029 new Throwable().getStackTrace is faster than Thread.currentThread().getStackTrace(). >>>> final StackTraceElement[] stackTrace = new Throwable().getStackTrace(); >>>> StackTraceElement last = null; >>>> for (int i = stackTrace.length - 1; i > 0; i--) { >>>> final String className = stackTrace[i].getClassName(); >>>> if (fqcnOfLogger.equals(className)) { >>>> return last; >>>> } >>>> last = stackTrace[i]; >>>> } >>>> return null; >>> >>> Your benchmark walks the stack backwards. >>> >>> To take the full benefits of only walking part of the stack >>> you should consider changing your algorithm to walk from >>> frame 0 instead. >>> >>> With the StackWalker API you get a chance to get the >>> Class that declares the method on the frame - which >>> makes it possible to use things like Class.isAssignableFrom >>> etc..., which could make it now possible to implement >>> different strategies. >>> >>> Hope this helps, >>> >>> -- daniel >>> >>>> >>>> Ralph >>>> >>>> >>>>> On May 10, 2016, at 9:57 AM, Mandy Chung wrote: >>>>> >>>>> What does your benchmark call? >>>>> >>>>> Mandy >>>>> >>>>>> On May 10, 2016, at 9:49 AM, Ralph Goers wrote: >>>>>> >>>>>> I just ran one of the Log4j performance tests that specifically captures location information. To run the test I do >>>>>> >>>>>> java -jar log4j-perf/target/benchmarks.jar ".*AsyncAppenderLog4j2LocationBenchmark.*" -f 1 -wi 10 -i 20 -t 4 -si true >>>>>> >>>>>> And the results are: >>>>>> >>>>>> java version "1.7.0_80 >>>>>> >>>>>> Benchmark Mode Samples Score Error Units >>>>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 124819.285 ? 3003.918 ops/s >>>>>> >>>>>> java version "1.8.0_65" >>>>>> >>>>>> Benchmark Mode Samples Score Error Units >>>>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 123209.746 ? 3064.672 ops/s >>>>>> >>>>>> >>>>>> java version "9-ea" >>>>>> Java(TM) SE Runtime Environment (build 9-ea+116) >>>>>> >>>>>> Benchmark Mode Samples Score Error Units >>>>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 96090.261 ? 4565.763 ops/s >>>>>> >>>>>> >>>>>> This tells me that Java 9 is about 23% slower than previous versions in walking the stack trace elements. >>>>>> >>>>>> Ralph >>>>>> >>>>>>> On Apr 13, 2016, at 12:03 PM, Mandy Chung wrote: >>>>>>> >>>>>>> If you record all stack frames, I can believe Throwable is faster because of a recent optimization JDK-8150778 that has been made in jdk9 to improve the Throwable::getStackTraceElements method. >>>>>>> >>>>>>> Mandy >>>>>>> >>>>>>>> On Apr 13, 2016, at 11:49 AM, Ralph Goers wrote: >>>>>>>> >>>>>>>> I did a raw test of StackWalker by itself and the performance was much better than using a Throwable to get the location information. However, I haven?t tested how it will be implemented in Log4j. We still support Java 7 (and will for some time) so we have to find a way to support using StackWalker when running on Java 9 even though we build with Java 7. >>>>>>>> >>>>>>>> Ralph >>>>>>>> >>>>>>>>> On Apr 13, 2016, at 10:27 AM, Mandy Chung wrote: >>>>>>>>> >>>>>>>>> It is good to know Log4J is planning to use StackWalker. >>>>>>>>> >>>>>>>>> Thanks for the feedback. I will reconsider. >>>>>>>>> >>>>>>>>> One thing to mention is the patch went in jdk9/hs-rt that will show up in jdk9/dev some time that changes the implementation to create StackTraceElement to get filename and line number. The object allocation should be cheap that does create short-lived objects. The main motivation of JDK-8153123 was to simplify the hotspot implementation that the runtime team had concern about. There is an open issue to follow up the performance (JDK-8153683). It?d be helpful to get your feedback on using StackWalker API and the performance data. >>>>>>>>> >>>>>>>>> Mandy >>>>>>>>> >>>>>>>>>> On Apr 13, 2016, at 6:51 AM, Ralph Goers wrote: >>>>>>>>>> >>>>>>>>>> I had planned on using StackWalker to generate the location information for every logging event. It seems that this change would thus cause the creation of a new StackTraceElement for every logger event. That seems wasteful. Log4j is currently in the process of trying to reduce the number of objects that are created while logging as it has a significant impact on garbage collection. So I am also in favor of getting the filename and line number directly from the StackFrame. >>>>>>>>>> >>>>>>>>>> Ralph >>>>>>>>>> >>>>>>>>>>> On Apr 12, 2016, at 5:15 PM, Mandy Chung wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Apr 12, 2016, at 1:34 AM, R?mi Forax wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Mandy, >>>>>>>>>>>> I really don't like this patch. >>>>>>>>>>>> >>>>>>>>>>>> Being forced to call toStackElement to get the line number is counter intuitive. >>>>>>>>>>>> I would prefer the two methods to not return Optional but an int and a String with the same convention as StackElement if the point of this patch is to remove the dependency to Optional. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I was expecting the common usage of StackWalker API does not need file name and line number. I think it'd be useful to include StackFrame::getBci (in the future it might include live information like locals etc) and keep the optional stuff and uncommon usage to StackTraceElement. >>>>>>>>>>> >>>>>>>>>>> Mandy >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> R?mi >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Le 11 avril 2016 23:22:39 CEST, Mandy Chung a ?crit : >>>>>>>>>>>>> Webrev at: >>>>>>>>>>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.00/index.html >>>>>>>>>>>>> >>>>>>>>>>>>> StackFrame::getFileName and StackFrame::getLineNumber are originally >>>>>>>>>>>>> proposed with the view of any stack walking code can migrate to the >>>>>>>>>>>>> StackWalker API without the use of StackTraceElement. >>>>>>>>>>>>> >>>>>>>>>>>>> File name and line number are useful for debugging and troubleshooting >>>>>>>>>>>>> purpose. It has additional overhead to map from a method and BCI to >>>>>>>>>>>>> look up the file name and line number. >>>>>>>>>>>>> >>>>>>>>>>>>> StackFrame::toStackTraceElement method returns StackTraceElement that >>>>>>>>>>>>> includes the file name and line number. There is no particular benefit >>>>>>>>>>>>> to duplicate getFileName and getLineNumber methods in StackFrame. It is >>>>>>>>>>>>> equivalently convenient to call >>>>>>>>>>>>> StackFrame.toStackTraceElement().getFileName() (or getLineNumber). >>>>>>>>>>>>> >>>>>>>>>>>>> This patch proposes to remove StackFrame::getFileName and >>>>>>>>>>>>> StackFrame::getLineNumber methods since such information can be >>>>>>>>>>>>> obtained from StackFrame.toStackTraceElement(). >>>>>>>>>>>>> >>>>>>>>>>>>> Mandy >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> >> > > From ralph.goers at dslextreme.com Wed May 11 16:57:57 2016 From: ralph.goers at dslextreme.com (Ralph Goers) Date: Wed, 11 May 2016 09:57:57 -0700 Subject: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed In-Reply-To: References: <5D245EC6-47C6-4BF1-A505-89934731A814@oracle.com> <360DDB44-FDFC-41DE-8DF9-9BBA3AF28581@oracle.com> <07C5EC23-C429-4961-B7D3-92B7C32FB535@dslextreme.com> <90BF6135-B457-4BD4-8DFF-9DE94F6D8DC7@oracle.com> <018AAA44-3689-4E79-B090-B0D1F0DD0CC1@oracle.com> <6A375668-62CA-47BE-B2AB-6BB3E7D3BEC0@dslextreme.com> <412730c6-fe73-88af-b80d-d8690f6721ee@oracle.com> <39C2DFD7-C49D-490A-A804-0FA60C1B2719@dslextreme.com> Message-ID: <3C161A46-360E-4E27-A544-51EF8A784735@dslextreme.com> It happens in situations like Foo:method1?>Logger.log?>DBAppender.append?>Hibernate.something?>Logger.log. It is actually pretty common when you create appenders that want to interact with third party libraries. For example, an Appender might use Netty to interact with sockets, Thrift to access some NoSQL package, etc. getCallerClass() only returns the Class object where I would need typically need the StackTraceElement (or StackFrame) and the Class. Traversing through how getCallerClass() is implemented it wasn?t clear to me exactly how it was getting the Class since I haven?t spent a lot of time looking at CallerClassFinder, AbstractStackWalker, etc and haven?t looked at all at how callStackWalker is implemented. But my point is that if obtaining the StackFrame and Class could be done so quickly that it wouldn?t add any noticeable overhead we could do that in every Logger.info, debug, etc. call. If we could just get the stack frame index so that we could obtain the StackFrame and Class later by using the index that would be even better since we would only be creating the StackFrame, etc if it is really required. Ralph > On May 11, 2016, at 9:35 AM, Daniel Fuchs wrote: > > Hi Ralph, > > On 11/05/16 18:14, Ralph Goers wrote: >> You are correct that most of the time it would be faster to start from frame 0. However, the problem we have with walking the stack from frame 0 is that it is possible to have a situation like >> >> Foo::method1?>Logger.log?>BarAppender.append?>Foo::method2 (or even method1 again)?>Logger.log > > The appender would call Logger.log? Is that a common situation? > That sounds strange to me. > > I was kind of assuming that you could walk the stack until > finding an instance of Logger (which would allow you to skip > all the appender's infrastructure), then continue walking until > you find something which is no longer a Logger. > > I'm not sure I understand your other comment about getCallerClass(). > That just walks 2 frames (skipping reflection frame). > You can do the same with StackWalker, that should enable you > to get the calling frame easily. > > best regards, > > -- daniel > From ralph.goers at dslextreme.com Wed May 11 16:59:34 2016 From: ralph.goers at dslextreme.com (Ralph Goers) Date: Wed, 11 May 2016 09:59:34 -0700 Subject: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed In-Reply-To: <7BE50964-ED62-4AC0-9E8F-82D595AEEDE9@oracle.com> References: <5D245EC6-47C6-4BF1-A505-89934731A814@oracle.com> <360DDB44-FDFC-41DE-8DF9-9BBA3AF28581@oracle.com> <07C5EC23-C429-4961-B7D3-92B7C32FB535@dslextreme.com> <90BF6135-B457-4BD4-8DFF-9DE94F6D8DC7@oracle.com> <018AAA44-3689-4E79-B090-B0D1F0DD0CC1@oracle.com> <6A375668-62CA-47BE-B2AB-6BB3E7D3BEC0@dslextreme.com> <412730c6-fe73-88af-b80d-d8690f6721ee@oracle.com> <39C2DFD7-C49D-490A-A804-0FA60C1B2719@dslextreme.com> <5DD7029A-5C1B-4118-B452-104FA9C93659@dslextreme.com> <7BE50964-ED62-4AC0-9E8F-82D595AEEDE9@oracle.com> Message-ID: OK, I will try to give that a try over the next few days and try to see how much overhead it incurs. Ralph > On May 11, 2016, at 9:43 AM, Mandy Chung wrote: > > >> On May 11, 2016, at 9:24 AM, Ralph Goers wrote: >> >> Currently StackWalker has a getCallerClass method, but not a getCallerStackFrame. Having that method could also solve the problem, but only if it is efficient enough that it could be called for every log event, since when we would be calling it we wouldn?t even know if the user required it. In looking at getCallerClass it isn?t clear to me how fast it actually is. >> > > You can implement getCallerStackFrame using StackWalker as follows: > walker.walk(s -> s.skip(2).findFirst()); > > StackWalker::getCallerClass is implemented using StackWalker while it uses a smaller batch size as it knows it only interests in the top few frames. It?s smaller footprint since it only gets the Class object. > > Mandy > >> Ralph >> >>> On May 11, 2016, at 9:14 AM, Ralph Goers wrote: >>> >>> Yes, we need the StakWalker API for other parts of our code where we need the Class so we can determine what ClassLoader to use. For creating a LogEvent with location information we primarily need the class name, method name and line number. However, the ?extended? Throwable also returns the name of the jar the class came from and the location of the jar, so in that case we would want to use the StackWalker API - so it probably makes more sense to always use it. >>> >>> You are correct that most of the time it would be faster to start from frame 0. However, the problem we have with walking the stack from frame 0 is that it is possible to have a situation like >>> >>> Foo::method1?>Logger.log?>BarAppender.append?>Foo::method2 (or even method1 again)?>Logger.log >>> >>> If we start from the top we will believe Foo::method 1 is where we were called from, which would be incorrect. If in the Logger.log method we were able to capture the current stack frame index from StackWalker we could then pass that on through and then when we actually need the StackElement we could just ask for index-1, but I don?t see any methods like that, which is unfortunate. >>> >>> Ralph >>> >>>> On May 11, 2016, at 7:22 AM, Daniel Fuchs wrote: >>>> >>>> Hi Ralph, >>>> >>>> On 10/05/16 19:40, Ralph Goers wrote: >>>>> The benchmark logs events using Log4j 2?s asynchronous loggers. In the process of doing that it captures the location information using the code below: >>>>> >>>>> >>>>> // LOG4J2-1029 new Throwable().getStackTrace is faster than Thread.currentThread().getStackTrace(). >>>>> final StackTraceElement[] stackTrace = new Throwable().getStackTrace(); >>>>> StackTraceElement last = null; >>>>> for (int i = stackTrace.length - 1; i > 0; i--) { >>>>> final String className = stackTrace[i].getClassName(); >>>>> if (fqcnOfLogger.equals(className)) { >>>>> return last; >>>>> } >>>>> last = stackTrace[i]; >>>>> } >>>>> return null; >>>> >>>> Your benchmark walks the stack backwards. >>>> >>>> To take the full benefits of only walking part of the stack >>>> you should consider changing your algorithm to walk from >>>> frame 0 instead. >>>> >>>> With the StackWalker API you get a chance to get the >>>> Class that declares the method on the frame - which >>>> makes it possible to use things like Class.isAssignableFrom >>>> etc..., which could make it now possible to implement >>>> different strategies. >>>> >>>> Hope this helps, >>>> >>>> -- daniel >>>> >>>>> >>>>> Ralph >>>>> >>>>> >>>>>> On May 10, 2016, at 9:57 AM, Mandy Chung wrote: >>>>>> >>>>>> What does your benchmark call? >>>>>> >>>>>> Mandy >>>>>> >>>>>>> On May 10, 2016, at 9:49 AM, Ralph Goers wrote: >>>>>>> >>>>>>> I just ran one of the Log4j performance tests that specifically captures location information. To run the test I do >>>>>>> >>>>>>> java -jar log4j-perf/target/benchmarks.jar ".*AsyncAppenderLog4j2LocationBenchmark.*" -f 1 -wi 10 -i 20 -t 4 -si true >>>>>>> >>>>>>> And the results are: >>>>>>> >>>>>>> java version "1.7.0_80 >>>>>>> >>>>>>> Benchmark Mode Samples Score Error Units >>>>>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 124819.285 ? 3003.918 ops/s >>>>>>> >>>>>>> java version "1.8.0_65" >>>>>>> >>>>>>> Benchmark Mode Samples Score Error Units >>>>>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 123209.746 ? 3064.672 ops/s >>>>>>> >>>>>>> >>>>>>> java version "9-ea" >>>>>>> Java(TM) SE Runtime Environment (build 9-ea+116) >>>>>>> >>>>>>> Benchmark Mode Samples Score Error Units >>>>>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 96090.261 ? 4565.763 ops/s >>>>>>> >>>>>>> >>>>>>> This tells me that Java 9 is about 23% slower than previous versions in walking the stack trace elements. >>>>>>> >>>>>>> Ralph >>>>>>> >>>>>>>> On Apr 13, 2016, at 12:03 PM, Mandy Chung wrote: >>>>>>>> >>>>>>>> If you record all stack frames, I can believe Throwable is faster because of a recent optimization JDK-8150778 that has been made in jdk9 to improve the Throwable::getStackTraceElements method. >>>>>>>> >>>>>>>> Mandy >>>>>>>> >>>>>>>>> On Apr 13, 2016, at 11:49 AM, Ralph Goers wrote: >>>>>>>>> >>>>>>>>> I did a raw test of StackWalker by itself and the performance was much better than using a Throwable to get the location information. However, I haven?t tested how it will be implemented in Log4j. We still support Java 7 (and will for some time) so we have to find a way to support using StackWalker when running on Java 9 even though we build with Java 7. >>>>>>>>> >>>>>>>>> Ralph >>>>>>>>> >>>>>>>>>> On Apr 13, 2016, at 10:27 AM, Mandy Chung wrote: >>>>>>>>>> >>>>>>>>>> It is good to know Log4J is planning to use StackWalker. >>>>>>>>>> >>>>>>>>>> Thanks for the feedback. I will reconsider. >>>>>>>>>> >>>>>>>>>> One thing to mention is the patch went in jdk9/hs-rt that will show up in jdk9/dev some time that changes the implementation to create StackTraceElement to get filename and line number. The object allocation should be cheap that does create short-lived objects. The main motivation of JDK-8153123 was to simplify the hotspot implementation that the runtime team had concern about. There is an open issue to follow up the performance (JDK-8153683). It?d be helpful to get your feedback on using StackWalker API and the performance data. >>>>>>>>>> >>>>>>>>>> Mandy >>>>>>>>>> >>>>>>>>>>> On Apr 13, 2016, at 6:51 AM, Ralph Goers wrote: >>>>>>>>>>> >>>>>>>>>>> I had planned on using StackWalker to generate the location information for every logging event. It seems that this change would thus cause the creation of a new StackTraceElement for every logger event. That seems wasteful. Log4j is currently in the process of trying to reduce the number of objects that are created while logging as it has a significant impact on garbage collection. So I am also in favor of getting the filename and line number directly from the StackFrame. >>>>>>>>>>> >>>>>>>>>>> Ralph >>>>>>>>>>> >>>>>>>>>>>> On Apr 12, 2016, at 5:15 PM, Mandy Chung wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Apr 12, 2016, at 1:34 AM, R?mi Forax wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Mandy, >>>>>>>>>>>>> I really don't like this patch. >>>>>>>>>>>>> >>>>>>>>>>>>> Being forced to call toStackElement to get the line number is counter intuitive. >>>>>>>>>>>>> I would prefer the two methods to not return Optional but an int and a String with the same convention as StackElement if the point of this patch is to remove the dependency to Optional. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I was expecting the common usage of StackWalker API does not need file name and line number. I think it'd be useful to include StackFrame::getBci (in the future it might include live information like locals etc) and keep the optional stuff and uncommon usage to StackTraceElement. >>>>>>>>>>>> >>>>>>>>>>>> Mandy >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> R?mi >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Le 11 avril 2016 23:22:39 CEST, Mandy Chung a ?crit : >>>>>>>>>>>>>> Webrev at: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.00/index.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> StackFrame::getFileName and StackFrame::getLineNumber are originally >>>>>>>>>>>>>> proposed with the view of any stack walking code can migrate to the >>>>>>>>>>>>>> StackWalker API without the use of StackTraceElement. >>>>>>>>>>>>>> >>>>>>>>>>>>>> File name and line number are useful for debugging and troubleshooting >>>>>>>>>>>>>> purpose. It has additional overhead to map from a method and BCI to >>>>>>>>>>>>>> look up the file name and line number. >>>>>>>>>>>>>> >>>>>>>>>>>>>> StackFrame::toStackTraceElement method returns StackTraceElement that >>>>>>>>>>>>>> includes the file name and line number. There is no particular benefit >>>>>>>>>>>>>> to duplicate getFileName and getLineNumber methods in StackFrame. It is >>>>>>>>>>>>>> equivalently convenient to call >>>>>>>>>>>>>> StackFrame.toStackTraceElement().getFileName() (or getLineNumber). >>>>>>>>>>>>>> >>>>>>>>>>>>>> This patch proposes to remove StackFrame::getFileName and >>>>>>>>>>>>>> StackFrame::getLineNumber methods since such information can be >>>>>>>>>>>>>> obtained from StackFrame.toStackTraceElement(). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Mandy >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > From daniel.fuchs at oracle.com Wed May 11 17:20:47 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 11 May 2016 19:20:47 +0200 Subject: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed In-Reply-To: <3C161A46-360E-4E27-A544-51EF8A784735@dslextreme.com> References: <5D245EC6-47C6-4BF1-A505-89934731A814@oracle.com> <360DDB44-FDFC-41DE-8DF9-9BBA3AF28581@oracle.com> <07C5EC23-C429-4961-B7D3-92B7C32FB535@dslextreme.com> <90BF6135-B457-4BD4-8DFF-9DE94F6D8DC7@oracle.com> <018AAA44-3689-4E79-B090-B0D1F0DD0CC1@oracle.com> <6A375668-62CA-47BE-B2AB-6BB3E7D3BEC0@dslextreme.com> <412730c6-fe73-88af-b80d-d8690f6721ee@oracle.com> <39C2DFD7-C49D-490A-A804-0FA60C1B2719@dslextreme.com> <3C161A46-360E-4E27-A544-51EF8A784735@dslextreme.com> Message-ID: Hi, On 11/05/16 18:57, Ralph Goers wrote: > But my point is that if obtaining the StackFrame and Class > could be done so quickly that it wouldn?t add any noticeable > overhead we could do that in every Logger.info, debug, etc. call. > If we could just get the stack frame index so that we could obtain > the StackFrame and Class later by using the index that would be even > better since we would only be creating the StackFrame, etc if it is really required. Working with stack frame indexes is at best fragile, unless you make a snapshot of the stack first and only used the index in relation to that snapshot. So I wouldn't recommend going that way. Furthermore to obtain such an index you would need to count the frames - which would mean walking the whole stack. I'm still not sure I understand why an appender would call Logger.log. That sounds like a recipe for stack overflow or endless ping pong loops. I understand that could theoretically happen but then the appender would need to protect itself against 'logging while logging'. Or am I misunderstanding? best regards, -- daniel From daniel.fuchs at oracle.com Wed May 11 17:39:03 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 11 May 2016 19:39:03 +0200 Subject: Review request for JDK-8156680: jdeps implementation refresh In-Reply-To: References: Message-ID: Hi Mandy, I had a look at the first webrev. Code reorganization in some of the files makes it difficult to follow what is going on. I will try to import the changes in my local workspace tomorrow and play with it a bit. I have two small comments so far: On 11/05/16 02:12, Mandy Chung wrote: > JDK-8156680: jdeps implementation refresh > JDK-8153042: jdeps should continue to report JDK internal APIs that are removed/renamed in JDK 9 > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8156680/webrev.00/ Archive.java: 106 public Stream getDependencies() { 107 return deps.values().stream() 108 .flatMap(Set::stream); 109 } I suspect it might be more correct to do: return deps.values().stream() .flatMap(Set::stream) .distinct(); DependencyFinder.java: 82 Set archives() { 83 waitForTasksCompleted(); 84 Set set = new LinkedHashSet<>(); 85 parsedClasses.values().stream() 86 .forEach(archive -> set.add(archive)); 87 return set; 88 } Should that be: Set archives() { waitForTasksCompleted(); return parsedClasses.values().stream() .toCollection(LinkedHashSet::new); } best regards, -- daniel > > This refactors the jdeps implementation that regression tests can be developed without the need to parse the output file. It also includes a list of the removed JDK internal APIs and provides the pointer where to look for more further information. > > JDK-8153481: tools/jdeps/modules/GenModuleInfo.java and ModuleTest.java fails intermittently > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153481/webrev.00/ > > Mandy > From daniel.fuchs at oracle.com Wed May 11 17:40:16 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 11 May 2016 19:40:16 +0200 Subject: Review request for JDK-8156680: jdeps implementation refresh In-Reply-To: References: Message-ID: <9f55be9c-68b6-4df1-83c3-ae0d1751bde5@oracle.com> On 11/05/16 02:12, Mandy Chung wrote: > JDK-8153481: tools/jdeps/modules/GenModuleInfo.java and ModuleTest.java fails intermittently > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153481/webrev.00/ > > Mandy second webrev above looks good. best regards, -- daniel From brent.christian at oracle.com Wed May 11 18:22:50 2016 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 11 May 2016 11:22:50 -0700 Subject: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival In-Reply-To: <57325921.9090100@oracle.com> References: <55479A4F.4060806@oracle.com> <5550FE5A.4070607@oracle.com> <55513EA7.1050700@oracle.com> <555192A4.3080305@gmail.com> <5551A0AA.6050800@gmail.com> <5552674E.4030009@oracle.com> <55526FF5.9000509@gmail.com> <55564473.3010704@oracle.com> <8DD50D66-D2C1-43E4-B7C5-992FE785958B@oracle.com> <57325921.9090100@oracle.com> Message-ID: <5733787A.70806@oracle.com> On 5/10/16 2:56 PM, Brent Christian wrote: > > While good progress was made during the original code review, all of the > overridden methods in Properties caused an explosion of unnecessary > JavaDoc (see specdiff at [2]). With the recent fix of 8073100 (new > "@hidden" JavaDoc tag), we can now avoid the additional clutter. To see @hidden in action, here's what the new specdiff looks like: http://cr.openjdk.java.net/~bchristi/8029891/webrev.4/specdiff/package-summary.html -Brent From ralph.goers at dslextreme.com Wed May 11 19:00:26 2016 From: ralph.goers at dslextreme.com (Ralph Goers) Date: Wed, 11 May 2016 12:00:26 -0700 Subject: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed In-Reply-To: References: <5D245EC6-47C6-4BF1-A505-89934731A814@oracle.com> <360DDB44-FDFC-41DE-8DF9-9BBA3AF28581@oracle.com> <07C5EC23-C429-4961-B7D3-92B7C32FB535@dslextreme.com> <90BF6135-B457-4BD4-8DFF-9DE94F6D8DC7@oracle.com> <018AAA44-3689-4E79-B090-B0D1F0DD0CC1@oracle.com> <6A375668-62CA-47BE-B2AB-6BB3E7D3BEC0@dslextreme.com> <412730c6-fe73-88af-b80d-d8690f6721ee@oracle.com> <39C2DFD7-C49D-490A-A804-0FA60C1B2719@dslextreme.com> <3C161A46-360E-4E27-A544-51EF8A784735@dslextreme.com> Message-ID: I am not at all familiar with how the stack is actually managed. I was hoping it was just an array and that the index into it was being kept track of. Since we know that we will only be adding more stack elements I would think that deferring use of that index wouldn?t be a problem. But since I have no idea how it is managed all I can really do is guess and hope. As far as the appender calling a logger, it happens all the time. Log4j 1 had serious problems with it and could get itself in a deadlock. In Log4j 2 we handle that by wrapping each appender with an AppenderControl. The AppenderControl has a thread local guard. If the guard is set then the appenderControl just ignores the event. But if logging for the stuff going on inside of an appender is routed to a different appender there is no problem. So recursion is not a problem. Without this most of the interesting things users do with Log4j wouldn?t be possible or at least would be hard to debug. I have to believe that jul will have the same problem with custom handlers written by users. Ralph > On May 11, 2016, at 10:20 AM, Daniel Fuchs wrote: > > Hi, > > On 11/05/16 18:57, Ralph Goers wrote: >> But my point is that if obtaining the StackFrame and Class >> could be done so quickly that it wouldn?t add any noticeable >> overhead we could do that in every Logger.info, debug, etc. call. >> If we could just get the stack frame index so that we could obtain >> the StackFrame and Class later by using the index that would be even >> better since we would only be creating the StackFrame, etc if it is really required. > > Working with stack frame indexes is at best fragile, unless > you make a snapshot of the stack first and only used the > index in relation to that snapshot. So I wouldn't recommend > going that way. Furthermore to obtain such an index you > would need to count the frames - which would mean walking the > whole stack. > > I'm still not sure I understand why an appender would > call Logger.log. That sounds like a recipe for stack > overflow or endless ping pong loops. > I understand that could theoretically happen but then the > appender would need to protect itself against 'logging > while logging'. Or am I misunderstanding? > > best regards, > > -- daniel > From uschindler at apache.org Wed May 11 19:35:32 2016 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 11 May 2016 21:35:32 +0200 Subject: MethodHandle for array length Message-ID: <00a601d1abbc$4a907ec0$dfb17c40$@apache.org> Hi, while working and trying the new JDK9 MethodHandles features like MethodHandles#countedLoop, I recognized a API inconsistency problem with it. We also found this while implementing the "Painless" scripting language for Elasticsearch (see https://goo.gl/DbOzjC)! Painless is a very limited scripting language with a very limited subset of classes to access and close integration into Elasticsearch (similar to Lucene's Expressions Module). Both compile script code to anonymous classes and Elasticsearch uses invokedynamic for the untyped stuff. It is much faster than Groovy or Nashorn, because it compiles most of the code completely static with known types (like Lucene expressions), but also supports a Groovy-like "def" type. The latter one uses invokedynamic, everything else is exactly the same speed as native Java code. During implementing array getters and setters for untyped stuff with invokedynamic we recognized the following problem (Java 8 code, see https://github.com/elastic/elasticsearch/pull/18232): There is MethodHandles.arrayElementGetter and MethodHandles.arrayElementSetter, so we can have full speed and full dynamic flexibility for array loads and stores - the speed is great, same as native array access! But there is one factory method missing in Java 8: MethodHandles.arrayLengthGetter (or similar name). As "length" is not a field on the array class, it is impossible to create a "simple" MethodHandle as field access to "array.class#length" to access it (it must invoke the "arraylength" bytecode, there is no field). I think the "length" field is just syntactic sugar of javac compiler. I know that Nashorn used to use java.lang.reflect.Array#getLength (not sure if this is still the case), but this makes usage inconsistent. You have to explicitly create a MethodHandle using the reflective array class to use it: And it is not strongly typed (it accepts Object). A real MethodHandle would be created for a specific type of array class and would return its length without runtime type checks. I know that at least Array.getLength() is optimized by Hotspot (in contrast to the other get/set methods, which are like 20 times slower than a method access, so MethodHandles.arrayElementGetter/Setter is very useful), but I would really like to suggest to fix this! With Java 9 this gets a bit worse: There is no "easy way" with the MethodHanldes class to generate a MethodHandles.countedLoop() on all elements of an array: public static MethodHandle countedLoop(MethodHandle iterations, MethodHandle init, MethodHandle body) [new in Java 9] With a full-featured API one could write: Class type = arraytype, e.g. long[].class or String[].class MethodHandle body = some code that uses MethodHandles.arrayElementGetter(type) for further processing MethodHandles.countedLoop(MethodHandles.arrayLengthGetter(type), MethodHandles.constant(int.class, 0), body); As you see, for the first parameter (count), you would need to use the reflective part in java.lang.reflect.Array if the method is still missing in Java 9. This is not bad here, because it is not called all the time, but for our scripting language, the reflective class was slower. We implemented our own version of "arrayLengthGetter": public class ArrayLengthHelper { private ArrayLengthHelper() {} private static final Lookup PRIV_LOOKUP = MethodHandles.lookup(); private static final Map,MethodHandle> ARRAY_TYPE_MH_MAPPING = Collections.unmodifiableMap( Stream.of(boolean[].class, byte[].class, short[].class, int[].class, long[].class, char[].class, float[].class, double[].class, Object[].class) .collect(Collectors.toMap(Function.identity(), type -> { try { return PRIV_LOOKUP.findStatic(PRIV_LOOKUP.lookupClass(), "getArrayLength", MethodType.methodType(int.class, type)); } catch (ReflectiveOperationException e) { throw new AssertionError(e); } })) ); private static final MethodHandle OBJECT_ARRAY_MH = ARRAY_TYPE_MH_MAPPING.get(Object[].class); static int getArrayLength(boolean[] array) { return array.length; } static int getArrayLength(byte[] array) { return array.length; } static int getArrayLength(short[] array) { return array.length; } static int getArrayLength(int[] array) { return array.length; } static int getArrayLength(long[] array) { return array.length; } static int getArrayLength(char[] array) { return array.length; } static int getArrayLength(float[] array) { return array.length; } static int getArrayLength(double[] array) { return array.length; } static int getArrayLength(Object[] array) { return array.length; } public static MethodHandle arrayLengthGetter(Class arrayType) { if (!arrayType.isArray()) { throw new IllegalArgumentException("type must be an array"); } return (ARRAY_TYPE_MH_MAPPING.containsKey(arrayType)) ? ARRAY_TYPE_MH_MAPPING.get(arrayType) : OBJECT_ARRAY_MH.asType(OBJECT_ARRAY_MH.type().changeParameterType(0, arrayType)); } } Interestingly I later found out that MethodHandles.arrayElementGetter/Setter uses the same "trick" behind the scenes! See MethodHandleImpl.ArrayAccessor: http://goo.gl/94f6OB I would suggest to add the missing Method to MethodHandles class and implement it together with the getters and setters in ArrayAccessor, similar to our example code (it is just a few lines more). In addition this one could then also use the extra intrinsic improvement that our class cannot use: makeIntrinsic(getAccessor(Object[].class, false), Intrinsic.ARRAY_LOAD); [with another intrinsic added: Intrinsic.ARRAY_LENGTH for the arraylength bytecode] What would be the process to propose such a change? Bug/Issue/JEP? I could quickly create a patch, but fixing the Intrinsic/LambdaForm stuff is way too complicated for me, so I would suggest to take this as an inspiration how to do it Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ From mandy.chung at oracle.com Wed May 11 19:44:07 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 11 May 2016 12:44:07 -0700 Subject: Review request for JDK-8156680: jdeps implementation refresh In-Reply-To: References: Message-ID: <6D81F159-5607-4BDA-94AB-6C9FD0FF1BD8@oracle.com> > On May 11, 2016, at 10:39 AM, Daniel Fuchs wrote: > > Hi Mandy, > > I had a look at the first webrev. > > Code reorganization in some of the files makes it difficult > to follow what is going on. I will try to import > the changes in my local workspace tomorrow and play with > it a bit. Thanks. > > I have two small comments so far: > > Archive.java: > > 106 public Stream getDependencies() { > 107 return deps.values().stream() > 108 .flatMap(Set::stream); > 109 } > > I suspect it might be more correct to do: > > return deps.values().stream() > .flatMap(Set::stream) > .distinct(); > This lets the caller of this method to decide if it wants to sort the stream, distince, or filtering to avoid unnecessary sort. > DependencyFinder.java: > > 82 Set archives() { > 83 waitForTasksCompleted(); > 84 Set set = new LinkedHashSet<>(); > 85 parsedClasses.values().stream() > 86 .forEach(archive -> set.add(archive)); > 87 return set; > 88 } > > Should that be: > > Set archives() { > waitForTasksCompleted(); > return parsedClasses.values().stream() > .toCollection(LinkedHashSet::new); > } > Will modify that. Mandy From stuart.marks at oracle.com Wed May 11 21:04:25 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 11 May 2016 14:04:25 -0700 Subject: RFR(m): 8140281 deprecate Optional.get() In-Reply-To: References: <1282fc0c-2d92-be13-d95e-9486cd556146@oracle.com> <571EA9D8.3010702@oracle.com> <5dad068b-038e-591c-49a1-ffcc22ffebb8@oracle.com> <350f4ee8-e59a-1518-adda-1a52f3654b96@oracle.com> Message-ID: On 5/10/16 7:59 PM, Martin Buchholz wrote: > Consider a library like guava classic. It currently supports jdk 6+, > and there's a good chance that library will do that until its end of > life, which is likely to be around the time when EVERYBODY is using > jdk 8+, which is still many years away. Even there, it would be nice > to compile with javac 9 without any warnings. Proliferation of > deprecation warnings in new JDK releases leave conscientious library > maintainers with no choice but to spray @SuppressWarnings everywhere. > They may even end up doing so preemptively. The deprecation warnings > are pure pain; no benefit; the replacement API may never be an option > for such a library. > > The older Java gets, the more players in the ecosystem, and the slower > the adoption curve. OK, sure, I get that there are libraries that will need to stay back on older releases for a very long time. What I don't necessarily get is why they might require @SuppressWarnings. Let's take a somewhat concrete example, using an existing, recently-deprecated API. The method SecurityManager.checkMemberAccess(Class, int) had no deprecation annotation in Java 7, and it was deprecated in Java 8. (Its deprecation was "upgraded" to forRemoval=true in Java 9, but let's just consider 7 and 8 for the moment.) Suppose I have some source code that uses this method, and I compile it using JDK 7. Since I'm meticulous about this, I enable all lint warnings and turn them into errors: $ $JDK7/bin/javac -Xlint:all -Werror CheckMember.java This works fine. If I recompile using JDK 8, then this happens: $ $JDK8/bin/javac -Xlint:all -Werror CheckMember.java CheckMember.java:6: warning: [deprecation] checkMemberAccess(Class,int) in SecurityManager has been deprecated sm.checkMemberAccess(String.class, Member.PUBLIC); ^ error: warnings found and -Werror specified 1 error 1 warning Disaster! Now I have to hack around with -Xlint options and @SuppressWarnings annotations! Or do I? Since I want this thing to run on 7 and 8, I could just continue compiling it using JDK 7, or if I want to compile using JDK 8, I can do this: $ $JDK8/bin/javac -Xlint:all -Werror -source 1.7 -target 1.7 -Xbootclasspath:$JDK7/jre/lib/rt.jar CheckMember.java This completes with no warnings or errors. In JDK 9 (I'm using build 116) I can do this: $ $JDK9/bin/javac -Xlint:all -Werror -release 7 CheckMember.java and again it completes with no warnings or errors. (I'm not sure why I have to switch from 1.7 to 7.) Note also that I don't have to have a JDK 7 lying around for this to work. This works if you're willing to build once and use the same binary on different JDK versions. Where you might run into trouble is if you want to use the same source code and compile it using different JDK versions. Is this what you're doing? If so, is there a reason you can't use the same binary on multiple releases? If not, can you explain what you need to do that causes deprecation warnings? s'marks From stuart.marks at oracle.com Wed May 11 21:37:11 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 11 May 2016 14:37:11 -0700 Subject: RFR(m): 8139233u1 add initial compact immutable collection implementations In-Reply-To: <663479067.594910.1462821425057.JavaMail.zimbra@u-pem.fr> References: <9622a280-f29a-820c-00e9-74f41964141f@oracle.com> <192fcb16-aa51-5662-e38b-1efb2a68937e@oracle.com> <394584297.477564.1462803923948.JavaMail.zimbra@u-pem.fr> <663479067.594910.1462821425057.JavaMail.zimbra@u-pem.fr> Message-ID: <1c9d4831-9436-078a-9974-5df6500a7f47@oracle.com> Hi, I agree with Stephen, using an enum here is overkill. :-) The way I think about this is that the collection implementations and the CollSer proxy are fairly closely coupled, so adding an enum here only makes this coupling more obscure. There's another wrinkle that I had slipped into the updated webrev. Only the low order 8 bits of the flags field indicates the type of the collection. The high order 24 bits are deliberately ignored by this implementation, so they can be used by future implementations to indicate some variations on the basic types. The 8/24 split is pretty much arbitrary. I'm not entirely sure how the 24 bits might be used, but it's nice having some spare bits around, and it's simpler than adding fields to future serialized forms. Speaking of serialized form, note that I still need to specify the serialized format. That's covered by JDK-8133977, forthcoming. s'marks On 5/9/16 12:17 PM, Remi Forax wrote: > Hi Stephen, > you may right :) > > First note that the Enum values are used as an ephemeral state, the serialized form still uses an integer as the original code. > You can also note that the enum is not loaded if no immutable collection is serialized (because CollSer is not initialized). > It's just a good old OOP trick that transforms a switch to a dispatch that will be used when de-serializing. > > In my opinion, if there are several other immutable collections (like the ordered set/map proposed by Stuart), the code with an enum is easier to modify that the current code, otherwise, as you said, it's an overkill. > > R?mi > > ----- Mail original ----- >> De: "Stephen Colebourne" >> ?: "core-libs-dev" >> Envoy?: Lundi 9 Mai 2016 19:49:15 >> Objet: Re: RFR(m): 8139233u1 add initial compact immutable collection implementations >> >> On 9 May 2016 at 15:25, Remi Forax wrote: >>> CollSer implementation can be improved to avoid the ugly switch/case by >>> replacing the constant list by an enum, >> >> CollSer is modelled on JSR-310 code which uses an int. An enum would >> be a huge overkill for this use case. >> >> Stephen >> From martinrb at google.com Wed May 11 21:37:15 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 11 May 2016 14:37:15 -0700 Subject: RFR(m): 8140281 deprecate Optional.get() In-Reply-To: References: <1282fc0c-2d92-be13-d95e-9486cd556146@oracle.com> <571EA9D8.3010702@oracle.com> <5dad068b-038e-591c-49a1-ffcc22ffebb8@oracle.com> <350f4ee8-e59a-1518-adda-1a52f3654b96@oracle.com> Message-ID: On Wed, May 11, 2016 at 2:04 PM, Stuart Marks wrote: > This works if you're willing to build once and use the same binary on > different JDK versions. Where you might run into trouble is if you want to > use the same source code and compile it using different JDK versions. Is > this what you're doing? If so, is there a reason you can't use the same > binary on multiple releases? If not, can you explain what you need to do > that causes deprecation warnings? The problem is again that the library maintainer is not the same as the compiler invoker. A conscientious library maintainer does not stop at ensuring that their own builds are warning free; they want to ensure as much as they can that their users can also do $compiler -Xlint:all -Werror, even with future javac releases and other folks' toolchains. Of course, this is an impossible task; compilers add warnings all the time. But still one tries! JDK maintainers have the rare luxury of targeting only one release at a time. From forax at univ-mlv.fr Wed May 11 21:40:34 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 11 May 2016 23:40:34 +0200 (CEST) Subject: MethodHandle for array length In-Reply-To: <00a601d1abbc$4a907ec0$dfb17c40$@apache.org> References: <00a601d1abbc$4a907ec0$dfb17c40$@apache.org> Message-ID: <313649021.1504150.1463002834275.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Uwe Schindler" > ?: "Core-Libs-Dev" > Envoy?: Mercredi 11 Mai 2016 21:35:32 > Objet: MethodHandle for array length > > Hi, > Hi Uwe, > while working and trying the new JDK9 MethodHandles features like > MethodHandles#countedLoop, I recognized a API inconsistency problem with it. > > We also found this while implementing the "Painless" scripting language for > Elasticsearch (see https://goo.gl/DbOzjC)! Painless is a very limited > scripting language with a very limited subset of classes to access and close > integration into Elasticsearch (similar to Lucene's Expressions Module). > Both compile script code to anonymous classes and Elasticsearch uses > invokedynamic for the untyped stuff. It is much faster than Groovy or > Nashorn, because it compiles most of the code completely static with known > types (like Lucene expressions), but also supports a Groovy-like "def" type. > The latter one uses invokedynamic, everything else is exactly the same speed > as native Java code. I think you can do something similar in Groovy with the annotation @TypeChecl and @StaticCompilation, see [1]. > > During implementing array getters and setters for untyped stuff with > invokedynamic we recognized the following problem (Java 8 code, see > https://github.com/elastic/elasticsearch/pull/18232): > > There is MethodHandles.arrayElementGetter and > MethodHandles.arrayElementSetter, so we can have full speed and full dynamic > flexibility for array loads and stores - the speed is great, same as native > array access! But there is one factory method missing in Java 8: > MethodHandles.arrayLengthGetter (or similar name). As "length" is not a > field on the array class, it is impossible to create a "simple" MethodHandle > as field access to "array.class#length" to access it (it must invoke the > "arraylength" bytecode, there is no field). I think the "length" field is > just syntactic sugar of javac compiler. > > I know that Nashorn used to use java.lang.reflect.Array#getLength (not sure > if this is still the case), but this makes usage inconsistent. You have to > explicitly create a MethodHandle using the reflective array class to use it: > And it is not strongly typed (it accepts Object). A real MethodHandle would > be created for a specific type of array class and would return its length > without runtime type checks. I know that at least Array.getLength() is > optimized by Hotspot (in contrast to the other get/set methods, which are > like 20 times slower than a method access, so > MethodHandles.arrayElementGetter/Setter is very useful), but I would really > like to suggest to fix this! > > With Java 9 this gets a bit worse: There is no "easy way" with the > MethodHanldes class to generate a MethodHandles.countedLoop() on all > elements of an array: > > public static MethodHandle countedLoop(MethodHandle iterations, MethodHandle > init, MethodHandle body) [new in Java 9] > > With a full-featured API one could write: > > Class type = arraytype, e.g. long[].class or String[].class > MethodHandle body = some code that uses > MethodHandles.arrayElementGetter(type) for further processing > MethodHandles.countedLoop(MethodHandles.arrayLengthGetter(type), > MethodHandles.constant(int.class, 0), body); > > As you see, for the first parameter (count), you would need to use the > reflective part in java.lang.reflect.Array if the method is still missing in > Java 9. This is not bad here, because it is not called all the time, but for > our scripting language, the reflective class was slower. > > We implemented our own version of "arrayLengthGetter": > > public class ArrayLengthHelper { > private ArrayLengthHelper() {} > > private static final Lookup PRIV_LOOKUP = MethodHandles.lookup(); > private static final Map,MethodHandle> ARRAY_TYPE_MH_MAPPING = > Collections.unmodifiableMap( > Stream.of(boolean[].class, byte[].class, short[].class, int[].class, > long[].class, char[].class, float[].class, double[].class, > Object[].class) > .collect(Collectors.toMap(Function.identity(), type -> { > try { > return PRIV_LOOKUP.findStatic(PRIV_LOOKUP.lookupClass(), > "getArrayLength", MethodType.methodType(int.class, type)); > } catch (ReflectiveOperationException e) { > throw new AssertionError(e); > } > })) > ); > private static final MethodHandle OBJECT_ARRAY_MH = > ARRAY_TYPE_MH_MAPPING.get(Object[].class); > > static int getArrayLength(boolean[] array) { return array.length; } > static int getArrayLength(byte[] array) { return array.length; } > static int getArrayLength(short[] array) { return array.length; } > static int getArrayLength(int[] array) { return array.length; } > static int getArrayLength(long[] array) { return array.length; } > static int getArrayLength(char[] array) { return array.length; } > static int getArrayLength(float[] array) { return array.length; } > static int getArrayLength(double[] array) { return array.length; } > static int getArrayLength(Object[] array) { return array.length; } > > public static MethodHandle arrayLengthGetter(Class arrayType) { > if (!arrayType.isArray()) { > throw new IllegalArgumentException("type must be an array"); > } > return (ARRAY_TYPE_MH_MAPPING.containsKey(arrayType)) ? > ARRAY_TYPE_MH_MAPPING.get(arrayType) : > OBJECT_ARRAY_MH.asType(OBJECT_ARRAY_MH.type().changeParameterType(0, > arrayType)); > } > } > > Interestingly I later found out that MethodHandles.arrayElementGetter/Setter > uses the same "trick" behind the scenes! See MethodHandleImpl.ArrayAccessor: > http://goo.gl/94f6OB > > I would suggest to add the missing Method to MethodHandles class and > implement it together with the getters and setters in ArrayAccessor, similar > to our example code (it is just a few lines more). In addition this one > could then also use the extra intrinsic improvement that our class cannot > use: makeIntrinsic(getAccessor(Object[].class, false), > Intrinsic.ARRAY_LOAD); > [with another intrinsic added: Intrinsic.ARRAY_LENGTH for the arraylength > bytecode] > > What would be the process to propose such a change? Bug/Issue/JEP? > I could quickly create a patch, but fixing the Intrinsic/LambdaForm stuff is > way too complicated for me, so I would suggest to take this as an > inspiration how to do it > > Uwe as you said, Array.getLength is already optimized by the JIT, it's because the length of an array is at the same offset for any kind of array in Hotspot, so unlike array access that depends on the kind of array, getting the length of an array is the same code for any kind of array. So you can safely, performance wise, create a method handle on Array.getLength, that's why there is no arrayLengthGetter in MethodHandles. regards, R?mi [1] http://www.infoq.com/articles/new-groovy-20 > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > > > From aleksej.efimov at oracle.com Wed May 11 23:30:49 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Thu, 12 May 2016 02:30:49 +0300 Subject: [9] RFR: 8145974: XMLStreamWriter produces invalid XML for surrogate pairs on OutputStreamWriter Message-ID: <5733C0A9.8000800@oracle.com> Hello, Please, help to review the fix for XMLStreamWriter bug [1]: XMLStreamWriter incorrectly writes surrogate pairs into pair of invalid character references. For example: "\ud83d\ude0a" is transformed into "��". It should be one character reference "😊" instead. The proposed patch fixes the XMLStreamWriterImpl to correctly process surrogate pairs: http://cr.openjdk.java.net/~aefimov/8145974/9/00 The build with fix applied was tested with JTREG and JCK xml tests - no related issues detected. Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8145974 From stuart.marks at oracle.com Wed May 11 23:47:23 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 11 May 2016 16:47:23 -0700 Subject: RFR(xs): 8156810 remove redundant sentence in SecurityManager.checkMemberAccess doc Message-ID: Hi all, Regarding this bug, https://bugs.openjdk.java.net/browse/JDK-8156810 I had recently "upgraded" the deprecation annotation of SecurityManager.checkMemberAccess() to include forRemoval=true. [1] [2] This included the addition of some text about removal in a future version. Unfortunately the deprecation text now reads, in part, This method will be changed in a future release to check the permission java.security.AllPermission. This method is subject to removal in a future version of Java SE. Obviously the first sentence is irrelevant now that we're going to remove the method entirely. Please review diff appended below that removes the first sentence. Thanks, s'marks [1] https://bugs.openjdk.java.net/browse/JDK-8145468 [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040192.html diff -r 5f4aff1d2242 src/java.base/share/classes/java/lang/SecurityManager.java --- a/src/java.base/share/classes/java/lang/SecurityManager.java Mon May 09 18:11:02 2016 +0800 +++ b/src/java.base/share/classes/java/lang/SecurityManager.java Wed May 11 16:46:11 2016 -0700 @@ -1627,8 +1627,7 @@ * @deprecated This method relies on the caller being at a stack depth * of 4 which is error-prone and cannot be enforced by the runtime. * Users of this method should instead invoke {@link #checkPermission} - * directly. This method will be changed in a future release - * to check the permission {@code java.security.AllPermission}. + * directly. * This method is subject to removal in a future version of Java SE. * * @see java.lang.reflect.Member From joe.darcy at oracle.com Wed May 11 23:50:01 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 11 May 2016 16:50:01 -0700 Subject: RFR(xs): 8156810 remove redundant sentence in SecurityManager.checkMemberAccess doc In-Reply-To: References: Message-ID: <5733C529.7000405@oracle.com> Looks fine Stuart, -Joe On 5/11/2016 4:47 PM, Stuart Marks wrote: > Hi all, > > Regarding this bug, > > https://bugs.openjdk.java.net/browse/JDK-8156810 > > I had recently "upgraded" the deprecation annotation of > SecurityManager.checkMemberAccess() to include forRemoval=true. [1] > [2] This included the addition of some text about removal in a future > version. Unfortunately the deprecation text now reads, in part, > > This method will be changed in a future release to check the > permission java.security.AllPermission. This method is subject > to removal in a future version of Java SE. > > Obviously the first sentence is irrelevant now that we're going to > remove the method entirely. > > Please review diff appended below that removes the first sentence. > > Thanks, > > s'marks > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8145468 > > [2] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040192.html > > > > diff -r 5f4aff1d2242 > src/java.base/share/classes/java/lang/SecurityManager.java > --- a/src/java.base/share/classes/java/lang/SecurityManager.java Mon > May 09 18:11:02 2016 +0800 > +++ b/src/java.base/share/classes/java/lang/SecurityManager.java Wed > May 11 16:46:11 2016 -0700 > @@ -1627,8 +1627,7 @@ > * @deprecated This method relies on the caller being at a stack > depth > * of 4 which is error-prone and cannot be enforced > by the runtime. > * Users of this method should instead invoke {@link > #checkPermission} > - * directly. This method will be changed in a future > release > - * to check the permission {@code > java.security.AllPermission}. > + * directly. > * This method is subject to removal in a future > version of Java SE. > * > * @see java.lang.reflect.Member From sean.mullan at oracle.com Thu May 12 00:33:41 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 11 May 2016 17:33:41 -0700 Subject: RFR(xs): 8156810 remove redundant sentence in SecurityManager.checkMemberAccess doc In-Reply-To: References: Message-ID: <5733CF65.7050502@oracle.com> Looks good. --Sean On 5/11/16 4:47 PM, Stuart Marks wrote: > Hi all, > > Regarding this bug, > > https://bugs.openjdk.java.net/browse/JDK-8156810 > > I had recently "upgraded" the deprecation annotation of > SecurityManager.checkMemberAccess() to include forRemoval=true. [1] [2] > This included the addition of some text about removal in a future > version. Unfortunately the deprecation text now reads, in part, > > This method will be changed in a future release to check the > permission java.security.AllPermission. This method is subject > to removal in a future version of Java SE. > > Obviously the first sentence is irrelevant now that we're going to > remove the method entirely. > > Please review diff appended below that removes the first sentence. > > Thanks, > > s'marks > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8145468 > > [2] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040192.html > > > > diff -r 5f4aff1d2242 > src/java.base/share/classes/java/lang/SecurityManager.java > --- a/src/java.base/share/classes/java/lang/SecurityManager.java Mon > May 09 18:11:02 2016 +0800 > +++ b/src/java.base/share/classes/java/lang/SecurityManager.java Wed > May 11 16:46:11 2016 -0700 > @@ -1627,8 +1627,7 @@ > * @deprecated This method relies on the caller being at a stack > depth > * of 4 which is error-prone and cannot be enforced by > the runtime. > * Users of this method should instead invoke {@link > #checkPermission} > - * directly. This method will be changed in a future > release > - * to check the permission {@code > java.security.AllPermission}. > + * directly. > * This method is subject to removal in a future > version of Java SE. > * > * @see java.lang.reflect.Member From david.holmes at oracle.com Thu May 12 03:39:41 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 May 2016 13:39:41 +1000 Subject: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival In-Reply-To: <57325921.9090100@oracle.com> References: <55479A4F.4060806@oracle.com> <5550FE5A.4070607@oracle.com> <55513EA7.1050700@oracle.com> <555192A4.3080305@gmail.com> <5551A0AA.6050800@gmail.com> <5552674E.4030009@oracle.com> <55526FF5.9000509@gmail.com> <55564473.3010704@oracle.com> <8DD50D66-D2C1-43E4-B7C5-992FE785958B@oracle.com> <57325921.9090100@oracle.com> Message-ID: Hi Brent, On 11/05/2016 7:56 AM, Brent Christian wrote: > Hi! Welcome back to 8029891, "Deadlock detected in > java/lang/ClassLoader/deadlock/GetResource.java". Our previous > discussion is at [1]. > > Briefly, java.util.Properties isa Hashtable, which synchronizes on > itself for any access. System.getProperties() returns the Properties > instance accessed by the system, which any application code might > synchronize on (that's what the test is doing). System properties are a > common way for changing default setting, so it's impractical to expect > the class loading code path not to call System.getProperty. > > The fix is to change Properties to store its values in an internal > ConcurrentHashMap, ignoring its Hashtable heritage. In this way, > Properties can be (partly) "de-sychronized", and deadlocks avoided. As before I don't have any major concerns with this approach. > While good progress was made during the original code review, all of the > overridden methods in Properties caused an explosion of unnecessary > JavaDoc (see specdiff at [2]). With the recent fix of 8073100 (new > "@hidden" JavaDoc tag), we can now avoid the additional clutter. The existing javadoc has a section "Methods inherited from java.util.Hashtable" which I can't see in your specdiff - what does that section say about the methods you overrode to delegate to the CHM instance? Are they simply not listed, or does it lie and claim they are inherited, or does it have some new way to present "@hidden" things? > Highlights from the previous discussion: > > * Specifics of where to remove synchronization: generally, read methods > will be de-synchronized, while write/bulk-read operations will stay > synchronized. > > * We considered whether we might be able use special-case code just for > system properties, instead of a general change to Properties. Because a > user is able to supply their own Properties object to > System.setProperties(), which is set as the system properties, and > current behavior reflects changes made to original Properties object, it > would be best to change the Properties class itself. > > * Don't leak extra add/remove functionality through returned Enumerations. > > * I said I would check on the synchronization of serialization. > writeHashtable() looks okay to me; I expect this is not such a concern > for readHashtable(). > > > A new webrev is here: > http://cr.openjdk.java.net/~bchristi/8029891/webrev.4/ > > Other changes since the last webrev I posted: > * In readHashtable(), I added a check to validate 'elements', as is done > in Hashtable. > > * I have indicated that Iterators from > [keySet|entrySet|values].iterator() no longer fail-fast. While perhaps > not strictly necessary, given the "no guarantees" nature of the > Hashtable spec, my personal preference is to make it clear that > Properties no longer makes a best (or any) effort to throw > ConcurrentModificationException. This should not affect any working > code (which would not see a CME anyway). Given that Properties are > meant to be used as a collection of largely static values, adding > additional code to maintain fail-fast behavior is not warranted. > > > FWIW, the deadlock code path is now different than what is seen in the > bug report (see [3]). We're now getting hung up on the > Integer.getInteger() call to get MAX_ARITY on line 60 of > MethodHandleImpl [4]. So while the original deadlock is resolved by all this change, there still exists a deadlock. I can see from the details that store() locks the properties object and can lead to MethodHandleNatives.linkCallsite, while in another thread we have at java.util.Hashtable.get(java.base at 9-ea/Hashtable.java:370) - waiting to lock <0x00000006cff097f0> (a java.util.Properties) ... at java.lang.invoke.CallSite.(java.base at 9-ea/CallSite.java:230) at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(java.base at 9-ea/MethodHandleNatives.java:250) I think we have some fundamental initialization order problems that need to be addressed in a holistic way rather than deadlock by deadlock (or initialization failure by initialization failure). Thanks, David > > Thanks, > -Brent > > 1. > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-May/033147.html > 2. > http://cr.openjdk.java.net/~bchristi/8029891/webrev.3/specdiff-plain/Properties.html > > 3. http://cr.openjdk.java.net/~bchristi/8029891/webrev.4/NewDeadlock.txt > 4. > http://hg.openjdk.java.net/jdk9/dev/jdk/file/1049321b86cb/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java > > > From sundararajan.athijegannathan at oracle.com Thu May 12 04:44:08 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 12 May 2016 10:14:08 +0530 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <57335E74.3090204@oracle.com> References: <57331659.1030008@oracle.com> <8918541F-29FD-4AFD-AE9A-4B3F1CF32C4E@oracle.com> <57335E74.3090204@oracle.com> Message-ID: <32076aea-7517-f61c-34a0-59b71d8acf57@oracle.com> +1 -Sundar On 5/11/2016 10:01 PM, shilpi.rastogi at oracle.com wrote: > Hi All, > > Please review the updated webrev- > http://cr.openjdk.java.net/~srastogi/8149574/webrev.07/ > > Changed the anonymous class package with no package name. > > Regards, > Shilpi > > On 5/11/2016 8:22 PM, Paul Sandoz wrote: >> Hi Shilpi, >> >> What makes me slightly queasy about the constant pool patching of T >> is it?s quite fragile and it produces a class with a slightly >> inconsistent state regarding the InnerClasses structures. It?s >> probably mostly harmless but still bothers me. >> >> One solution is to combine ASM with constant pool patching. Use ASM >> to generate the class bytes, and query the constant pool in the >> ClassWriter, then remember the class bytes, the pool size, and index >> to patch (a cursory glance at ClassWriter suggests this is possible). >> >> But i think Michael raises an important point about simplification >> using the default package, if that is possible. However, if the >> default package is to be used ASM is still required to generate class >> bytes and define the class anonymously within the scope of the host >> class. Thus in this approach the addition of patching should not add >> much more complexity and i think would be more in sync with that of >> the host class. >> >> Paul. >> >>> On 11 May 2016, at 13:24, shilpi.rastogi at oracle.com wrote: >>> >>> Hi All, >>> >>> Please review the following- >>> >>> https://bugs.openjdk.java.net/browse/JDK-8149574 >>> >>> Solution: Changed anonymous class package name with the package name >>> of its host class. >>> >>> Two approaches to solve this- >>> 1. Parse .class and get the class name index form constant pool and >>> patch it with new name >>> http://cr.openjdk.java.net/~srastogi/8149574/webrev.05/ >>> >>> 2. Create class with new name (With ASM) >>> http://cr.openjdk.java.net/~srastogi/8149574/webrev.06/ >>> >>> Which approach is better? >>> >>> Thanks, >>> Shilpi >>> >>> >>> > From huizhe.wang at oracle.com Thu May 12 04:51:43 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 11 May 2016 21:51:43 -0700 Subject: [9] RFR: 8145974: XMLStreamWriter produces invalid XML for surrogate pairs on OutputStreamWriter In-Reply-To: <5733C0A9.8000800@oracle.com> References: <5733C0A9.8000800@oracle.com> Message-ID: <57340BDF.4090509@oracle.com> Hi Aleksej, The change looks good overall. It may be better to replace the name "writeCodePoint" with "writeCharRef" or "writeEscaped". Doing the "isSurrogatePair" check in place of the call for writeSurrogatePair may be more descriptive and readable as well, that is: + if ( index != end - 1 &&Character.isSurrogatePair(ch, content[index+1])) { +writeCharRef( Character.toCodePoint(ch, content[index+1])); + index++; + } else { +writeCharRef(ch); + } If you do that, you wouldn't need the method "writeSurrogatePair". For the test, it may be good to call writer.close() at the end of the test. Also, would the content read is the same (vs contains) as the expectedContent? Thanks, Joe On 5/11/2016 4:30 PM, Aleks Efimov wrote: > Hello, > > Please, help to review the fix for XMLStreamWriter bug [1]: > XMLStreamWriter incorrectly writes surrogate pairs into pair of > invalid character references. > For example: "\ud83d\ude0a" is transformed into "��". It > should be one character reference "😊" instead. > The proposed patch fixes the XMLStreamWriterImpl to correctly process > surrogate pairs: > http://cr.openjdk.java.net/~aefimov/8145974/9/00 > > The build with fix applied was tested with JTREG and JCK xml tests - > no related issues detected. > > Aleksej > > [1] https://bugs.openjdk.java.net/browse/JDK-8145974 > From Alan.Bateman at oracle.com Thu May 12 06:13:09 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 May 2016 07:13:09 +0100 Subject: Memory leak in com.sun.jndi.ldap.pool.PoolCleaner In-Reply-To: <0b3579c4-d3d5-ff77-68f0-d1e7749829aa@apache.org> References: <5732DCBA.7010505@oracle.com> <0b3579c4-d3d5-ff77-68f0-d1e7749829aa@apache.org> Message-ID: <57341EF5.2040607@oracle.com> On 11/05/2016 12:18, Mark Thomas wrote: > : > Sure. Done. > Review ID: 9087338 > I found it, and moved it to the JDK project in JIRA: https://bugs.openjdk.java.net/browse/JDK-8156824 From markt at apache.org Thu May 12 07:15:20 2016 From: markt at apache.org (Mark Thomas) Date: Thu, 12 May 2016 08:15:20 +0100 Subject: Memory leak in com.sun.jndi.ldap.pool.PoolCleaner In-Reply-To: <57341EF5.2040607@oracle.com> References: <5732DCBA.7010505@oracle.com> <0b3579c4-d3d5-ff77-68f0-d1e7749829aa@apache.org> <57341EF5.2040607@oracle.com> Message-ID: On 12/05/2016 07:13, Alan Bateman wrote: > > > On 11/05/2016 12:18, Mark Thomas wrote: >> : >> Sure. Done. >> Review ID: 9087338 >> > I found it, and moved it to the JDK project in JIRA: > > https://bugs.openjdk.java.net/browse/JDK-8156824 Thanks. Mark From uschindler at apache.org Thu May 12 08:23:27 2016 From: uschindler at apache.org (Uwe Schindler) Date: Thu, 12 May 2016 10:23:27 +0200 Subject: MethodHandle for array length In-Reply-To: <313649021.1504150.1463002834275.JavaMail.zimbra@u-pem.fr> References: <00a601d1abbc$4a907ec0$dfb17c40$@apache.org> <313649021.1504150.1463002834275.JavaMail.zimbra@u-pem.fr> Message-ID: <016b01d1ac27$91930b10$b4b92130$@apache.org> Hi Remi, > > while working and trying the new JDK9 MethodHandles features like > > MethodHandles#countedLoop, I recognized a API inconsistency problem > with it. > > > > We also found this while implementing the "Painless" scripting language for > > Elasticsearch (see https://goo.gl/DbOzjC)! Painless is a very limited > > scripting language with a very limited subset of classes to access and close > > integration into Elasticsearch (similar to Lucene's Expressions Module). > > Both compile script code to anonymous classes and Elasticsearch uses > > invokedynamic for the untyped stuff. It is much faster than Groovy or > > Nashorn, because it compiles most of the code completely static with > known > > types (like Lucene expressions), but also supports a Groovy-like "def" type. > > The latter one uses invokedynamic, everything else is exactly the same > speed > > as native Java code. > > I think you can do something similar in Groovy with the annotation > @TypeChecl and @StaticCompilation, see [1]. The reason why we not use Groovy is security-related. It is impossible to limit access to only a very limited subset of Java classes and methods with Groovy. Because of many security issues Groovy is no longer an option. But that is unrelated to this issue, of course :-) The script snippets in Painless or Lucene expressions are scripts that are executed multiple times on millions of search results during collecting fulltext search hits. E.g. when you want to customize the score. For that to work it is important that the compiled script is using primitive types for score and so on. > > During implementing array getters and setters for untyped stuff with > > invokedynamic we recognized the following problem (Java 8 code, see > > https://github.com/elastic/elasticsearch/pull/18232): > > > > There is MethodHandles.arrayElementGetter and > > MethodHandles.arrayElementSetter, so we can have full speed and full > dynamic > > flexibility for array loads and stores - the speed is great, same as native > > array access! But there is one factory method missing in Java 8: > > MethodHandles.arrayLengthGetter (or similar name). As "length" is not a > > field on the array class, it is impossible to create a "simple" MethodHandle > > as field access to "array.class#length" to access it (it must invoke the > > "arraylength" bytecode, there is no field). I think the "length" field is > > just syntactic sugar of javac compiler. > > > > I know that Nashorn used to use java.lang.reflect.Array#getLength (not > sure > > if this is still the case), but this makes usage inconsistent. You have to > > explicitly create a MethodHandle using the reflective array class to use it: > > And it is not strongly typed (it accepts Object). A real MethodHandle would > > be created for a specific type of array class and would return its length > > without runtime type checks. I know that at least Array.getLength() is > > optimized by Hotspot (in contrast to the other get/set methods, which are > > like 20 times slower than a method access, so > > MethodHandles.arrayElementGetter/Setter is very useful), but I would > really > > like to suggest to fix this! > > > > With Java 9 this gets a bit worse: There is no "easy way" with the > > MethodHanldes class to generate a MethodHandles.countedLoop() on all > > elements of an array: > > > > public static MethodHandle countedLoop(MethodHandle iterations, > MethodHandle > > init, MethodHandle body) [new in Java 9] > > > > With a full-featured API one could write: > > > > Class type = arraytype, e.g. long[].class or String[].class > > MethodHandle body = some code that uses > > MethodHandles.arrayElementGetter(type) for further processing > > MethodHandles.countedLoop(MethodHandles.arrayLengthGetter(type), > > MethodHandles.constant(int.class, 0), body); > > > > As you see, for the first parameter (count), you would need to use the > > reflective part in java.lang.reflect.Array if the method is still missing in > > Java 9. This is not bad here, because it is not called all the time, but for > > our scripting language, the reflective class was slower. > > > > We implemented our own version of "arrayLengthGetter": > > > > public class ArrayLengthHelper { > > private ArrayLengthHelper() {} > > > > private static final Lookup PRIV_LOOKUP = MethodHandles.lookup(); > > private static final Map,MethodHandle> > ARRAY_TYPE_MH_MAPPING = > > Collections.unmodifiableMap( > > Stream.of(boolean[].class, byte[].class, short[].class, int[].class, > > long[].class, char[].class, float[].class, double[].class, > > Object[].class) > > .collect(Collectors.toMap(Function.identity(), type -> { > > try { > > return PRIV_LOOKUP.findStatic(PRIV_LOOKUP.lookupClass(), > > "getArrayLength", MethodType.methodType(int.class, type)); > > } catch (ReflectiveOperationException e) { > > throw new AssertionError(e); > > } > > })) > > ); > > private static final MethodHandle OBJECT_ARRAY_MH = > > ARRAY_TYPE_MH_MAPPING.get(Object[].class); > > > > static int getArrayLength(boolean[] array) { return array.length; } > > static int getArrayLength(byte[] array) { return array.length; } > > static int getArrayLength(short[] array) { return array.length; } > > static int getArrayLength(int[] array) { return array.length; } > > static int getArrayLength(long[] array) { return array.length; } > > static int getArrayLength(char[] array) { return array.length; } > > static int getArrayLength(float[] array) { return array.length; } > > static int getArrayLength(double[] array) { return array.length; } > > static int getArrayLength(Object[] array) { return array.length; } > > > > public static MethodHandle arrayLengthGetter(Class arrayType) { > > if (!arrayType.isArray()) { > > throw new IllegalArgumentException("type must be an array"); > > } > > return (ARRAY_TYPE_MH_MAPPING.containsKey(arrayType)) ? > > ARRAY_TYPE_MH_MAPPING.get(arrayType) : > > > OBJECT_ARRAY_MH.asType(OBJECT_ARRAY_MH.type().changeParameterTy > pe(0, > > arrayType)); > > } > > } > > > > Interestingly I later found out that > MethodHandles.arrayElementGetter/Setter > > uses the same "trick" behind the scenes! See > MethodHandleImpl.ArrayAccessor: > > http://goo.gl/94f6OB > > > > I would suggest to add the missing Method to MethodHandles class and > > implement it together with the getters and setters in ArrayAccessor, similar > > to our example code (it is just a few lines more). In addition this one > > could then also use the extra intrinsic improvement that our class cannot > > use: makeIntrinsic(getAccessor(Object[].class, false), > > Intrinsic.ARRAY_LOAD); > > [with another intrinsic added: Intrinsic.ARRAY_LENGTH for the arraylength > > bytecode] > > > > What would be the process to propose such a change? Bug/Issue/JEP? > > I could quickly create a patch, but fixing the Intrinsic/LambdaForm stuff is > > way too complicated for me, so I would suggest to take this as an > > inspiration how to do it > > > > Uwe > > as you said, Array.getLength is already optimized by the JIT, it's because the > length of an array is at the same offset for any kind of array in Hotspot, so > unlike array access that depends on the kind of array, getting the length of an > array is the same code for any kind of array. So you can safely, performance > wise, create a method handle on Array.getLength, that's why there is no > arrayLengthGetter in MethodHandles. That might be fine, but it is not user friendly. You have to spend a lot of time to get this running. If the API would be consistent the above countedLoop would be a no-brainer to implement. I don?t care if the MethodHandles.arrayLengthGetter is implemented with java.lang.reflect.Array or the proposed code in MethodHandlesImpl.ArrayAccessor. It should just be abstracted and an implementation detail. Because the array length is something very special, so there should be an "official and easy to understand way" to get a MethodHandle for it, that is consistent with the other API. MethodHandles has accessor to array elements but not to length - that seems wrong - really wrong, sorry! If you think that java.lang.reflect.Array is fine because of the intrinsic, then just implement MethodHandles.arrayLengthGetter like: private static final MH_ARRAY_LENGTH = publicLookup().findStatic(Array.class, "getLength", methodType(int.class, Object.class); // add trycatch public static MethodHandle arrayLengthGetter(Class arrayType) { if (!arrayType.isArray()) { throw new IllegalArgumentException("arrayType must be an array"); } return MH_ARRAY_LENGTH.asType(MH_ARRAY_LENGTH.type().changeParameterType(0, arrayType)); } It should just be there! The change is simple (both cases), so why not add it? What do others think? Uwe From daniel.fuchs at oracle.com Thu May 12 08:44:08 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 12 May 2016 10:44:08 +0200 Subject: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed In-Reply-To: References: <5D245EC6-47C6-4BF1-A505-89934731A814@oracle.com> <360DDB44-FDFC-41DE-8DF9-9BBA3AF28581@oracle.com> <07C5EC23-C429-4961-B7D3-92B7C32FB535@dslextreme.com> <90BF6135-B457-4BD4-8DFF-9DE94F6D8DC7@oracle.com> <018AAA44-3689-4E79-B090-B0D1F0DD0CC1@oracle.com> <6A375668-62CA-47BE-B2AB-6BB3E7D3BEC0@dslextreme.com> <412730c6-fe73-88af-b80d-d8690f6721ee@oracle.com> <39C2DFD7-C49D-490A-A804-0FA60C1B2719@dslextreme.com> <3C161A46-360E-4E27-A544-51EF8A784735@dslextreme.com> Message-ID: <6d4631b1-3f47-a165-c88e-d76a07f8536f@oracle.com> Hi Ralph, On 11/05/16 21:00, Ralph Goers wrote: > I am not at all familiar with how the stack is actually managed. I was hoping it was just an array and that the index into it was being kept track of. Since we know that we will only be adding more stack elements I would think that deferring use of that index wouldn?t be a problem. But since I have no idea how it is managed all I can really do is guess and hope. > > As far as the appender calling a logger, it happens all the time. > Log4j 1 had serious problems with it and could get itself in a deadlock. > In Log4j 2 we handle that by wrapping each appender with an > AppenderControl.The AppenderControl has a thread local guard. If the guard > is set then the appenderControl just ignores the event. > But if logging for the stuff going on inside of an appender is routed > to a different appender there is no problem. So recursion is not a problem. > Without this most of the interesting things users do with Log4j wouldn?t > be possible or at least would be hard to debug. > I have to believe that jul will have the same problem with custom handlers > written by users. Yes JUL would have exactly the same kind of problem. However putting guards in place can be costly so I believe it's best to leave that to the concrete Handler implementation - where you best know whether such guards will be needed or not, (in that case - to the custom handler). Concerning your scenario - then if I understand correctly there are two cases: Foo::method1?>Logger.log("foo1")?>BarAppender.append?>Foo::method2 (or even method1 again)?>Logger.log("foo2")->XAppender.append->Foo::method3... case #1: XAppender == BarAppender case #2: XAppender != BarAppender in case #1, for Logger.log("foo2"), the guards should prevent prevent recursion and hopefully this will happen before trying to get the caller information. in case #2, for Logger.log("foo2"), then I believe you would want the caller identified as Foo::method2 - not as Foo::method1. Identifying the caller as Foo::method1 would IMHO be very confusing, as you wouldn't be able to find any trace of the log message "foo2" in the code of that method. so it seems to me that even in this case, starting at frame 0 and stopping at frame Foo::method2 would be a better strategy than starting at frame N and stopping at frame Foo::method1? But maybe I misunderstood. Best regards, -- daniel > > Ralph > >> On May 11, 2016, at 10:20 AM, Daniel Fuchs wrote: >> >> Hi, >> >> On 11/05/16 18:57, Ralph Goers wrote: >>> But my point is that if obtaining the StackFrame and Class >>> could be done so quickly that it wouldn?t add any noticeable >>> overhead we could do that in every Logger.info, debug, etc. call. >>> If we could just get the stack frame index so that we could obtain >>> the StackFrame and Class later by using the index that would be even >>> better since we would only be creating the StackFrame, etc if it is really required. >> >> Working with stack frame indexes is at best fragile, unless >> you make a snapshot of the stack first and only used the >> index in relation to that snapshot. So I wouldn't recommend >> going that way. Furthermore to obtain such an index you >> would need to count the frames - which would mean walking the >> whole stack. >> >> I'm still not sure I understand why an appender would >> call Logger.log. That sounds like a recipe for stack >> overflow or endless ping pong loops. >> I understand that could theoretically happen but then the >> appender would need to protect itself against 'logging >> while logging'. Or am I misunderstanding? >> >> best regards, >> >> -- daniel >> > > From michael.haupt at oracle.com Thu May 12 09:36:18 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 12 May 2016 11:36:18 +0200 Subject: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode In-Reply-To: <573339BF.4060107@oracle.com> References: <5733165C.6090305@oracle.com> <94710EE3-E8C4-4B0D-A21C-4458B1E905C3@oracle.com> <573339BF.4060107@oracle.com> Message-ID: Hi Shilpi, thanks for the clarification. OK by me then - please note this is a lower-case review. Best, Michael > Am 11.05.2016 um 15:55 schrieb shilpi.rastogi at oracle.com: > > Thank You Michael for comments! > > It was fixed for VarargsArrayTest.java but not fixed for java/lang/invoke/CustomizedLambdaFormTest.java. > > > Boris Molodenkov added a comment -2016-05-02 02:37-Restricted toConfidential > One more test > RULE "java/lang/invoke/CustomizedLambdaFormTest.java" StatusError Parse Exception: [-esa]: vm option(s) found, need to specify /othervm > > Thanks, > Shilpi > > On 5/11/2016 6:47 PM, Michael Haupt wrote: >> Hi Shilpi, >> >> not a review - the bug mentions that this issue is fixed in Jake already and that the bug should be closed once the fix from Jake propagates to dev. What is the status of that? >> >> Best, >> >> Michael >> >>> Am 11.05.2016 um 13:24 schrieb shilpi.rastogi at oracle.com: >>> >>> Hi All, >>> >>> Please review one small fix for >>> >>> https://bugs.openjdk.java.net/browse/JDK-8155791 >>> http://cr.openjdk.java.net/~srastogi/8155791/webrev.00/ >>> >>> Thanks, >>> Shilpi > -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From ecki at zusammenkunft.net Thu May 12 09:33:44 2016 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Thu, 12 May 2016 11:33:44 +0200 Subject: Memory leak in com.sun.jndi.ldap.pool.PoolCleaner In-Reply-To: References: <5732DCBA.7010505@oracle.com> <0b3579c4-d3d5-ff77-68f0-d1e7749829aa@apache.org> <57341EF5.2040607@oracle.com> Message-ID: <60d9521e-6fd2-46c3-a8e9-5f6fd090a269.maildroid@localhost> Hello, Should this also care about overwriting threadlocals, threadgroup, securitycontext and default exception handler (i.e. using the new constructor for managed threads and some). Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Mark Thomas To: Alan Bateman , core-libs-dev at openjdk.java.net Sent: Do., 12 Mai 2016 11:15 Subject: Re: Memory leak in com.sun.jndi.ldap.pool.PoolCleaner On 12/05/2016 07:13, Alan Bateman wrote: > > > On 11/05/2016 12:18, Mark Thomas wrote: >> : >> Sure. Done. >> Review ID: 9087338 >> > I found it, and moved it to the JDK project in JIRA: > > https://bugs.openjdk.java.net/browse/JDK-8156824 Thanks. Mark From michael.haupt at oracle.com Thu May 12 09:38:25 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 12 May 2016 11:38:25 +0200 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <32076aea-7517-f61c-34a0-59b71d8acf57@oracle.com> References: <57331659.1030008@oracle.com> <8918541F-29FD-4AFD-AE9A-4B3F1CF32C4E@oracle.com> <57335E74.3090204@oracle.com> <32076aea-7517-f61c-34a0-59b71d8acf57@oracle.com> Message-ID: ... yes. Best, Michael > Am 12.05.2016 um 06:44 schrieb Sundararajan Athijegannathan : > > +1 > > -Sundar > > > On 5/11/2016 10:01 PM, shilpi.rastogi at oracle.com wrote: >> Hi All, >> >> Please review the updated webrev- >> http://cr.openjdk.java.net/~srastogi/8149574/webrev.07/ >> >> Changed the anonymous class package with no package name. >> >> Regards, >> Shilpi >> >> On 5/11/2016 8:22 PM, Paul Sandoz wrote: >>> Hi Shilpi, >>> >>> What makes me slightly queasy about the constant pool patching of T >>> is it?s quite fragile and it produces a class with a slightly >>> inconsistent state regarding the InnerClasses structures. It?s >>> probably mostly harmless but still bothers me. >>> >>> One solution is to combine ASM with constant pool patching. Use ASM >>> to generate the class bytes, and query the constant pool in the >>> ClassWriter, then remember the class bytes, the pool size, and index >>> to patch (a cursory glance at ClassWriter suggests this is possible). >>> >>> But i think Michael raises an important point about simplification >>> using the default package, if that is possible. However, if the >>> default package is to be used ASM is still required to generate class >>> bytes and define the class anonymously within the scope of the host >>> class. Thus in this approach the addition of patching should not add >>> much more complexity and i think would be more in sync with that of >>> the host class. >>> >>> Paul. >>> >>>> On 11 May 2016, at 13:24, shilpi.rastogi at oracle.com wrote: >>>> >>>> Hi All, >>>> >>>> Please review the following- >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8149574 >>>> >>>> Solution: Changed anonymous class package name with the package name >>>> of its host class. >>>> >>>> Two approaches to solve this- >>>> 1. Parse .class and get the class name index form constant pool and >>>> patch it with new name >>>> http://cr.openjdk.java.net/~srastogi/8149574/webrev.05/ >>>> >>>> 2. Create class with new name (With ASM) >>>> http://cr.openjdk.java.net/~srastogi/8149574/webrev.06/ >>>> >>>> Which approach is better? >>>> >>>> Thanks, >>>> Shilpi >>>> >>>> >>>> >> > -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From szegedia at gmail.com Thu May 12 09:37:02 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Thu, 12 May 2016 11:37:02 +0200 Subject: MethodHandle for array length In-Reply-To: <00a601d1abbc$4a907ec0$dfb17c40$@apache.org> References: <00a601d1abbc$4a907ec0$dfb17c40$@apache.org> Message-ID: Hi Uwe, If you?re targetting JDK 9 only, you could also consider basing your language?s dynamic operations on Dynalink; it?s integrated into JDK 9 and is specifically meant as a way to ease implementation of languages that have dynamic types. It happens to have a predefined GET_LENGTH[1] operation that does exactly what you want when BeansLinker[2] applies it to Java arrays. The documentation can be found at >; the jdk.dynalink package description is a good starting point (for some reason the main package is listed in a separate ?Other Packages? section on the overview page? probably a Javadoc glitch w/regard to Jigsaw) Attila. [1] http://download.java.net/java/jdk9/docs/jdk/api/dynalink//jdk/dynalink/StandardOperation.html#GET_LENGTH [2] http://download.java.net/java/jdk9/docs/jdk/api/dynalink/jdk/dynalink/beans/BeansLinker.html > On 11 May 2016, at 21:35, Uwe Schindler wrote: > > Hi, > > while working and trying the new JDK9 MethodHandles features like MethodHandles#countedLoop, I recognized a API inconsistency problem with it. > > We also found this while implementing the "Painless" scripting language for Elasticsearch (see https://goo.gl/DbOzjC)! Painless is a very limited scripting language with a very limited subset of classes to access and close integration into Elasticsearch (similar to Lucene's Expressions Module). Both compile script code to anonymous classes and Elasticsearch uses invokedynamic for the untyped stuff. It is much faster than Groovy or Nashorn, because it compiles most of the code completely static with known types (like Lucene expressions), but also supports a Groovy-like "def" type. The latter one uses invokedynamic, everything else is exactly the same speed as native Java code. > > During implementing array getters and setters for untyped stuff with invokedynamic we recognized the following problem (Java 8 code, see https://github.com/elastic/elasticsearch/pull/18232): > > There is MethodHandles.arrayElementGetter and MethodHandles.arrayElementSetter, so we can have full speed and full dynamic flexibility for array loads and stores - the speed is great, same as native array access! But there is one factory method missing in Java 8: MethodHandles.arrayLengthGetter (or similar name). As "length" is not a field on the array class, it is impossible to create a "simple" MethodHandle as field access to "array.class#length" to access it (it must invoke the "arraylength" bytecode, there is no field). I think the "length" field is just syntactic sugar of javac compiler. > > I know that Nashorn used to use java.lang.reflect.Array#getLength (not sure if this is still the case), but this makes usage inconsistent. You have to explicitly create a MethodHandle using the reflective array class to use it: And it is not strongly typed (it accepts Object). A real MethodHandle would be created for a specific type of array class and would return its length without runtime type checks. I know that at least Array.getLength() is optimized by Hotspot (in contrast to the other get/set methods, which are like 20 times slower than a method access, so MethodHandles.arrayElementGetter/Setter is very useful), but I would really like to suggest to fix this! > > With Java 9 this gets a bit worse: There is no "easy way" with the MethodHanldes class to generate a MethodHandles.countedLoop() on all elements of an array: > > public static MethodHandle countedLoop(MethodHandle iterations, MethodHandle init, MethodHandle body) [new in Java 9] > > With a full-featured API one could write: > > Class type = arraytype, e.g. long[].class or String[].class > MethodHandle body = some code that uses MethodHandles.arrayElementGetter(type) for further processing > MethodHandles.countedLoop(MethodHandles.arrayLengthGetter(type), MethodHandles.constant(int.class, 0), body); > > As you see, for the first parameter (count), you would need to use the reflective part in java.lang.reflect.Array if the method is still missing in Java 9. This is not bad here, because it is not called all the time, but for our scripting language, the reflective class was slower. > > We implemented our own version of "arrayLengthGetter": > > public class ArrayLengthHelper { > private ArrayLengthHelper() {} > > private static final Lookup PRIV_LOOKUP = MethodHandles.lookup(); > private static final Map,MethodHandle> ARRAY_TYPE_MH_MAPPING = Collections.unmodifiableMap( > Stream.of(boolean[].class, byte[].class, short[].class, int[].class, long[].class, char[].class, float[].class, double[].class, Object[].class) > .collect(Collectors.toMap(Function.identity(), type -> { > try { > return PRIV_LOOKUP.findStatic(PRIV_LOOKUP.lookupClass(), "getArrayLength", MethodType.methodType(int.class, type)); > } catch (ReflectiveOperationException e) { > throw new AssertionError(e); > } > })) > ); > private static final MethodHandle OBJECT_ARRAY_MH = ARRAY_TYPE_MH_MAPPING.get(Object[].class); > > static int getArrayLength(boolean[] array) { return array.length; } > static int getArrayLength(byte[] array) { return array.length; } > static int getArrayLength(short[] array) { return array.length; } > static int getArrayLength(int[] array) { return array.length; } > static int getArrayLength(long[] array) { return array.length; } > static int getArrayLength(char[] array) { return array.length; } > static int getArrayLength(float[] array) { return array.length; } > static int getArrayLength(double[] array) { return array.length; } > static int getArrayLength(Object[] array) { return array.length; } > > public static MethodHandle arrayLengthGetter(Class arrayType) { > if (!arrayType.isArray()) { > throw new IllegalArgumentException("type must be an array"); > } > return (ARRAY_TYPE_MH_MAPPING.containsKey(arrayType)) ? > ARRAY_TYPE_MH_MAPPING.get(arrayType) : > OBJECT_ARRAY_MH.asType(OBJECT_ARRAY_MH.type().changeParameterType(0, arrayType)); > } > } > > Interestingly I later found out that MethodHandles.arrayElementGetter/Setter uses the same "trick" behind the scenes! See MethodHandleImpl.ArrayAccessor: http://goo.gl/94f6OB > > I would suggest to add the missing Method to MethodHandles class and implement it together with the getters and setters in ArrayAccessor, similar to our example code (it is just a few lines more). In addition this one could then also use the extra intrinsic improvement that our class cannot use: makeIntrinsic(getAccessor(Object[].class, false), Intrinsic.ARRAY_LOAD); > [with another intrinsic added: Intrinsic.ARRAY_LENGTH for the arraylength bytecode] > > What would be the process to propose such a change? Bug/Issue/JEP? > I could quickly create a patch, but fixing the Intrinsic/LambdaForm stuff is way too complicated for me, so I would suggest to take this as an inspiration how to do it > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > > From michael.haupt at oracle.com Thu May 12 09:48:30 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 12 May 2016 11:48:30 +0200 Subject: MethodHandle for array length In-Reply-To: <00a601d1abbc$4a907ec0$dfb17c40$@apache.org> References: <00a601d1abbc$4a907ec0$dfb17c40$@apache.org> Message-ID: <3FD85BA6-799F-465F-8B33-BD75635D33AE@oracle.com> Hi Uwe, > Am 11.05.2016 um 21:35 schrieb Uwe Schindler : > With Java 9 this gets a bit worse: There is no "easy way" with the MethodHanldes class to generate a MethodHandles.countedLoop() on all elements of an array: > > public static MethodHandle countedLoop(MethodHandle iterations, MethodHandle init, MethodHandle body) [new in Java 9] this isn't a remedy when you need the index in each iteration, but you can generate a loop over all elements of an array using iteratedLoop(), as illustrated by this test from LoopCombinatorTest: @Test public static void testIterateSum() throws Throwable { // Integer[] a = new Integer[]{1,2,3,4,5,6}; int sum = 0; for (int e : a) { sum += e; } return sum; => 21 MethodHandle loop = MethodHandles.iteratedLoop(Iterate.MH_sumIterator, Iterate.MH_sumInit, Iterate.MH_sumStep); assertEquals(Iterate.MT_sum, loop.type()); assertEquals(21, loop.invoke(new Integer[]{1, 2, 3, 4, 5, 6})); } ... where MH_sumIterator is a handle to this method: static Iterator sumIterator(Integer[] a) { return Arrays.asList(a).iterator(); } Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From uschindler at apache.org Thu May 12 09:56:59 2016 From: uschindler at apache.org (Uwe Schindler) Date: Thu, 12 May 2016 11:56:59 +0200 Subject: MethodHandle for array length In-Reply-To: References: <00a601d1abbc$4a907ec0$dfb17c40$@apache.org> Message-ID: <019401d1ac34$a450a340$ecf1e9c0$@apache.org> Hi Attila, thanks for the info. We are currently targeting Java 8. The proposal made here was more about making the API in the MethodHandles class ?feature complete?, because you have the array element getters/setters there, but not the length. This is pure inconsistent, because for countedLoop (which is new in Java 9), you coulduse it. From a user perspective this is also easier to understand. In our code we stay for now with the code as described. I was just hoping that Java 9 would make the API more consistent and easy to use. The new MethodHandles.countedLoop really cries for support to natively and straigtforward way to get the array length ? because this is the ?normal way to process arrays with for-loops. And this is not natively possible unless you use my hack or java.lang.reflect.Array#getLength. For now, I added this as a ?hack some private inner class like ArrayAccessor in the JDK?, but I would like to get rid of it once we are targetting Java 9. This is why I started the thread here. My request is just to make the public MethodHandles API easy to use and consistent, which it isn?t. And addition of that should be easy and could be done in the same JEP like the new loop stuff in MethodHandles. I?d make a proposal, but I have no idea what the process would be. FYI, we also have a DynamicCallSite in Painless that uses polymorphic caching, up to 5 different types using MethodHandles.guardWithTest: https://goo.gl/GhWmTS Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ From: Attila Szegedi [mailto:szegedia at gmail.com] Sent: Thursday, May 12, 2016 11:37 AM To: Uwe Schindler Cc: Core-Libs-Dev Subject: Re: MethodHandle for array length Hi Uwe, If you?re targetting JDK 9 only, you could also consider basing your language?s dynamic operations on Dynalink; it?s integrated into JDK 9 and is specifically meant as a way to ease implementation of languages that have dynamic types. It happens to have a predefined GET_LENGTH[1] operation that does exactly what you want when BeansLinker[2] applies it to Java arrays. The documentation can be found at >; the jdk.dynalink package description is a good starting point (for some reason the main package is listed in a separate ?Other Packages? section on the overview page? probably a Javadoc glitch w/regard to Jigsaw) Attila. [1] http://download.java.net/java/jdk9/docs/jdk/api/dynalink//jdk/dynalink/StandardOperation.html#GET_LENGTH [2] http://download.java.net/java/jdk9/docs/jdk/api/dynalink/jdk/dynalink/beans/BeansLinker.html On 11 May 2016, at 21:35, Uwe Schindler > wrote: Hi, while working and trying the new JDK9 MethodHandles features like MethodHandles#countedLoop, I recognized a API inconsistency problem with it. We also found this while implementing the "Painless" scripting language for Elasticsearch (see https://goo.gl/DbOzjC)! Painless is a very limited scripting language with a very limited subset of classes to access and close integration into Elasticsearch (similar to Lucene's Expressions Module). Both compile script code to anonymous classes and Elasticsearch uses invokedynamic for the untyped stuff. It is much faster than Groovy or Nashorn, because it compiles most of the code completely static with known types (like Lucene expressions), but also supports a Groovy-like "def" type. The latter one uses invokedynamic, everything else is exactly the same speed as native Java code. During implementing array getters and setters for untyped stuff with invokedynamic we recognized the following problem (Java 8 code, see https://github.com/elastic/elasticsearch/pull/18232): There is MethodHandles.arrayElementGetter and MethodHandles.arrayElementSetter, so we can have full speed and full dynamic flexibility for array loads and stores - the speed is great, same as native array access! But there is one factory method missing in Java 8: MethodHandles.arrayLengthGetter (or similar name). As "length" is not a field on the array class, it is impossible to create a "simple" MethodHandle as field access to "array.class#length" to access it (it must invoke the "arraylength" bytecode, there is no field). I think the "length" field is just syntactic sugar of javac compiler. I know that Nashorn used to use java.lang.reflect.Array#getLength (not sure if this is still the case), but this makes usage inconsistent. You have to explicitly create a MethodHandle using the reflective array class to use it: And it is not strongly typed (it accepts Object). A real MethodHandle would be created for a specific type of array class and would return its length without runtime type checks. I know that at least Array.getLength() is optimized by Hotspot (in contrast to the other get/set methods, which are like 20 times slower than a method access, so MethodHandles.arrayElementGetter/Setter is very useful), but I would really like to suggest to fix this! With Java 9 this gets a bit worse: There is no "easy way" with the MethodHanldes class to generate a MethodHandles.countedLoop() on all elements of an array: public static MethodHandle countedLoop(MethodHandle iterations, MethodHandle init, MethodHandle body) [new in Java 9] With a full-featured API one could write: Class type = arraytype, e.g. long[].class or String[].class MethodHandle body = some code that uses MethodHandles.arrayElementGetter(type) for further processing MethodHandles.countedLoop(MethodHandles.arrayLengthGetter(type), MethodHandles.constant(int.class, 0), body); As you see, for the first parameter (count), you would need to use the reflective part in java.lang.reflect.Array if the method is still missing in Java 9. This is not bad here, because it is not called all the time, but for our scripting language, the reflective class was slower. We implemented our own version of "arrayLengthGetter": public class ArrayLengthHelper { private ArrayLengthHelper() {} private static final Lookup PRIV_LOOKUP = MethodHandles.lookup(); private static final Map,MethodHandle> ARRAY_TYPE_MH_MAPPING = Collections.unmodifiableMap( Stream.of(boolean[].class, byte[].class, short[].class, int[].class, long[].class, char[].class, float[].class, double[].class, Object[].class) .collect(Collectors.toMap(Function.identity(), type -> { try { return PRIV_LOOKUP.findStatic(PRIV_LOOKUP.lookupClass(), "getArrayLength", MethodType.methodType(int.class, type)); } catch (ReflectiveOperationException e) { throw new AssertionError(e); } })) ); private static final MethodHandle OBJECT_ARRAY_MH = ARRAY_TYPE_MH_MAPPING.get(Object[].class); static int getArrayLength(boolean[] array) { return array.length; } static int getArrayLength(byte[] array) { return array.length; } static int getArrayLength(short[] array) { return array.length; } static int getArrayLength(int[] array) { return array.length; } static int getArrayLength(long[] array) { return array.length; } static int getArrayLength(char[] array) { return array.length; } static int getArrayLength(float[] array) { return array.length; } static int getArrayLength(double[] array) { return array.length; } static int getArrayLength(Object[] array) { return array.length; } public static MethodHandle arrayLengthGetter(Class arrayType) { if (!arrayType.isArray()) { throw new IllegalArgumentException("type must be an array"); } return (ARRAY_TYPE_MH_MAPPING.containsKey(arrayType)) ? ARRAY_TYPE_MH_MAPPING.get(arrayType) : OBJECT_ARRAY_MH.asType(OBJECT_ARRAY_MH.type().changeParameterType(0, arrayType)); } } Interestingly I later found out that MethodHandles.arrayElementGetter/Setter uses the same "trick" behind the scenes! See MethodHandleImpl.ArrayAccessor: http://goo.gl/94f6OB I would suggest to add the missing Method to MethodHandles class and implement it together with the getters and setters in ArrayAccessor, similar to our example code (it is just a few lines more). In addition this one could then also use the extra intrinsic improvement that our class cannot use: makeIntrinsic(getAccessor(Object[].class, false), Intrinsic.ARRAY_LOAD); [with another intrinsic added: Intrinsic.ARRAY_LENGTH for the arraylength bytecode] What would be the process to propose such a change? Bug/Issue/JEP? I could quickly create a patch, but fixing the Intrinsic/LambdaForm stuff is way too complicated for me, so I would suggest to take this as an inspiration how to do it Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ From paul.sandoz at oracle.com Thu May 12 10:11:59 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 12 May 2016 12:11:59 +0200 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <57335E74.3090204@oracle.com> References: <57331659.1030008@oracle.com> <8918541F-29FD-4AFD-AE9A-4B3F1CF32C4E@oracle.com> <57335E74.3090204@oracle.com> Message-ID: <07F81381-B038-47B2-BE70-76D3769598A5@oracle.com> > On 11 May 2016, at 18:31, shilpi.rastogi at oracle.com wrote: > > Hi All, > > Please review the updated webrev- http://cr.openjdk.java.net/~srastogi/8149574/webrev.07/ > 1219 FieldVisitor fv; 1220 MethodVisitor mv; 1221 AnnotationVisitor av0; Field ?fv is not used. Since ?av0? is only used once, might as well declare it at line #1246. Can you break up the long lines at #1242 & #1252 ? My inclination is to turn the anon static block into a method returning byte[] and then do: /* */ private static final byte[] T_BYTES = generateT(); private static byte[] generateT() { ? } One concern, more so because of my ignorance, is why can the default package be used. Does anyone know? Paul. > Changed the anonymous class package with no package name. > > Regards, > Shilpi > From jan.lahoda at oracle.com Thu May 12 10:25:09 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 12 May 2016 12:25:09 +0200 Subject: RFR: 8133549: Generalize jshell's EditingHistory Message-ID: <57345A05.2060504@oracle.com> Hello, In jshell, there's a special history mode that is intended to aid with editing/re-entering multi-line snippets (EditingHistory). It works like this: when the user goes back through the history to the first line of a multi-line snippet, and enters/confirms that line, the history view is limited only to the given snippet. I.e. up and down arrows won't go through the whole history, but only the few lines of the given snippet. When the multi-line snippet is finished, the history is restored to the original full state. The proposal here is to generalize this history mode so that it can be used in jjs as well. For this, a new support class is added into jdk.internal.le, that implements this history. Also, ConsoleReader is extended to also accept actions as a Runnable instead of only ActionListener, so that the EditingHistory can add extra actions to jump by the whole snippets when going back in history. Bug: https://bugs.openjdk.java.net/browse/JDK-8133549 Webrev: jdk repository: http://cr.openjdk.java.net/~jlahoda/8133549/jdk/webrev.00/ langtools repository: http://cr.openjdk.java.net/~jlahoda/8133549/langtools/webrev.00/ nashorn repository: http://cr.openjdk.java.net/~jlahoda/8133549/nashorn/webrev.00/ Any comments are welcome! Thanks, Jan From markt at apache.org Thu May 12 11:12:05 2016 From: markt at apache.org (Mark Thomas) Date: Thu, 12 May 2016 12:12:05 +0100 Subject: Memory leak in com.sun.jndi.ldap.pool.PoolCleaner In-Reply-To: <60d9521e-6fd2-46c3-a8e9-5f6fd090a269.maildroid@localhost> References: <5732DCBA.7010505@oracle.com> <0b3579c4-d3d5-ff77-68f0-d1e7749829aa@apache.org> <57341EF5.2040607@oracle.com> <60d9521e-6fd2-46c3-a8e9-5f6fd090a269.maildroid@localhost> Message-ID: On 12/05/2016 10:33, ecki at zusammenkunft.net wrote: > Hello, > > Should this also care about overwriting threadlocals, threadgroup, securitycontext and default exception handler (i.e. using the new constructor for managed threads and some). > > Gruss > Bernd > I have only observed memory leaks caused by the context class loader. If there are potential leaks via other routes (I don't know the code well enough to answer that question) then it would make sense to fix them at the same time. Mark From guido at trentalancia.net Thu May 12 11:37:17 2016 From: guido at trentalancia.net (Guido Trentalancia) Date: Thu, 12 May 2016 13:37:17 +0200 Subject: [PATCH 0/2] fix build errors with gcc6 Message-ID: <1463053037.12329.31.camel@trentalancia.net> Hello. The following set of two patches aims to fix the errors that currently occur during compilation of OpenJDK8U with gcc6 (version 6.1.0). Other three patches needed to build OpenJDK8U have been posted to the hotspot-dev with a similar message subject (for a total of five patches). I suppose most changes are trivial and therefore the patches can be applied easily. After applying the patchset, I can now build OpenJDK8 Update and it seems to be working fine (although it has not been extensively tested yet). The following build options have been used: --enable-unlimited-crypto --with-extra-cflags="-O3 -march=nehalem -mtune=nehalem -Wno-error -fpermissive -fno-delete-null-pointer-checks -fno-lifetime-dse" --with-extra-cxxflags="-O3 -march=nehalem -mtune=nehalem -Wno-error -fpermissive -fno-delete-null-pointer-checks -fno-lifetime-dse" --with-boot-jdk=/usr/lib64/jdk1.7.0_04 Thanks very much to Se?n Coffey and Erik Joelsson for pointing me to the right mailing list. Regards, Guido From guido at trentalancia.net Thu May 12 11:38:34 2016 From: guido at trentalancia.net (Guido Trentalancia) Date: Thu, 12 May 2016 13:38:34 +0200 Subject: [PATCH 1/2] fix build errors with gcc6 Message-ID: <1463053114.12329.34.camel@trentalancia.net> The following (RFC) patch aims to fix a build error when using gcc6: /home/guido/new/jdk8u60/mercurial-rep/tmp/jdk8u/jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp: In function ?_jobject* Java_com_sun_java_util_jar_pack_NativeUnpack_getUnusedInput(JNIEnv*, jobject)?: /home/guido/new/jdk8u60/mercurial-rep/tmp/jdk8u/jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp:295:12: error: cannot convert ?bool? to ?jobject {aka _jobject*}? in return return false; ^~~~~ Signed-off-by: Guido Trentalancia --- jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- jdk8u/jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp.orig 2016-05-10 23:53:03.603809077 +0200 +++ jdk8u/jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp 2016-05-10 23:53:19.277033625 +0200 @@ -292,7 +292,7 @@ Java_com_sun_java_util_jar_pack_NativeUn if (uPtr->aborting()) { THROW_IOE(uPtr->get_abort_message()); - return false; + return 0; } // We have fetched all the files. From guido at trentalancia.net Thu May 12 11:39:48 2016 From: guido at trentalancia.net (Guido Trentalancia) Date: Thu, 12 May 2016 13:39:48 +0200 Subject: [PATCH 2/2] fix build errors with gcc6 Message-ID: <1463053188.12329.36.camel@trentalancia.net> Disable the -Werror compiler flag while compiling JDK SCTP. Signed-off-by: Guido Trentalancia --- jdk/make/lib/NioLibraries.gmk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- jdk8u-build2/jdk/make/lib/NioLibraries.gmk 2016-05-11 00:03:25.591433084 +0200 +++ jdk8u-build1/jdk/make/lib/NioLibraries.gmk 2016-05-11 00:10:18.941034797 +0200 @@ -170,7 +170,7 @@ ifeq ($(OPENJDK_TARGET_OS_API), posix) ifeq (, $(filter $(OPENJDK_TARGET_OS), macosx aix)) # Suppress unused parameters required by exported JNI functions. - SCTP_WERROR := -Werror -Wno-error=unused-parameter + SCTP_WERROR := -Wno-error=unused-parameter ifeq ($(OPENJDK_TARGET_CPU_ARCH), ppc) SCTP_WERROR := endif From sundararajan.athijegannathan at oracle.com Thu May 12 11:44:41 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 12 May 2016 17:14:41 +0530 Subject: RFR: 8133549: Generalize jshell's EditingHistory In-Reply-To: <57345A05.2060504@oracle.com> References: <57345A05.2060504@oracle.com> Message-ID: <5bc12b5b-f705-d840-832a-1511ef92fdcd@oracle.com> The nashorn and jdk repo changes look good to me. Thanks, -Sundar On 5/12/2016 3:55 PM, Jan Lahoda wrote: > Hello, > > In jshell, there's a special history mode that is intended to aid with > editing/re-entering multi-line snippets (EditingHistory). It works > like this: when the user goes back through the history to the first > line of a multi-line snippet, and enters/confirms that line, the > history view is limited only to the given snippet. I.e. up and down > arrows won't go through the whole history, but only the few lines of > the given snippet. When the multi-line snippet is finished, the > history is restored to the original full state. > > The proposal here is to generalize this history mode so that it can be > used in jjs as well. For this, a new support class is added into > jdk.internal.le, that implements this history. Also, ConsoleReader is > extended to also accept actions as a Runnable instead of only > ActionListener, so that the EditingHistory can add extra actions to > jump by the whole snippets when going back in history. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8133549 > > Webrev: > jdk repository: > http://cr.openjdk.java.net/~jlahoda/8133549/jdk/webrev.00/ > > langtools repository: > http://cr.openjdk.java.net/~jlahoda/8133549/langtools/webrev.00/ > > nashorn repository: > http://cr.openjdk.java.net/~jlahoda/8133549/nashorn/webrev.00/ > > Any comments are welcome! > > Thanks, > Jan From paul.sandoz at oracle.com Thu May 12 11:46:28 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 12 May 2016 13:46:28 +0200 Subject: RFR: Implement RandomAccess spliterator In-Reply-To: <817c2727755b46bdbf71bc041c5855ea@gsdghkp03etn2.firmwide.corp.gs.com> References: <817c2727755b46bdbf71bc041c5855ea@gsdghkp03etn2.firmwide.corp.gs.com> Message-ID: <791C1C9E-359E-43FF-AEE4-848472556886@oracle.com> Hi Hiroshi, This is a good example of what seems like a small feature and yet there are some unexpected complexities :-) We will need to refine the implementation specification of List.spliterator, which currently states: * @implSpec * The default implementation creates a * late-binding spliterator * from the list's {@code Iterator}. The spliterator inherits the * fail-fast properties of the list's iterator. Since the existing implementation is derived from the iterator: @Override default Spliterator spliterator() { return Spliterators.spliterator(this, Spliterator.ORDERED); } concurrent modification checking will occur. The RandomAccessSpliterator should also support modification checking, which i think requires it be an inner class to check co-mod state. I am struggling to understand the points you make about the spliterator of a sub-list of a Vector being required to be an iterator-based implementation. Since AbstractList.SubList can access a Vector?s elements through List.get/set why cannot RandomAccessSpliterator? If we want to support random access spliterators on sub-lists i think we would anyway need to override the spliterator method to check for concurrent modification (as is the case of the iterator method). Paul. > On 11 May 2016, at 11:25, Ito, Hiroshi wrote: > > Hi, > > Please kindly review the attached patch for RandomAccessSpliterator implementation. > > Currently default implementation of spliterator is an IteratorSpliterator which is not optimal for RandomAccess data structures (besides ArrayList and Vector). This patch is to provide a default RandomAccessSpliterator implementation for RandomAccess data structure. > > The figures below demonstrate the performance difference before and after the change. Note the significant performance improvement in test SelectTest.parallel_lazy_streams_gsc (parallel streams performance test for non-JDK Lists that implement RandomAccess but don't yet implement their own spliterators). > > Benchmark code: https://github.com/goldmansachs/gs-collections/blob/master/jmh-tests/src/main/java/com/gs/collections/impl/jmh/SelectTest.java > > With IteratorSpliterator as default: > > Benchmark Mode Cnt Score Error Units > SelectTest.parallel_lazy_jdk thrpt 20 172.671 ? 14.231 ops/s > SelectTest.parallel_lazy_streams_gsc thrpt 20 20.662 ? 0.493 ops/s > SelectTest.serial_lazy_jdk thrpt 20 89.384 ? 4.431 ops/s > SelectTest.serial_lazy_streams_gsc thrpt 20 80.831 ? 7.875 ops/s > > With RandomAccessSpliterator as default: > > Benchmark Mode Cnt Score Error Units > SelectTest.parallel_lazy_jdk thrpt 20 174.190 ? 16.870 ops/s > SelectTest.parallel_lazy_streams_gsc thrpt 20 180.740 ? 9.594 ops/s > SelectTest.serial_lazy_jdk thrpt 20 85.719 ? 2.414 ops/s > SelectTest.serial_lazy_streams_gsc thrpt 20 78.760 ? 1.029 ops/s > > Majority of the patch is contributed by Paul Sandoz and he should be credited in the Contributed-by field. > > Along with this patch submission, we have a question for SubList spliterator implementation that we retained old behavior for now (i.e. return IteratorSpliterator, refer to RandomAccessSubList#spliterator()). We have found that Vector's subList is wrapped by RandomAccessSubList, that is RandomAccess but not a Vector anymore, and it expects to use IteratorSpliterator. We were not sure what's the best approach to distinguish Vector from other RandomAccess data structure within RandomAccessSublist, so we kept it return IteratorSpliterator for now. > > One approach could be to introduce VectorSubList that returns IteratorSpliterator (or an implementation similar to VectorSpliterator?). Then we could revert the spliterator() override in RandomAccessSublist. > > What would be your suggestion to handle this? > > Depending on your suggestion, we might fix the subList spliterator in this patch, or submit a separate patch if the amount of the change is significant. > > Thanks, > Hiroshi > From shilpi.rastogi at oracle.com Thu May 12 12:02:54 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Thu, 12 May 2016 17:32:54 +0530 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <07F81381-B038-47B2-BE70-76D3769598A5@oracle.com> References: <57331659.1030008@oracle.com> <8918541F-29FD-4AFD-AE9A-4B3F1CF32C4E@oracle.com> <57335E74.3090204@oracle.com> <07F81381-B038-47B2-BE70-76D3769598A5@oracle.com> Message-ID: <573470EE.5080105@oracle.com> Thank You Paul for comments. Please review updated webrev http://cr.openjdk.java.net/~srastogi/8149574/webrev.08/ Regards, Shilpi On 5/12/2016 3:41 PM, Paul Sandoz wrote: >> On 11 May 2016, at 18:31, shilpi.rastogi at oracle.com wrote: >> >> Hi All, >> >> Please review the updated webrev- http://cr.openjdk.java.net/~srastogi/8149574/webrev.07/ >> > > 1219 FieldVisitor fv; > 1220 MethodVisitor mv; > 1221 AnnotationVisitor av0; > > Field ?fv is not used. Since ?av0? is only used once, might as well declare it at line #1246. > > Can you break up the long lines at #1242 & #1252 ? > > > My inclination is to turn the anon static block into a method returning byte[] and then do: > > /* > > */ > private static final byte[] T_BYTES = generateT(); > private static byte[] generateT() { > ? > } > > > One concern, more so because of my ignorance, is why can the default package be used. Does anyone know? > > Paul. > >> Changed the anonymous class package with no package name. >> >> Regards, >> Shilpi >> From Fabrizio.Giudici at tidalwave.it Thu May 12 12:11:25 2016 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Thu, 12 May 2016 14:11:25 +0200 Subject: JDK 1.8.0_66, diacritics and file problems, follow up Message-ID: Hello. A year ago I asked about problems with the handling of files with diacritics in their name, as per this thread: http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-April/017183.html For almost the whole past year I suspended the investigation and moved to other things to do, but I've resumed the thing a few days ago, trying to create a more controlled scenario. Among a number of things to discuss, I think that I discovered a bug in the JDK. I recall that I was answered that some problems are related to the filesystem and Java can't do much, but in this case it seems there's an inconsistency in the behaviour beetween the old IO and NIO. Consider the test below, that given a path probes the existence and try to read bytes by using java.io.File and java.nio.file.*: private void tryToOpen (final Path path) throws IOException { final boolean filesExists = Files.exists(path); final boolean pathToFileExists = path.toFile().exists(); boolean canBeOpenedNio = false; try { Files.readAllBytes(path); canBeOpenedNio = true; } catch (IOException e) { } boolean canBeOpenedIo = false; try (final InputStream is = new FileInputStream(path.toFile())) { is.read(); canBeOpenedIo = true; } catch (IOException e) { } final String result = String.format("Files.exists(): %s, toFile.exists(): %s, canBeOpened NIO: %s canBeOpened IO: %s ", filesExists, pathToFileExists, canBeOpenedNio, canBeOpenedIo) + toDebugString(path.toString()); assertThat(result + toDebugString(path.toString()), filesExists, is(true)); assertThat(result + toDebugString(path.toString()), pathToFileExists, is(true)); assertThat(result + toDebugString(path.toString()), canBeOpenedIo, is(true)); assertThat(result + toDebugString(path.toString()), canBeOpenedNio, is(true)); } The Paths submitted to the test are discovered by Files.walk(). What I'm seeing is that all the troubled files show now no access problems with NIO, while IO fails (e.g. toFile().exists() returns false while Files.exists(path) returns true). Message: Files.exists(): true, toFile.exists(): false, canBeOpened NIO: true canBeOpened IO: false /var/test-sets/MusicTestSets/iTunes-fg-20160504-1-iconv/Music/Ivo Pogorelich/Ravel_ Gaspard De La Nuit; Prokofiev_ Piano Sonata #6/03 Ravel_ Gaspard De La Nuit - Scarbo_ Mod??r??.mp3/var/test-sets/MusicTestSets/iTunes-fg-20160504-1-iconv/Music/Ivo Pogorelich/Ravel_ Gaspard De La Nuit; Prokofiev_ Piano Sonata #6/03 Ravel_ Gaspard De La Nuit - Scarbo_ Mod??r??.mp3 Expected: is but: was Message: Files.exists(): true, toFile.exists(): false, canBeOpened NIO: true canBeOpened IO: false /var/test-sets/MusicTestSets/iTunes-fg-20160504-1-noiconv/Music/Ivo Pogorelich/Ravel_ Gaspard De La Nuit; Prokofiev_ Piano Sonata #6/03 Ravel_ Gaspard De La Nuit - Scarbo_ Mode??re??.mp3/var/test-sets/MusicTestSets/iTunes-fg-20160504-1-noiconv/Music/Ivo Pogorelich/Ravel_ Gaspard De La Nuit; Prokofiev_ Piano Sonata #6/03 Ravel_ Gaspard De La Nuit - Scarbo_ Mode??re??.mp3 Expected: is but: was The following code thus can be used to probe a troubled Path (so far I see that the problem only happens with the EXT4 filesytem; no problems with e.g. BTRFS and HFS+): private static boolean isTroubled (final @Nonnull Path path) { return Files.exists(path) != path.toFile().exists(); } I was able to implement a first workaround for libraries I'm using that unfortunately are based on java.io.File: I create a temporary symbolic link without diacritics, use it in place of the original, then delete it after the processing, and it works. There are other remaining troubles with file names, but I'd like to first have a feedback on this point. Thanks. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From sundararajan.athijegannathan at oracle.com Thu May 12 12:24:00 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 12 May 2016 17:54:00 +0530 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <573470EE.5080105@oracle.com> References: <57331659.1030008@oracle.com> <8918541F-29FD-4AFD-AE9A-4B3F1CF32C4E@oracle.com> <57335E74.3090204@oracle.com> <07F81381-B038-47B2-BE70-76D3769598A5@oracle.com> <573470EE.5080105@oracle.com> Message-ID: <8faed7ed-3fa2-30f3-a684-cf06c63d8697@oracle.com> Hi Paul: On default package: with the new rule a VM anonymous class has to be either [1] in the same package as that of the host class or [2] in the unnamed package. MethodHandleImpl's T class was earlier in java.lang.invoke package. So we can either fix it [1] to match the package of the host class every time [modify/regenerate class bytes for every host class or patch constant pool entries every time] or [2] generate in unnamed package and use it unmodified every time. The option [2] is being used because it involves no bytecode modification or constant pool patching. -Sundar On 5/12/2016 5:32 PM, shilpi.rastogi at oracle.com wrote: > Thank You Paul for comments. > Please review updated webrev > http://cr.openjdk.java.net/~srastogi/8149574/webrev.08/ > > Regards, > Shilpi > > On 5/12/2016 3:41 PM, Paul Sandoz wrote: >>> On 11 May 2016, at 18:31, shilpi.rastogi at oracle.com wrote: >>> >>> Hi All, >>> >>> Please review the updated webrev- >>> http://cr.openjdk.java.net/~srastogi/8149574/webrev.07/ >>> >> >> 1219 FieldVisitor fv; >> 1220 MethodVisitor mv; >> 1221 AnnotationVisitor av0; >> >> Field ?fv is not used. Since ?av0? is only used once, might as well >> declare it at line #1246. >> >> Can you break up the long lines at #1242 & #1252 ? >> >> >> My inclination is to turn the anon static block into a method >> returning byte[] and then do: >> >> /* >> > floating as is the current case> >> */ >> private static final byte[] T_BYTES = generateT(); >> private static byte[] generateT() { >> ? >> } >> >> >> One concern, more so because of my ignorance, is why can the default >> package be used. Does anyone know? >> >> Paul. >> >>> Changed the anonymous class package with no package name. >>> >>> Regards, >>> Shilpi >>> > From uschindler at apache.org Thu May 12 12:34:34 2016 From: uschindler at apache.org (Uwe Schindler) Date: Thu, 12 May 2016 14:34:34 +0200 Subject: MethodHandle for array length In-Reply-To: <3FD85BA6-799F-465F-8B33-BD75635D33AE@oracle.com> References: <00a601d1abbc$4a907ec0$dfb17c40$@apache.org> <3FD85BA6-799F-465F-8B33-BD75635D33AE@oracle.com> Message-ID: <01d301d1ac4a$a65264b0$f2f72e10$@apache.org> Hi Michael, > > Am 11.05.2016 um 21:35 schrieb Uwe Schindler : > > With Java 9 this gets a bit worse: There is no "easy way" with the > MethodHanldes class to generate a MethodHandles.countedLoop() on all > elements of an array: > > > > public static MethodHandle countedLoop(MethodHandle iterations, > MethodHandle init, MethodHandle body) [new in Java 9] > > this isn't a remedy when you need the index in each iteration, but you can > generate a loop over all elements of an array using iteratedLoop(), as > illustrated by this test from LoopCombinatorTest: > > @Test > public static void testIterateSum() throws Throwable { > // Integer[] a = new Integer[]{1,2,3,4,5,6}; int sum = 0; for (int e : a) { sum > += e; } return sum; => 21 > MethodHandle loop = > MethodHandles.iteratedLoop(Iterate.MH_sumIterator, Iterate.MH_sumInit, > Iterate.MH_sumStep); > assertEquals(Iterate.MT_sum, loop.type()); > assertEquals(21, loop.invoke(new Integer[]{1, 2, 3, 4, 5, 6})); > } > > ... where MH_sumIterator is a handle to this method: > > static Iterator sumIterator(Integer[] a) { > return Arrays.asList(a).iterator(); > } Of course this works, too. My proposal or question here was more about the API inconsistency in general. You can do a lot here and there, you can implement effective or non-effective loops with MethodHandles, but still the following holds true: java.lang.invoke.MethodHandles is missing an accessor for "array.length", which is not understandable. The "countedLoop" here was just an example use case (if that one is great or not does not matter), it was just posted to actually show the API and how it *could* be used. The real example from our script engine was not related to loops, it was an actual invokedynamic callsite implementation where it was not possible to figure out how to get a method handle to the very special arraylength byte code, aka "array.length javac sugar". Everything else to handle arrays is there at one single place, but the array length is missing and you get very annoyed. If you are not so familiar to bytecode and the mechanics behind, you have a very hard time to find out how to do this: the intuitive solutions does not work: "array.length" -> aha it?s a field, so let's try Lookup.findGetter(long[].class, "length", int.class) -> does not work! What is so hard to accept the proposal to have MethodHandles.arrayLengthGetter, implemented in the most effective way (as a methodhandle that solely calls the special bytecode "arraylength")? In fact thais is like a 10 liner to implement + Javadocs. No need to delay a release, there are still changes in JDK 9 going on that are far more risky than this. Best, Uwe > Best, > > Michael > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | LangTools Team | Nashorn > Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, > Germany > > ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D- > 80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering > 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > Oracle is committed to > developing practices and products that help protect the environment From Alan.Bateman at oracle.com Thu May 12 12:41:04 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 May 2016 13:41:04 +0100 Subject: JDK 1.8.0_66, diacritics and file problems, follow up In-Reply-To: References: Message-ID: <573479E0.7040205@oracle.com> On 12/05/2016 13:11, Fabrizio Giudici wrote: > : > > The Paths submitted to the test are discovered by Files.walk(). > > What I'm seeing is that all the troubled files show now no access > problems with NIO, while IO fails (e.g. toFile().exists() returns > false while Files.exists(path) returns true). > > : > > > The following code thus can be used to probe a troubled Path (so far I > see that the problem only happens with the EXT4 filesytem; no problems > with e.g. BTRFS and HFS+): > > private static boolean isTroubled (final @Nonnull Path path) > { > return Files.exists(path) != path.toFile().exists(); > } > > I was able to implement a first workaround for libraries I'm using > that unfortunately are based on java.io.File: I create a temporary > symbolic link without diacritics, use it in place of the original, > then delete it after the processing, and it works. I assume is a decoding and encoding round trip issue, meaning bytes -> String -> bytes. When you use the new file system API then you are using a Path which will use the underlying representation to access the file. Once you call toString or switch to java.io.File the bytes are decoded, and then re-encoded when you access the file via File::exists. Yes, all very subtle. So you can summarize the environment? You mention HFS+ and there is a mention about use NFD normalization. There is also a mention of a Raspberry Pi. So are the files transferred between the systems or is there SAMBA or other network access in the picture. -Alan. From vladimir.x.ivanov at oracle.com Thu May 12 12:42:05 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 12 May 2016 15:42:05 +0300 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <573470EE.5080105@oracle.com> References: <57331659.1030008@oracle.com> <8918541F-29FD-4AFD-AE9A-4B3F1CF32C4E@oracle.com> <57335E74.3090204@oracle.com> <07F81381-B038-47B2-BE70-76D3769598A5@oracle.com> <573470EE.5080105@oracle.com> Message-ID: <5c0c4872-8729-182b-9736-62a35b9e7dcf@oracle.com> Overall, looks really good! I like how it shapes out. A couple of nitpicks: (1) Please, use more meaningful names: INJECTED_INVOKER_TEMPLATE vs T_BYTES, invokerTemplateGenerator vs tBytesGenerator, InjectedInvoker vs T. (2) There's no need in a constructor. The invoker is never instantiated. (3) I don't see any point in T.init(). It is called from BindCaller.makeInjectedInvoker [1], but: (1) it's initialized later anyway [2]; and (2) Unsafe.ensureClassInitialized can be used. Frankly speaking, I'd prefer [2] to be converted into an assert. Also, I don't see any point in forcing the initialization of the invoker class during construction. I think it can go away as well. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/698b526d7c3b/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java#l1123 [2] http://hg.openjdk.java.net/jdk9/dev/jdk/file/698b526d7c3b/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java#l1137 On 5/12/16 3:02 PM, shilpi.rastogi at oracle.com wrote: > Thank You Paul for comments. > Please review updated webrev > http://cr.openjdk.java.net/~srastogi/8149574/webrev.08/ > > Regards, > Shilpi > > On 5/12/2016 3:41 PM, Paul Sandoz wrote: >>> On 11 May 2016, at 18:31, shilpi.rastogi at oracle.com wrote: >>> >>> Hi All, >>> >>> Please review the updated webrev- >>> http://cr.openjdk.java.net/~srastogi/8149574/webrev.07/ >>> >> >> 1219 FieldVisitor fv; >> 1220 MethodVisitor mv; >> 1221 AnnotationVisitor av0; >> >> Field ?fv is not used. Since ?av0? is only used once, might as well >> declare it at line #1246. >> >> Can you break up the long lines at #1242 & #1252 ? >> >> >> My inclination is to turn the anon static block into a method >> returning byte[] and then do: >> >> /* >> > floating as is the current case> >> */ >> private static final byte[] T_BYTES = generateT(); >> private static byte[] generateT() { >> ? >> } >> >> >> One concern, more so because of my ignorance, is why can the default >> package be used. Does anyone know? >> >> Paul. >> >>> Changed the anonymous class package with no package name. >>> >>> Regards, >>> Shilpi >>> > From paul.sandoz at oracle.com Thu May 12 12:42:20 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 12 May 2016 14:42:20 +0200 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <8faed7ed-3fa2-30f3-a684-cf06c63d8697@oracle.com> References: <57331659.1030008@oracle.com> <8918541F-29FD-4AFD-AE9A-4B3F1CF32C4E@oracle.com> <57335E74.3090204@oracle.com> <07F81381-B038-47B2-BE70-76D3769598A5@oracle.com> <573470EE.5080105@oracle.com> <8faed7ed-3fa2-30f3-a684-cf06c63d8697@oracle.com> Message-ID: > On 12 May 2016, at 14:24, Sundararajan Athijegannathan wrote: > > Hi Paul: > > On default package: with the new rule a VM anonymous class has to be > either [1] in the same package as that of the host class or [2] in the > unnamed package. Yes. > MethodHandleImpl's T class was earlier in > java.lang.invoke package. So we can either fix it [1] to match the > package of the host class every time [modify/regenerate class bytes for > every host class or patch constant pool entries every time] or [2] > generate in unnamed package and use it unmodified every time. > The option > [2] is being used because it involves no bytecode modification or > constant pool patching. > I realise that aspect [*]. Placing aside the technical details of generating anon classes, what i don?t understand are the implications of choosing the unnamed package over the host class package. Are there any such implications that we would favour using the unnamed package over the host class package? Paul. [*] And FWIW i reckon constant pool patching becomes easy when querying the class writer. From Roger.Riggs at Oracle.com Thu May 12 14:18:57 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 12 May 2016 10:18:57 -0400 Subject: RFR:JDK-8155823: Add date-time patterns 'v' and 'vvvv' In-Reply-To: References: <5730BC5D.7050807@oracle.com> <573227B7.4090603@oracle.com> Message-ID: Looks fine. Thanks for the updates, Roger On 5/11/2016 4:30 AM, Stephen Colebourne wrote: > This seems fine by me. > Stephen > > On 10 May 2016 at 19:25, nadeesh tv wrote: >> Hi, >> >> Stephen, Roger Thanks for the comments. >> Please see the updated webrev >> http://cr.openjdk.java.net/~ntv/8155823/webrev.04/ >> >> Apart from the fix, made a correction in the java doc of ZoneRules.java >> >> Thanks and Regards, >> Nadeesh >> >> On 5/10/2016 12:54 AM, Roger Riggs wrote: >> >> Hi Nadeesh, >> >> java/time/format/DateTimeFormatter.java: line 312 >> >> - Move 'v' up 1 line so it is after 'V' and before 'z'. >> Also in DateTimeFormatterBuilder.java: line 1415+ >> >> - the description of the number of letters does not need to be repeated; >> put one copy before the specifics of 'z' and 'v'. >> >> "If the count of letters is one, then the short name is output. >> + * If the count of letters is four, then the full name is output. >> + * Two, three and five or more letters throw {@code >> IllegalArgumentException}." >> >> DateTimeFormatterBuilder.java >> - line 1625/1626: should include what happens with vv and vvv to be >> consistent with DateTimeFormatter doc for ZoneId names. >> >> - line 1647: The description in DateTimeFormatter says that count = 2 and 3 >> should also produce the short value >> but the code will throw IAE. >> >> -line 1988: "almost" --- can this be more specific about what matches or >> does not match >> >> In the test it is a bit bothersome that the tests have to rely on timezone >> specific data. >> >> Thanks, Roger >> >> On 5/9/2016 12:35 PM, nadeesh tv wrote: >> >> >> Hi all, >> >> Reposting because subject line did not follow the format. >> >> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8155823 >> Issue: Add date-time patterns 'v' and 'vvvv' >> webrev: http://cr.openjdk.java.net/~ntv/8155823/webrev.03/ >> >> This webrev also contain the fix of related bug >> https://bugs.openjdk.java.net/browse/JDK-8154567 as part of this. >> >> Special thanks for Stephen for his help in writing the spec. >> >> >> >> -- >> Thanks and Regards, >> Nadeesh TV >> From Fabrizio.Giudici at tidalwave.it Thu May 12 15:54:35 2016 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Thu, 12 May 2016 17:54:35 +0200 Subject: JDK 1.8.0_66, diacritics and file problems, follow up In-Reply-To: <573479E0.7040205@oracle.com> References: <573479E0.7040205@oracle.com> Message-ID: On Thu, 12 May 2016 14:41:04 +0200, Alan Bateman wrote: > I assume is a decoding and encoding round trip issue, meaning bytes -> > String -> bytes. When you use the new file system API then you are using > a Path which will use the underlying representation to access the file. > Once you call toString or switch to java.io.File the bytes are decoded, > and then re-encoded when you access the file via File::exists. Yes, all > very subtle. It's what I presumed. In any case, (unless there's something very wrong in my environment: and I can't exclude it yet) I'd call it a bug, since the File API is not deprecated and shoudln't behave in a different way than NIO. > So you can summarize the environment? You mention HFS+ and there is a > mention about use NFD normalization. There is also a mention of a > Raspberry Pi. So are the files transferred between the systems or is > there SAMBA or other network access in the picture. The environment is complex, because of a large number of variants. I'm trying to create the simpler testcase as possible, but there are a few things that I'm not understanding well. In any case: the files are .mp3 imported from CDs by iTunes on Mac OS X El Capitan (hence the numerous non ASCII characters). Then, the files are rsynced to Linux. Here the first complication. rsync (not the one distributed with El Capitan, but a version 3.x separately installed) has got an --iconv option that can be used, AFAIU, to take "a certain" care of the issue (I'm writing "a certain" because there are still things that I don't understand). For instance, it seems that with BTRFS is makes a difference, eliminating any problem. I have to double check. Question: do you have a suggestion on how to programmatically re-create the files with their problematic names without passing through that complex setup? I thought about tarring the files, but I'm not sure that tar doesn't play in the same field. At the moment I'm working like that: 1. looking at the encoding of the names with something such as ls | od -c 2. creating names with that specific encoding by using something like System.exec("/bin/touch " + new String(array of bytes as per the result of the previous step)). Does it make sense? If it does, I could share soon a simple Java, self-contained test case. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From mandy.chung at oracle.com Thu May 12 16:45:53 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 12 May 2016 09:45:53 -0700 Subject: Review request for JDK-8156575: Add jdeps -addmods, -system, -inverse options In-Reply-To: <6D81F159-5607-4BDA-94AB-6C9FD0FF1BD8@oracle.com> References: <6D81F159-5607-4BDA-94AB-6C9FD0FF1BD8@oracle.com> Message-ID: This patch applies on the top of the jdeps refresh patch [1].. Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8156575/webrev.01/ The -addmods option is the same as what the runtime supports so that we can run jdeps in the same command-line options as runtime. -system is to specify an alternative java.home. -inverse option will find the modules that depend on a given root module directly and indirectly. It?s useful to use with the -requires option or -package, -regex options: Example output: $ jdeps -I -mp mods -addmods m4,m5 -requires java.logging java.sql [jrt:/java.sql] requires mandated java.base requires public java.logging requires public java.xml java.sql -> java.logging java.sql -> java.util.logging java.logging javax.sql -> java.util.logging java.logging m5 [file:///scratch/mchung/ws/jdk9/jdk9-jdeps/JTwork/scratch/mods/m5/] requires mandated java.base requires public java.compiler requires public java.logging requires java.sql requires public m4 m5 -> java.logging p5 -> java.util.logging java.logging Inverse transitive dependences on [java.logging] java.logging <- java.sql <- m5 java.logging <- m4 <- m5 java.logging <- m5 $ jdeps -I -mp mods -requires jdk.unsupported -m java.se java.desktop [jrt:/java.desktop] requires mandated java.base requires public java.datatransfer requires java.prefs requires public java.xml requires jdk.unsupported java.desktop -> jdk.unsupported sun.awt -> sun.misc jdk.unsupported (internal) sun.awt.image -> sun.misc jdk.unsupported (internal) Inverse transitive dependences on [jdk.unsupported] jdk.unsupported <- java.desktop <- java.se [1] http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8156680/webrev.01/ From xueming.shen at oracle.com Thu May 12 16:52:37 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 12 May 2016 09:52:37 -0700 Subject: JDK 1.8.0_66, diacritics and file problems, follow up In-Reply-To: References: <573479E0.7040205@oracle.com> Message-ID: <3e9d95af-9e55-6037-6e30-ec4fac9a9295@oracle.com> On 5/12/16 8:54 AM, Fabrizio Giudici wrote: > On Thu, 12 May 2016 14:41:04 +0200, Alan Bateman > wrote: > > >> I assume is a decoding and encoding round trip issue, meaning bytes >> -> String -> bytes. When you use the new file system API then you are >> using a Path which will use the underlying representation to access >> the file. Once you call toString or switch to java.io.File the bytes >> are decoded, and then re-encoded when you access the file via >> File::exists. Yes, all very subtle. > > It's what I presumed. In any case, (unless there's something very > wrong in my environment: and I can't exclude it yet) I'd call it a > bug, since the File API is not deprecated and shoudln't behave in a > different way than NIO. > >> So you can summarize the environment? You mention HFS+ and there is a >> mention about use NFD normalization. There is also a mention of a >> Raspberry Pi. So are the files transferred between the systems or is >> there SAMBA or other network access in the picture. > > The environment is complex, because of a large number of variants. I'm > trying to create the simpler testcase as possible, but there are a few > things that I'm not understanding well. > > In any case: the files are .mp3 imported from CDs by iTunes on Mac OS > X El Capitan (hence the numerous non ASCII characters). Then, the > files are rsynced to Linux. Here the first complication. rsync (not > the one distributed with El Capitan, but a version 3.x separately > installed) has got an --iconv option that can be used, AFAIU, to take > "a certain" care of the issue (I'm writing "a certain" because there > are still things that I don't understand). For instance, it seems that > with BTRFS is makes a difference, eliminating any problem. I have to > double check. > It sounds more like a hfs+/nfd file path issue (file name on nfs+ is in unicode nfd form). Myabe the nfd-ed file name gets messed up while doing the utf8-xxx-utf8 conversion. Does that --iconv have any specific encoding name specified? "Everything" is supposed to be taken care by #7130915 :-) but something might be missed. -sherman > Question: do you have a suggestion on how to programmatically > re-create the files with their problematic names without passing > through that complex setup? I thought about tarring the files, but I'm > not sure that tar doesn't play in the same field. At the moment I'm > working like that: > > 1. looking at the encoding of the names with something such as ls | od -c > 2. creating names with that specific encoding by using something like > System.exec("/bin/touch " + new String(array of bytes as per the > result of the previous step)). > > Does it make sense? If it does, I could share soon a simple Java, > self-contained test case. > From aleksej.efimov at oracle.com Thu May 12 17:00:56 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Thu, 12 May 2016 20:00:56 +0300 Subject: [9] RFR: 8145974: XMLStreamWriter produces invalid XML for surrogate pairs on OutputStreamWriter In-Reply-To: <57340BDF.4090509@oracle.com> References: <5733C0A9.8000800@oracle.com> <57340BDF.4090509@oracle.com> Message-ID: <5734B6C8.7060803@oracle.com> Hi Joe, Thanks for your comments and suggestions. New webrev can be found at this location: http://cr.openjdk.java.net/~aefimov/8145974/9/01 Answers are inlined. Best Regards, Aleksej On 12/05/16 07:51, huizhe wang wrote: > Hi Aleksej, > > The change looks good overall. It may be better to replace the name > "writeCodePoint" with "writeCharRef" or "writeEscaped". Replaced with 'writeCharRef' > Doing the "isSurrogatePair" check in place of the call for > writeSurrogatePair may be more descriptive and readable as well, that is: Agree. writeSurrogatePair is replaced with isSurrogatePair in-place check - was a leftover from previous version of the fix. > If you do that, you wouldn't need the method "writeSurrogatePair". "writeSurrogatePair" was removed > > For the test, it may be good to call writer.close() at the end of the > test. Also, would the content read is the same (vs contains) as the > expectedContent? "writer.close()" was added and 'contains' was replaced with testng's assertEquals. > > Thanks, > Joe > > On 5/11/2016 4:30 PM, Aleks Efimov wrote: >> Hello, >> >> Please, help to review the fix for XMLStreamWriter bug [1]: >> XMLStreamWriter incorrectly writes surrogate pairs into pair of >> invalid character references. >> For example: "\ud83d\ude0a" is transformed into "��". >> It should be one character reference "😊" instead. >> The proposed patch fixes the XMLStreamWriterImpl to correctly process >> surrogate pairs: >> http://cr.openjdk.java.net/~aefimov/8145974/9/00 >> >> The build with fix applied was tested with JTREG and JCK xml tests - >> no related issues detected. >> >> Aleksej >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8145974 >> > From daniel.fuchs at oracle.com Thu May 12 17:31:32 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 12 May 2016 19:31:32 +0200 Subject: Review request for JDK-8156575: Add jdeps -addmods, -system, -inverse options In-Reply-To: References: <6D81F159-5607-4BDA-94AB-6C9FD0FF1BD8@oracle.com> Message-ID: <113b916e-7c89-179c-5140-170db1c40811@oracle.com> Hi Mandy, I am a bit surprised that the verbose option doesn't seem to have any effect on the output of jdeps -I I have built 4 jars: unsafe.jar has some class that depend directly on sun.misc.Unsafe, and some that don't. indirect.jar has some classes that depends indirectly on sun.misc.Unsafe: they depend on classes from unsafe.jar that depend on sun.misc.Unsafe. It also has classes that don't depend on sun.misc.Unsafe, either directly or indirectly. indirect2.jar also has some classes that depends indirectly on sun.misc.Unsafe: they depend on classes from unsafe.jar that depend on sun.misc.Unsafe. It also has classes that don't depend on sun.misc.Unsafe, either directly or indirectly. safe.jar has classes that depends on other classes in unsafe.jar, indirect.jar, and indirect2.jar However the classes it depends on do not depend on sun.misc.Unsafe, either directly or indirectly. If I run: $ ./bin/jdeps -I -e sun.misc.Usafe -modulepath ~/test/JdepsTest/dist -addmods unsafe,safe,indirect,indirect2 Inverse transitive dependences matching sun.misc.Usafe indirect <- safe indirect2 <- safe unsafe <- indirect <- safe unsafe <- indirect2 <- safe unsafe <- safe So it looks like the granurality of the analysis is performed at module level. Is there anyway to make the analysis at class level, so that 'safe' isn't reported to depend on sun.misc.Unsafe? I tried passing -verbose:class or -v but it doesn't appear to have any effect, the result is always the same. best regards, -- daniel On 12/05/16 18:45, Mandy Chung wrote: > This patch applies on the top of the jdeps refresh patch [1].. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8156575/webrev.01/ > > The -addmods option is the same as what the runtime supports so that we > can run jdeps in the same command-line options as runtime. -system is > to specify an alternative java.home. > > -inverse option will find the modules that depend on a given root module > directly and indirectly. It?s useful to use with the -requires option > or -package, -regex options: > > Example output: > $ jdeps -I -mp mods -addmods m4,m5 -requires java.logging > java.sql > [jrt:/java.sql] > requires mandated java.base > requires public java.logging > requires public java.xml > java.sql -> java.logging > java.sql -> > java.util.logging java.logging > javax.sql -> > java.util.logging java.logging > m5 > [file:///scratch/mchung/ws/jdk9/jdk9-jdeps/JTwork/scratch/mods/m5/] > requires mandated java.base > requires public java.compiler > requires public java.logging > requires java.sql > requires public m4 > m5 -> java.logging > p5 -> > java.util.logging java.logging > > Inverse transitive dependences on [java.logging] > java.logging <- java.sql <- m5 > java.logging <- m4 <- m5 > java.logging <- m5 > > $ jdeps -I -mp mods -requires jdk.unsupported -m java.se > java.desktop > [jrt:/java.desktop] > requires mandated java.base > requires public java.datatransfer > requires java.prefs > requires public java.xml > requires jdk.unsupported > java.desktop -> jdk.unsupported > sun.awt -> sun.misc > jdk.unsupported (internal) > sun.awt.image -> sun.misc > jdk.unsupported (internal) > > Inverse transitive dependences on [jdk.unsupported] > jdk.unsupported <- java.desktop <- java.se > > > [1] http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8156680/webrev.01/ > From mandy.chung at oracle.com Thu May 12 17:38:11 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 12 May 2016 10:38:11 -0700 Subject: Review request for JDK-8156575: Add jdeps -addmods, -system, -inverse options In-Reply-To: <113b916e-7c89-179c-5140-170db1c40811@oracle.com> References: <6D81F159-5607-4BDA-94AB-6C9FD0FF1BD8@oracle.com> <113b916e-7c89-179c-5140-170db1c40811@oracle.com> Message-ID: <3448876A-5BE1-40AA-9517-73B13DBEE52E@oracle.com> I think I know where the issue is. Can you send me your test and I can modify and include it in this patch? Mandy > On May 12, 2016, at 10:31 AM, Daniel Fuchs wrote: > > Hi Mandy, > > I am a bit surprised that the verbose option doesn't seem > to have any effect on the output of jdeps -I > > I have built 4 jars: > > unsafe.jar has some class that depend directly on > sun.misc.Unsafe, and some that don't. > indirect.jar has some classes that depends indirectly > on sun.misc.Unsafe: they depend on classes > from unsafe.jar that depend on sun.misc.Unsafe. > It also has classes that don't depend on sun.misc.Unsafe, > either directly or indirectly. > indirect2.jar also has some classes that depends indirectly > on sun.misc.Unsafe: they depend on classes > from unsafe.jar that depend on sun.misc.Unsafe. > It also has classes that don't depend on sun.misc.Unsafe, > either directly or indirectly. > safe.jar has classes that depends on other classes in > unsafe.jar, indirect.jar, and indirect2.jar > However the classes it depends on do not depend on > sun.misc.Unsafe, either directly or indirectly. > > If I run: > $ ./bin/jdeps -I -e sun.misc.Usafe -modulepath ~/test/JdepsTest/dist -addmods unsafe,safe,indirect,indirect2 > > Inverse transitive dependences matching sun.misc.Usafe > indirect <- safe > indirect2 <- safe > unsafe <- indirect <- safe > unsafe <- indirect2 <- safe > unsafe <- safe > > So it looks like the granurality of the analysis is performed > at module level. Is there anyway to make the analysis at class > level, so that 'safe' isn't reported to depend on sun.misc.Unsafe? > > I tried passing -verbose:class or -v but it doesn't appear to have any > effect, the result is always the same. > > best regards, > > -- daniel > > On 12/05/16 18:45, Mandy Chung wrote: >> This patch applies on the top of the jdeps refresh patch [1].. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8156575/webrev.01/ >> >> The -addmods option is the same as what the runtime supports so that we >> can run jdeps in the same command-line options as runtime. -system is >> to specify an alternative java.home. >> >> -inverse option will find the modules that depend on a given root module >> directly and indirectly. It?s useful to use with the -requires option >> or -package, -regex options: >> >> Example output: >> $ jdeps -I -mp mods -addmods m4,m5 -requires java.logging >> java.sql >> [jrt:/java.sql] >> requires mandated java.base >> requires public java.logging >> requires public java.xml >> java.sql -> java.logging >> java.sql -> >> java.util.logging java.logging >> javax.sql -> >> java.util.logging java.logging >> m5 >> [file:///scratch/mchung/ws/jdk9/jdk9-jdeps/JTwork/scratch/mods/m5/] >> requires mandated java.base >> requires public java.compiler >> requires public java.logging >> requires java.sql >> requires public m4 >> m5 -> java.logging >> p5 -> >> java.util.logging java.logging >> >> Inverse transitive dependences on [java.logging] >> java.logging <- java.sql <- m5 >> java.logging <- m4 <- m5 >> java.logging <- m5 >> >> $ jdeps -I -mp mods -requires jdk.unsupported -m java.se >> java.desktop >> [jrt:/java.desktop] >> requires mandated java.base >> requires public java.datatransfer >> requires java.prefs >> requires public java.xml >> requires jdk.unsupported >> java.desktop -> jdk.unsupported >> sun.awt -> sun.misc >> jdk.unsupported (internal) >> sun.awt.image -> sun.misc >> jdk.unsupported (internal) >> >> Inverse transitive dependences on [jdk.unsupported] >> jdk.unsupported <- java.desktop <- java.se >> >> >> [1] http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8156680/webrev.01/ >> > From huizhe.wang at oracle.com Thu May 12 17:51:54 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 12 May 2016 10:51:54 -0700 Subject: [9] RFR: 8145974: XMLStreamWriter produces invalid XML for surrogate pairs on OutputStreamWriter In-Reply-To: <5734B6C8.7060803@oracle.com> References: <5733C0A9.8000800@oracle.com> <57340BDF.4090509@oracle.com> <5734B6C8.7060803@oracle.com> Message-ID: <5734C2BA.2090805@oracle.com> Thanks Aleksej. The change looks good. Best, Joe On 5/12/2016 10:00 AM, Aleks Efimov wrote: > Hi Joe, > > Thanks for your comments and suggestions. New webrev can be found at > this location: > http://cr.openjdk.java.net/~aefimov/8145974/9/01 > Answers are inlined. > > Best Regards, > Aleksej > > On 12/05/16 07:51, huizhe wang wrote: > >> Hi Aleksej, >> >> The change looks good overall. It may be better to replace the name >> "writeCodePoint" with "writeCharRef" or "writeEscaped". > > Replaced with 'writeCharRef' > > >> Doing the "isSurrogatePair" check in place of the call for >> writeSurrogatePair may be more descriptive and readable as well, that >> is: > Agree. writeSurrogatePair is replaced with isSurrogatePair in-place > check - was a leftover from previous version of the fix. >> If you do that, you wouldn't need the method "writeSurrogatePair". > "writeSurrogatePair" was removed >> >> For the test, it may be good to call writer.close() at the end of the >> test. Also, would the content read is the same (vs contains) as the >> expectedContent? > "writer.close()" was added and 'contains' was replaced with testng's > assertEquals. >> >> Thanks, >> Joe >> >> On 5/11/2016 4:30 PM, Aleks Efimov wrote: >>> Hello, >>> >>> Please, help to review the fix for XMLStreamWriter bug [1]: >>> XMLStreamWriter incorrectly writes surrogate pairs into pair of >>> invalid character references. >>> For example: "\ud83d\ude0a" is transformed into "��". >>> It should be one character reference "😊" instead. >>> The proposed patch fixes the XMLStreamWriterImpl to correctly >>> process surrogate pairs: >>> http://cr.openjdk.java.net/~aefimov/8145974/9/00 >>> >>> The build with fix applied was tested with JTREG and JCK xml tests - >>> no related issues detected. >>> >>> Aleksej >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8145974 >>> >> > From Fabrizio.Giudici at tidalwave.it Thu May 12 18:17:29 2016 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Thu, 12 May 2016 20:17:29 +0200 Subject: JDK 1.8.0_66, diacritics and file problems, follow up In-Reply-To: <3e9d95af-9e55-6037-6e30-ec4fac9a9295@oracle.com> References: <573479E0.7040205@oracle.com> <3e9d95af-9e55-6037-6e30-ec4fac9a9295@oracle.com> Message-ID: On Thu, 12 May 2016 18:52:37 +0200, Xueming Shen wrote: > It sounds more like a hfs+/nfd file path issue (file name on nfs+ is in > unicode nfd form). Myabe the > nfd-ed file name gets messed up while doing the utf8-xxx-utf8 > conversion. Does that --iconv have > any specific encoding name specified? It does: --iconv=utf-8-mac,utf-8 But I don't know whether it works :-) Well, probably yes, in BTRFS it does... but BTRFS and EXT4 are on two different machines, so I haven't eliminated yet all the possible contextual problems. I suppose the conversion is performed by the client rsync, but I can't exclude that the destination rsync (I'm rsyncing over ssh) doesn't have a role. Back to work on it in a few hours. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From mandy.chung at oracle.com Thu May 12 18:44:03 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 12 May 2016 11:44:03 -0700 Subject: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival In-Reply-To: <57325921.9090100@oracle.com> References: <55479A4F.4060806@oracle.com> <5550FE5A.4070607@oracle.com> <55513EA7.1050700@oracle.com> <555192A4.3080305@gmail.com> <5551A0AA.6050800@gmail.com> <5552674E.4030009@oracle.com> <55526FF5.9000509@gmail.com> <55564473.3010704@oracle.com> <8DD50D66-D2C1-43E4-B7C5-992FE785958B@oracle.com> <57325921.9090100@oracle.com> Message-ID: <0B7583E3-56D0-423C-9F74-45C05B632C98@oracle.com> Hi Brent, > > A new webrev is here: > http://cr.openjdk.java.net/~bchristi/8029891/webrev.4/ This patch looks good. To help future readers to understand this, it may be better to move: 1152 private transient ConcurrentHashMap map = 1153 new ConcurrentHashMap<>(8); to the beginning and add a comment describing what are lock-free and what are synchronized (basically some part of your summary below). Also a comment in Hashtable::defaultWriteHashtable and readHashtable methods to mention that they are overridden by Properties. In the GetResource.java test, what is the reason taking out: 73 URL u2 = Thread.currentThread().getContextClassLoader().getResource("sun/util/resources/CalendarData.class?); Mandy From xueming.shen at oracle.com Thu May 12 19:16:00 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 12 May 2016 12:16:00 -0700 Subject: RFR: 8147588: Jar file and Zip file not removed in spite of the OPEN_DELETE flag Message-ID: <5734D670.3080004@oracle.com> Hi, Please help review the proposed change for #8147588 issue: https://bugs.openjdk.java.net/browse/JDK-8147588 webrev: http://cr.openjdk.java.net/~sherman/8147588/webrev This is a regression on Windows platform triggered by the change for https://bugs.openjdk.java.net/browse/JDK-8145260, in which we brought the ZipFile native natively code to java for better performance (both memory and access). As showed the from ln#107-114 at webrev below http://cr.openjdk.java.net/~sherman/8145260/webrev.push/src/java.base/share/native/libzip/ZipFile.c-.html The original native implementation uses a special "Windows-only" option O_TEMPORARY to open the zip/jar file on Windows to support this OPEN_DELETE functionality. There is no corresponding public open/delete functionality at java.io API right now. The proposed the change here is to add a private constructor for RandomAccessFile and access from ZipFile via SharedSecrets. This O_TEMPORARY is only supported on Windows platform. Thanks, Sherman From mandy.chung at oracle.com Thu May 12 20:43:27 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 12 May 2016 13:43:27 -0700 Subject: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival In-Reply-To: References: <55479A4F.4060806@oracle.com> <5550FE5A.4070607@oracle.com> <55513EA7.1050700@oracle.com> <555192A4.3080305@gmail.com> <5551A0AA.6050800@gmail.com> <5552674E.4030009@oracle.com> <55526FF5.9000509@gmail.com> <55564473.3010704@oracle.com> <8DD50D66-D2C1-43E4-B7C5-992FE785958B@oracle.com> <57325921.9090100@oracle.com> Message-ID: <63959873-4A29-40B7-A95C-C2A0A1202823@oracle.com> > On May 11, 2016, at 8:39 PM, David Holmes wrote: > >> While good progress was made during the original code review, all of the >> overridden methods in Properties caused an explosion of unnecessary >> JavaDoc (see specdiff at [2]). With the recent fix of 8073100 (new >> "@hidden" JavaDoc tag), we can now avoid the additional clutter. > > The existing javadoc has a section "Methods inherited from java.util.Hashtable" which I can't see in your specdiff - what does that section say about the methods you overrode to delegate to the CHM instance? Are they simply not listed, or does it lie and claim they are inherited, or does it have some new way to present "@hidden" things? No javadoc will be generated for @Hidden methods. Kumar can give more details about it. > >> FWIW, the deadlock code path is now different than what is seen in the >> bug report (see [3]). We're now getting hung up on the >> Integer.getInteger() call to get MAX_ARITY on line 60 of >> MethodHandleImpl [4]. > > So while the original deadlock is resolved by all this change, there still exists a deadlock. Properties::get is now lock-free with this change. The stack trace below is the deadlock before this fix. > I can see from the details that store() locks the properties object and can lead to MethodHandleNatives.linkCallsite, while in another thread we have > > at java.util.Hashtable.get(java.base at 9-ea/Hashtable.java:370) > - waiting to lock <0x00000006cff097f0> (a java.util.Properties) > ... > at java.lang.invoke.CallSite.(java.base at 9-ea/CallSite.java:230) > at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(java.base at 9-ea/MethodHandleNatives.java:250) > > I think we have some fundamental initialization order problems that need to be addressed in a holistic way rather than deadlock by deadlock (or initialization failure by initialization failure). The startup initialization has been updated significantly. That should clean up a few initialization failures. However, I agree that there are still deadlocks and initialization failures to be addressed. Mandy From brent.christian at oracle.com Thu May 12 21:02:36 2016 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 12 May 2016 14:02:36 -0700 Subject: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival In-Reply-To: References: <55479A4F.4060806@oracle.com> <5550FE5A.4070607@oracle.com> <55513EA7.1050700@oracle.com> <555192A4.3080305@gmail.com> <5551A0AA.6050800@gmail.com> <5552674E.4030009@oracle.com> <55526FF5.9000509@gmail.com> <55564473.3010704@oracle.com> <8DD50D66-D2C1-43E4-B7C5-992FE785958B@oracle.com> <57325921.9090100@oracle.com> Message-ID: <5734EF6C.5090603@oracle.com> Hi, David On 5/11/16 8:39 PM, David Holmes wrote: > On 11/05/2016 7:56 AM, Brent Christian wrote: >> While good progress was made during the original code review, all of the >> overridden methods in Properties caused an explosion of unnecessary >> JavaDoc (see specdiff at [2]). With the recent fix of 8073100 (new >> "@hidden" JavaDoc tag), we can now avoid the additional clutter. > > The existing javadoc has a section "Methods inherited from > java.util.Hashtable" which I can't see in your specdiff - what does that > section say about the methods you overrode to delegate to the CHM > instance? Are they simply not listed, or does it lie and claim they are > inherited, or does it have some new way to present "@hidden" things? Good catch! specdiff didn't pick up that change with --config=javadoc, which is a bit troubling, but it does show up with --config=plain: http://cr.openjdk.java.net/~bchristi/8029891/webrev.4/specdiff-plain/Properties.html With all of the inherited methods @hidden, it looks like that section is left out altogether. > while the original deadlock is resolved by all this change, there > still exists a deadlock. I should have been clearer. Since this issue was filed, the code paths in question changed a fair bit with jigsaw. Pre-fix, the test still hung, but in different code (NewDeadlock.txt). As Mandy said, with the fix, Properties::get no longer locks on the object, and this test passes. Thanks, -Brent From brent.christian at oracle.com Thu May 12 21:44:28 2016 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 12 May 2016 14:44:28 -0700 Subject: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival In-Reply-To: <0B7583E3-56D0-423C-9F74-45C05B632C98@oracle.com> References: <55479A4F.4060806@oracle.com> <5550FE5A.4070607@oracle.com> <55513EA7.1050700@oracle.com> <555192A4.3080305@gmail.com> <5551A0AA.6050800@gmail.com> <5552674E.4030009@oracle.com> <55526FF5.9000509@gmail.com> <55564473.3010704@oracle.com> <8DD50D66-D2C1-43E4-B7C5-992FE785958B@oracle.com> <57325921.9090100@oracle.com> <0B7583E3-56D0-423C-9F74-45C05B632C98@oracle.com> Message-ID: <5734F93C.10201@oracle.com> On 5/12/16 11:44 AM, Mandy Chung wrote: > > This patch looks good. > > To help future readers to understand this, it may be better to move: > 1152 private transient ConcurrentHashMap map = > 1153 new ConcurrentHashMap<>(8); > > to the beginning and add a comment describing what are lock-free and what are synchronized (basically some part of your summary below). > > Also a comment in Hashtable::defaultWriteHashtable and readHashtable methods to mention that they are overridden by Properties. Good ideas. > In the GetResource.java test, what is the reason taking out: > 73 URL u2 = Thread.currentThread().getContextClassLoader().getResource("sun/util/resources/CalendarData.class?); > It was coming back null and failing the test, I think because Jigsaw moved CalendarData into a different module (jdk.localedata, I believe?). I fiddled with @modules a bit, but stopped when I discovered that when the test deadlocks, it hangs on the first call to getResource() and doesn't get to this line. I can look into getting it to load CalendarData again, if you like. Thanks, -Brent From mandy.chung at oracle.com Thu May 12 23:15:33 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 12 May 2016 16:15:33 -0700 Subject: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival In-Reply-To: <5734F93C.10201@oracle.com> References: <55479A4F.4060806@oracle.com> <5550FE5A.4070607@oracle.com> <55513EA7.1050700@oracle.com> <555192A4.3080305@gmail.com> <5551A0AA.6050800@gmail.com> <5552674E.4030009@oracle.com> <55526FF5.9000509@gmail.com> <55564473.3010704@oracle.com> <8DD50D66-D2C1-43E4-B7C5-992FE785958B@oracle.com> <57325921.9090100@oracle.com> <0B7583E3-56D0-423C-9F74-45C05B632C98@oracle.com> <5734F93C.10201@oracle.com> Message-ID: <859C354C-FCFD-430E-9869-2364623E29D6@oracle.com> > On May 12, 2016, at 2:44 PM, Brent Christian wrote: > > On 5/12/16 11:44 AM, Mandy Chung wrote: >> >> This patch looks good. >> >> To help future readers to understand this, it may be better to move: >> 1152 private transient ConcurrentHashMap map = >> 1153 new ConcurrentHashMap<>(8); >> >> to the beginning and add a comment describing what are lock-free and what are synchronized (basically some part of your summary below). >> >> Also a comment in Hashtable::defaultWriteHashtable and readHashtable methods to mention that they are overridden by Properties. > > Good ideas. > >> In the GetResource.java test, what is the reason taking out: >> 73 URL u2 = Thread.currentThread().getContextClassLoader().getResource("sun/util/resources/CalendarData.class?); >> > > It was coming back null and failing the test, I think because > Jigsaw moved CalendarData into a different module (jdk.localedata, I believe?). src/java.base/share/classes/sun/util/resources/CalendarData.properties is still in java.base. This is due to resource encapsulation. Unnamed module calling ClassLoader::getResource of a resource in a named module returns null. > I fiddled with @modules a bit, but stopped when I discovered that when the test deadlocks, it hangs on the first call to getResource() and doesn't get to this line. > > I can look into getting it to load CalendarData again, if you like. The launcher and builtin class loader implementation has changed so much that the code path exercised JDK-6977738 no longer exists. I think dropping line 73 is okay. Mandy From brent.christian at oracle.com Thu May 12 23:55:52 2016 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 12 May 2016 16:55:52 -0700 Subject: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival In-Reply-To: <859C354C-FCFD-430E-9869-2364623E29D6@oracle.com> References: <55479A4F.4060806@oracle.com> <5550FE5A.4070607@oracle.com> <55513EA7.1050700@oracle.com> <555192A4.3080305@gmail.com> <5551A0AA.6050800@gmail.com> <5552674E.4030009@oracle.com> <55526FF5.9000509@gmail.com> <55564473.3010704@oracle.com> <8DD50D66-D2C1-43E4-B7C5-992FE785958B@oracle.com> <57325921.9090100@oracle.com> <0B7583E3-56D0-423C-9F74-45C05B632C98@oracle.com> <5734F93C.10201@oracle.com> <859C354C-FCFD-430E-9869-2364623E29D6@oracle.com> Message-ID: <57351808.3040207@oracle.com> Update to the test, and additional comments: http://cr.openjdk.java.net/~bchristi/8029891/webrev.5/webrev/ Thanks, -Brent On 5/12/16 4:15 PM, Mandy Chung wrote: > >> On May 12, 2016, at 2:44 PM, Brent Christian wrote: >> >> On 5/12/16 11:44 AM, Mandy Chung wrote: >>> >>> This patch looks good. >>> >>> To help future readers to understand this, it may be better to move: >>> 1152 private transient ConcurrentHashMap map = >>> 1153 new ConcurrentHashMap<>(8); >>> >>> to the beginning and add a comment describing what are lock-free and what are synchronized (basically some part of your summary below). >>> >>> Also a comment in Hashtable::defaultWriteHashtable and readHashtable methods to mention that they are overridden by Properties. >> >> Good ideas. >> >>> In the GetResource.java test, what is the reason taking out: >>> 73 URL u2 = Thread.currentThread().getContextClassLoader().getResource("sun/util/resources/CalendarData.class?); >>> >> >> It was coming back null and failing the test, I think because >> Jigsaw moved CalendarData into a different module (jdk.localedata, I believe?). > > src/java.base/share/classes/sun/util/resources/CalendarData.properties is still in java.base. This is due to resource encapsulation. Unnamed module calling ClassLoader::getResource of a resource in a named module returns null. > > >> I fiddled with @modules a bit, but stopped when I discovered that when the test deadlocks, it hangs on the first call to getResource() and doesn't get to this line. >> >> I can look into getting it to load CalendarData again, if you like. > > The launcher and builtin class loader implementation has changed so much that the code path exercised JDK-6977738 no longer exists. I think dropping line 73 is okay. > > Mandy > From david.holmes at oracle.com Fri May 13 00:58:03 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 May 2016 10:58:03 +1000 Subject: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival In-Reply-To: <5734EF6C.5090603@oracle.com> References: <55479A4F.4060806@oracle.com> <5550FE5A.4070607@oracle.com> <55513EA7.1050700@oracle.com> <555192A4.3080305@gmail.com> <5551A0AA.6050800@gmail.com> <5552674E.4030009@oracle.com> <55526FF5.9000509@gmail.com> <55564473.3010704@oracle.com> <8DD50D66-D2C1-43E4-B7C5-992FE785958B@oracle.com> <57325921.9090100@oracle.com> <5734EF6C.5090603@oracle.com> Message-ID: Hi Brent, On 13/05/2016 7:02 AM, Brent Christian wrote: > Hi, David > > On 5/11/16 8:39 PM, David Holmes wrote: >> On 11/05/2016 7:56 AM, Brent Christian wrote: >>> While good progress was made during the original code review, all of the >>> overridden methods in Properties caused an explosion of unnecessary >>> JavaDoc (see specdiff at [2]). With the recent fix of 8073100 (new >>> "@hidden" JavaDoc tag), we can now avoid the additional clutter. >> >> The existing javadoc has a section "Methods inherited from >> java.util.Hashtable" which I can't see in your specdiff - what does that >> section say about the methods you overrode to delegate to the CHM >> instance? Are they simply not listed, or does it lie and claim they are >> inherited, or does it have some new way to present "@hidden" things? > > Good catch! specdiff didn't pick up that change with --config=javadoc, > which is a bit troubling, but it does show up with --config=plain: > > http://cr.openjdk.java.net/~bchristi/8029891/webrev.4/specdiff-plain/Properties.html > > > With all of the inherited methods @hidden, it looks like that section > is left out altogether. Okay, so I have to say @hidden seems to me to be seriously flawed! If a class has a method that can be called then IMHO that has to be documented in that class as either being first defined, overridden, or inherited - it can't just say nothing as-if the method were not there! If we are overriding in a trivial way that does not change the specification at all then there should be a simple way to show that - perhaps the "Methods inherited from ..." should be split into two parts: method implementations inherited from ..., and method specifications inherited from ... ?? I guess I need to raise this with the javadoc folk :( Is there a mailing list for that? >> while the original deadlock is resolved by all this change, there >> still exists a deadlock. > > I should have been clearer. Since this issue was filed, the code paths > in question changed a fair bit with jigsaw. Pre-fix, the test still > hung, but in different code (NewDeadlock.txt). As Mandy said, with the > fix, Properties::get no longer locks on the object, and this test passes. Ah, sorry about the misunderstanding. Thanks, David > Thanks, > -Brent From stuart.marks at oracle.com Fri May 13 01:37:07 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 12 May 2016 18:37:07 -0700 Subject: RFR(m): 8140281 deprecate Optional.get() In-Reply-To: References: <1282fc0c-2d92-be13-d95e-9486cd556146@oracle.com> <571EA9D8.3010702@oracle.com> <5dad068b-038e-591c-49a1-ffcc22ffebb8@oracle.com> <350f4ee8-e59a-1518-adda-1a52f3654b96@oracle.com> Message-ID: <504a1c7f-40c1-6338-5113-4faebfbcfad2@oracle.com> On 5/11/16 2:37 PM, Martin Buchholz wrote: > The problem is again that the library maintainer is not the same as > the compiler invoker. > A conscientious library maintainer does not stop at ensuring that > their own builds are warning free; they want to ensure as much as they > can that their users can also do $compiler -Xlint:all -Werror, even > with future javac releases and other folks' toolchains. Of course, > this is an impossible task; compilers add warnings all the time. But > still one tries! > > JDK maintainers have the rare luxury of targeting only one release at a time. OK, thanks for clarifying this. I hadn't quite followed your exchange with Peter Levart on this topic. It looks to me like there are three general scenarios for handling different target versions: 1) Library sources built, targeted to JDK N (either by building on JDK N, or using -source/-target/-release); binaries run on JRE N .. JRE N+k. 2) Library sources maintained to be buildable on JDK N .. JDK N+k. This is what you do. 3) Library sources maintained to be buildable on JDK N .. JDK N+k plus other non-JDK toolchains. You might be doing this too. I'm aware of several non-JDK toolchains. I mention (3) for completeness. I'm not sure what more there is to say about this, other than that it exists. If anyone has any thoughts, please contribute. The main thing that's new to me is that you, and possibly others, are using (2). I'd be interested in how frequently (2) is used. My hunch is that most people use (1), but actually, that's something of a digression. Anyway, let's get back to the main topic of this segment of the thread, which is the cost of deprecating something. If something you're using is deprecated in JDK N, then you can't migrate away from it until JDK N-1 and all earlier releases are no longer supported by your library. That could take years. Thus you have to use @SuppressWarnings to deal with the warnings. So what's the driver of the cost? I'm thinking it's not the length of time that @SW has to be in your source base. The @SW for deprecated usages will have to stick around for the same length of time no matter what API is being deprecated. Is it instead the frequency of usage? So, for example, if there's one usage of something obscure that gets deprecated, it gets one @SW annotation. If that sticks around for ten years, no big deal. On the other hand, if something that's used much more frequently were to be deprecated, then you'd have to sprinkle @SW around in perhaps hundreds of places in the source base, and they'd have to stay in there for years. I'm guessing that would have a much higher cost. Not only the work of putting in a bunch of @SW, but the decreased readability and maintainability caused by having @SW clutter up the code. But again, I'm starting to guess a bit here. Is the cost imposed by deprecation based on the *principle* of not wanting to use APIs deprecated in a new JDK, even when compiling for an old JDK? Or is the cost imposed by the maintenance of having @SW all over the code, in order to control the warnings? If the latter, then it would seem to me that more effective ways of controlling warnings would reduce your costs. I have some ideas about this but I don't want to start exploring them until it's clear that they would actually help. s'marks From peter.levart at gmail.com Fri May 13 07:10:32 2016 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 13 May 2016 09:10:32 +0200 Subject: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival In-Reply-To: <57351808.3040207@oracle.com> References: <55479A4F.4060806@oracle.com> <5550FE5A.4070607@oracle.com> <55513EA7.1050700@oracle.com> <555192A4.3080305@gmail.com> <5551A0AA.6050800@gmail.com> <5552674E.4030009@oracle.com> <55526FF5.9000509@gmail.com> <55564473.3010704@oracle.com> <8DD50D66-D2C1-43E4-B7C5-992FE785958B@oracle.com> <57325921.9090100@oracle.com> <0B7583E3-56D0-423C-9F74-45C05B632C98@oracle.com> <5734F93C.10201@oracle.com> <859C354C-FCFD-430E-9869-2364623E29D6@oracle.com> <57351808.3040207@oracle.com> Message-ID: <16da3ca8-5a9a-9981-2823-aa02a45f400c@gmail.com> Hi Brent, This looks good. It might also be a good idea to add a test that checks this new implementation detail (the unsynchronized get) that new code will become dependent upon, for example: /* * @test * @bug 8029891 * @summary Test that the Properties.get() method does not synchronize any more * @run main CheckUnsynchronizedGet */ public class CheckUnsynchronizedGet { public static void main(String[] args) { Properties props = new Properties(); synchronized (props) { props.setProperty("key", "value"); String value = CompletableFuture.supplyAsync(() -> props.getProperty("key")).join(); assert "value".equals(value); } } } What do you think? Regards, Peter On 05/13/2016 01:55 AM, Brent Christian wrote: > Update to the test, and additional comments: > > http://cr.openjdk.java.net/~bchristi/8029891/webrev.5/webrev/ > > Thanks, > -Brent > > On 5/12/16 4:15 PM, Mandy Chung wrote: >> >>> On May 12, 2016, at 2:44 PM, Brent Christian >>> wrote: >>> >>> On 5/12/16 11:44 AM, Mandy Chung wrote: >>>> >>>> This patch looks good. >>>> >>>> To help future readers to understand this, it may be better to move: >>>> 1152 private transient ConcurrentHashMap map = >>>> 1153 new ConcurrentHashMap<>(8); >>>> >>>> to the beginning and add a comment describing what are lock-free >>>> and what are synchronized (basically some part of your summary below). >>>> >>>> Also a comment in Hashtable::defaultWriteHashtable and >>>> readHashtable methods to mention that they are overridden by >>>> Properties. >>> >>> Good ideas. >>> >>>> In the GetResource.java test, what is the reason taking out: >>>> 73 URL u2 = >>>> Thread.currentThread().getContextClassLoader().getResource("sun/util/resources/CalendarData.class?); >>>> >>> >>> It was coming back null and failing the test, I think because >>> Jigsaw moved CalendarData into a different module (jdk.localedata, I >>> believe?). >> >> src/java.base/share/classes/sun/util/resources/CalendarData.properties >> is still in java.base. This is due to resource encapsulation. >> Unnamed module calling ClassLoader::getResource of a resource in a >> named module returns null. >> >> >>> I fiddled with @modules a bit, but stopped when I discovered that >>> when the test deadlocks, it hangs on the first call to getResource() >>> and doesn't get to this line. >>> >>> I can look into getting it to load CalendarData again, if you like. >> >> The launcher and builtin class loader implementation has changed so >> much that the code path exercised JDK-6977738 no longer exists. I >> think dropping line 73 is okay. >> >> Mandy >> From shilpi.rastogi at oracle.com Fri May 13 07:13:59 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Fri, 13 May 2016 12:43:59 +0530 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <5c0c4872-8729-182b-9736-62a35b9e7dcf@oracle.com> References: <57331659.1030008@oracle.com> <8918541F-29FD-4AFD-AE9A-4B3F1CF32C4E@oracle.com> <57335E74.3090204@oracle.com> <07F81381-B038-47B2-BE70-76D3769598A5@oracle.com> <573470EE.5080105@oracle.com> <5c0c4872-8729-182b-9736-62a35b9e7dcf@oracle.com> Message-ID: <57357EB7.3060700@oracle.com> Thank you Vladimir for comments. Please review updated webrev http://cr.openjdk.java.net/~srastogi/8149574/webrev.09/ Regards, Shilpi On 5/12/2016 6:12 PM, Vladimir Ivanov wrote: > rankly speaking, I'd prefer [2] to be co From forax at univ-mlv.fr Fri May 13 08:36:43 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 13 May 2016 10:36:43 +0200 (CEST) Subject: MethodHandle for array length In-Reply-To: <01d301d1ac4a$a65264b0$f2f72e10$@apache.org> References: <00a601d1abbc$4a907ec0$dfb17c40$@apache.org> <3FD85BA6-799F-465F-8B33-BD75635D33AE@oracle.com> <01d301d1ac4a$a65264b0$f2f72e10$@apache.org> Message-ID: <1843689259.97223.1463128603038.JavaMail.zimbra@u-pem.fr> Hi Uwe, I was planning to add a bug for this feature but it seems that Michael was faster than me, https://bugs.openjdk.java.net/browse/JDK-8156915 regards, R?mi ----- Mail original ----- > De: "Uwe Schindler" > ?: "Michael Haupt" , "Core-Libs-Dev" > Envoy?: Jeudi 12 Mai 2016 14:34:34 > Objet: RE: MethodHandle for array length > > Hi Michael, > > > > Am 11.05.2016 um 21:35 schrieb Uwe Schindler : > > > With Java 9 this gets a bit worse: There is no "easy way" with the > > MethodHanldes class to generate a MethodHandles.countedLoop() on all > > elements of an array: > > > > > > public static MethodHandle countedLoop(MethodHandle iterations, > > MethodHandle init, MethodHandle body) [new in Java 9] > > > > this isn't a remedy when you need the index in each iteration, but you can > > generate a loop over all elements of an array using iteratedLoop(), as > > illustrated by this test from LoopCombinatorTest: > > > > @Test > > public static void testIterateSum() throws Throwable { > > // Integer[] a = new Integer[]{1,2,3,4,5,6}; int sum = 0; for (int e : > > a) { sum > > += e; } return sum; => 21 > > MethodHandle loop = > > MethodHandles.iteratedLoop(Iterate.MH_sumIterator, Iterate.MH_sumInit, > > Iterate.MH_sumStep); > > assertEquals(Iterate.MT_sum, loop.type()); > > assertEquals(21, loop.invoke(new Integer[]{1, 2, 3, 4, 5, 6})); > > } > > > > ... where MH_sumIterator is a handle to this method: > > > > static Iterator sumIterator(Integer[] a) { > > return Arrays.asList(a).iterator(); > > } > > Of course this works, too. > > My proposal or question here was more about the API inconsistency in general. > You can do a lot here and there, you can implement effective or > non-effective loops with MethodHandles, but still the following holds true: > java.lang.invoke.MethodHandles is missing an accessor for "array.length", > which is not understandable. The "countedLoop" here was just an example use > case (if that one is great or not does not matter), it was just posted to > actually show the API and how it *could* be used. > > The real example from our script engine was not related to loops, it was an > actual invokedynamic callsite implementation where it was not possible to > figure out how to get a method handle to the very special arraylength byte > code, aka "array.length javac sugar". Everything else to handle arrays is > there at one single place, but the array length is missing and you get very > annoyed. If you are not so familiar to bytecode and the mechanics behind, > you have a very hard time to find out how to do this: the intuitive > solutions does not work: "array.length" -> aha it?s a field, so let's try > Lookup.findGetter(long[].class, "length", int.class) -> does not work! > > What is so hard to accept the proposal to have > MethodHandles.arrayLengthGetter, implemented in the most effective way (as a > methodhandle that solely calls the special bytecode "arraylength")? In fact > thais is like a 10 liner to implement + Javadocs. No need to delay a > release, there are still changes in JDK 9 going on that are far more risky > than this. > > Best, > Uwe > > > Best, > > > > Michael > > > > -- > > > > > > Dr. Michael Haupt | Principal Member of Technical Staff > > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > > Oracle Java Platform Group | LangTools Team | Nashorn > > Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, > > Germany > > > > ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D- > > 80992 M?nchen > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering > > 163/167, 3543 AS Utrecht, Niederlande > > Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 > > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to > > developing practices and products that help protect the environment > > From paul.sandoz at oracle.com Fri May 13 08:39:10 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 13 May 2016 10:39:10 +0200 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <57357EB7.3060700@oracle.com> References: <57331659.1030008@oracle.com> <8918541F-29FD-4AFD-AE9A-4B3F1CF32C4E@oracle.com> <57335E74.3090204@oracle.com> <07F81381-B038-47B2-BE70-76D3769598A5@oracle.com> <573470EE.5080105@oracle.com> <5c0c4872-8729-182b-9736-62a35b9e7dcf@oracle.com> <57357EB7.3060700@oracle.com> Message-ID: <6FDBC724-2E4C-4D9E-96C1-67674EE6CD95@oracle.com> > On 13 May 2016, at 09:13, shilpi.rastogi at oracle.com wrote: > > Thank you Vladimir for comments. > > Please review updated webrev http://cr.openjdk.java.net/~srastogi/8149574/webrev.09/ > Just one minor comment (last one i promise!): 1140 MethodHandle vamh = prepareForInvoker(MH_checkCallerClass); 1141 Object ok = bccInvoker.invokeExact(vamh, new Object[]{hostClass, bcc}); 1142 assert((boolean)ok); If you wanna keep that assert I think it would be better to state: assert Boolean.TRUE.equals(ok) : ok; since the cast could theoretically result in an NPE rather than an AE. Paul. From shilpi.rastogi at oracle.com Fri May 13 08:56:39 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Fri, 13 May 2016 14:26:39 +0530 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <6FDBC724-2E4C-4D9E-96C1-67674EE6CD95@oracle.com> References: <57331659.1030008@oracle.com> <8918541F-29FD-4AFD-AE9A-4B3F1CF32C4E@oracle.com> <57335E74.3090204@oracle.com> <07F81381-B038-47B2-BE70-76D3769598A5@oracle.com> <573470EE.5080105@oracle.com> <5c0c4872-8729-182b-9736-62a35b9e7dcf@oracle.com> <57357EB7.3060700@oracle.com> <6FDBC724-2E4C-4D9E-96C1-67674EE6CD95@oracle.com> Message-ID: <573596C7.7020107@oracle.com> Thanks Paul! Please review http://cr.openjdk.java.net/~srastogi/8149574/webrev10.0/ Regards, Shilpi On 5/13/2016 2:09 PM, Paul Sandoz wrote: > assert Boolean.TRUE.equals(ok) : ok; From paul.sandoz at oracle.com Fri May 13 09:00:23 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 13 May 2016 11:00:23 +0200 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <573596C7.7020107@oracle.com> References: <57331659.1030008@oracle.com> <8918541F-29FD-4AFD-AE9A-4B3F1CF32C4E@oracle.com> <57335E74.3090204@oracle.com> <07F81381-B038-47B2-BE70-76D3769598A5@oracle.com> <573470EE.5080105@oracle.com> <5c0c4872-8729-182b-9736-62a35b9e7dcf@oracle.com> <57357EB7.3060700@oracle.com> <6FDBC724-2E4C-4D9E-96C1-67674EE6CD95@oracle.com> <573596C7.7020107@oracle.com> Message-ID: <379D0FA1-9553-4251-B872-C50B43C173F4@oracle.com> > On 13 May 2016, at 10:56, shilpi.rastogi at oracle.com wrote: > > Thanks Paul! > > Please review http://cr.openjdk.java.net/~srastogi/8149574/webrev10.0/ > +1 Paul. From uschindler at apache.org Fri May 13 09:54:41 2016 From: uschindler at apache.org (Uwe Schindler) Date: Fri, 13 May 2016 11:54:41 +0200 Subject: MethodHandle for array length In-Reply-To: <1843689259.97223.1463128603038.JavaMail.zimbra@u-pem.fr> References: <00a601d1abbc$4a907ec0$dfb17c40$@apache.org> <3FD85BA6-799F-465F-8B33-BD75635D33AE@oracle.com> <01d301d1ac4a$a65264b0$f2f72e10$@apache.org> <1843689259.97223.1463128603038.JavaMail.zimbra@u-pem.fr> Message-ID: <036d01d1acfd$7b0a48f0$711edad0$@apache.org> Hi, OK, thanks for creating an issue! Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Remi Forax [mailto:forax at univ-mlv.fr] > Sent: Friday, May 13, 2016 10:37 AM > To: Uwe Schindler > Cc: Michael Haupt ; Core-Libs-Dev dev at openjdk.java.net> > Subject: Re: MethodHandle for array length > > Hi Uwe, > I was planning to add a bug for this feature but it seems that Michael was > faster than me, > https://bugs.openjdk.java.net/browse/JDK-8156915 > > regards, > R?mi > > ----- Mail original ----- > > De: "Uwe Schindler" > > ?: "Michael Haupt" , "Core-Libs-Dev" libs-dev at openjdk.java.net> > > Envoy?: Jeudi 12 Mai 2016 14:34:34 > > Objet: RE: MethodHandle for array length > > > > Hi Michael, > > > > > > Am 11.05.2016 um 21:35 schrieb Uwe Schindler > : > > > > With Java 9 this gets a bit worse: There is no "easy way" with the > > > MethodHanldes class to generate a MethodHandles.countedLoop() on all > > > elements of an array: > > > > > > > > public static MethodHandle countedLoop(MethodHandle iterations, > > > MethodHandle init, MethodHandle body) [new in Java 9] > > > > > > this isn't a remedy when you need the index in each iteration, but you > can > > > generate a loop over all elements of an array using iteratedLoop(), as > > > illustrated by this test from LoopCombinatorTest: > > > > > > @Test > > > public static void testIterateSum() throws Throwable { > > > // Integer[] a = new Integer[]{1,2,3,4,5,6}; int sum = 0; for (int e : > > > a) { sum > > > += e; } return sum; => 21 > > > MethodHandle loop = > > > MethodHandles.iteratedLoop(Iterate.MH_sumIterator, > Iterate.MH_sumInit, > > > Iterate.MH_sumStep); > > > assertEquals(Iterate.MT_sum, loop.type()); > > > assertEquals(21, loop.invoke(new Integer[]{1, 2, 3, 4, 5, 6})); > > > } > > > > > > ... where MH_sumIterator is a handle to this method: > > > > > > static Iterator sumIterator(Integer[] a) { > > > return Arrays.asList(a).iterator(); > > > } > > > > Of course this works, too. > > > > My proposal or question here was more about the API inconsistency in > general. > > You can do a lot here and there, you can implement effective or > > non-effective loops with MethodHandles, but still the following holds true: > > java.lang.invoke.MethodHandles is missing an accessor for "array.length", > > which is not understandable. The "countedLoop" here was just an example > use > > case (if that one is great or not does not matter), it was just posted to > > actually show the API and how it *could* be used. > > > > The real example from our script engine was not related to loops, it was an > > actual invokedynamic callsite implementation where it was not possible to > > figure out how to get a method handle to the very special arraylength byte > > code, aka "array.length javac sugar". Everything else to handle arrays is > > there at one single place, but the array length is missing and you get very > > annoyed. If you are not so familiar to bytecode and the mechanics behind, > > you have a very hard time to find out how to do this: the intuitive > > solutions does not work: "array.length" -> aha it?s a field, so let's try > > Lookup.findGetter(long[].class, "length", int.class) -> does not work! > > > > What is so hard to accept the proposal to have > > MethodHandles.arrayLengthGetter, implemented in the most effective > way (as a > > methodhandle that solely calls the special bytecode "arraylength")? In fact > > thais is like a 10 liner to implement + Javadocs. No need to delay a > > release, there are still changes in JDK 9 going on that are far more risky > > than this. > > > > Best, > > Uwe > > > > > Best, > > > > > > Michael > > > > > > -- > > > > > > > > > Dr. Michael Haupt | Principal Member of Technical Staff > > > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > > > Oracle Java Platform Group | LangTools Team | Nashorn > > > Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, > > > Germany > > > > > > ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D- > > > 80992 M?nchen > > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. | > Hertogswetering > > > 163/167, 3543 AS Utrecht, Niederlande > > > Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 > > > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > > Oracle is committed to > > > developing practices and products that help protect the environment > > > > From uschindler at apache.org Fri May 13 10:14:55 2016 From: uschindler at apache.org (Uwe Schindler) Date: Fri, 13 May 2016 12:14:55 +0200 Subject: MethodHandle for array length References: <00a601d1abbc$4a907ec0$dfb17c40$@apache.org> <3FD85BA6-799F-465F-8B33-BD75635D33AE@oracle.com> <01d301d1ac4a$a65264b0$f2f72e10$@apache.org> <1843689259.97223.1463128603038.JavaMail.zimbra@u-pem.fr> Message-ID: <037401d1ad00$4f275cc0$ed761640$@apache.org> Hi, One addition, maybe add to issue: If this was added, jdk.dynalink module could use it, too - this was mentioned by Attila already: http://hg.openjdk.java.net/jdk9/dev/nashorn/file/4b118e012ac4/src/jdk.dynalink/share/classes/jdk/dynalink/beans/BeanLinker.java Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Uwe Schindler [mailto:uschindler at apache.org] > Sent: Friday, May 13, 2016 11:55 AM > To: 'Remi Forax' > Cc: 'Michael Haupt' ; 'Core-Libs-Dev' dev at openjdk.java.net> > Subject: RE: MethodHandle for array length > > Hi, > > OK, thanks for creating an issue! > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > > > -----Original Message----- > > From: Remi Forax [mailto:forax at univ-mlv.fr] > > Sent: Friday, May 13, 2016 10:37 AM > > To: Uwe Schindler > > Cc: Michael Haupt ; Core-Libs-Dev > dev at openjdk.java.net> > > Subject: Re: MethodHandle for array length > > > > Hi Uwe, > > I was planning to add a bug for this feature but it seems that Michael was > > faster than me, > > https://bugs.openjdk.java.net/browse/JDK-8156915 > > > > regards, > > R?mi > > > > ----- Mail original ----- > > > De: "Uwe Schindler" > > > ?: "Michael Haupt" , "Core-Libs-Dev" > > libs-dev at openjdk.java.net> > > > Envoy?: Jeudi 12 Mai 2016 14:34:34 > > > Objet: RE: MethodHandle for array length > > > > > > Hi Michael, > > > > > > > > Am 11.05.2016 um 21:35 schrieb Uwe Schindler > > : > > > > > With Java 9 this gets a bit worse: There is no "easy way" with the > > > > MethodHanldes class to generate a MethodHandles.countedLoop() on > all > > > > elements of an array: > > > > > > > > > > public static MethodHandle countedLoop(MethodHandle iterations, > > > > MethodHandle init, MethodHandle body) [new in Java 9] > > > > > > > > this isn't a remedy when you need the index in each iteration, but you > > can > > > > generate a loop over all elements of an array using iteratedLoop(), as > > > > illustrated by this test from LoopCombinatorTest: > > > > > > > > @Test > > > > public static void testIterateSum() throws Throwable { > > > > // Integer[] a = new Integer[]{1,2,3,4,5,6}; int sum = 0; for (int e : > > > > a) { sum > > > > += e; } return sum; => 21 > > > > MethodHandle loop = > > > > MethodHandles.iteratedLoop(Iterate.MH_sumIterator, > > Iterate.MH_sumInit, > > > > Iterate.MH_sumStep); > > > > assertEquals(Iterate.MT_sum, loop.type()); > > > > assertEquals(21, loop.invoke(new Integer[]{1, 2, 3, 4, 5, 6})); > > > > } > > > > > > > > ... where MH_sumIterator is a handle to this method: > > > > > > > > static Iterator sumIterator(Integer[] a) { > > > > return Arrays.asList(a).iterator(); > > > > } > > > > > > Of course this works, too. > > > > > > My proposal or question here was more about the API inconsistency in > > general. > > > You can do a lot here and there, you can implement effective or > > > non-effective loops with MethodHandles, but still the following holds > true: > > > java.lang.invoke.MethodHandles is missing an accessor for > "array.length", > > > which is not understandable. The "countedLoop" here was just an > example > > use > > > case (if that one is great or not does not matter), it was just posted to > > > actually show the API and how it *could* be used. > > > > > > The real example from our script engine was not related to loops, it was > an > > > actual invokedynamic callsite implementation where it was not possible > to > > > figure out how to get a method handle to the very special arraylength > byte > > > code, aka "array.length javac sugar". Everything else to handle arrays is > > > there at one single place, but the array length is missing and you get very > > > annoyed. If you are not so familiar to bytecode and the mechanics > behind, > > > you have a very hard time to find out how to do this: the intuitive > > > solutions does not work: "array.length" -> aha it?s a field, so let's try > > > Lookup.findGetter(long[].class, "length", int.class) -> does not work! > > > > > > What is so hard to accept the proposal to have > > > MethodHandles.arrayLengthGetter, implemented in the most effective > > way (as a > > > methodhandle that solely calls the special bytecode "arraylength")? In > fact > > > thais is like a 10 liner to implement + Javadocs. No need to delay a > > > release, there are still changes in JDK 9 going on that are far more risky > > > than this. > > > > > > Best, > > > Uwe > > > > > > > Best, > > > > > > > > Michael > > > > > > > > -- > > > > > > > > > > > > Dr. Michael Haupt | Principal Member of Technical Staff > > > > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > > > > Oracle Java Platform Group | LangTools Team | Nashorn > > > > Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 > Potsdam, > > > > Germany > > > > > > > > ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, > D- > > > > 80992 M?nchen > > > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. | > > Hertogswetering > > > > 163/167, 3543 AS Utrecht, Niederlande > > > > Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 > > > > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > > > Oracle is committed to > > > > developing practices and products that help protect the environment > > > > > > From Alan.Bateman at oracle.com Fri May 13 10:27:55 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 May 2016 11:27:55 +0100 Subject: RFR: 8147588: Jar file and Zip file not removed in spite of the OPEN_DELETE flag In-Reply-To: <5734D670.3080004@oracle.com> References: <5734D670.3080004@oracle.com> Message-ID: <5735AC2B.3010808@oracle.com> On 12/05/2016 20:16, Xueming Shen wrote: > Hi, > > Please help review the proposed change for #8147588 > > issue: https://bugs.openjdk.java.net/browse/JDK-8147588 > webrev: http://cr.openjdk.java.net/~sherman/8147588/webrev > > This is a regression on Windows platform triggered by the change for > https://bugs.openjdk.java.net/browse/JDK-8145260, in which we brought > the ZipFile native natively code to java for better performance (both > memory and access). > > As showed the from ln#107-114 at webrev below > http://cr.openjdk.java.net/~sherman/8145260/webrev.push/src/java.base/share/native/libzip/ZipFile.c-.html > > > The original native implementation uses a special "Windows-only" > option O_TEMPORARY to open the zip/jar file on Windows to support > this OPEN_DELETE functionality. > > There is no corresponding public open/delete functionality at java.io > API right now. The proposed the change here is to add a private > constructor for RandomAccessFile and access from ZipFile via > SharedSecrets. This O_TEMPORARY is only supported on Windows > platform. I assume O_TEMPORARY maps to Windows FILE_FLAG_DELETE_ON_CLOSE flag. In the new file system API then this gets exposed as the DELETE_ON_CLOSE open option but it isn't exposed via RAF. I assume it would be too much of a change to move ZipFile, particularly with behavior changes related to interruption. I've looked through the patch but I just wondering if there are cleaner alternatives. What would you think about not pushing O_TEMPORARY to RAF but instead have ZipFile open the zip file with ZFILE_Open, wrap it with a FileDescriptor and then create a RAF to that FileDescriptor. I realize RAF doesn't have a public constructor for this so it needs plumbing but the nice this is that it keeps this specific mode issue out of RAF. -Alan From peter.levart at gmail.com Fri May 13 10:54:55 2016 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 13 May 2016 12:54:55 +0200 Subject: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival In-Reply-To: <57351808.3040207@oracle.com> References: <55479A4F.4060806@oracle.com> <5550FE5A.4070607@oracle.com> <55513EA7.1050700@oracle.com> <555192A4.3080305@gmail.com> <5551A0AA.6050800@gmail.com> <5552674E.4030009@oracle.com> <55526FF5.9000509@gmail.com> <55564473.3010704@oracle.com> <8DD50D66-D2C1-43E4-B7C5-992FE785958B@oracle.com> <57325921.9090100@oracle.com> <0B7583E3-56D0-423C-9F74-45C05B632C98@oracle.com> <5734F93C.10201@oracle.com> <859C354C-FCFD-430E-9869-2364623E29D6@oracle.com> <57351808.3040207@oracle.com> Message-ID: <59fa5f78-aa55-2252-cff8-befd3dea997a@gmail.com> Note that there is a possible initialization circularity introduced by this patch, which I think is harmless because: - ThreadLocalRandom has just recently been enhanced to cope with such situations - CHM needs ThreadLocalRandom in put() for example, when new entry is being inserted, TLR invokes Boolean.getBoolean("java.util.secureRandomSeed") as the last thing in its static initializer but still works correctly even before this last part of initializer is finished). - When an invocation of Boolean.getBoolean ends up in the same Properties instance (the System.getProperties()) it might be asking for an entry in the same CHM instance (CHM.get()) which is just being modified by put(). This amounts to re-entrance of CHM instance, but is harmless as Boolean.getBoolean is only possibly invoked as the last thing of various CHM modifications methods when the CHM state is already consistent (see addCount() invocations in CHM). Regards, Peter On 05/13/2016 01:55 AM, Brent Christian wrote: > Update to the test, and additional comments: > > http://cr.openjdk.java.net/~bchristi/8029891/webrev.5/webrev/ > > Thanks, > -Brent > > On 5/12/16 4:15 PM, Mandy Chung wrote: >> >>> On May 12, 2016, at 2:44 PM, Brent Christian >>> wrote: >>> >>> On 5/12/16 11:44 AM, Mandy Chung wrote: >>>> >>>> This patch looks good. >>>> >>>> To help future readers to understand this, it may be better to move: >>>> 1152 private transient ConcurrentHashMap map = >>>> 1153 new ConcurrentHashMap<>(8); >>>> >>>> to the beginning and add a comment describing what are lock-free >>>> and what are synchronized (basically some part of your summary below). >>>> >>>> Also a comment in Hashtable::defaultWriteHashtable and >>>> readHashtable methods to mention that they are overridden by >>>> Properties. >>> >>> Good ideas. >>> >>>> In the GetResource.java test, what is the reason taking out: >>>> 73 URL u2 = >>>> Thread.currentThread().getContextClassLoader().getResource("sun/util/resources/CalendarData.class?); >>>> >>> >>> It was coming back null and failing the test, I think because >>> Jigsaw moved CalendarData into a different module (jdk.localedata, I >>> believe?). >> >> src/java.base/share/classes/sun/util/resources/CalendarData.properties >> is still in java.base. This is due to resource encapsulation. >> Unnamed module calling ClassLoader::getResource of a resource in a >> named module returns null. >> >> >>> I fiddled with @modules a bit, but stopped when I discovered that >>> when the test deadlocks, it hangs on the first call to getResource() >>> and doesn't get to this line. >>> >>> I can look into getting it to load CalendarData again, if you like. >> >> The launcher and builtin class loader implementation has changed so >> much that the code path exercised JDK-6977738 no longer exists. I >> think dropping line 73 is okay. >> >> Mandy >> From vladimir.x.ivanov at oracle.com Fri May 13 13:41:33 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 13 May 2016 16:41:33 +0300 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <573596C7.7020107@oracle.com> References: <57331659.1030008@oracle.com> <8918541F-29FD-4AFD-AE9A-4B3F1CF32C4E@oracle.com> <57335E74.3090204@oracle.com> <07F81381-B038-47B2-BE70-76D3769598A5@oracle.com> <573470EE.5080105@oracle.com> <5c0c4872-8729-182b-9736-62a35b9e7dcf@oracle.com> <57357EB7.3060700@oracle.com> <6FDBC724-2E4C-4D9E-96C1-67674EE6CD95@oracle.com> <573596C7.7020107@oracle.com> Message-ID: <09f076bd-eebb-f2a3-5483-a1a695e51ab2@oracle.com> MethodHandle vamh = prepareForInvoker(MH_checkCallerClass); Object ok = bccInvoker.invokeExact(vamh, new Object[]{hostClass, bcc}); + assert Boolean.TRUE.equals(ok) : ok; What I meant is to convert the whole test (inside try-catch block) into an assert. + UNSAFE.ensureClassInitialized(bcc); Do people see any reason to force invoker class init? I'd prefer to see it goes away. Also, as a second thought, generateInvokerTemplate() looks clearer than invokerTemplateGenerator(). Something like the following: http://cr.openjdk.java.net/~vlivanov/8149574/webrev.00/ Additional cleanup: checkCallerClass() should return injected invoker class when invoked using a method handle, so no need in 2nd argument. Best regards, Vladimir Ivanov On 5/13/16 11:56 AM, shilpi.rastogi at oracle.com wrote: > Thanks Paul! > > Please review http://cr.openjdk.java.net/~srastogi/8149574/webrev10.0/ > > Regards, > Shilpi > > On 5/13/2016 2:09 PM, Paul Sandoz wrote: >> assert Boolean.TRUE.equals(ok) : ok; > From forax at univ-mlv.fr Fri May 13 13:51:01 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 13 May 2016 15:51:01 +0200 (CEST) Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <09f076bd-eebb-f2a3-5483-a1a695e51ab2@oracle.com> References: <57331659.1030008@oracle.com> <07F81381-B038-47B2-BE70-76D3769598A5@oracle.com> <573470EE.5080105@oracle.com> <5c0c4872-8729-182b-9736-62a35b9e7dcf@oracle.com> <57357EB7.3060700@oracle.com> <6FDBC724-2E4C-4D9E-96C1-67674EE6CD95@oracle.com> <573596C7.7020107@oracle.com> <09f076bd-eebb-f2a3-5483-a1a695e51ab2@oracle.com> Message-ID: <9372690.370218.1463147461441.JavaMail.zimbra@u-pem.fr> Also instead of MethodVisitor mv = cw.visitMethod(ACC_PRIVATE | ACC_STATIC, "invoke_V", "(Ljava/lang/invoke/MethodHandle;[Ljava/lang/Object;)Ljava/lang/Object;", null, new String[] { "java/lang/Throwable" }); because the code is never read by a java compiler (as javac), you don't need to specify the exception (checked exceptions are a Java the language artifact) MethodVisitor mv = cw.visitMethod(ACC_PRIVATE | ACC_STATIC, "invoke_V", "(Ljava/lang/invoke/MethodHandle;[Ljava/lang/Object;)Ljava/lang/Object;", null, null); my 2 cents, R?mi ----- Mail original ----- > De: "Vladimir Ivanov" > ?: "shilpi rastogi" > Cc: core-libs-dev at openjdk.java.net > Envoy?: Vendredi 13 Mai 2016 15:41:33 > Objet: Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() > > MethodHandle vamh = prepareForInvoker(MH_checkCallerClass); > Object ok = bccInvoker.invokeExact(vamh, new Object[]{hostClass, bcc}); > + assert Boolean.TRUE.equals(ok) : ok; > > What I meant is to convert the whole test (inside try-catch block) into > an assert. > > > + UNSAFE.ensureClassInitialized(bcc); > > Do people see any reason to force invoker class init? I'd prefer to see > it goes away. > > Also, as a second thought, generateInvokerTemplate() looks clearer than > invokerTemplateGenerator(). > > Something like the following: > http://cr.openjdk.java.net/~vlivanov/8149574/webrev.00/ > > Additional cleanup: checkCallerClass() should return injected invoker > class when invoked using a method handle, so no need in 2nd argument. > > Best regards, > Vladimir Ivanov > > On 5/13/16 11:56 AM, shilpi.rastogi at oracle.com wrote: > > Thanks Paul! > > > > Please review http://cr.openjdk.java.net/~srastogi/8149574/webrev10.0/ > > > > Regards, > > Shilpi > > > > On 5/13/2016 2:09 PM, Paul Sandoz wrote: > >> assert Boolean.TRUE.equals(ok) : ok; > > > From vladimir.x.ivanov at oracle.com Fri May 13 14:01:24 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 13 May 2016 17:01:24 +0300 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <9372690.370218.1463147461441.JavaMail.zimbra@u-pem.fr> References: <57331659.1030008@oracle.com> <07F81381-B038-47B2-BE70-76D3769598A5@oracle.com> <573470EE.5080105@oracle.com> <5c0c4872-8729-182b-9736-62a35b9e7dcf@oracle.com> <57357EB7.3060700@oracle.com> <6FDBC724-2E4C-4D9E-96C1-67674EE6CD95@oracle.com> <573596C7.7020107@oracle.com> <09f076bd-eebb-f2a3-5483-a1a695e51ab2@oracle.com> <9372690.370218.1463147461441.JavaMail.zimbra@u-pem.fr> Message-ID: Good point, Remi. I agree that it's redundant. Best regards, Vladimir Ivanov On 5/13/16 4:51 PM, Remi Forax wrote: > Also instead of > MethodVisitor mv = cw.visitMethod(ACC_PRIVATE | ACC_STATIC, "invoke_V", > "(Ljava/lang/invoke/MethodHandle;[Ljava/lang/Object;)Ljava/lang/Object;", > null, new String[] { "java/lang/Throwable" }); > > because the code is never read by a java compiler (as javac), you don't need to specify the exception > (checked exceptions are a Java the language artifact) > MethodVisitor mv = cw.visitMethod(ACC_PRIVATE | ACC_STATIC, "invoke_V", > "(Ljava/lang/invoke/MethodHandle;[Ljava/lang/Object;)Ljava/lang/Object;", > null, null); > > my 2 cents, > R?mi > > ----- Mail original ----- >> De: "Vladimir Ivanov" >> ?: "shilpi rastogi" >> Cc: core-libs-dev at openjdk.java.net >> Envoy?: Vendredi 13 Mai 2016 15:41:33 >> Objet: Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() >> >> MethodHandle vamh = prepareForInvoker(MH_checkCallerClass); >> Object ok = bccInvoker.invokeExact(vamh, new Object[]{hostClass, bcc}); >> + assert Boolean.TRUE.equals(ok) : ok; >> >> What I meant is to convert the whole test (inside try-catch block) into >> an assert. >> >> >> + UNSAFE.ensureClassInitialized(bcc); >> >> Do people see any reason to force invoker class init? I'd prefer to see >> it goes away. >> >> Also, as a second thought, generateInvokerTemplate() looks clearer than >> invokerTemplateGenerator(). >> >> Something like the following: >> http://cr.openjdk.java.net/~vlivanov/8149574/webrev.00/ >> >> Additional cleanup: checkCallerClass() should return injected invoker >> class when invoked using a method handle, so no need in 2nd argument. >> >> Best regards, >> Vladimir Ivanov >> >> On 5/13/16 11:56 AM, shilpi.rastogi at oracle.com wrote: >>> Thanks Paul! >>> >>> Please review http://cr.openjdk.java.net/~srastogi/8149574/webrev10.0/ >>> >>> Regards, >>> Shilpi >>> >>> On 5/13/2016 2:09 PM, Paul Sandoz wrote: >>>> assert Boolean.TRUE.equals(ok) : ok; >>> >> From mandy.chung at oracle.com Fri May 13 14:55:17 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 13 May 2016 07:55:17 -0700 Subject: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival In-Reply-To: <16da3ca8-5a9a-9981-2823-aa02a45f400c@gmail.com> References: <55479A4F.4060806@oracle.com> <5550FE5A.4070607@oracle.com> <55513EA7.1050700@oracle.com> <555192A4.3080305@gmail.com> <5551A0AA.6050800@gmail.com> <5552674E.4030009@oracle.com> <55526FF5.9000509@gmail.com> <55564473.3010704@oracle.com> <8DD50D66-D2C1-43E4-B7C5-992FE785958B@oracle.com> <57325921.9090100@oracle.com> <0B7583E3-56D0-423C-9F74-45C05B632C98@oracle.com> <5734F93C.10201@oracle.com> <859C354C-FCFD-430E-9869-2364623E29D6@oracle.com> <57351808.3040207@oracle.com> <16da3ca8-5a9a-9981-2823-aa02a45f400c@gmail.com> Message-ID: Good idea. Mandy > On May 13, 2016, at 12:10 AM, Peter Levart wrote: > > Hi Brent, > > > This looks good. It might also be a good idea to add a test that checks this new implementation detail (the unsynchronized get) that new code will become dependent upon, for example: > > > /* > * @test > * @bug 8029891 > * @summary Test that the Properties.get() method does not synchronize any more > * @run main CheckUnsynchronizedGet > */ > public class CheckUnsynchronizedGet { > > public static void main(String[] args) { > Properties props = new Properties(); > synchronized (props) { > props.setProperty("key", "value"); > String value = > CompletableFuture.supplyAsync(() -> props.getProperty("key")).join(); > assert "value".equals(value); > } > } > } > > What do you think? > > Regards, Peter > > On 05/13/2016 01:55 AM, Brent Christian wrote: >> Update to the test, and additional comments: >> >> http://cr.openjdk.java.net/~bchristi/8029891/webrev.5/webrev/ >> >> Thanks, >> -Brent >> >> On 5/12/16 4:15 PM, Mandy Chung wrote: >>> >>>> On May 12, 2016, at 2:44 PM, Brent Christian wrote: >>>> >>>> On 5/12/16 11:44 AM, Mandy Chung wrote: >>>>> >>>>> This patch looks good. >>>>> >>>>> To help future readers to understand this, it may be better to move: >>>>> 1152 private transient ConcurrentHashMap map = >>>>> 1153 new ConcurrentHashMap<>(8); >>>>> >>>>> to the beginning and add a comment describing what are lock-free and what are synchronized (basically some part of your summary below). >>>>> >>>>> Also a comment in Hashtable::defaultWriteHashtable and readHashtable methods to mention that they are overridden by Properties. >>>> >>>> Good ideas. >>>> >>>>> In the GetResource.java test, what is the reason taking out: >>>>> 73 URL u2 = Thread.currentThread().getContextClassLoader().getResource("sun/util/resources/CalendarData.class?); >>>>> >>>> >>>> It was coming back null and failing the test, I think because >>>> Jigsaw moved CalendarData into a different module (jdk.localedata, I believe?). >>> >>> src/java.base/share/classes/sun/util/resources/CalendarData.properties is still in java.base. This is due to resource encapsulation. Unnamed module calling ClassLoader::getResource of a resource in a named module returns null. >>> >>> >>>> I fiddled with @modules a bit, but stopped when I discovered that when the test deadlocks, it hangs on the first call to getResource() and doesn't get to this line. >>>> >>>> I can look into getting it to load CalendarData again, if you like. >>> >>> The launcher and builtin class loader implementation has changed so much that the code path exercised JDK-6977738 no longer exists. I think dropping line 73 is okay. >>> >>> Mandy >>> > From mandy.chung at oracle.com Fri May 13 14:55:55 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 13 May 2016 07:55:55 -0700 Subject: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival In-Reply-To: <57351808.3040207@oracle.com> References: <55479A4F.4060806@oracle.com> <5550FE5A.4070607@oracle.com> <55513EA7.1050700@oracle.com> <555192A4.3080305@gmail.com> <5551A0AA.6050800@gmail.com> <5552674E.4030009@oracle.com> <55526FF5.9000509@gmail.com> <55564473.3010704@oracle.com> <8DD50D66-D2C1-43E4-B7C5-992FE785958B@oracle.com> <57325921.9090100@oracle.com> <0B7583E3-56D0-423C-9F74-45C05B632C98@oracle.com> <5734F93C.10201@oracle.com> <859C354C-FCFD-430E-9869-2364623E29D6@oracle.com> <57351808.3040207@oracle.com> Message-ID: <1D6DAE1C-FD55-4D99-B48E-5B2C6215B4B6@oracle.com> > On May 12, 2016, at 4:55 PM, Brent Christian wrote: > > Update to the test, and additional comments: > > http://cr.openjdk.java.net/~bchristi/8029891/webrev.5/webrev/ > +1 Mandy From mandy.chung at oracle.com Fri May 13 15:01:58 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 13 May 2016 08:01:58 -0700 Subject: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival In-Reply-To: References: <55479A4F.4060806@oracle.com> <5550FE5A.4070607@oracle.com> <55513EA7.1050700@oracle.com> <555192A4.3080305@gmail.com> <5551A0AA.6050800@gmail.com> <5552674E.4030009@oracle.com> <55526FF5.9000509@gmail.com> <55564473.3010704@oracle.com> <8DD50D66-D2C1-43E4-B7C5-992FE785958B@oracle.com> <57325921.9090100@oracle.com> <5734EF6C.5090603@oracle.com> Message-ID: > On May 12, 2016, at 5:58 PM, David Holmes wrote: >> >> With all of the inherited methods @hidden, it looks like that section >> is left out altogether. > > Okay, so I have to say @hidden seems to me to be seriously flawed! If a class has a method that can be called then IMHO that has to be documented in that class as either being first defined, overridden, or inherited - it can't just say nothing as-if the method were not there! > > If we are overriding in a trivial way that does not change the specification at all then there should be a simple way to show that - perhaps the "Methods inherited from ..." should be split into two parts: method implementations inherited from ..., and method specifications inherited from ... ?? > I agree for this case these methods should not be hidden as if it?s not there (that?s probably carried from the original @treatAsPrivate request). > I guess I need to raise this with the javadoc folk :( Is there a mailing list for that? Can you file a JBS issue? Kumar is on vacation and will talk with him when he?s back. Mandy From brian.burkhalter at oracle.com Fri May 13 17:42:31 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 13 May 2016 10:42:31 -0700 Subject: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds In-Reply-To: <500F8362-2DD6-4B29-A786-CD425E284C1D@oracle.com> References: <29a10b5a-9a23-f839-8cf7-71fd8cc0a86c@Oracle.com> <1F6EC53A-3913-48AC-81A9-4CC5B699DDB0@oracle.com> <2a520081-bd5a-360f-b04a-31c5e63b4596@Oracle.com> <08424057-6035-0a08-2150-2eaaa013f8e4@oracle.com> <04DA3578-E41F-41F7-84DC-B9BBB410281F@oracle.com> <05392e04-d971-1856-18b1-05cbca76fa20@Oracle.com> <8D563048-63B0-40EF-9736-CB1C43C9B5A5@oracle.com> <4106036f-3958-4b6c-503e-26ff9c13a035@Oracle.com> <500F8362-2DD6-4B29-A786-CD425E284C1D@oracle.com> Message-ID: Hello, I have a third version of the patch here: http://cr.openjdk.java.net/~bpb/8130679/webrev.00/ This one I believe addresses all the inconsistencies including the one in https://bugs.openjdk.java.net/browse/JDK-8029804 at the expense of a slight weakening of the specification of the Writer.write({char[],String},int,int) methods, and matches the behavior of all the classes affected. I have tested it and inspected the code extensively. Thanks, Brian On May 10, 2016, at 8:11 AM, Brian Burkhalter wrote: > On May 10, 2016, at 8:03 AM, Roger Riggs wrote: > >> Good catch, the javadoc needs to match the code and in this case the new language >> does not match the code. Some cases are harder to follow because they delegate >> to other classes for copying. > > I think I?ll drop BufferedWriter from this RFR and let Pavel handle it in 8029804. > >> It may also be the case that since Writer.write(char[], off, len) is abstract, it cannot enforce the contract >> consistently on all subclasses and something special will be needed for that javadoc. > > I?ll see whether this needs changing before revving. From brian.burkhalter at oracle.com Fri May 13 18:04:55 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 13 May 2016 11:04:55 -0700 Subject: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds In-Reply-To: References: <29a10b5a-9a23-f839-8cf7-71fd8cc0a86c@Oracle.com> <1F6EC53A-3913-48AC-81A9-4CC5B699DDB0@oracle.com> <2a520081-bd5a-360f-b04a-31c5e63b4596@Oracle.com> <08424057-6035-0a08-2150-2eaaa013f8e4@oracle.com> <04DA3578-E41F-41F7-84DC-B9BBB410281F@oracle.com> <05392e04-d971-1856-18b1-05cbca76fa20@Oracle.com> <8D563048-63B0-40EF-9736-CB1C43C9B5A5@oracle.com> <4106036f-3958-4b6c-503e-26ff9c13a035@Oracle.com> <500F8362-2DD6-4B29-A786-CD425E284C1D@oracle.com> Message-ID: <83747781-5ECF-4F86-AF21-79F928A6AFEE@oracle.com> Correction: wrong link provided below: http://cr.openjdk.java.net/~bpb/8130679/webrev.02/ Sorry for the confusion. Brian On May 13, 2016, at 10:42 AM, Brian Burkhalter wrote: > I have a third version of the patch here: > > http://cr.openjdk.java.net/~bpb/8130679/webrev.00/ > > This one I believe addresses all the inconsistencies including the one in https://bugs.openjdk.java.net/browse/JDK-8029804 at the expense of a slight weakening of the specification of the Writer.write({char[],String},int,int) methods, and matches the behavior of all the classes affected. I have tested it and inspected the code extensively. From pavel.rappo at oracle.com Fri May 13 18:25:10 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 13 May 2016 19:25:10 +0100 Subject: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds In-Reply-To: <83747781-5ECF-4F86-AF21-79F928A6AFEE@oracle.com> References: <29a10b5a-9a23-f839-8cf7-71fd8cc0a86c@Oracle.com> <1F6EC53A-3913-48AC-81A9-4CC5B699DDB0@oracle.com> <2a520081-bd5a-360f-b04a-31c5e63b4596@Oracle.com> <08424057-6035-0a08-2150-2eaaa013f8e4@oracle.com> <04DA3578-E41F-41F7-84DC-B9BBB410281F@oracle.com> <05392e04-d971-1856-18b1-05cbca76fa20@Oracle.com> <8D563048-63B0-40EF-9736-CB1C43C9B5A5@oracle.com> <4106036f-3958-4b6c-503e-26ff9c13a035@Oracle.com> <500F8362-2DD6-4B29-A786-CD425E284C1D@oracle.com> <83747781-5ECF-4F86-AF21-79F928A6AFEE@oracle.com> Message-ID: Brian, This looks good! -------------------------------------------------------------------------------- Could you please fix this tiny typo in-place? 145 * @throws IOException if the pipe is 146 * broken}, ^^^ And one more thing. You've removed this `@see` indentation in Writer.java. (Surprisingly enough, some views generated by webrev, e.g. sdiff, do not show it!) 36 * @see BufferedWriter 37 * @see CharArrayWriter 38 * @see FilterWriter 39 * @see OutputStreamWriter > 40 * @see FileWriter 41 * @see PipedWriter 42 * @see PrintWriter 43 * @see StringWriter 44 * @see Reader I believe it was intentional. It's a cute way to show the tree of inheritance. Compare it with java.io.Reader: * @see BufferedReader * @see LineNumberReader * @see CharArrayReader * @see InputStreamReader * @see FileReader * @see FilterReader * @see PushbackReader * @see PipedReader * @see StringReader * @see Writer Thanks. > On 13 May 2016, at 19:04, Brian Burkhalter wrote: > > Correction: wrong link provided below: > > http://cr.openjdk.java.net/~bpb/8130679/webrev.02/ > > Sorry for the confusion. > > Brian > > On May 13, 2016, at 10:42 AM, Brian Burkhalter wrote: > >> I have a third version of the patch here: >> >> http://cr.openjdk.java.net/~bpb/8130679/webrev.00/ >> >> This one I believe addresses all the inconsistencies including the one in https://bugs.openjdk.java.net/browse/JDK-8029804 at the expense of a slight weakening of the specification of the Writer.write({char[],String},int,int) methods, and matches the behavior of all the classes affected. I have tested it and inspected the code extensively. > From brian.burkhalter at oracle.com Fri May 13 18:34:14 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 13 May 2016 11:34:14 -0700 Subject: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds In-Reply-To: References: <29a10b5a-9a23-f839-8cf7-71fd8cc0a86c@Oracle.com> <1F6EC53A-3913-48AC-81A9-4CC5B699DDB0@oracle.com> <2a520081-bd5a-360f-b04a-31c5e63b4596@Oracle.com> <08424057-6035-0a08-2150-2eaaa013f8e4@oracle.com> <04DA3578-E41F-41F7-84DC-B9BBB410281F@oracle.com> <05392e04-d971-1856-18b1-05cbca76fa20@Oracle.com> <8D563048-63B0-40EF-9736-CB1C43C9B5A5@oracle.com> <4106036f-3958-4b6c-503e-26ff9c13a035@Oracle.com> <500F8362-2DD6-4B29-A786-CD425E284C1D@oracle.com> <83747781-5ECF-4F86-AF21-79F928A6AFEE@oracle.com> Message-ID: <1FA8AFB2-1D5E-4249-B689-778F6ADCCC35@oracle.com> Hi Pavel, On May 13, 2016, at 11:25 AM, Pavel Rappo wrote: > This looks good! Good good! Thanks! > -------------------------------------------------------------------------------- > Could you please fix this tiny typo in-place? > > 145 * @throws IOException if the pipe is > 146 * broken}, > ^^^ OK > And one more thing. You've removed this `@see` indentation in Writer.java. > (Surprisingly enough, some views generated by webrev, e.g. sdiff, do not show > it!) > > 36 * @see BufferedWriter > 37 * @see CharArrayWriter > 38 * @see FilterWriter > 39 * @see OutputStreamWriter >> 40 * @see FileWriter > 41 * @see PipedWriter > 42 * @see PrintWriter > 43 * @see StringWriter > 44 * @see Reader > > I believe it was intentional. It's a cute way to show the tree of inheritance. > Compare it with java.io.Reader: > > * @see BufferedReader > * @see LineNumberReader > * @see CharArrayReader > * @see InputStreamReader > * @see FileReader > * @see FilterReader > * @see PushbackReader > * @see PipedReader > * @see StringReader > * @see Writer That cuteness was lost on me; I?ll reinstate it. Brian From Roger.Riggs at Oracle.com Fri May 13 18:44:00 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 13 May 2016 14:44:00 -0400 Subject: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds In-Reply-To: <1FA8AFB2-1D5E-4249-B689-778F6ADCCC35@oracle.com> References: <29a10b5a-9a23-f839-8cf7-71fd8cc0a86c@Oracle.com> <1F6EC53A-3913-48AC-81A9-4CC5B699DDB0@oracle.com> <2a520081-bd5a-360f-b04a-31c5e63b4596@Oracle.com> <08424057-6035-0a08-2150-2eaaa013f8e4@oracle.com> <04DA3578-E41F-41F7-84DC-B9BBB410281F@oracle.com> <05392e04-d971-1856-18b1-05cbca76fa20@Oracle.com> <8D563048-63B0-40EF-9736-CB1C43C9B5A5@oracle.com> <4106036f-3958-4b6c-503e-26ff9c13a035@Oracle.com> <500F8362-2DD6-4B29-A786-CD425E284C1D@oracle.com> <83747781-5ECF-4F86-AF21-79F928A6AFEE@oracle.com> <1FA8AFB2-1D5E-4249-B689-778F6ADCCC35@oracle.com> Message-ID: <306e56cf-d732-a2c3-9a82-62d6d8982edf@Oracle.com> Hi Brian, Looks fine. Thanks for digging through all the cases. The @see indenting is ok, but not really a thing. White space is should not be used/relied upon for formatting. Roger On 5/13/2016 2:34 PM, Brian Burkhalter wrote: > Hi Pavel, > > On May 13, 2016, at 11:25 AM, Pavel Rappo wrote: > >> This looks good! > Good good! Thanks! > >> -------------------------------------------------------------------------------- >> Could you please fix this tiny typo in-place? >> >> 145 * @throws IOException if the pipe is >> 146 * broken}, >> ^^^ > OK > >> And one more thing. You've removed this `@see` indentation in Writer.java. >> (Surprisingly enough, some views generated by webrev, e.g. sdiff, do not show >> it!) >> >> 36 * @see BufferedWriter >> 37 * @see CharArrayWriter >> 38 * @see FilterWriter >> 39 * @see OutputStreamWriter >>> 40 * @see FileWriter >> 41 * @see PipedWriter >> 42 * @see PrintWriter >> 43 * @see StringWriter >> 44 * @see Reader >> >> I believe it was intentional. It's a cute way to show the tree of inheritance. >> Compare it with java.io.Reader: >> >> * @see BufferedReader >> * @see LineNumberReader >> * @see CharArrayReader >> * @see InputStreamReader >> * @see FileReader >> * @see FilterReader >> * @see PushbackReader >> * @see PipedReader >> * @see StringReader >> * @see Writer > That cuteness was lost on me; I?ll reinstate it. > > Brian From xueming.shen at oracle.com Fri May 13 18:49:26 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 13 May 2016 11:49:26 -0700 Subject: RFR: 8147588: Jar file and Zip file not removed in spite of the OPEN_DELETE flag In-Reply-To: <5735AC2B.3010808@oracle.com> References: <5734D670.3080004@oracle.com> <5735AC2B.3010808@oracle.com> Message-ID: <55af6df6-3ed8-1bae-e1f7-15dd0c46002d@oracle.com> On 5/13/16 3:27 AM, Alan Bateman wrote: > On 12/05/2016 20:16, Xueming Shen wrote: >> Hi, >> >> Please help review the proposed change for #8147588 >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8147588 >> webrev: http://cr.openjdk.java.net/~sherman/8147588/webrev >> >> This is a regression on Windows platform triggered by the change for >> https://bugs.openjdk.java.net/browse/JDK-8145260, in which we brought >> the ZipFile native natively code to java for better performance (both >> memory and access). >> >> As showed the from ln#107-114 at webrev below >> http://cr.openjdk.java.net/~sherman/8145260/webrev.push/src/java.base/share/native/libzip/ZipFile.c-.html >> >> >> The original native implementation uses a special "Windows-only" >> option O_TEMPORARY to open the zip/jar file on Windows to support >> this OPEN_DELETE functionality. >> >> There is no corresponding public open/delete functionality at java.io >> API right now. The proposed the change here is to add a private >> constructor for RandomAccessFile and access from ZipFile via >> SharedSecrets. This O_TEMPORARY is only supported on Windows >> platform. > I assume O_TEMPORARY maps to Windows FILE_FLAG_DELETE_ON_CLOSE flag. > In the new file system API then this gets exposed as the > DELETE_ON_CLOSE open option but it isn't exposed via RAF. I assume it > would be too much of a change to move ZipFile, particularly with > behavior changes related to interruption. > > I've looked through the patch but I just wondering if there are > cleaner alternatives. What would you think about not pushing > O_TEMPORARY to RAF but instead have ZipFile open the zip file with > ZFILE_Open, wrap it with a FileDescriptor and then create a RAF to > that FileDescriptor. I realize RAF doesn't have a public constructor > for this so it needs plumbing but the nice this is that it keeps this > specific mode issue out of RAF. > something like this? http://cr.openjdk.java.net/~sherman/8147588/webrev/ -sherman From brian.burkhalter at oracle.com Fri May 13 18:59:14 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 13 May 2016 11:59:14 -0700 Subject: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds In-Reply-To: <306e56cf-d732-a2c3-9a82-62d6d8982edf@Oracle.com> References: <29a10b5a-9a23-f839-8cf7-71fd8cc0a86c@Oracle.com> <1F6EC53A-3913-48AC-81A9-4CC5B699DDB0@oracle.com> <2a520081-bd5a-360f-b04a-31c5e63b4596@Oracle.com> <08424057-6035-0a08-2150-2eaaa013f8e4@oracle.com> <04DA3578-E41F-41F7-84DC-B9BBB410281F@oracle.com> <05392e04-d971-1856-18b1-05cbca76fa20@Oracle.com> <8D563048-63B0-40EF-9736-CB1C43C9B5A5@oracle.com> <4106036f-3958-4b6c-503e-26ff9c13a035@Oracle.com> <500F8362-2DD6-4B29-A786-CD425E284C1D@oracle.com> <83747781-5ECF-4F86-AF21-79F928A6AFEE@oracle.com> <1FA8AFB2-1D5E-4249-B689-778F6ADCCC35@oracle.com> <306e56cf-d732-a2c3-9a82-62d6d8982edf@Oracle.com> Message-ID: Hi Roger, On May 13, 2016, at 11:44 AM, Roger Riggs wrote: > Looks fine. Thanks for digging through all the cases. Thanks & you?re welcome. > The @see indenting is ok, but not really a thing. White space is should not be used/relied upon for formatting. The public javadoc http://download.java.net/java/jdk9/docs/api/java/io/Writer.html just shows the @see contents as one wrapped line. It seemed to me that to have ?@see Writer? in the Writer class itself was unnecessary given the lack of formatting as it merely points back to the same class. Brian From chris.hegarty at oracle.com Fri May 13 19:01:55 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 13 May 2016 20:01:55 +0100 Subject: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds In-Reply-To: <83747781-5ECF-4F86-AF21-79F928A6AFEE@oracle.com> References: <29a10b5a-9a23-f839-8cf7-71fd8cc0a86c@Oracle.com> <1F6EC53A-3913-48AC-81A9-4CC5B699DDB0@oracle.com> <2a520081-bd5a-360f-b04a-31c5e63b4596@Oracle.com> <08424057-6035-0a08-2150-2eaaa013f8e4@oracle.com> <04DA3578-E41F-41F7-84DC-B9BBB410281F@oracle.com> <05392e04-d971-1856-18b1-05cbca76fa20@Oracle.com> <8D563048-63B0-40EF-9736-CB1C43C9B5A5@oracle.com> <4106036f-3958-4b6c-503e-26ff9c13a035@Oracle.com> <500F8362-2DD6-4B29-A786-CD425E284C1D@oracle.com> <83747781-5ECF-4F86-AF21-79F928A6AFEE@oracle.com> Message-ID: <74C913E4-4B4E-45E1-8B8D-DADFC21938BB@oracle.com> On 13 May 2016, at 19:04, Brian Burkhalter wrote: > Correction: wrong link provided below: > > http://cr.openjdk.java.net/~bpb/8130679/webrev.02/ Looks good to me Brian. -Chris. > Sorry for the confusion. > > Brian > > On May 13, 2016, at 10:42 AM, Brian Burkhalter wrote: > >> I have a third version of the patch here: >> >> http://cr.openjdk.java.net/~bpb/8130679/webrev.00/ >> >> This one I believe addresses all the inconsistencies including the one in https://bugs.openjdk.java.net/browse/JDK-8029804 at the expense of a slight weakening of the specification of the Writer.write({char[],String},int,int) methods, and matches the behavior of all the classes affected. I have tested it and inspected the code extensively. > From Alan.Bateman at oracle.com Fri May 13 20:24:14 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 May 2016 21:24:14 +0100 Subject: RFR: 8147588: Jar file and Zip file not removed in spite of the OPEN_DELETE flag In-Reply-To: <55af6df6-3ed8-1bae-e1f7-15dd0c46002d@oracle.com> References: <5734D670.3080004@oracle.com> <5735AC2B.3010808@oracle.com> <55af6df6-3ed8-1bae-e1f7-15dd0c46002d@oracle.com> Message-ID: <573637EE.1030108@oracle.com> On 13/05/2016 19:49, Xueming Shen wrote: > > something like this? > http://cr.openjdk.java.net/~sherman/8147588/webrev/ Along these lines, yes. Would it be cleaner if ZipFile_openAndDelete were rename to ZipFile_open and used ZFILE_Open in libzip instead of winFileHandleOpen in libjava? Also given the platforms and modes then would it be simpler to use use ZFILE_Open for all platforms/cases. Should JavaIORandomAccessFileAccess.open be renamed to wrap as it does not open the file? -Alan From xueming.shen at oracle.com Fri May 13 21:09:29 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 13 May 2016 14:09:29 -0700 Subject: RFR: 8147588: Jar file and Zip file not removed in spite of the OPEN_DELETE flag In-Reply-To: <573637EE.1030108@oracle.com> References: <5734D670.3080004@oracle.com> <5735AC2B.3010808@oracle.com> <55af6df6-3ed8-1bae-e1f7-15dd0c46002d@oracle.com> <573637EE.1030108@oracle.com> Message-ID: <53e0df03-067e-ca8d-6143-921df1acc351@oracle.com> On 5/13/16 1:24 PM, Alan Bateman wrote: > > > On 13/05/2016 19:49, Xueming Shen wrote: >> >> something like this? >> http://cr.openjdk.java.net/~sherman/8147588/webrev/ > Along these lines, yes. > > Would it be cleaner if ZipFile_openAndDelete were rename to > ZipFile_open and used ZFILE_Open in libzip instead of > winFileHandleOpen in libjava? Also given the platforms and modes then > would it be simpler to use use ZFILE_Open for all platforms/cases. > My memory suggests the reason we went to winFileHandleOpen() is for that windows' long path issue we dealt with years ago. ZFILE_Open() does not appear to deal with that. Sure I can bring ZFILE_Open in for the non-windows platform, though my original wish is to reduce the native exposure of the ZipFile. I don't have a strong feeling for that though. > Should JavaIORandomAccessFileAccess.open be renamed to wrap as it does > not open the file? > It means to "open" an RandomAccessFile object, how about "create"? "wrap" a little indicates the RandomAccessFile does not nothing but only a wrapper around the "fd". -Sherman From iris.clark at oracle.com Fri May 13 23:20:23 2016 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 13 May 2016 16:20:23 -0700 (PDT) Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version Message-ID: Hi. Reviving this work from a few months back. Please review the following changes to move jdk.Version to jdk.lang.Runtime.Version. Bug 8144062: Move jdk.Version to java.lang.Runtime.Version https://bugs.openjdk.java.net/browse/JDK-8144062 webrev http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/ When jdk.Version was initially pushed in jdk-9+1-5, it was Improperly exported by java.base. After exploring a few options, the best choice was to move jdk.Version to java.lang.Runtime.Version (a nested class of Runtime). By making Version an SE API, it may be exported by the java.base module. As part of the move, a limited number of chnages were made to the Version class: - Change package name and class declaration (to static) - Eliminate use of "JDK" when describing a Java SE API - Initial clarifications related to zeros (trailing vs. Internal components) - Small typographical and grammatical enhancements - Indentation The complete Runtime.Version specification is available here: http://cr.openjdk.java.net/~iris/verona/8144062/doc.1/java/lang/Runtime.Version.html The old jdk.Version.current() was replaced with Runtime.version(). In System.getProperties(), we indicate which version-related system properties may be supported by Runtime.Version. The remaining jdk and langtools file changes are all side-effects of changing jdk.Version.current() to Runtime.version(). Thanks, Iris From forax at univ-mlv.fr Fri May 13 23:31:36 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 14 May 2016 01:31:36 +0200 (CEST) Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version In-Reply-To: References: Message-ID: <1554585217.477366.1463182296059.JavaMail.zimbra@u-pem.fr> Hi Iris, is there a way to avoid to use regex when parsing the version ? java.lang.Runtime.Version is used during the boot process, so now every Java programs loads a bunch of classes related to java.util.regex even if they do not use any regex or use another regex engine (like Nashorn or JRuby). regards, R?mi ----- Mail original ----- > De: "Iris Clark" > ?: "Java Core Libs" , compiler-dev at openjdk.java.net > Cc: verona-dev at openjdk.java.net > Envoy?: Samedi 14 Mai 2016 01:20:23 > Objet: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version > > Hi. > > Reviving this work from a few months back. > > Please review the following changes to move jdk.Version to > java.lang.Runtime.Version. > > Bug > > 8144062: Move jdk.Version to java.lang.Runtime.Version > https://bugs.openjdk.java.net/browse/JDK-8144062 > > webrev > > http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/ > > When jdk.Version was initially pushed in jdk-9+1-5, it was > Improperly exported by java.base. After exploring a few > options, the best choice was to move jdk.Version to > java.lang.Runtime.Version (a nested class of Runtime). By > making Version an SE API, it may be exported by the java.base > module. > > As part of the move, a limited number of chnages were > made to the Version class: > > - Change package name and class declaration (to static) > - Eliminate use of "JDK" when describing a Java SE API > - Initial clarifications related to zeros (trailing vs. > Internal components) > - Small typographical and grammatical enhancements > - Indentation > > The complete Runtime.Version specification is available here: > > http://cr.openjdk.java.net/~iris/verona/8144062/doc.1/java/lang/Runtime.Version.html > > The old jdk.Version.current() was replaced with > Runtime.version(). > > In System.getProperties(), we indicate which version-related > system properties may be supported by Runtime.Version. > > The remaining jdk and langtools file changes are all > side-effects of changing jdk.Version.current() to > Runtime.version(). > > Thanks, > Iris > From mandy.chung at oracle.com Sat May 14 04:48:36 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 13 May 2016 21:48:36 -0700 Subject: Review request for JDK-8156575: Add jdeps -addmods, -system, -inverse options In-Reply-To: <113b916e-7c89-179c-5140-170db1c40811@oracle.com> References: <6D81F159-5607-4BDA-94AB-6C9FD0FF1BD8@oracle.com> <113b916e-7c89-179c-5140-170db1c40811@oracle.com> Message-ID: <8C15B5A6-0E24-44C3-9788-F21D0D5B6BAB@oracle.com> Daniel, I have added more tests and fixed a few issues http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8156575/webrev.02/ I also created a test case similar to yours. This patch applies on top of: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8156680/webrev.02/ for JDK-8156680: jdeps implementation refresh Thanks Mandy From Alan.Bateman at oracle.com Sat May 14 20:01:54 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 14 May 2016 21:01:54 +0100 Subject: RFR: 8147588: Jar file and Zip file not removed in spite of the OPEN_DELETE flag In-Reply-To: <53e0df03-067e-ca8d-6143-921df1acc351@oracle.com> References: <5734D670.3080004@oracle.com> <5735AC2B.3010808@oracle.com> <55af6df6-3ed8-1bae-e1f7-15dd0c46002d@oracle.com> <573637EE.1030108@oracle.com> <53e0df03-067e-ca8d-6143-921df1acc351@oracle.com> Message-ID: <57378432.2040904@oracle.com> On 13/05/2016 22:09, Xueming Shen wrote: > > My memory suggests the reason we went to winFileHandleOpen() is for > that windows' long path issue > we dealt with years ago. ZFILE_Open() does not appear to deal with that. > > Sure I can bring ZFILE_Open in for the non-windows platform, though my > original wish is to reduce the > native exposure of the ZipFile. I don't have a strong feeling for that > though. > Ah, I forgot the long file name issue, in which case then maybe your first approach to have RAF support at additional mode is more appealing. Sorry for sending down you part way down another road. -Alan From xueming.shen at oracle.com Sun May 15 18:54:35 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Sun, 15 May 2016 11:54:35 -0700 Subject: RFR: 8147588: Jar file and Zip file not removed in spite of the OPEN_DELETE flag In-Reply-To: <57378432.2040904@oracle.com> References: <5734D670.3080004@oracle.com> <5735AC2B.3010808@oracle.com> <55af6df6-3ed8-1bae-e1f7-15dd0c46002d@oracle.com> <573637EE.1030108@oracle.com> <53e0df03-067e-ca8d-6143-921df1acc351@oracle.com> <57378432.2040904@oracle.com> Message-ID: <5738C5EB.8090408@oracle.com> Thanks Alan, Here is the webrev with the first proposed change. http://cr.openjdk.java.net/~sherman/8147588/webrev/ -sherman On 5/14/2016 1:01 PM, Alan Bateman wrote: > On 13/05/2016 22:09, Xueming Shen wrote: >> >> My memory suggests the reason we went to winFileHandleOpen() is for >> that windows' long path issue >> we dealt with years ago. ZFILE_Open() does not appear to deal with that. >> >> Sure I can bring ZFILE_Open in for the non-windows platform, though >> my original wish is to reduce the >> native exposure of the ZipFile. I don't have a strong feeling for >> that though. >> > Ah, I forgot the long file name issue, in which case then maybe your > first approach to have RAF support at additional mode is more > appealing. Sorry for sending down you part way down another road. > > -Alan From peter.levart at gmail.com Sun May 15 22:08:09 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 16 May 2016 00:08:09 +0200 Subject: Cleaner cleanup Message-ID: <8b4dd573-da7b-fd6c-eb49-24f2b15a11cc@gmail.com> Hi Roger and others, When the new Cleaner API was created the implementation of Cleanable(s) was split into the low-level abstract [Soft|Weak|Phantom]Cleanable classes to be used internally for purposes where the footprint matters and their corresponding CleanerImpl.[Soft|Weak|Phantom]CleanableRef subclasses used as implementations that take a Runnable cleanup action and are exposed via the public Cleaner API. When thinking of possible JDK internal use cases for the low-level API, I came to the conclusion that [Soft|Weak|Phantom]Cleanable classes are not suitable as is, because in cases where footprint matters, it is usually also the case that the number of [Soft|Weak|Phantom]Cleanable instances created is larger and that construction performance also matters. Especially multi-threaded construction. I'm thinking of the use cases of auto-cleanable concurrent data structures. In such use cases, the present features of [Soft|Weak|Phantom]Cleanable classes, namely the guaranteed just-once cleanup action invocation and keeping the Cleanable instance reachable until the cleanup action is performed, are actually not needed and just present footprint and performance (contention) overhead. They also present an overhead as they don't allow GC to automatically collect the Cleanable instances if the data structure containing them becomes unreachable and corresponding registered cleanup actions obsolete. The mentioned features are important for public Cleaner.Cleanable instances as they are usually used for cleanup of native resources where the performance of their creation is not so drastically important and where there is no intrinsic data structure to hold them reachable. I propose to move those features from the [Soft|Weak|Phantom]Cleanable classes down the hierarchy to the CleanerImpl.[Soft|Weak|Phantom]CleanableRef subclasses: http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner.cleanup/webrev.01/ In this change I also removed the CleanerImpl.[Soft|Weak]CleanableRef subclasses as they are not needed and I believe will never be. I also renamed the CleanerImpl.PhantomCleanableRef subclass to CleanerImpl.PhantomCleanableImpl. Changes to the implementation are straightforward. The most work was put into the corresponding test. I did some clean-up to it and also changed it to accommodate for the new behavior of [Soft|Weak|Phantom]Cleanable classes. The changes speak for itself. One of the not-so obvious changes was to replace the CleanableCase.clearRef() action with the CleanableCase.releaseReferent() action. The old clearRef() action did not serve any purpose. Whether this method was called or not, the behavior of the corresponding Cleanable was unchanged as the Reference instance (referenced from the 'ref' field) was always of the same strength as the Cleanable itself. So clearing it could not affect the behavior of the Cleanable. I changed 'ref' to hold a direct reference to the referent and renamed the field to 'referent'. I changed the EV_XXX int constants to Event enum constants with helper methods used in CleanableCase.expectedCleanups() method that now returns the number of expected cleanup invocations - in the PhantomCleanableImpl case this is the number of expected cleanup action invocations while in the plain XxxCleanable subclass cases it is the number of Cleanable.clean() method invocations. I added the no-actions case to both PhantomCleanableImpl and XxxCleanable cases and extended the number and combinations of XxxCleanable cases. The checkCleaned() method was extended to verify that the number of cleanup invocations is *no more* and no less then the expected. See how WeakKey test is now simplified. This is the typical use-case for WeakCleanable I was talking about. So, what do you think of this cleanup? Regards, Peter From shilpi.rastogi at oracle.com Mon May 16 05:18:29 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Mon, 16 May 2016 10:48:29 +0530 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: References: <57331659.1030008@oracle.com> <07F81381-B038-47B2-BE70-76D3769598A5@oracle.com> <573470EE.5080105@oracle.com> <5c0c4872-8729-182b-9736-62a35b9e7dcf@oracle.com> <57357EB7.3060700@oracle.com> <6FDBC724-2E4C-4D9E-96C1-67674EE6CD95@oracle.com> <573596C7.7020107@oracle.com> <09f076bd-eebb-f2a3-5483-a1a695e51ab2@oracle.com> <9372690.370218.1463147461441.JavaMail.zimbra@u-pem.fr> Message-ID: <57395825.1030100@oracle.com> Thanks Vladimir and Remi. Please review updated webrev http://cr.openjdk.java.net/~srastogi/8149574/webrev/ Regards, Shilpi On 5/13/2016 7:31 PM, Vladimir Ivanov wrote: > Good point, Remi. I agree that it's redundant. > > Best regards, > Vladimir Ivanov > > On 5/13/16 4:51 PM, Remi Forax wrote: >> Also instead of >> MethodVisitor mv = cw.visitMethod(ACC_PRIVATE | ACC_STATIC, >> "invoke_V", >> "(Ljava/lang/invoke/MethodHandle;[Ljava/lang/Object;)Ljava/lang/Object;", >> null, new String[] { "java/lang/Throwable" }); >> >> because the code is never read by a java compiler (as javac), you >> don't need to specify the exception >> (checked exceptions are a Java the language artifact) >> MethodVisitor mv = cw.visitMethod(ACC_PRIVATE | ACC_STATIC, >> "invoke_V", >> "(Ljava/lang/invoke/MethodHandle;[Ljava/lang/Object;)Ljava/lang/Object;", >> null, null); >> >> my 2 cents, >> R?mi >> >> ----- Mail original ----- >>> De: "Vladimir Ivanov" >>> ?: "shilpi rastogi" >>> Cc: core-libs-dev at openjdk.java.net >>> Envoy?: Vendredi 13 Mai 2016 15:41:33 >>> Objet: Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of >>> Unsafe.defineAnonymousClass() >>> >>> MethodHandle vamh = prepareForInvoker(MH_checkCallerClass); >>> Object ok = bccInvoker.invokeExact(vamh, new >>> Object[]{hostClass, bcc}); >>> + assert Boolean.TRUE.equals(ok) : ok; >>> >>> What I meant is to convert the whole test (inside try-catch block) into >>> an assert. >>> >>> >>> + UNSAFE.ensureClassInitialized(bcc); >>> >>> Do people see any reason to force invoker class init? I'd prefer to see >>> it goes away. >>> >>> Also, as a second thought, generateInvokerTemplate() looks clearer than >>> invokerTemplateGenerator(). >>> >>> Something like the following: >>> http://cr.openjdk.java.net/~vlivanov/8149574/webrev.00/ >>> >>> Additional cleanup: checkCallerClass() should return injected invoker >>> class when invoked using a method handle, so no need in 2nd argument. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 5/13/16 11:56 AM, shilpi.rastogi at oracle.com wrote: >>>> Thanks Paul! >>>> >>>> Please review http://cr.openjdk.java.net/~srastogi/8149574/webrev10.0/ >>>> >>>> Regards, >>>> Shilpi >>>> >>>> On 5/13/2016 2:09 PM, Paul Sandoz wrote: >>>>> assert Boolean.TRUE.equals(ok) : ok; >>>> >>> From bhanu.prakash.gopularam at oracle.com Mon May 16 06:16:11 2016 From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam) Date: Sun, 15 May 2016 23:16:11 -0700 (PDT) Subject: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields Message-ID: Hi all, Could you please review fix for following issue. Bug id: https://bugs.openjdk.java.net/browse/JDK-8156718 Solution: Added tck tests for validating getFrom method for unsupported non-Iso temporal fields Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.00/ Thanks, Bhanu From huaming.li at oracle.com Mon May 16 07:39:52 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Mon, 16 May 2016 15:39:52 +0800 Subject: JDK 9 RFR of JDK-8157006/8157011: Problem list java/io/pathNames/GeneralWin32.java and tools/pack200/TestNormal.java Message-ID: <57397948.2020401@oracle.com> java/io/pathNames/GeneralWin32.java has been seen to fail with high frequency on windows. Until JDK-8156595 is addressed, the test should be problem listed. bug: https://bugs.openjdk.java.net/browse/JDK-8157006 tools/pack200/TestNormal.java has been seen to fail with some frequency on windows. Until JDK-8156807 is addressed, the test should be problem listed. bug: https://bugs.openjdk.java.net/browse/JDK-8157011 webrev: http://cr.openjdk.java.net/~mli/8157006/webrev.00/ Thank you -Hamlin From me at noctarius.com Mon May 16 08:37:46 2016 From: me at noctarius.com (Christoph Engelbert) Date: Mon, 16 May 2016 10:37:46 +0200 Subject: Cleaner cleanup In-Reply-To: <8b4dd573-da7b-fd6c-eb49-24f2b15a11cc@gmail.com> References: <8b4dd573-da7b-fd6c-eb49-24f2b15a11cc@gmail.com> Message-ID: <1015E2BE-A93C-46AF-8013-911C5B7DEFC8@noctarius.com> Hey Peter, First of all, I really love this Cleanup API! Anyhow I think it would make sense to have Cleanable extend AutoCloseable for exactly the use case you rendered in your JavaDoc of the Cleaner class. Made up example: public T execute(BufferAction bufferAction) { Buffer buffer = allocateBuffer(); try (Cleanable wrapper = cleaner.register(buffer, Buffer::deallocate) { bufferAction.execute(buffer); } } I agree that you probably want to encapsulate the cleaner registration and cleaning action but for frameworks it might be beneficial to have a common utility method implementing a pattern such as the one above. Chris > On 16 May 2016, at 00:08, Peter Levart wrote: > > Hi Roger and others, > > When the new Cleaner API was created the implementation of Cleanable(s) was split into the low-level abstract [Soft|Weak|Phantom]Cleanable classes to be used internally for purposes where the footprint matters and their corresponding CleanerImpl.[Soft|Weak|Phantom]CleanableRef subclasses used as implementations that take a Runnable cleanup action and are exposed via the public Cleaner API. > > When thinking of possible JDK internal use cases for the low-level API, I came to the conclusion that [Soft|Weak|Phantom]Cleanable classes are not suitable as is, because in cases where footprint matters, it is usually also the case that the number of [Soft|Weak|Phantom]Cleanable instances created is larger and that construction performance also matters. Especially multi-threaded construction. I'm thinking of the use cases of auto-cleanable concurrent data structures. In such use cases, the present features of [Soft|Weak|Phantom]Cleanable classes, namely the guaranteed just-once cleanup action invocation and keeping the Cleanable instance reachable until the cleanup action is performed, are actually not needed and just present footprint and performance (contention) overhead. They also present an overhead as they don't allow GC to automatically collect the Cleanable instances if the data structure containing them becomes unreachable and corresponding registered cleanup actions obsolete. > > The mentioned features are important for public Cleaner.Cleanable instances as they are usually used for cleanup of native resources where the performance of their creation is not so drastically important and where there is no intrinsic data structure to hold them reachable. > > I propose to move those features from the [Soft|Weak|Phantom]Cleanable classes down the hierarchy to the CleanerImpl.[Soft|Weak|Phantom]CleanableRef subclasses: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner.cleanup/webrev.01/ > > > In this change I also removed the CleanerImpl.[Soft|Weak]CleanableRef subclasses as they are not needed and I believe will never be. I also renamed the CleanerImpl.PhantomCleanableRef subclass to CleanerImpl.PhantomCleanableImpl. > > Changes to the implementation are straightforward. The most work was put into the corresponding test. I did some clean-up to it and also changed it to accommodate for the new behavior of [Soft|Weak|Phantom]Cleanable classes. The changes speak for itself. One of the not-so obvious changes was to replace the CleanableCase.clearRef() action with the CleanableCase.releaseReferent() action. The old clearRef() action did not serve any purpose. Whether this method was called or not, the behavior of the corresponding Cleanable was unchanged as the Reference instance (referenced from the 'ref' field) was always of the same strength as the Cleanable itself. So clearing it could not affect the behavior of the Cleanable. > > I changed 'ref' to hold a direct reference to the referent and renamed the field to 'referent'. I changed the EV_XXX int constants to Event enum constants with helper methods used in CleanableCase.expectedCleanups() method that now returns the number of expected cleanup invocations - in the PhantomCleanableImpl case this is the number of expected cleanup action invocations while in the plain XxxCleanable subclass cases it is the number of Cleanable.clean() method invocations. I added the no-actions case to both PhantomCleanableImpl and XxxCleanable cases and extended the number and combinations of XxxCleanable cases. > > The checkCleaned() method was extended to verify that the number of cleanup invocations is *no more* and no less then the expected. > > See how WeakKey test is now simplified. This is the typical use-case for WeakCleanable I was talking about. > > > So, what do you think of this cleanup? > > > Regards, Peter > From me at noctarius.com Mon May 16 08:40:24 2016 From: me at noctarius.com (Christoph Engelbert) Date: Mon, 16 May 2016 10:40:24 +0200 Subject: Cleaner cleanup In-Reply-To: <1015E2BE-A93C-46AF-8013-911C5B7DEFC8@noctarius.com> References: <8b4dd573-da7b-fd6c-eb49-24f2b15a11cc@gmail.com> <1015E2BE-A93C-46AF-8013-911C5B7DEFC8@noctarius.com> Message-ID: <2D440D10-4638-459D-BC6B-0CAB093F1865@noctarius.com> Peter, Just as a quick correction of the previous example, obviously Buffer::deallocate wouldn?t work, but I guess you get the point. Chris > On 16 May 2016, at 10:37, Christoph Engelbert wrote: > > Hey Peter, > > First of all, I really love this Cleanup API! > Anyhow I think it would make sense to have Cleanable extend AutoCloseable for exactly the use case you rendered in your JavaDoc of the Cleaner class. > > Made up example: > public T execute(BufferAction bufferAction) { > Buffer buffer = allocateBuffer(); > try (Cleanable wrapper = cleaner.register(buffer, Buffer::deallocate) { > bufferAction.execute(buffer); > } > } > > I agree that you probably want to encapsulate the cleaner registration and cleaning action but for frameworks it might be beneficial to have a common utility method implementing a pattern such as the one above. > > Chris > >> On 16 May 2016, at 00:08, Peter Levart wrote: >> >> Hi Roger and others, >> >> When the new Cleaner API was created the implementation of Cleanable(s) was split into the low-level abstract [Soft|Weak|Phantom]Cleanable classes to be used internally for purposes where the footprint matters and their corresponding CleanerImpl.[Soft|Weak|Phantom]CleanableRef subclasses used as implementations that take a Runnable cleanup action and are exposed via the public Cleaner API. >> >> When thinking of possible JDK internal use cases for the low-level API, I came to the conclusion that [Soft|Weak|Phantom]Cleanable classes are not suitable as is, because in cases where footprint matters, it is usually also the case that the number of [Soft|Weak|Phantom]Cleanable instances created is larger and that construction performance also matters. Especially multi-threaded construction. I'm thinking of the use cases of auto-cleanable concurrent data structures. In such use cases, the present features of [Soft|Weak|Phantom]Cleanable classes, namely the guaranteed just-once cleanup action invocation and keeping the Cleanable instance reachable until the cleanup action is performed, are actually not needed and just present footprint and performance (contention) overhead. They also present an overhead as they don't allow GC to automatically collect the Cleanable instances if the data structure containing them becomes unreachable and corresponding registered cleanup actions obsolete. >> >> The mentioned features are important for public Cleaner.Cleanable instances as they are usually used for cleanup of native resources where the performance of their creation is not so drastically important and where there is no intrinsic data structure to hold them reachable. >> >> I propose to move those features from the [Soft|Weak|Phantom]Cleanable classes down the hierarchy to the CleanerImpl.[Soft|Weak|Phantom]CleanableRef subclasses: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner.cleanup/webrev.01/ >> >> >> In this change I also removed the CleanerImpl.[Soft|Weak]CleanableRef subclasses as they are not needed and I believe will never be. I also renamed the CleanerImpl.PhantomCleanableRef subclass to CleanerImpl.PhantomCleanableImpl. >> >> Changes to the implementation are straightforward. The most work was put into the corresponding test. I did some clean-up to it and also changed it to accommodate for the new behavior of [Soft|Weak|Phantom]Cleanable classes. The changes speak for itself. One of the not-so obvious changes was to replace the CleanableCase.clearRef() action with the CleanableCase.releaseReferent() action. The old clearRef() action did not serve any purpose. Whether this method was called or not, the behavior of the corresponding Cleanable was unchanged as the Reference instance (referenced from the 'ref' field) was always of the same strength as the Cleanable itself. So clearing it could not affect the behavior of the Cleanable. >> >> I changed 'ref' to hold a direct reference to the referent and renamed the field to 'referent'. I changed the EV_XXX int constants to Event enum constants with helper methods used in CleanableCase.expectedCleanups() method that now returns the number of expected cleanup invocations - in the PhantomCleanableImpl case this is the number of expected cleanup action invocations while in the plain XxxCleanable subclass cases it is the number of Cleanable.clean() method invocations. I added the no-actions case to both PhantomCleanableImpl and XxxCleanable cases and extended the number and combinations of XxxCleanable cases. >> >> The checkCleaned() method was extended to verify that the number of cleanup invocations is *no more* and no less then the expected. >> >> See how WeakKey test is now simplified. This is the typical use-case for WeakCleanable I was talking about. >> >> >> So, what do you think of this cleanup? >> >> >> Regards, Peter >> > From vladimir.x.ivanov at oracle.com Mon May 16 10:36:24 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 16 May 2016 13:36:24 +0300 Subject: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() In-Reply-To: <57395825.1030100@oracle.com> References: <57331659.1030008@oracle.com> <07F81381-B038-47B2-BE70-76D3769598A5@oracle.com> <573470EE.5080105@oracle.com> <5c0c4872-8729-182b-9736-62a35b9e7dcf@oracle.com> <57357EB7.3060700@oracle.com> <6FDBC724-2E4C-4D9E-96C1-67674EE6CD95@oracle.com> <573596C7.7020107@oracle.com> <09f076bd-eebb-f2a3-5483-a1a695e51ab2@oracle.com> <9372690.370218.1463147461441.JavaMail.zimbra@u-pem.fr> <57395825.1030100@oracle.com> Message-ID: <9641fcfd-cb7c-5d86-d77a-8c8f37de9a2e@oracle.com> Looks good. Best regards, Vladimir Ivanov PS: I noticed you missed ACC_PRIVATE flag on the invoker class, but then erroneously put it on the method. Please, move it to class flags before pushing. No need to send updated webrev. + cw.visit(52, ACC_PRIVATE | ACC_SUPER, "InjectedInvoker", null, "java/lang/Object", null); + + MethodVisitor mv = cw.visitMethod(ACC_STATIC, "invoke_V", On 5/16/16 8:18 AM, shilpi.rastogi at oracle.com wrote: > Thanks Vladimir and Remi. > > Please review updated webrev > http://cr.openjdk.java.net/~srastogi/8149574/webrev/ > > Regards, > Shilpi > > On 5/13/2016 7:31 PM, Vladimir Ivanov wrote: >> Good point, Remi. I agree that it's redundant. >> >> Best regards, >> Vladimir Ivanov >> >> On 5/13/16 4:51 PM, Remi Forax wrote: >>> Also instead of >>> MethodVisitor mv = cw.visitMethod(ACC_PRIVATE | ACC_STATIC, >>> "invoke_V", >>> "(Ljava/lang/invoke/MethodHandle;[Ljava/lang/Object;)Ljava/lang/Object;", >>> >>> null, new String[] { "java/lang/Throwable" }); >>> >>> because the code is never read by a java compiler (as javac), you >>> don't need to specify the exception >>> (checked exceptions are a Java the language artifact) >>> MethodVisitor mv = cw.visitMethod(ACC_PRIVATE | ACC_STATIC, >>> "invoke_V", >>> "(Ljava/lang/invoke/MethodHandle;[Ljava/lang/Object;)Ljava/lang/Object;", >>> >>> null, null); >>> >>> my 2 cents, >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "Vladimir Ivanov" >>>> ?: "shilpi rastogi" >>>> Cc: core-libs-dev at openjdk.java.net >>>> Envoy?: Vendredi 13 Mai 2016 15:41:33 >>>> Objet: Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of >>>> Unsafe.defineAnonymousClass() >>>> >>>> MethodHandle vamh = prepareForInvoker(MH_checkCallerClass); >>>> Object ok = bccInvoker.invokeExact(vamh, new >>>> Object[]{hostClass, bcc}); >>>> + assert Boolean.TRUE.equals(ok) : ok; >>>> >>>> What I meant is to convert the whole test (inside try-catch block) into >>>> an assert. >>>> >>>> >>>> + UNSAFE.ensureClassInitialized(bcc); >>>> >>>> Do people see any reason to force invoker class init? I'd prefer to see >>>> it goes away. >>>> >>>> Also, as a second thought, generateInvokerTemplate() looks clearer than >>>> invokerTemplateGenerator(). >>>> >>>> Something like the following: >>>> http://cr.openjdk.java.net/~vlivanov/8149574/webrev.00/ >>>> >>>> Additional cleanup: checkCallerClass() should return injected invoker >>>> class when invoked using a method handle, so no need in 2nd argument. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 5/13/16 11:56 AM, shilpi.rastogi at oracle.com wrote: >>>>> Thanks Paul! >>>>> >>>>> Please review http://cr.openjdk.java.net/~srastogi/8149574/webrev10.0/ >>>>> >>>>> Regards, >>>>> Shilpi >>>>> >>>>> On 5/13/2016 2:09 PM, Paul Sandoz wrote: >>>>>> assert Boolean.TRUE.equals(ok) : ok; >>>>> >>>> > From peter.levart at gmail.com Mon May 16 10:54:03 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 16 May 2016 12:54:03 +0200 Subject: Cleaner cleanup In-Reply-To: <1015E2BE-A93C-46AF-8013-911C5B7DEFC8@noctarius.com> References: <8b4dd573-da7b-fd6c-eb49-24f2b15a11cc@gmail.com> <1015E2BE-A93C-46AF-8013-911C5B7DEFC8@noctarius.com> Message-ID: Hi Christoph, On 05/16/2016 10:37 AM, Christoph Engelbert wrote: > Hey Peter, > > First of all, I really love this Cleanup API! > Anyhow I think it would make sense to have Cleanable extend AutoCloseable for exactly the use case you rendered in your JavaDoc of the Cleaner class. > > Made up example: > public T execute(BufferAction bufferAction) { > Buffer buffer = allocateBuffer(); > try (Cleanable wrapper = cleaner.register(buffer, Buffer::deallocate) { > bufferAction.execute(buffer); > } > } > > I agree that you probably want to encapsulate the cleaner registration and cleaning action but for frameworks it might be beneficial to have a common utility method implementing a pattern such as the one above. > > Chris I think the Cleaner API is more suitable to be used inside various classes that themselves implement AutoCloseable rather than as an (optional) aspect on top of them. So your example would simply read: public T execute(BufferAction bufferAction) { try (Buffer buffer = allocateBuffer()) { bufferAction.execute(buffer); } } There's no point in doing both things as in your example: using try-with-resources + the Cleaner API on top. try-with-resources already guarantees cleanup. Cleanable API is meant to be used inside otherwise AutoCleanable implementations to shield the user from native resource leaks if the user forgets to use or can't use try-with-resources. Regards, Peter > >> On 16 May 2016, at 00:08, Peter Levart wrote: >> >> Hi Roger and others, >> >> When the new Cleaner API was created the implementation of Cleanable(s) was split into the low-level abstract [Soft|Weak|Phantom]Cleanable classes to be used internally for purposes where the footprint matters and their corresponding CleanerImpl.[Soft|Weak|Phantom]CleanableRef subclasses used as implementations that take a Runnable cleanup action and are exposed via the public Cleaner API. >> >> When thinking of possible JDK internal use cases for the low-level API, I came to the conclusion that [Soft|Weak|Phantom]Cleanable classes are not suitable as is, because in cases where footprint matters, it is usually also the case that the number of [Soft|Weak|Phantom]Cleanable instances created is larger and that construction performance also matters. Especially multi-threaded construction. I'm thinking of the use cases of auto-cleanable concurrent data structures. In such use cases, the present features of [Soft|Weak|Phantom]Cleanable classes, namely the guaranteed just-once cleanup action invocation and keeping the Cleanable instance reachable until the cleanup action is performed, are actually not needed and just present footprint and performance (contention) overhead. They also present an overhead as they don't allow GC to automatically collect the Cleanable instances if the data structure containing them becomes unreachable and corresponding registered cleanup actions obsolete. >> >> The mentioned features are important for public Cleaner.Cleanable instances as they are usually used for cleanup of native resources where the performance of their creation is not so drastically important and where there is no intrinsic data structure to hold them reachable. >> >> I propose to move those features from the [Soft|Weak|Phantom]Cleanable classes down the hierarchy to the CleanerImpl.[Soft|Weak|Phantom]CleanableRef subclasses: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner.cleanup/webrev.01/ >> >> >> In this change I also removed the CleanerImpl.[Soft|Weak]CleanableRef subclasses as they are not needed and I believe will never be. I also renamed the CleanerImpl.PhantomCleanableRef subclass to CleanerImpl.PhantomCleanableImpl. >> >> Changes to the implementation are straightforward. The most work was put into the corresponding test. I did some clean-up to it and also changed it to accommodate for the new behavior of [Soft|Weak|Phantom]Cleanable classes. The changes speak for itself. One of the not-so obvious changes was to replace the CleanableCase.clearRef() action with the CleanableCase.releaseReferent() action. The old clearRef() action did not serve any purpose. Whether this method was called or not, the behavior of the corresponding Cleanable was unchanged as the Reference instance (referenced from the 'ref' field) was always of the same strength as the Cleanable itself. So clearing it could not affect the behavior of the Cleanable. >> >> I changed 'ref' to hold a direct reference to the referent and renamed the field to 'referent'. I changed the EV_XXX int constants to Event enum constants with helper methods used in CleanableCase.expectedCleanups() method that now returns the number of expected cleanup invocations - in the PhantomCleanableImpl case this is the number of expected cleanup action invocations while in the plain XxxCleanable subclass cases it is the number of Cleanable.clean() method invocations. I added the no-actions case to both PhantomCleanableImpl and XxxCleanable cases and extended the number and combinations of XxxCleanable cases. >> >> The checkCleaned() method was extended to verify that the number of cleanup invocations is *no more* and no less then the expected. >> >> See how WeakKey test is now simplified. This is the typical use-case for WeakCleanable I was talking about. >> >> >> So, what do you think of this cleanup? >> >> >> Regards, Peter >> From peter.levart at gmail.com Mon May 16 10:57:07 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 16 May 2016 12:57:07 +0200 Subject: Cleaner cleanup In-Reply-To: References: <8b4dd573-da7b-fd6c-eb49-24f2b15a11cc@gmail.com> <1015E2BE-A93C-46AF-8013-911C5B7DEFC8@noctarius.com> Message-ID: <87304630-464d-3a97-19ff-5d2dd3eafb38@gmail.com> Correction in line... On 05/16/2016 12:54 PM, Peter Levart wrote: > Hi Christoph, > > > On 05/16/2016 10:37 AM, Christoph Engelbert wrote: >> Hey Peter, >> >> First of all, I really love this Cleanup API! >> Anyhow I think it would make sense to have Cleanable extend >> AutoCloseable for exactly the use case you rendered in your JavaDoc >> of the Cleaner class. >> >> Made up example: >> public T execute(BufferAction bufferAction) { >> Buffer buffer = allocateBuffer(); >> try (Cleanable wrapper = cleaner.register(buffer, >> Buffer::deallocate) { >> bufferAction.execute(buffer); >> } >> } >> >> I agree that you probably want to encapsulate the cleaner >> registration and cleaning action but for frameworks it might be >> beneficial to have a common utility method implementing a pattern >> such as the one above. >> >> Chris > > I think the Cleaner API is more suitable to be used inside various > classes that themselves implement AutoCloseable rather than as an > (optional) aspect on top of them. So your example would simply read: > > public T execute(BufferAction bufferAction) { > try (Buffer buffer = allocateBuffer()) { > bufferAction.execute(buffer); > } > } > > There's no point in doing both things as in your example: using > try-with-resources + the Cleaner API on top. try-with-resources > already guarantees cleanup. Sorry, the following: > *Cleanable* API is meant to be used inside otherwise *AutoCleanable* > implementations to shield the user from native resource leaks if the > user forgets to use or can't use try-with-resources. Should read: *Cleaner* API is meant to be used inside otherwise *AutoCloseable* implementations to shield the user from native resource leaks if the user forgets to use or can't use try-with-resources. > > Regards, Peter > >> >>> On 16 May 2016, at 00:08, Peter Levart wrote: >>> >>> Hi Roger and others, >>> >>> When the new Cleaner API was created the implementation of >>> Cleanable(s) was split into the low-level abstract >>> [Soft|Weak|Phantom]Cleanable classes to be used internally for >>> purposes where the footprint matters and their corresponding >>> CleanerImpl.[Soft|Weak|Phantom]CleanableRef subclasses used as >>> implementations that take a Runnable cleanup action and are exposed >>> via the public Cleaner API. >>> >>> When thinking of possible JDK internal use cases for the low-level >>> API, I came to the conclusion that [Soft|Weak|Phantom]Cleanable >>> classes are not suitable as is, because in cases where footprint >>> matters, it is usually also the case that the number of >>> [Soft|Weak|Phantom]Cleanable instances created is larger and that >>> construction performance also matters. Especially multi-threaded >>> construction. I'm thinking of the use cases of auto-cleanable >>> concurrent data structures. In such use cases, the present features >>> of [Soft|Weak|Phantom]Cleanable classes, namely the guaranteed >>> just-once cleanup action invocation and keeping the Cleanable >>> instance reachable until the cleanup action is performed, are >>> actually not needed and just present footprint and performance >>> (contention) overhead. They also present an overhead as they don't >>> allow GC to automatically collect the Cleanable instances if the >>> data structure containing them becomes unreachable and corresponding >>> registered cleanup actions obsolete. >>> >>> The mentioned features are important for public Cleaner.Cleanable >>> instances as they are usually used for cleanup of native resources >>> where the performance of their creation is not so drastically >>> important and where there is no intrinsic data structure to hold >>> them reachable. >>> >>> I propose to move those features from the >>> [Soft|Weak|Phantom]Cleanable classes down the hierarchy to the >>> CleanerImpl.[Soft|Weak|Phantom]CleanableRef subclasses: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner.cleanup/webrev.01/ >>> >>> >>> In this change I also removed the >>> CleanerImpl.[Soft|Weak]CleanableRef subclasses as they are not >>> needed and I believe will never be. I also renamed the >>> CleanerImpl.PhantomCleanableRef subclass to >>> CleanerImpl.PhantomCleanableImpl. >>> >>> Changes to the implementation are straightforward. The most work was >>> put into the corresponding test. I did some clean-up to it and also >>> changed it to accommodate for the new behavior of >>> [Soft|Weak|Phantom]Cleanable classes. The changes speak for itself. >>> One of the not-so obvious changes was to replace the >>> CleanableCase.clearRef() action with the >>> CleanableCase.releaseReferent() action. The old clearRef() action >>> did not serve any purpose. Whether this method was called or not, >>> the behavior of the corresponding Cleanable was unchanged as the >>> Reference instance (referenced from the 'ref' field) was always of >>> the same strength as the Cleanable itself. So clearing it could not >>> affect the behavior of the Cleanable. >>> >>> I changed 'ref' to hold a direct reference to the referent and >>> renamed the field to 'referent'. I changed the EV_XXX int constants >>> to Event enum constants with helper methods used in >>> CleanableCase.expectedCleanups() method that now returns the number >>> of expected cleanup invocations - in the PhantomCleanableImpl case >>> this is the number of expected cleanup action invocations while in >>> the plain XxxCleanable subclass cases it is the number of >>> Cleanable.clean() method invocations. I added the no-actions case to >>> both PhantomCleanableImpl and XxxCleanable cases and extended the >>> number and combinations of XxxCleanable cases. >>> >>> The checkCleaned() method was extended to verify that the number of >>> cleanup invocations is *no more* and no less then the expected. >>> >>> See how WeakKey test is now simplified. This is the typical use-case >>> for WeakCleanable I was talking about. >>> >>> >>> So, what do you think of this cleanup? >>> >>> >>> Regards, Peter >>> > > From me at noctarius.com Mon May 16 11:00:15 2016 From: me at noctarius.com (Christoph Engelbert) Date: Mon, 16 May 2016 13:00:15 +0200 Subject: Cleaner cleanup In-Reply-To: <87304630-464d-3a97-19ff-5d2dd3eafb38@gmail.com> References: <8b4dd573-da7b-fd6c-eb49-24f2b15a11cc@gmail.com> <1015E2BE-A93C-46AF-8013-911C5B7DEFC8@noctarius.com> <87304630-464d-3a97-19ff-5d2dd3eafb38@gmail.com> Message-ID: <4EEBBB5D-8136-488A-B710-78638FEFAF95@noctarius.com> Hey Peter, Thanks for your answer. Actually you?re right, makes perfect sense. Somehow it still feels wrong to implement the same pattern (inside lots of classes) over and over again. Inheritance, on the other hand, is not always possible. Chris > On 16 May 2016, at 12:57, Peter Levart wrote: > > Correction in line... > > On 05/16/2016 12:54 PM, Peter Levart wrote: >> Hi Christoph, >> >> >> On 05/16/2016 10:37 AM, Christoph Engelbert wrote: >>> Hey Peter, >>> >>> First of all, I really love this Cleanup API! >>> Anyhow I think it would make sense to have Cleanable extend AutoCloseable for exactly the use case you rendered in your JavaDoc of the Cleaner class. >>> >>> Made up example: >>> public T execute(BufferAction bufferAction) { >>> Buffer buffer = allocateBuffer(); >>> try (Cleanable wrapper = cleaner.register(buffer, Buffer::deallocate) { >>> bufferAction.execute(buffer); >>> } >>> } >>> >>> I agree that you probably want to encapsulate the cleaner registration and cleaning action but for frameworks it might be beneficial to have a common utility method implementing a pattern such as the one above. >>> >>> Chris >> >> I think the Cleaner API is more suitable to be used inside various classes that themselves implement AutoCloseable rather than as an (optional) aspect on top of them. So your example would simply read: >> >> public T execute(BufferAction bufferAction) { >> try (Buffer buffer = allocateBuffer()) { >> bufferAction.execute(buffer); >> } >> } >> >> There's no point in doing both things as in your example: using try-with-resources + the Cleaner API on top. try-with-resources already guarantees cleanup. > > Sorry, the following: >> Cleanable API is meant to be used inside otherwise AutoCleanable implementations to shield the user from native resource leaks if the user forgets to use or can't use try-with-resources. > > Should read: > > Cleaner API is meant to be used inside otherwise AutoCloseable implementations to shield the user from native resource leaks if the user forgets to use or can't use try-with-resources. > >> >> Regards, Peter >> >>> >>>> On 16 May 2016, at 00:08, Peter Levart wrote: >>>> >>>> Hi Roger and others, >>>> >>>> When the new Cleaner API was created the implementation of Cleanable(s) was split into the low-level abstract [Soft|Weak|Phantom]Cleanable classes to be used internally for purposes where the footprint matters and their corresponding CleanerImpl.[Soft|Weak|Phantom]CleanableRef subclasses used as implementations that take a Runnable cleanup action and are exposed via the public Cleaner API. >>>> >>>> When thinking of possible JDK internal use cases for the low-level API, I came to the conclusion that [Soft|Weak|Phantom]Cleanable classes are not suitable as is, because in cases where footprint matters, it is usually also the case that the number of [Soft|Weak|Phantom]Cleanable instances created is larger and that construction performance also matters. Especially multi-threaded construction. I'm thinking of the use cases of auto-cleanable concurrent data structures. In such use cases, the present features of [Soft|Weak|Phantom]Cleanable classes, namely the guaranteed just-once cleanup action invocation and keeping the Cleanable instance reachable until the cleanup action is performed, are actually not needed and just present footprint and performance (contention) overhead. They also present an overhead as they don't allow GC to automatically collect the Cleanable instances if the data structure containing them becomes unreachable and corresponding registered cleanup actions obsolete. >>>> >>>> The mentioned features are important for public Cleaner.Cleanable instances as they are usually used for cleanup of native resources where the performance of their creation is not so drastically important and where there is no intrinsic data structure to hold them reachable. >>>> >>>> I propose to move those features from the [Soft|Weak|Phantom]Cleanable classes down the hierarchy to the CleanerImpl.[Soft|Weak|Phantom]CleanableRef subclasses: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner.cleanup/webrev.01/ >>>> >>>> >>>> In this change I also removed the CleanerImpl.[Soft|Weak]CleanableRef subclasses as they are not needed and I believe will never be. I also renamed the CleanerImpl.PhantomCleanableRef subclass to CleanerImpl.PhantomCleanableImpl. >>>> >>>> Changes to the implementation are straightforward. The most work was put into the corresponding test. I did some clean-up to it and also changed it to accommodate for the new behavior of [Soft|Weak|Phantom]Cleanable classes. The changes speak for itself. One of the not-so obvious changes was to replace the CleanableCase.clearRef() action with the CleanableCase.releaseReferent() action. The old clearRef() action did not serve any purpose. Whether this method was called or not, the behavior of the corresponding Cleanable was unchanged as the Reference instance (referenced from the 'ref' field) was always of the same strength as the Cleanable itself. So clearing it could not affect the behavior of the Cleanable. >>>> >>>> I changed 'ref' to hold a direct reference to the referent and renamed the field to 'referent'. I changed the EV_XXX int constants to Event enum constants with helper methods used in CleanableCase.expectedCleanups() method that now returns the number of expected cleanup invocations - in the PhantomCleanableImpl case this is the number of expected cleanup action invocations while in the plain XxxCleanable subclass cases it is the number of Cleanable.clean() method invocations. I added the no-actions case to both PhantomCleanableImpl and XxxCleanable cases and extended the number and combinations of XxxCleanable cases. >>>> >>>> The checkCleaned() method was extended to verify that the number of cleanup invocations is *no more* and no less then the expected. >>>> >>>> See how WeakKey test is now simplified. This is the typical use-case for WeakCleanable I was talking about. >>>> >>>> >>>> So, what do you think of this cleanup? >>>> >>>> >>>> Regards, Peter >>>> >> >> > From vladimir.x.ivanov at oracle.com Mon May 16 11:52:20 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 16 May 2016 14:52:20 +0300 Subject: RFR 8156485 MethodHandles.varHandleExactInvoker should perform exact checks In-Reply-To: <3CB67D61-5B26-4F05-BF30-45837D69812F@oracle.com> References: <3CB67D61-5B26-4F05-BF30-45837D69812F@oracle.com> Message-ID: <4f19d6d3-d29e-7f42-e544-8358b5f4c908@oracle.com> Looks good. Best regards, Vladimir Ivanov PS: regarding naming, makeVarHandleMethodInvoker is shorter and as informative. Since there are only 2 flavors of invokers for VarHandles (for MHs there are also basic invokers), there's no need to explicitly mention the modes in method names. On 5/10/16 4:36 PM, Paul Sandoz wrote: > Hi, > > Please review: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8156486-varHandleExactInvoker/webrev/ > > A bug slipped in with recent VarHandle implementation improvements, and this was not caught by relevant tests. The MethodHandle returned from MethodHandles.varHandleExactInvoker performed an incorrect match using erased signatures. Ooops. > > I fixed this by consolidating the lambda form generation for exact and generic VH invokers. > > The tests are also updated, primarily to VarHandleTestMethod* (changes to other areas are minor clean ups) to correctly test the 4 ways to obtain a MethodHandle to a VarHandle access mode method, and to correctly differentiate between testing exact and generic invocation. > > Thanks, > Paul. > From claes.redestad at oracle.com Mon May 16 12:20:13 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 16 May 2016 14:20:13 +0200 Subject: Cleaner cleanup In-Reply-To: <8b4dd573-da7b-fd6c-eb49-24f2b15a11cc@gmail.com> References: <8b4dd573-da7b-fd6c-eb49-24f2b15a11cc@gmail.com> Message-ID: <5739BAFD.7090309@oracle.com> Hi Peter, I for one think this looks like a very nice cleanup. The patch drops 5 classes from a minimal VM startup test, which is a welcome improvement. /Claes On 2016-05-16 00:08, Peter Levart wrote: > Hi Roger and others, > > When the new Cleaner API was created the implementation of > Cleanable(s) was split into the low-level abstract > [Soft|Weak|Phantom]Cleanable classes to be used internally for > purposes where the footprint matters and their corresponding > CleanerImpl.[Soft|Weak|Phantom]CleanableRef subclasses used as > implementations that take a Runnable cleanup action and are exposed > via the public Cleaner API. > > When thinking of possible JDK internal use cases for the low-level > API, I came to the conclusion that [Soft|Weak|Phantom]Cleanable > classes are not suitable as is, because in cases where footprint > matters, it is usually also the case that the number of > [Soft|Weak|Phantom]Cleanable instances created is larger and that > construction performance also matters. Especially multi-threaded > construction. I'm thinking of the use cases of auto-cleanable > concurrent data structures. In such use cases, the present features of > [Soft|Weak|Phantom]Cleanable classes, namely the guaranteed just-once > cleanup action invocation and keeping the Cleanable instance reachable > until the cleanup action is performed, are actually not needed and > just present footprint and performance (contention) overhead. They > also present an overhead as they don't allow GC to automatically > collect the Cleanable instances if the data structure containing them > becomes unreachable and corresponding registered cleanup actions > obsolete. > > The mentioned features are important for public Cleaner.Cleanable > instances as they are usually used for cleanup of native resources > where the performance of their creation is not so drastically > important and where there is no intrinsic data structure to hold them > reachable. > > I propose to move those features from the [Soft|Weak|Phantom]Cleanable > classes down the hierarchy to the > CleanerImpl.[Soft|Weak|Phantom]CleanableRef subclasses: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner.cleanup/webrev.01/ > > > In this change I also removed the CleanerImpl.[Soft|Weak]CleanableRef > subclasses as they are not needed and I believe will never be. I also > renamed the CleanerImpl.PhantomCleanableRef subclass to > CleanerImpl.PhantomCleanableImpl. > > Changes to the implementation are straightforward. The most work was > put into the corresponding test. I did some clean-up to it and also > changed it to accommodate for the new behavior of > [Soft|Weak|Phantom]Cleanable classes. The changes speak for itself. > One of the not-so obvious changes was to replace the > CleanableCase.clearRef() action with the > CleanableCase.releaseReferent() action. The old clearRef() action did > not serve any purpose. Whether this method was called or not, the > behavior of the corresponding Cleanable was unchanged as the Reference > instance (referenced from the 'ref' field) was always of the same > strength as the Cleanable itself. So clearing it could not affect the > behavior of the Cleanable. > > I changed 'ref' to hold a direct reference to the referent and renamed > the field to 'referent'. I changed the EV_XXX int constants to Event > enum constants with helper methods used in > CleanableCase.expectedCleanups() method that now returns the number of > expected cleanup invocations - in the PhantomCleanableImpl case this > is the number of expected cleanup action invocations while in the > plain XxxCleanable subclass cases it is the number of > Cleanable.clean() method invocations. I added the no-actions case to > both PhantomCleanableImpl and XxxCleanable cases and extended the > number and combinations of XxxCleanable cases. > > The checkCleaned() method was extended to verify that the number of > cleanup invocations is *no more* and no less then the expected. > > See how WeakKey test is now simplified. This is the typical use-case > for WeakCleanable I was talking about. > > > So, what do you think of this cleanup? > > > Regards, Peter > From sean.coffey at oracle.com Mon May 16 12:44:11 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 16 May 2016 13:44:11 +0100 Subject: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code Message-ID: <5739C09B.7000302@oracle.com> Some extra capturing of context in exception handling. I've re-based the original suggested patch and added some minor edits. https://bugs.openjdk.java.net/browse/JDK-8151832 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832/webrev/index.html -- Regards, Sean. From Alan.Bateman at oracle.com Mon May 16 12:51:18 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 May 2016 13:51:18 +0100 Subject: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code In-Reply-To: <5739C09B.7000302@oracle.com> References: <5739C09B.7000302@oracle.com> Message-ID: <5739C246.9000908@oracle.com> On 16/05/2016 13:44, Se?n Coffey wrote: > Some extra capturing of context in exception handling. I've re-based > the original suggested patch and added some minor edits. > > https://bugs.openjdk.java.net/browse/JDK-8151832 > webrev : > http://cr.openjdk.java.net/~coffeys/webrev.8151832/webrev/index.html > Would it be possible to leave out the changes to the source files in the module and loader directories for now? We have many changes to this code coming that replace parts of this code and I think would be better to do a pass over the exceptions in a few months once the code is more stable. -Alan. From sean.coffey at oracle.com Mon May 16 13:45:05 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 16 May 2016 14:45:05 +0100 Subject: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code In-Reply-To: <5739C246.9000908@oracle.com> References: <5739C09B.7000302@oracle.com> <5739C246.9000908@oracle.com> Message-ID: <5739CEE1.2090903@oracle.com> On 16/05/16 13:51, Alan Bateman wrote: > On 16/05/2016 13:44, Se?n Coffey wrote: >> Some extra capturing of context in exception handling. I've re-based >> the original suggested patch and added some minor edits. >> >> https://bugs.openjdk.java.net/browse/JDK-8151832 >> webrev : >> http://cr.openjdk.java.net/~coffeys/webrev.8151832/webrev/index.html >> > Would it be possible to leave out the changes to the source files in > the module and loader directories for now? We have many changes to > this code coming that replace parts of this code and I think would be > better to do a pass over the exceptions in a few months once the code > is more stable. Yes, I can hold off. I figured such improvements might help people while they adopt and set up modules but let's cancel until the code stabilizes some more! regards, Sean. > > -Alan. From jaroslav at kamenik.cz Mon May 16 13:48:00 2016 From: jaroslav at kamenik.cz (=?UTF-8?Q?Jaroslav_Kamen=C3=ADk?=) Date: Mon, 16 May 2016 15:48:00 +0200 Subject: Helpers for MethodHandles.byteArrayViewVarHandle VarHandle Message-ID: Hi, what do you thing about adding helper methods for this kind of VarHandle? It would be nice to have something like Long.getFrom[LE/BE](byte[] arr, int index) // LE/BE -> endianity Long.setTo[LE/BE](long val, byte[] arr, int index) or Arrays.getLongFrom[LE/BE](byte[] arr, int index) Arrays.setLongTo[LE/BE](long val, byte[] arr, int index) Jaroslav From Alan.Bateman at oracle.com Mon May 16 14:10:59 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 May 2016 15:10:59 +0100 Subject: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code In-Reply-To: <5739CEE1.2090903@oracle.com> References: <5739C09B.7000302@oracle.com> <5739C246.9000908@oracle.com> <5739CEE1.2090903@oracle.com> Message-ID: <5739D4F3.70801@oracle.com> On 16/05/2016 14:45, Se?n Coffey wrote: > > On 16/05/16 13:51, Alan Bateman wrote: >> On 16/05/2016 13:44, Se?n Coffey wrote: >>> Some extra capturing of context in exception handling. I've re-based >>> the original suggested patch and added some minor edits. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8151832 >>> webrev : >>> http://cr.openjdk.java.net/~coffeys/webrev.8151832/webrev/index.html >>> >> Would it be possible to leave out the changes to the source files in >> the module and loader directories for now? We have many changes to >> this code coming that replace parts of this code and I think would be >> better to do a pass over the exceptions in a few months once the code >> is more stable. > Yes, I can hold off. I figured such improvements might help people > while they adopt and set up modules but let's cancel until the code > stabilizes some more! > Thanks. The rest mostly look okay although I think several of these exceptions in the jimage code need to re-examined - for example IOOBE is thrown in several places where the root cause must be a corrupt or truncated jimage file. -Alan From peter.levart at gmail.com Mon May 16 14:32:55 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 16 May 2016 16:32:55 +0200 Subject: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more In-Reply-To: References: <56B72242.7050102@gmail.com> <7BA56B2F-C1C6-4EAF-B900-A825C6B602EF@oracle.com> <56CA080F.6010308@gmail.com> <56CB83FF.4010808@Oracle.com> <56CC8A4A.9080303@gmail.com> <56CEAC28.80802@gmail.com> <56CEB49A.4090000@oracle.com> <56CEC6A5.3070202@gmail.com> <56D0C5F5.7060509@Oracle.com> <56DC29DE.4040006@gmail.com> <059F3798-66D4-4300-B618-09868A04E3DC@oracle.com> <56E09299.2050900@gmail.com> <8EDD817B-F124-4613-9EEE-7865EE67037D@oracle.com> <56F96778.5020202@gmail.com> <56FE914E.2070804@gmail.com> <56FE9D14.8010404@gmail.com> <56FEA5FF.4060801@gmail.com> <56FEED59.7090906@Oracle.com> <56FF04B5.2030507@oracle.com> <56FFABED.2060708@gmail.com> <5702E18D.7010807@Oracle.com> <5703CE96.4040001@gmail.com> <5704B01F.4070406@gmail.com> <570514C1.5000507@Oracle.com> Message-ID: Hi Martin, As I have been studying the CleanerTest too recently, let me comment on some questions... On 05/09/2016 06:34 PM, Martin Buchholz wrote: > --- > > Assert.assertEquals(map.get(k2), data, "value should be found > in the map"); > key = null; > System.gc(); > Assert.assertNotEquals(map.get(k2), data, "value should not be > found in the map"); > > I initially expected this to fail at least intermittently because a > cleaner may not yet have removed the entry from the map. ...The cleaner need not remove the entry from the map in order for this code to succeed. The sufficient condition is that GC discovers the k1 and k2 WeakReference(s) and clears them. When a WeakKey is cleared it is only equal to itself since the referent is gone (see equals() method). So it is important to ensure that the referent remains reachable at least until the 1st assert above (perhaps by inserting Reference.reachabilityFence(key) just after it)... > > Why aren't we calling whitebox.fullGC() everywhere where System.gc() > is being called? > > What's particularly confusing here is that the WeakKey is not actually > surely removed from the map, but instead two WeakKeys that may have > been equal become non-equal when they get cleared by the gc. Which is > generally bad practice. Which suggests we wouldn't implement a real > public concurrent map of weak keys this way. Why not? We don't need to lookup the value after the WeakKey(s) are cleared, since by definition, we can't reach their referent any more (the 'key'). But the instance of the WeakKey that is inserted in the map can still be removed because it is the same instance that is referenced by the WeakCleanable and a cleared WeakKey is still equal to itself. So we have the following invariants: - while the key (the referent) is still reachable, multiple WeakKeys with the same referent are equal among themselves so a WeakKey can be constructed that is equal to some other WeakKey in the map. - after the key (the referent) becomes weakly-reachable and GC kicks-in, all WeakReferences with referents from the selected set are cleared atomically, including WeakKey(s) and WeakCleanable(s) refering to the same key referent, so only the instance of the WeakKey that is inserted in the map can be used to remove the stale entry from it. You can find a simpler implementation of WeakKey in my "Cleaner cleanup" proposal where WeakKey is a subclass of WeakCleanable and simply removes itself from the map when its clean() method is called by the Cleaner thread... > > --- > > WeakCleanable and friends are defined in jdk.internal, don't appear to > be used at all, and since there are fields in CleanerImpl, they impose > a hidden tax on all users of Cleaner. I don't see why there is both > WeakCleanable (using subclassing) and WeakCleanableRef (using a > provided Runnable). Is a compelling use case for WeakCleanables > forthcoming? I have a few ideas that I would like to present, but I first wanted to propose making [Soft|Weak]Cleanable(s) even more low-level to make those use cases feasible. See the "Cleaner cleanup" thread for more info on that. Regards, Peter From iris.clark at oracle.com Mon May 16 17:52:33 2016 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 16 May 2016 10:52:33 -0700 (PDT) Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version In-Reply-To: <1554585217.477366.1463182296059.JavaMail.zimbra@u-pem.fr> References: <1554585217.477366.1463182296059.JavaMail.zimbra@u-pem.fr> Message-ID: Hi, Remi. Thanks for taking the time to review this change. > java.lang.Runtime.Version is used during the boot process I don?t think that Runtime.Version is used during boot because I'm not seeing it loaded with a small test program invoked with "java -verbose:class Hi". In fact, I'm not seeing a difference in the number of loaded classes between promoted build 118 and my build for 8144062 (based on jdk9/dev). See appended stats. If my test program is in a JAR file, then more classes are loaded including Runtime.Version; however the equivalent number of classes are loaded before my changes too. The performance problem identified by the following bug should resolve this issue: 8150678: JarFile stream() and entries(0 methods need performance enhancement https://bugs.openjdk.java.net/browse/JDK-8150678 Regards, Iris ----- $ cat Hi.java public class Hi { public static void main(String ... args) { System.out.println("hi"); System.exit(42); } $ wc Hi.ver* 501 2000 39758 Hi.verbose-118 576 2300 45915 Hi.verbose-118-jar 501 2000 39734 Hi.verbose-8144062 576 2300 45905 Hi.verbose-8144062-jar 2154 8600 171312 total -----Original Message----- From: Remi Forax [mailto:forax at univ-mlv.fr] Sent: Friday, May 13, 2016 4:32 PM To: Iris Clark Cc: Java Core Libs; compiler-dev at openjdk.java.net; verona-dev at openjdk.java.net Subject: Re: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version Hi Iris, is there a way to avoid to use regex when parsing the version ? java.lang.Runtime.Version is used during the boot process, so now every Java programs loads a bunch of classes related to java.util.regex even if they do not use any regex or use another regex engine (like Nashorn or JRuby). regards, R?mi ----- Mail original ----- > De: "Iris Clark" > ?: "Java Core Libs" , > compiler-dev at openjdk.java.net > Cc: verona-dev at openjdk.java.net > Envoy?: Samedi 14 Mai 2016 01:20:23 > Objet: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version > > Hi. > > Reviving this work from a few months back. > > Please review the following changes to move jdk.Version to > java.lang.Runtime.Version. > > Bug > > 8144062: Move jdk.Version to java.lang.Runtime.Version > https://bugs.openjdk.java.net/browse/JDK-8144062 > > webrev > > http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/ > > When jdk.Version was initially pushed in jdk-9+1-5, it was Improperly > exported by java.base. After exploring a few options, the best choice > was to move jdk.Version to java.lang.Runtime.Version (a nested class > of Runtime). By making Version an SE API, it may be exported by the > java.base module. > > As part of the move, a limited number of chnages were made to the > Version class: > > - Change package name and class declaration (to static) > - Eliminate use of "JDK" when describing a Java SE API > - Initial clarifications related to zeros (trailing vs. > Internal components) > - Small typographical and grammatical enhancements > - Indentation > > The complete Runtime.Version specification is available here: > > > http://cr.openjdk.java.net/~iris/verona/8144062/doc.1/java/lang/Runtim > e.Version.html > > The old jdk.Version.current() was replaced with Runtime.version(). > > In System.getProperties(), we indicate which version-related system > properties may be supported by Runtime.Version. > > The remaining jdk and langtools file changes are all side-effects of > changing jdk.Version.current() to Runtime.version(). > > Thanks, > Iris > From forax at univ-mlv.fr Mon May 16 18:38:03 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 16 May 2016 20:38:03 +0200 (CEST) Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version In-Reply-To: References: <1554585217.477366.1463182296059.JavaMail.zimbra@u-pem.fr> Message-ID: <103793588.142588.1463423883417.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Iris Clark" > ?: "Remi Forax" > Cc: "Java Core Libs" , compiler-dev at openjdk.java.net, verona-dev at openjdk.java.net > Envoy?: Lundi 16 Mai 2016 19:52:33 > Objet: RE: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version > > Hi, Remi. Hi Iris, > > Thanks for taking the time to review this change. > > > java.lang.Runtime.Version is used during the boot process > > I don?t think that Runtime.Version is used during boot because > I'm not seeing it loaded with a small test program invoked with > "java -verbose:class Hi". In fact, I'm not seeing a difference > in the number of loaded classes between promoted build 118 and > my build for 8144062 (based on jdk9/dev). See appended stats. > > If my test program is in a JAR file, then more classes are > loaded including Runtime.Version; however the equivalent number > of classes are loaded before my changes too. I've double checked and yes, Runtime.Version is not loaded by default, my bad on this, it's own runtime that has an indirect dependency on Runtime.Version. > > The performance problem identified by the following bug should > resolve this issue: > > 8150678: JarFile stream() and entries(0 methods need performance > enhancement > https://bugs.openjdk.java.net/browse/JDK-8150678 > > Regards, > Iris regards, R?mi > > ----- > $ cat Hi.java > public class Hi { > public static void main(String ... args) { > System.out.println("hi"); > System.exit(42); > } > $ wc Hi.ver* > 501 2000 39758 Hi.verbose-118 > 576 2300 45915 Hi.verbose-118-jar > 501 2000 39734 Hi.verbose-8144062 > 576 2300 45905 Hi.verbose-8144062-jar > 2154 8600 171312 total > > -----Original Message----- > From: Remi Forax [mailto:forax at univ-mlv.fr] > Sent: Friday, May 13, 2016 4:32 PM > To: Iris Clark > Cc: Java Core Libs; compiler-dev at openjdk.java.net; > verona-dev at openjdk.java.net > Subject: Re: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version > > Hi Iris, > is there a way to avoid to use regex when parsing the version ? > > java.lang.Runtime.Version is used during the boot process, so now every Java > programs loads a bunch of classes related to java.util.regex even if they do > not use any regex or use another regex engine (like Nashorn or JRuby). > > regards, > R?mi > > ----- Mail original ----- > > De: "Iris Clark" > > ?: "Java Core Libs" , > > compiler-dev at openjdk.java.net > > Cc: verona-dev at openjdk.java.net > > Envoy?: Samedi 14 Mai 2016 01:20:23 > > Objet: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version > > > > Hi. > > > > Reviving this work from a few months back. > > > > Please review the following changes to move jdk.Version to > > java.lang.Runtime.Version. > > > > Bug > > > > 8144062: Move jdk.Version to java.lang.Runtime.Version > > https://bugs.openjdk.java.net/browse/JDK-8144062 > > > > webrev > > > > http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/ > > > > When jdk.Version was initially pushed in jdk-9+1-5, it was Improperly > > exported by java.base. After exploring a few options, the best choice > > was to move jdk.Version to java.lang.Runtime.Version (a nested class > > of Runtime). By making Version an SE API, it may be exported by the > > java.base module. > > > > As part of the move, a limited number of chnages were made to the > > Version class: > > > > - Change package name and class declaration (to static) > > - Eliminate use of "JDK" when describing a Java SE API > > - Initial clarifications related to zeros (trailing vs. > > Internal components) > > - Small typographical and grammatical enhancements > > - Indentation > > > > The complete Runtime.Version specification is available here: > > > > > > http://cr.openjdk.java.net/~iris/verona/8144062/doc.1/java/lang/Runtim > > e.Version.html > > > > The old jdk.Version.current() was replaced with Runtime.version(). > > > > In System.getProperties(), we indicate which version-related system > > properties may be supported by Runtime.Version. > > > > The remaining jdk and langtools file changes are all side-effects of > > changing jdk.Version.current() to Runtime.version(). > > > > Thanks, > > Iris > > > From martinrb at google.com Mon May 16 18:53:33 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 16 May 2016 11:53:33 -0700 Subject: RFR: JDK-8157069: Assorted ZipFile improvements Message-ID: Hi Xueming, https://bugs.openjdk.java.net/browse/JDK-8157069 http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ZipFile-assortment/ Hopefully other improvements later. BTW, I notice that the CEN is stored in a byte[], and someday someone will create a zip file with a CEN that won't fit! From xueming.shen at oracle.com Mon May 16 19:55:01 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 16 May 2016 12:55:01 -0700 Subject: RFR: JDK-8157069: Assorted ZipFile improvements In-Reply-To: References: Message-ID: <573A2595.8010600@oracle.com> On 05/16/2016 11:53 AM, Martin Buchholz wrote: > Hi Xueming, > > https://bugs.openjdk.java.net/browse/JDK-8157069 > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ZipFile-assortment/ > > Hopefully other improvements later. > looks fine. yes, someone will have to deal with a > byte[] cen table, some day. -sherman From stuart.marks at oracle.com Mon May 16 22:48:54 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 16 May 2016 15:48:54 -0700 Subject: RFR(s): 8133977 add specification for serial form of immutable collections Message-ID: <704c44ef-e3e7-d483-5dcd-b7e19bbbf6fc@oracle.com> Hi all, Please review this changeset that adds specifications of the serialized forms (really, a single serialization proxy class) for the immutable collections implementation. There are no code changes in this changeset, just documentation. It's somewhat odd, but the class doc for the serialization proxy isn't actually included in the serialized-form.html output. I had to jigger around the method doc for readResolve() to include some general information about the class. I also added links manually from the List, Map, and Set interfaces to the serialized form and vice-versa. I'm not aware of another way for a private class to link to its (proxied) serialized form. I was able to coerce specdiff into giving a diff of serialized-form.html. It's not very convenient, though; like serialized-form.html, the html diff is one big file. The only difference is the addition of java.util.CollSer. Webrev: http://cr.openjdk.java.net/~smarks/reviews/8133977/webrev.0/ API specdiff: http://cr.openjdk.java.net/~smarks/reviews/8133977/specdiff.0/api.specdiff/overview-summary.html serialized-form.html diff: http://cr.openjdk.java.net/~smarks/reviews/8133977/specdiff.0/serial.specdiff/specdiff-summary.html Thanks, s'marks From aleksej.efimov at oracle.com Mon May 16 23:39:43 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Tue, 17 May 2016 02:39:43 +0300 Subject: RFR [9]: 8072579: XjcOptionalPropertyTest.java creates files in test.src Message-ID: <573A5A3F.7050702@oracle.com> Hi, Please, help to review XjcOptionalPropertyTest test modification bug [1]. The list of applied changes: 1. Test files are now generated in jtreg work directory (scratch), instead of test source folder. 2. Shell script was replaced with java code: xjc tool is now invoked via jdk.testlibrary.JDKToolLauncher. 3. Compilation of xjc generated classes is done with usage of JDKToolLauncher. Webrev: http://cr.openjdk.java.net/~aefimov/8072579/9/00 With Best Regards, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8072579 From aleksej.efimov at oracle.com Mon May 16 23:57:31 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Tue, 17 May 2016 02:57:31 +0300 Subject: RFR [9]: 8157096: [TEST_BUG] test/javax/xml/bind/xjc/8145039/JaxbMarshallTest.java is skipped by jtreg Message-ID: <573A5E6B.2070202@oracle.com> Hi, Please review the changes to test/javax/xml/bind/xjc/8145039/JaxbMarshallTest.java: 1. The test is skipped by JTREG due to incorrect module name in jtreg @modules tag: javax.xml.bind -> java.xml.bind 2. The compilation of XJC generated classes now requires "-addmods java.xml.bind" argument to be passed to javac tool. The test was executed with JTREG and passed. Webrev: http://cr.openjdk.java.net/~aefimov/8157096/9/00 JBS: https://bugs.openjdk.java.net/browse/JDK-8157096 With Best Regards, Aleksej From martinrb at google.com Tue May 17 03:19:23 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 16 May 2016 20:19:23 -0700 Subject: Can an object be finalized while still weakly reachable? Message-ID: I have some evidence that an object's finalize method can run while a weak reference pointing to it is not yet cleared, which surprised me. E.g. class F { protected void finalize() { assert wref.get() != this; } } static WeakReference wref = new WeakReference(new F()); If this is a bug, I can try to give y'all a repro recipe. If not, we should fix the docs """When the weak references to a weakly-reachable object are cleared, the object becomes eligible for finalization.""" (It's also quite possible I made a mistake diagnosing this) From nadeesh.tv at oracle.com Tue May 17 04:18:26 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Tue, 17 May 2016 09:48:26 +0530 Subject: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields In-Reply-To: References: Message-ID: <573A9B92.60201@oracle.com> Hi Bhanu, I think you should add a test case comparing the return value of getFrom() ( Not an official reviewer) Regards, Nadeesh On 5/16/2016 11:46 AM, Bhanu Gopularam wrote: > Hi all, > > Could you please review fix for following issue. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8156718 > > Solution: Added tck tests for validating getFrom method for unsupported non-Iso temporal fields > > Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.00/ > > Thanks, > Bhanu -- Thanks and Regards, Nadeesh TV From peter.levart at gmail.com Tue May 17 06:49:11 2016 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 17 May 2016 08:49:11 +0200 Subject: Can an object be finalized while still weakly reachable? In-Reply-To: References: Message-ID: <298d69ca-a7bc-2798-7f88-2bdff21b78a7@gmail.com> Hi Martin, On 05/17/2016 05:19 AM, Martin Buchholz wrote: > I have some evidence that an object's finalize method can run while a > weak reference pointing to it is not yet cleared, which surprised me. > > E.g. > class F { protected void finalize() { assert wref.get() != this; } } > static WeakReference wref = new WeakReference(new F()); > > If this is a bug, I can try to give y'all a repro recipe. > If not, we should fix the docs > """When the weak references to a weakly-reachable object are cleared, > the object becomes eligible for finalization.""" > > (It's also quite possible I made a mistake diagnosing this) What can happen with above code is that you get a NPE from dereferencing wref in finlailze(). In case NPE is not thrown and the program constructs only a single instance of F then assert should succeed. It is possible that you made a mistake. Can you post the real code? Regards, Peter From peter.levart at gmail.com Tue May 17 07:29:04 2016 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 17 May 2016 09:29:04 +0200 Subject: RFR(s): 8133977 add specification for serial form of immutable collections In-Reply-To: <704c44ef-e3e7-d483-5dcd-b7e19bbbf6fc@oracle.com> References: <704c44ef-e3e7-d483-5dcd-b7e19bbbf6fc@oracle.com> Message-ID: Hi Stuart, On 05/17/2016 12:48 AM, Stuart Marks wrote: > Hi all, > > Please review this changeset that adds specifications of the > serialized forms (really, a single serialization proxy class) for the > immutable collections implementation. There are no code changes in > this changeset, just documentation. > > It's somewhat odd, but the class doc for the serialization proxy isn't > actually included in the serialized-form.html output. I had to jigger > around the method doc for readResolve() to include some general > information about the class. > > I also added links manually from the List, Map, and Set interfaces to > the serialized form and vice-versa. I'm not aware of another way for a > private class to link to its (proxied) serialized form. > > I was able to coerce specdiff into giving a diff of > serialized-form.html. It's not very convenient, though; like > serialized-form.html, the html diff is one big file. The only > difference is the addition of java.util.CollSer. > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8133977/webrev.0/ > > API specdiff: > > > http://cr.openjdk.java.net/~smarks/reviews/8133977/specdiff.0/api.specdiff/overview-summary.html > > > serialized-form.html diff: > > > http://cr.openjdk.java.net/~smarks/reviews/8133977/specdiff.0/serial.specdiff/specdiff-summary.html > > > Thanks, > > s'marks Perhaps java.util.CollSer could be promoted to be a public class. It does, after all, specify the API (serialization form == API). I don't see a point in hiding it and then jiggering around the method doc for readResolve()... You could just restrict its use by keeping the constructor(s) package-private... What do you think? Regards, Peter From martinrb at google.com Tue May 17 07:55:19 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 17 May 2016 00:55:19 -0700 Subject: Can an object be finalized while still weakly reachable? In-Reply-To: <298d69ca-a7bc-2798-7f88-2bdff21b78a7@gmail.com> References: <298d69ca-a7bc-2798-7f88-2bdff21b78a7@gmail.com> Message-ID: Thanks, Peter. My current theory is indeed that I made a mistake, and have encountered my first real finalization resurrection bug. ZipFile + Inflater have 4 finalize methods and a WeakHashMap in play! My static reference was finalized because it used to be unreachable, not because it is now weakly reachable! On Mon, May 16, 2016 at 11:49 PM, Peter Levart wrote: > Hi Martin, > > > > On 05/17/2016 05:19 AM, Martin Buchholz wrote: >> >> I have some evidence that an object's finalize method can run while a >> weak reference pointing to it is not yet cleared, which surprised me. >> >> E.g. >> class F { protected void finalize() { assert wref.get() != this; } } >> static WeakReference wref = new WeakReference(new F()); >> >> If this is a bug, I can try to give y'all a repro recipe. >> If not, we should fix the docs >> """When the weak references to a weakly-reachable object are cleared, >> the object becomes eligible for finalization.""" >> >> (It's also quite possible I made a mistake diagnosing this) > > > What can happen with above code is that you get a NPE from dereferencing > wref in finlailze(). In case NPE is not thrown and the program constructs > only a single instance of F then assert should succeed. > > It is possible that you made a mistake. Can you post the real code? > > Regards, Peter > From huaming.li at oracle.com Tue May 17 08:04:19 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Tue, 17 May 2016 16:04:19 +0800 Subject: JDK 9 RFR of JDK-8157006/8157011: Problem list java/io/pathNames/GeneralWin32.java and tools/pack200/TestNormal.java In-Reply-To: <57397948.2020401@oracle.com> References: <57397948.2020401@oracle.com> Message-ID: <573AD083.7010202@oracle.com> Would you please review the change to problem list 2 frequently failing tests. Thank you -Hamlin On 2016/5/16 15:39, Hamlin Li wrote: > java/io/pathNames/GeneralWin32.java > has been seen to fail with high frequency on windows. Until > JDK-8156595 is addressed, the test should be problem listed. > bug: https://bugs.openjdk.java.net/browse/JDK-8157006 > > tools/pack200/TestNormal.java > has been seen to fail with some frequency on windows. Until > JDK-8156807 is addressed, the test should be problem listed. > bug: https://bugs.openjdk.java.net/browse/JDK-8157011 > > webrev: http://cr.openjdk.java.net/~mli/8157006/webrev.00/ > > Thank you > -Hamlin From scolebourne at joda.org Tue May 17 08:55:43 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 17 May 2016 09:55:43 +0100 Subject: RFR(s): 8133977 add specification for serial form of immutable collections In-Reply-To: References: <704c44ef-e3e7-d483-5dcd-b7e19bbbf6fc@oracle.com> Message-ID: CollSer should not be public, especially not just for serialization reasons. Stuart, I disagree with using an int for the flags, it should be a byte. If you need future expansion you can use 0xff to indicate it with the parser reacting accordingly. That is the strategy for JSR 310 Stephen On 17 May 2016 8:29 a.m., "Peter Levart" wrote: Hi Stuart, On 05/17/2016 12:48 AM, Stuart Marks wrote: > Hi all, > > Please review this changeset that adds specifications of the serialized > forms (really, a single serialization proxy class) for the immutable > collections implementation. There are no code changes in this changeset, > just documentation. > > It's somewhat odd, but the class doc for the serialization proxy isn't > actually included in the serialized-form.html output. I had to jigger > around the method doc for readResolve() to include some general information > about the class. > > I also added links manually from the List, Map, and Set interfaces to the > serialized form and vice-versa. I'm not aware of another way for a private > class to link to its (proxied) serialized form. > > I was able to coerce specdiff into giving a diff of serialized-form.html. > It's not very convenient, though; like serialized-form.html, the html diff > is one big file. The only difference is the addition of java.util.CollSer. > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8133977/webrev.0/ > > API specdiff: > > > > http://cr.openjdk.java.net/~smarks/reviews/8133977/specdiff.0/api.specdiff/overview-summary.html > > serialized-form.html diff: > > > > http://cr.openjdk.java.net/~smarks/reviews/8133977/specdiff.0/serial.specdiff/specdiff-summary.html > > Thanks, > > s'marks > Perhaps java.util.CollSer could be promoted to be a public class. It does, after all, specify the API (serialization form == API). I don't see a point in hiding it and then jiggering around the method doc for readResolve()... You could just restrict its use by keeping the constructor(s) package-private... What do you think? Regards, Peter From paul.sandoz at oracle.com Tue May 17 10:31:01 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 17 May 2016 12:31:01 +0200 Subject: Helpers for MethodHandles.byteArrayViewVarHandle VarHandle In-Reply-To: References: Message-ID: Hi Jaroslav, I would prefer not to spread such functionality beyond that of ByteBuffer and the VarHandle producing methods on MethodHandles. It?s an advanced feature so think ok if less visible. Note at the moment a VarHandle produced for byte[]/ByteBuffer view is not cached but it is certainly possible to do so. ? Separately, i may revisit the signatures for access to also include an alignment-offset argument (which is expected to be constant when looping) in addition to the index (e.g. byte-index = ao + (i << LOG_2_UNIT_SIZE)). Thus bringing alignment into the foreground where it is harder to forget about or ignore. Paul. > On 16 May 2016, at 15:48, Jaroslav Kamen?k wrote: > > Hi, > > what do you thing about adding helper methods for this kind of VarHandle? > > It would be nice to have something like > > Long.getFrom[LE/BE](byte[] arr, int index) // LE/BE -> endianity > Long.setTo[LE/BE](long val, byte[] arr, int index) > > or > > Arrays.getLongFrom[LE/BE](byte[] arr, int index) > Arrays.setLongTo[LE/BE](long val, byte[] arr, int index) > > > Jaroslav From paul.sandoz at oracle.com Tue May 17 10:31:23 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 17 May 2016 12:31:23 +0200 Subject: RFR 8156485 MethodHandles.varHandleExactInvoker should perform exact checks In-Reply-To: <4f19d6d3-d29e-7f42-e544-8358b5f4c908@oracle.com> References: <3CB67D61-5B26-4F05-BF30-45837D69812F@oracle.com> <4f19d6d3-d29e-7f42-e544-8358b5f4c908@oracle.com> Message-ID: > On 16 May 2016, at 13:52, Vladimir Ivanov wrote: > > Looks good. > Thanks. > Best regards, > Vladimir Ivanov > > PS: regarding naming, makeVarHandleMethodInvoker is shorter and as informative. Since there are only 2 flavors of invokers for VarHandles (for MHs there are also basic invokers), there's no need to explicitly mention the modes in method names. > I renamed the method as you suggest. (FWIW the naming consistency is a little wonky with MHs with generic/general etc as in makeExactOrGeneralInvoker, but i resisted renaming that for now) Paul. From peter.levart at gmail.com Tue May 17 10:33:38 2016 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 17 May 2016 12:33:38 +0200 Subject: RFR(s): 8133977 add specification for serial form of immutable collections In-Reply-To: References: <704c44ef-e3e7-d483-5dcd-b7e19bbbf6fc@oracle.com> Message-ID: <562b5874-bfaf-c2d7-d498-b084f67253df@gmail.com> On 05/17/2016 10:55 AM, Stephen Colebourne wrote: > CollSer should not be public, especially not just for serialization > reasons. I don't see a compelling reason why. Javadocs mention it by name. By making it Serializable, it is effectively public, so it can't go away or be renamed. What is gained by hiding it? Regards, Peter > > Stuart, I disagree with using an int for the flags, it should be a byte. If > you need future expansion you can use 0xff to indicate it with the parser > reacting accordingly. That is the strategy for JSR 310 > > Stephen > On 17 May 2016 8:29 a.m., "Peter Levart" wrote: > > Hi Stuart, > > > > On 05/17/2016 12:48 AM, Stuart Marks wrote: > >> Hi all, >> >> Please review this changeset that adds specifications of the serialized >> forms (really, a single serialization proxy class) for the immutable >> collections implementation. There are no code changes in this changeset, >> just documentation. >> >> It's somewhat odd, but the class doc for the serialization proxy isn't >> actually included in the serialized-form.html output. I had to jigger >> around the method doc for readResolve() to include some general information >> about the class. >> >> I also added links manually from the List, Map, and Set interfaces to the >> serialized form and vice-versa. I'm not aware of another way for a private >> class to link to its (proxied) serialized form. >> >> I was able to coerce specdiff into giving a diff of serialized-form.html. >> It's not very convenient, though; like serialized-form.html, the html diff >> is one big file. The only difference is the addition of java.util.CollSer. >> >> Webrev: >> >> http://cr.openjdk.java.net/~smarks/reviews/8133977/webrev.0/ >> >> API specdiff: >> >> >> >> http://cr.openjdk.java.net/~smarks/reviews/8133977/specdiff.0/api.specdiff/overview-summary.html >> >> serialized-form.html diff: >> >> >> >> http://cr.openjdk.java.net/~smarks/reviews/8133977/specdiff.0/serial.specdiff/specdiff-summary.html >> >> Thanks, >> >> s'marks >> > Perhaps java.util.CollSer could be promoted to be a public class. It does, > after all, specify the API (serialization form == API). I don't see a point > in hiding it and then jiggering around the method doc for readResolve()... > You could just restrict its use by keeping the constructor(s) > package-private... > > What do you think? > > Regards, Peter From chris.hegarty at oracle.com Tue May 17 10:43:02 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 17 May 2016 11:43:02 +0100 Subject: RFR(s): 8133977 add specification for serial form of immutable collections In-Reply-To: References: <704c44ef-e3e7-d483-5dcd-b7e19bbbf6fc@oracle.com> Message-ID: <90EB34AC-5AFC-4972-9EAB-04072F54F640@oracle.com> On 17 May 2016, at 09:55, Stephen Colebourne wrote: > CollSer should not be public, especially not just for serialization > reasons. Right, and I see no reason to refer to it by name in the javadoc, the link should be sufficient. > Stuart, I disagree with using an int for the flags, it should be a byte. If > you need future expansion you can use 0xff to indicate it with the parser > reacting accordingly. That is the strategy for JSR 310 The JSR 310 Serialization framework is a little more involved, as you know. I wonder if it is worth following that pattern more closely here? That way java.util.Ser could be a generic proxy for all new Serializable types in the java.util package, and not just the immutable collections. The 310 pattern also results in a reasonable place to document the serial form. -Chris. > Stephen > On 17 May 2016 8:29 a.m., "Peter Levart" wrote: > > Hi Stuart, > > > > On 05/17/2016 12:48 AM, Stuart Marks wrote: > >> Hi all, >> >> Please review this changeset that adds specifications of the serialized >> forms (really, a single serialization proxy class) for the immutable >> collections implementation. There are no code changes in this changeset, >> just documentation. >> >> It's somewhat odd, but the class doc for the serialization proxy isn't >> actually included in the serialized-form.html output. I had to jigger >> around the method doc for readResolve() to include some general information >> about the class. >> >> I also added links manually from the List, Map, and Set interfaces to the >> serialized form and vice-versa. I'm not aware of another way for a private >> class to link to its (proxied) serialized form. >> >> I was able to coerce specdiff into giving a diff of serialized-form.html. >> It's not very convenient, though; like serialized-form.html, the html diff >> is one big file. The only difference is the addition of java.util.CollSer. >> >> Webrev: >> >> http://cr.openjdk.java.net/~smarks/reviews/8133977/webrev.0/ >> >> API specdiff: >> >> >> >> http://cr.openjdk.java.net/~smarks/reviews/8133977/specdiff.0/api.specdiff/overview-summary.html >> >> serialized-form.html diff: >> >> >> >> http://cr.openjdk.java.net/~smarks/reviews/8133977/specdiff.0/serial.specdiff/specdiff-summary.html >> >> Thanks, >> >> s'marks >> > > Perhaps java.util.CollSer could be promoted to be a public class. It does, > after all, specify the API (serialization form == API). I don't see a point > in hiding it and then jiggering around the method doc for readResolve()... > You could just restrict its use by keeping the constructor(s) > package-private... > > What do you think? > > Regards, Peter From scolebourne at joda.org Tue May 17 11:38:23 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 17 May 2016 12:38:23 +0100 Subject: RFR(s): 8133977 add specification for serial form of immutable collections In-Reply-To: <90EB34AC-5AFC-4972-9EAB-04072F54F640@oracle.com> References: <704c44ef-e3e7-d483-5dcd-b7e19bbbf6fc@oracle.com> <90EB34AC-5AFC-4972-9EAB-04072F54F640@oracle.com> Message-ID: I've just checked, and yes the 310 Ser class is more involved (and more efficient) as it implements Externalizable. (Externalizable saves bytes over Serializable, by taking full control of the output IIRC). While criticisms of the 310 design are welcome, it was carefully crafted to be a generally useful package-based pattern for serialization. Following exactly that pattern here would seem desirable if possible. ie. a single Ser class for all new serialized forms in java.util, starting with immutable collections. Stephen On 17 May 2016 at 11:43, Chris Hegarty wrote: > > On 17 May 2016, at 09:55, Stephen Colebourne wrote: > >> CollSer should not be public, especially not just for serialization >> reasons. > > Right, and I see no reason to refer to it by name in the javadoc, the > link should be sufficient. > >> Stuart, I disagree with using an int for the flags, it should be a byte. If >> you need future expansion you can use 0xff to indicate it with the parser >> reacting accordingly. That is the strategy for JSR 310 > > The JSR 310 Serialization framework is a little more involved, as you know. > I wonder if it is worth following that pattern more closely here? That way > java.util.Ser could be a generic proxy for all new Serializable types in the > java.util package, and not just the immutable collections. The 310 pattern > also results in a reasonable place to document the serial form. > > -Chris. > >> Stephen >> On 17 May 2016 8:29 a.m., "Peter Levart" wrote: >> >> Hi Stuart, >> >> >> >> On 05/17/2016 12:48 AM, Stuart Marks wrote: >> >>> Hi all, >>> >>> Please review this changeset that adds specifications of the serialized >>> forms (really, a single serialization proxy class) for the immutable >>> collections implementation. There are no code changes in this changeset, >>> just documentation. >>> >>> It's somewhat odd, but the class doc for the serialization proxy isn't >>> actually included in the serialized-form.html output. I had to jigger >>> around the method doc for readResolve() to include some general information >>> about the class. >>> >>> I also added links manually from the List, Map, and Set interfaces to the >>> serialized form and vice-versa. I'm not aware of another way for a private >>> class to link to its (proxied) serialized form. >>> >>> I was able to coerce specdiff into giving a diff of serialized-form.html. >>> It's not very convenient, though; like serialized-form.html, the html diff >>> is one big file. The only difference is the addition of java.util.CollSer. >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~smarks/reviews/8133977/webrev.0/ >>> >>> API specdiff: >>> >>> >>> >>> http://cr.openjdk.java.net/~smarks/reviews/8133977/specdiff.0/api.specdiff/overview-summary.html >>> >>> serialized-form.html diff: >>> >>> >>> >>> http://cr.openjdk.java.net/~smarks/reviews/8133977/specdiff.0/serial.specdiff/specdiff-summary.html >>> >>> Thanks, >>> >>> s'marks >>> >> >> Perhaps java.util.CollSer could be promoted to be a public class. It does, >> after all, specify the API (serialization form == API). I don't see a point >> in hiding it and then jiggering around the method doc for readResolve()... >> You could just restrict its use by keeping the constructor(s) >> package-private... >> >> What do you think? >> >> Regards, Peter > From scolebourne at joda.org Tue May 17 11:41:19 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 17 May 2016 12:41:19 +0100 Subject: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields In-Reply-To: <573A9B92.60201@oracle.com> References: <573A9B92.60201@oracle.com> Message-ID: I would also like to see the test case methods be named "getFrom" not "getfrom". Stephen On 17 May 2016 at 05:18, nadeesh tv wrote: > Hi Bhanu, > > I think you should add a test case comparing the return value of getFrom() > > ( Not an official reviewer) > > Regards, > Nadeesh > > On 5/16/2016 11:46 AM, Bhanu Gopularam wrote: >> >> Hi all, >> >> Could you please review fix for following issue. >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8156718 >> >> Solution: Added tck tests for validating getFrom method for unsupported >> non-Iso temporal fields >> >> Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.00/ >> >> Thanks, >> Bhanu > > > -- > Thanks and Regards, > Nadeesh TV > From chris.hegarty at oracle.com Tue May 17 11:43:15 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 17 May 2016 12:43:15 +0100 Subject: RFR(s): 8133977 add specification for serial form of immutable collections In-Reply-To: References: <704c44ef-e3e7-d483-5dcd-b7e19bbbf6fc@oracle.com> <90EB34AC-5AFC-4972-9EAB-04072F54F640@oracle.com> Message-ID: <5466D1B5-E671-4C10-9023-0AD1453C8623@oracle.com> On 17 May 2016, at 12:38, Stephen Colebourne wrote: > I've just checked, and yes the 310 Ser class is more involved (and > more efficient) as it implements Externalizable. (Externalizable saves > bytes over Serializable, by taking full control of the output IIRC). Right. That is my understanding also. > While criticisms of the 310 design are welcome, it was carefully > crafted to be a generally useful package-based pattern for > serialization. It is. No criticism here. In fact, the opposite. That is why I suggested following it. > Following exactly that pattern here would seem > desirable if possible. ie. a single Ser class for all new serialized > forms in java.util, starting with immutable collections. It would be nice, and generally useful going forward. -Chris. > Stephen > > > On 17 May 2016 at 11:43, Chris Hegarty wrote: >> >> On 17 May 2016, at 09:55, Stephen Colebourne wrote: >> >>> CollSer should not be public, especially not just for serialization >>> reasons. >> >> Right, and I see no reason to refer to it by name in the javadoc, the >> link should be sufficient. >> >>> Stuart, I disagree with using an int for the flags, it should be a byte. If >>> you need future expansion you can use 0xff to indicate it with the parser >>> reacting accordingly. That is the strategy for JSR 310 >> >> The JSR 310 Serialization framework is a little more involved, as you know. >> I wonder if it is worth following that pattern more closely here? That way >> java.util.Ser could be a generic proxy for all new Serializable types in the >> java.util package, and not just the immutable collections. The 310 pattern >> also results in a reasonable place to document the serial form. >> >> -Chris. >> >>> Stephen >>> On 17 May 2016 8:29 a.m., "Peter Levart" wrote: >>> >>> Hi Stuart, >>> >>> >>> >>> On 05/17/2016 12:48 AM, Stuart Marks wrote: >>> >>>> Hi all, >>>> >>>> Please review this changeset that adds specifications of the serialized >>>> forms (really, a single serialization proxy class) for the immutable >>>> collections implementation. There are no code changes in this changeset, >>>> just documentation. >>>> >>>> It's somewhat odd, but the class doc for the serialization proxy isn't >>>> actually included in the serialized-form.html output. I had to jigger >>>> around the method doc for readResolve() to include some general information >>>> about the class. >>>> >>>> I also added links manually from the List, Map, and Set interfaces to the >>>> serialized form and vice-versa. I'm not aware of another way for a private >>>> class to link to its (proxied) serialized form. >>>> >>>> I was able to coerce specdiff into giving a diff of serialized-form.html. >>>> It's not very convenient, though; like serialized-form.html, the html diff >>>> is one big file. The only difference is the addition of java.util.CollSer. >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~smarks/reviews/8133977/webrev.0/ >>>> >>>> API specdiff: >>>> >>>> >>>> >>>> http://cr.openjdk.java.net/~smarks/reviews/8133977/specdiff.0/api.specdiff/overview-summary.html >>>> >>>> serialized-form.html diff: >>>> >>>> >>>> >>>> http://cr.openjdk.java.net/~smarks/reviews/8133977/specdiff.0/serial.specdiff/specdiff-summary.html >>>> >>>> Thanks, >>>> >>>> s'marks >>>> >>> >>> Perhaps java.util.CollSer could be promoted to be a public class. It does, >>> after all, specify the API (serialization form == API). I don't see a point >>> in hiding it and then jiggering around the method doc for readResolve()... >>> You could just restrict its use by keeping the constructor(s) >>> package-private... >>> >>> What do you think? >>> >>> Regards, Peter >> From sundararajan.athijegannathan at oracle.com Tue May 17 12:04:28 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 17 May 2016 17:34:28 +0530 Subject: RFR 8154192: Deprivilege java.scripting module Message-ID: <3e1bed67-ae64-00c2-2e99-21af225e2b30@oracle.com> Please review fix for https://bugs.openjdk.java.net/browse/JDK-8154192 java.scripting module is assigned to platform class loader (instead of boot loader). And java.scripting module is given AllPermission [previously it had AllPermission implicitly because of being boot loader code] jdk repo: http://cr.openjdk.java.net/~sundar/8154192/jdk/webrev.00/ top level repo: http://cr.openjdk.java.net/~sundar/8154192/top/webrev.00/ Tests: javax.script API tests, jrunscript, jjs tool tests and nashorn tests. Thanks, -Sundar From Alan.Bateman at oracle.com Tue May 17 12:14:35 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 17 May 2016 13:14:35 +0100 Subject: RFR: 8147588: Jar file and Zip file not removed in spite of the OPEN_DELETE flag In-Reply-To: <5738C5EB.8090408@oracle.com> References: <5734D670.3080004@oracle.com> <5735AC2B.3010808@oracle.com> <55af6df6-3ed8-1bae-e1f7-15dd0c46002d@oracle.com> <573637EE.1030108@oracle.com> <53e0df03-067e-ca8d-6143-921df1acc351@oracle.com> <57378432.2040904@oracle.com> <5738C5EB.8090408@oracle.com> Message-ID: <573B0B2B.4040204@oracle.com> On 15/05/2016 19:54, Xueming Shen wrote: > Thanks Alan, > > Here is the webrev with the first proposed change. > > http://cr.openjdk.java.net/~sherman/8147588/webrev/ > > -sherman > It needs a bit of clean-up but I think we can live with the approach. One thing that could be cleaned up is to move the loading of RAF to SharedSecrets.getJavaIORandomAccessFileAccess using ensuredInitialized. Another suggestion is to rename to newRandomAccess with the 3 parameters as a flags parameter to allow additional flags be passed in. This would allow the ZipFile.Source change to be simply: String flags = (toDelete) ? "t" : ""; this.zfile = SharedSecrets.getJavaIORandomAccessFileAccess() .newRandomAccessFile(key.file, mode, flags); It would need isWindows and so would be a lot cleaner (I think). -Alan From james.laskey at oracle.com Tue May 17 12:18:12 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 17 May 2016 09:18:12 -0300 Subject: RFR 8154192: Deprivilege java.scripting module In-Reply-To: <3e1bed67-ae64-00c2-2e99-21af225e2b30@oracle.com> References: <3e1bed67-ae64-00c2-2e99-21af225e2b30@oracle.com> Message-ID: <93DC831E-AC89-4059-82B5-4029A3840EF9@oracle.com> +1 > On May 17, 2016, at 9:04 AM, Sundararajan Athijegannathan wrote: > > Please review fix for https://bugs.openjdk.java.net/browse/JDK-8154192 > > java.scripting module is assigned to platform class loader (instead of > boot loader). And java.scripting module is given AllPermission > [previously it had AllPermission implicitly because of being boot loader > code] > > jdk repo: > > http://cr.openjdk.java.net/~sundar/8154192/jdk/webrev.00/ > > top level repo: > > http://cr.openjdk.java.net/~sundar/8154192/top/webrev.00/ > > Tests: javax.script API tests, jrunscript, jjs tool tests and nashorn tests. > > Thanks, > > -Sundar > From shilpi.rastogi at oracle.com Tue May 17 12:21:03 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Tue, 17 May 2016 17:51:03 +0530 Subject: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode In-Reply-To: References: <5733165C.6090305@oracle.com> <94710EE3-E8C4-4B0D-A21C-4458B1E905C3@oracle.com> <573339BF.4060107@oracle.com> Message-ID: <573B0CAF.9020309@oracle.com> Gentle Reminder! https://bugs.openjdk.java.net/browse/JDK-8155791 http://cr.openjdk.java.net/~srastogi/8155791/webrev.00/ On 5/12/2016 3:06 PM, Michael Haupt wrote: > Hi Shilpi, > > thanks for the clarification. OK by me then - please note this is a lower-case review. > > Best, > > Michael > >> Am 11.05.2016 um 15:55 schrieb shilpi.rastogi at oracle.com: >> >> Thank You Michael for comments! >> >> It was fixed for VarargsArrayTest.java but not fixed for java/lang/invoke/CustomizedLambdaFormTest.java. >> >> >> Boris Molodenkov added a comment -2016-05-02 02:37-Restricted toConfidential >> One more test >> RULE "java/lang/invoke/CustomizedLambdaFormTest.java" StatusError Parse Exception: [-esa]: vm option(s) found, need to specify /othervm >> >> Thanks, >> Shilpi >> >> On 5/11/2016 6:47 PM, Michael Haupt wrote: >>> Hi Shilpi, >>> >>> not a review - the bug mentions that this issue is fixed in Jake already and that the bug should be closed once the fix from Jake propagates to dev. What is the status of that? >>> >>> Best, >>> >>> Michael >>> >>>> Am 11.05.2016 um 13:24 schrieb shilpi.rastogi at oracle.com: >>>> >>>> Hi All, >>>> >>>> Please review one small fix for >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8155791 >>>> http://cr.openjdk.java.net/~srastogi/8155791/webrev.00/ >>>> >>>> Thanks, >>>> Shilpi From Alan.Bateman at oracle.com Tue May 17 12:24:31 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 17 May 2016 13:24:31 +0100 Subject: RFR 8154192: Deprivilege java.scripting module In-Reply-To: <3e1bed67-ae64-00c2-2e99-21af225e2b30@oracle.com> References: <3e1bed67-ae64-00c2-2e99-21af225e2b30@oracle.com> Message-ID: <573B0D7F.9080907@oracle.com> On 17/05/2016 13:04, Sundararajan Athijegannathan wrote: > Please review fix for https://bugs.openjdk.java.net/browse/JDK-8154192 > > java.scripting module is assigned to platform class loader (instead of > boot loader). And java.scripting module is given AllPermission > [previously it had AllPermission implicitly because of being boot loader > code] > > jdk repo: > > http://cr.openjdk.java.net/~sundar/8154192/jdk/webrev.00/ > > top level repo: > > http://cr.openjdk.java.net/~sundar/8154192/top/webrev.00/ > > Would it be possible to keep the PLATFORM_MODULES sorted? Otherwise it looks okay as a first patch. I think we also need to understand why this module needs AllPermission. From a quick look then it creates the SL with all permissions but the iteration will be restricted by whatever is on the stack so I just wonder if it works as intended. -Alan From aleksey.shipilev at oracle.com Tue May 17 12:30:48 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 17 May 2016 15:30:48 +0300 Subject: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode In-Reply-To: <573B0CAF.9020309@oracle.com> References: <5733165C.6090305@oracle.com> <94710EE3-E8C4-4B0D-A21C-4458B1E905C3@oracle.com> <573339BF.4060107@oracle.com> <573B0CAF.9020309@oracle.com> Message-ID: <573B0EF8.3020101@oracle.com> On 05/17/2016 03:21 PM, shilpi.rastogi at oracle.com wrote: > Gentle Reminder! > > https://bugs.openjdk.java.net/browse/JDK-8155791 > http://cr.openjdk.java.net/~srastogi/8155791/webrev.00/ >>> Parse Exception: [-esa]: vm option(s) found, need to specify /othervm Still not getting this. The message tells to specify /othervm. But the original code in CustomizedLambdaFormTest already has "/othervm", and the fix adds "/bootclasspath". This contradicts both the comment and the synopsis for the issue. Thanks, -Aleksey From aleksey.shipilev at oracle.com Tue May 17 12:39:53 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 17 May 2016 15:39:53 +0300 Subject: RFR [9]: 8157096: [TEST_BUG] test/javax/xml/bind/xjc/8145039/JaxbMarshallTest.java is skipped by jtreg In-Reply-To: <573A5E6B.2070202@oracle.com> References: <573A5E6B.2070202@oracle.com> Message-ID: <573B1119.6050001@oracle.com> On 05/17/2016 02:57 AM, Aleks Efimov wrote: > Webrev: http://cr.openjdk.java.net/~aefimov/8157096/9/00 > JBS: https://bugs.openjdk.java.net/browse/JDK-8157096 Looks good. Thanks, -Aleksey From shilpi.rastogi at oracle.com Tue May 17 12:45:37 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Tue, 17 May 2016 18:15:37 +0530 Subject: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode In-Reply-To: <573B0EF8.3020101@oracle.com> References: <5733165C.6090305@oracle.com> <94710EE3-E8C4-4B0D-A21C-4458B1E905C3@oracle.com> <573339BF.4060107@oracle.com> <573B0CAF.9020309@oracle.com> <573B0EF8.3020101@oracle.com> Message-ID: <573B1271.9070908@oracle.com> On 5/17/2016 6:00 PM, Aleksey Shipilev wrote: > On 05/17/2016 03:21 PM, shilpi.rastogi at oracle.com wrote: >> Gentle Reminder! >> >> https://bugs.openjdk.java.net/browse/JDK-8155791 >> http://cr.openjdk.java.net/~srastogi/8155791/webrev.00/ >>>> Parse Exception: [-esa]: vm option(s) found, need to specify /othervm > Still not getting this. The message tells to specify /othervm. > > But the original code in CustomizedLambdaFormTest already has > "/othervm", and the fix adds "/bootclasspath". This contradicts both the > comment and the synopsis for the issue. jtreg 4.2b02 requires main/bootclasspath mode to specify othervm if any command-line flags are used. So just added * @run main/bootclasspath/othervm -esa CustomizedLambdaFormTest Regards, Shilpi > Thanks, > -Aleksey > > > > From sundararajan.athijegannathan at oracle.com Tue May 17 12:54:46 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 17 May 2016 18:24:46 +0530 Subject: RFR 8157146: Add debug printlns to tests FieldSetAccessibleTest and VerifyJimage.java Message-ID: <0311bf23-b3cc-8688-458c-6f20a5422c46@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8157146/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8157146 This is test only change to debug printlns. Thanks, -Sundar From aleksey.shipilev at oracle.com Tue May 17 12:58:44 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 17 May 2016 15:58:44 +0300 Subject: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode In-Reply-To: <573B1271.9070908@oracle.com> References: <5733165C.6090305@oracle.com> <94710EE3-E8C4-4B0D-A21C-4458B1E905C3@oracle.com> <573339BF.4060107@oracle.com> <573B0CAF.9020309@oracle.com> <573B0EF8.3020101@oracle.com> <573B1271.9070908@oracle.com> Message-ID: <573B1584.9050105@oracle.com> On 05/17/2016 03:45 PM, shilpi.rastogi at oracle.com wrote: > On 5/17/2016 6:00 PM, Aleksey Shipilev wrote: >> On 05/17/2016 03:21 PM, shilpi.rastogi at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8155791 >>> http://cr.openjdk.java.net/~srastogi/8155791/webrev.00/ >>>>> Parse Exception: [-esa]: vm option(s) found, need to specify /othervm >> Still not getting this. The message tells to specify /othervm. >> >> But the original code in CustomizedLambdaFormTest already has >> "/othervm", and the fix adds "/bootclasspath". This contradicts both the >> comment and the synopsis for the issue. > jtreg 4.2b02 requires main/bootclasspath mode to specify othervm if > any command-line flags are used. > So just added > > * @run main/bootclasspath/othervm -esa CustomizedLambdaFormTest Ah, so you are saying "main/othervm" is illegal when other command-line flags are used? And you need "main/bootclasspath/othervm"? I am asking because I see lots of other tests in both jdk9/dev and jdk9/hs that run with "main/othervm" and -D/-X options. -Aleksey From david.holmes at oracle.com Tue May 17 13:05:14 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 May 2016 23:05:14 +1000 Subject: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode In-Reply-To: <573B1584.9050105@oracle.com> References: <5733165C.6090305@oracle.com> <94710EE3-E8C4-4B0D-A21C-4458B1E905C3@oracle.com> <573339BF.4060107@oracle.com> <573B0CAF.9020309@oracle.com> <573B0EF8.3020101@oracle.com> <573B1271.9070908@oracle.com> <573B1584.9050105@oracle.com> Message-ID: <6ad91a68-b32f-6b47-6372-84cea857bc01@oracle.com> On 17/05/2016 10:58 PM, Aleksey Shipilev wrote: > On 05/17/2016 03:45 PM, shilpi.rastogi at oracle.com wrote: >> On 5/17/2016 6:00 PM, Aleksey Shipilev wrote: >>> On 05/17/2016 03:21 PM, shilpi.rastogi at oracle.com wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8155791 >>>> http://cr.openjdk.java.net/~srastogi/8155791/webrev.00/ >>>>>> Parse Exception: [-esa]: vm option(s) found, need to specify /othervm >>> Still not getting this. The message tells to specify /othervm. >>> >>> But the original code in CustomizedLambdaFormTest already has >>> "/othervm", and the fix adds "/bootclasspath". This contradicts both the >>> comment and the synopsis for the issue. >> jtreg 4.2b02 requires main/bootclasspath mode to specify othervm if >> any command-line flags are used. >> So just added >> >> * @run main/bootclasspath/othervm -esa CustomizedLambdaFormTest > > Ah, so you are saying "main/othervm" is illegal when other command-line > flags are used? And you need "main/bootclasspath/othervm"? I am asking > because I see lots of other tests in both jdk9/dev and jdk9/hs that run > with "main/othervm" and -D/-X options. I think the "bootclasspath" part is the significant part. David > -Aleksey > > > > From aleksey.shipilev at oracle.com Tue May 17 13:08:19 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 17 May 2016 16:08:19 +0300 Subject: RFR 8157146: Add debug printlns to tests FieldSetAccessibleTest and VerifyJimage.java In-Reply-To: <0311bf23-b3cc-8688-458c-6f20a5422c46@oracle.com> References: <0311bf23-b3cc-8688-458c-6f20a5422c46@oracle.com> Message-ID: <573B17C3.2010506@oracle.com> On 05/17/2016 03:54 PM, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8157146/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8157146 Shouldn't it follow the same pattern other catch blocks? Surely you want to run all test cases, and not abort on the first VerifyError? 239 } catch (VerifyError ve) { 240 System.err.println("VerifyError for " + clsName); 241 throw ve; Should be: 239 } catch (VerifyError ve) { 240 ve.printStackTrace(System.err); 241 failed.add(s); 242 } catch (Exception t) { 243 t.printStackTrace(System.err); 244 failed.add(s); 245 } catch (NoClassDefFoundError e) { 246 e.printStackTrace(System.err); 247 failed.add(s); Also I think this should be before the attempt to load the class, to capture even the failing attempt: 237 System.out.println("Loading " + clsName); Ditto for VerifyJimage.java. Thanks, -Aleksey From Alan.Bateman at oracle.com Tue May 17 13:12:15 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 17 May 2016 14:12:15 +0100 Subject: RFR 8157146: Add debug printlns to tests FieldSetAccessibleTest and VerifyJimage.java In-Reply-To: <573B17C3.2010506@oracle.com> References: <0311bf23-b3cc-8688-458c-6f20a5422c46@oracle.com> <573B17C3.2010506@oracle.com> Message-ID: <573B18AF.5010009@oracle.com> On 17/05/2016 14:08, Aleksey Shipilev wrote: > On 05/17/2016 03:54 PM, Sundararajan Athijegannathan wrote: >> Please review http://cr.openjdk.java.net/~sundar/8157146/webrev.00/ for >> https://bugs.openjdk.java.net/browse/JDK-8157146 > Shouldn't it follow the same pattern other catch blocks? Surely you want > to run all test cases, and not abort on the first VerifyError? > > 239 } catch (VerifyError ve) { > 240 System.err.println("VerifyError for " + clsName); > 241 throw ve; > > Should be: > > 239 } catch (VerifyError ve) { > 240 ve.printStackTrace(System.err); > 241 failed.add(s); > 242 } catch (Exception t) { > 243 t.printStackTrace(System.err); > 244 failed.add(s); > 245 } catch (NoClassDefFoundError e) { > 246 e.printStackTrace(System.err); > 247 failed.add(s); > > > Also I think this should be before the attempt to load the class, to > capture even the failing attempt: > > 237 System.out.println("Loading " + clsName); > > Ditto for VerifyJimage.java. > I agree, best to keep the test consistent. That said, something is very broken if we have .class files in the jimage that are failing verification so I am curious what this is. -Alan From Alan.Bateman at oracle.com Tue May 17 13:20:15 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 17 May 2016 14:20:15 +0100 Subject: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode In-Reply-To: <573B0CAF.9020309@oracle.com> References: <5733165C.6090305@oracle.com> <94710EE3-E8C4-4B0D-A21C-4458B1E905C3@oracle.com> <573339BF.4060107@oracle.com> <573B0CAF.9020309@oracle.com> Message-ID: <573B1A8F.3080802@oracle.com> On 17/05/2016 13:21, shilpi.rastogi at oracle.com wrote: > Gentle Reminder! > > https://bugs.openjdk.java.net/browse/JDK-8155791 > http://cr.openjdk.java.net/~srastogi/8155791/webrev.00/ Is this test failing? I can't quite tell why it needs to be on the boot class path, -Alan. From sundararajan.athijegannathan at oracle.com Tue May 17 13:26:31 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 17 May 2016 18:56:31 +0530 Subject: RFR 8157146: Add debug printlns to tests FieldSetAccessibleTest and VerifyJimage.java In-Reply-To: <573B18AF.5010009@oracle.com> References: <0311bf23-b3cc-8688-458c-6f20a5422c46@oracle.com> <573B17C3.2010506@oracle.com> <573B18AF.5010009@oracle.com> Message-ID: <3a5a29dd-3576-11fe-4f90-9f7b3efaf030@oracle.com> Please review the updated webrev: http://cr.openjdk.java.net/~sundar/8157146/webrev.01/ Thanks, -Sundar On 5/17/2016 6:42 PM, Alan Bateman wrote: > On 17/05/2016 14:08, Aleksey Shipilev wrote: >> On 05/17/2016 03:54 PM, Sundararajan Athijegannathan wrote: >>> Please review http://cr.openjdk.java.net/~sundar/8157146/webrev.00/ for >>> https://bugs.openjdk.java.net/browse/JDK-8157146 >> Shouldn't it follow the same pattern other catch blocks? Surely you want >> to run all test cases, and not abort on the first VerifyError? >> >> 239 } catch (VerifyError ve) { >> 240 System.err.println("VerifyError for " + clsName); >> 241 throw ve; >> >> Should be: >> >> 239 } catch (VerifyError ve) { >> 240 ve.printStackTrace(System.err); >> 241 failed.add(s); >> 242 } catch (Exception t) { >> 243 t.printStackTrace(System.err); >> 244 failed.add(s); >> 245 } catch (NoClassDefFoundError e) { >> 246 e.printStackTrace(System.err); >> 247 failed.add(s); >> >> >> Also I think this should be before the attempt to load the class, to >> capture even the failing attempt: >> >> 237 System.out.println("Loading " + clsName); >> >> Ditto for VerifyJimage.java. >> > I agree, best to keep the test consistent. That said, something is > very broken if we have .class files in the jimage that are failing > verification so I am curious what this is. > > -Alan From Alan.Bateman at oracle.com Tue May 17 13:30:17 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 17 May 2016 14:30:17 +0100 Subject: RFR 8157146: Add debug printlns to tests FieldSetAccessibleTest and VerifyJimage.java In-Reply-To: <3a5a29dd-3576-11fe-4f90-9f7b3efaf030@oracle.com> References: <0311bf23-b3cc-8688-458c-6f20a5422c46@oracle.com> <573B17C3.2010506@oracle.com> <573B18AF.5010009@oracle.com> <3a5a29dd-3576-11fe-4f90-9f7b3efaf030@oracle.com> Message-ID: <573B1CE9.3060809@oracle.com> On 17/05/2016 14:26, Sundararajan Athijegannathan wrote: > Please review the updated webrev: > http://cr.openjdk.java.net/~sundar/8157146/webrev.01/ > > This version looks okay to me. Now let's see if I find out where the bad class is coming from. -Alan From martinrb at google.com Tue May 17 13:34:52 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 17 May 2016 06:34:52 -0700 Subject: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode In-Reply-To: <573B1A8F.3080802@oracle.com> References: <5733165C.6090305@oracle.com> <94710EE3-E8C4-4B0D-A21C-4458B1E905C3@oracle.com> <573339BF.4060107@oracle.com> <573B0CAF.9020309@oracle.com> <573B1A8F.3080802@oracle.com> Message-ID: In jdk8 the /othervm is missing. http://mail.openjdk.java.net/pipermail/jtreg-use/2016-May/000478.html On Tue, May 17, 2016 at 6:20 AM, Alan Bateman wrote: > > > On 17/05/2016 13:21, shilpi.rastogi at oracle.com wrote: >> >> Gentle Reminder! >> >> https://bugs.openjdk.java.net/browse/JDK-8155791 >> http://cr.openjdk.java.net/~srastogi/8155791/webrev.00/ > > Is this test failing? I can't quite tell why it needs to be on the boot > class path, > > -Alan. From Alan.Bateman at oracle.com Tue May 17 14:14:45 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 17 May 2016 15:14:45 +0100 Subject: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode In-Reply-To: References: <5733165C.6090305@oracle.com> <94710EE3-E8C4-4B0D-A21C-4458B1E905C3@oracle.com> <573339BF.4060107@oracle.com> <573B0CAF.9020309@oracle.com> <573B1A8F.3080802@oracle.com> Message-ID: <573B2755.6080301@oracle.com> On 17/05/2016 14:34, Martin Buchholz wrote: > In jdk8 the /othervm is missing. > http://mail.openjdk.java.net/pipermail/jtreg-use/2016-May/000478.html > Ah, I assumed we were discussing the version in jdk9/dev. BTW: My interest here is to make sure we didn't break anything with the module system refresh two weeks ago. We are currently joined at the hip to jtreg and so had to force an update to jtreg as part of the update. We updated many tests as part of this and I don't recall any tests failing when we pushed. -Alan From aleksey.shipilev at oracle.com Tue May 17 14:31:38 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 17 May 2016 17:31:38 +0300 Subject: RFR 8157146: Add debug printlns to tests FieldSetAccessibleTest and VerifyJimage.java In-Reply-To: <3a5a29dd-3576-11fe-4f90-9f7b3efaf030@oracle.com> References: <0311bf23-b3cc-8688-458c-6f20a5422c46@oracle.com> <573B17C3.2010506@oracle.com> <573B18AF.5010009@oracle.com> <3a5a29dd-3576-11fe-4f90-9f7b3efaf030@oracle.com> Message-ID: <573B2B4A.3050200@oracle.com> On 05/17/2016 04:26 PM, Sundararajan Athijegannathan wrote: > Please review the updated webrev: > http://cr.openjdk.java.net/~sundar/8157146/webrev.01/ Yes, reviewed. Thanks, -Aleksey From joe.darcy at oracle.com Tue May 17 14:37:11 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 17 May 2016 07:37:11 -0700 Subject: RFR 8157146: Add debug printlns to tests FieldSetAccessibleTest and VerifyJimage.java In-Reply-To: <3a5a29dd-3576-11fe-4f90-9f7b3efaf030@oracle.com> References: <0311bf23-b3cc-8688-458c-6f20a5422c46@oracle.com> <573B17C3.2010506@oracle.com> <573B18AF.5010009@oracle.com> <3a5a29dd-3576-11fe-4f90-9f7b3efaf030@oracle.com> Message-ID: <16bac522-fa9e-4fbd-1d0b-a59efe9fbb14@oracle.com> Note that the two existing catch blocks 243 } catch (Exception t) { 244 t.printStackTrace(System.err); 245 failed.add(s); 246 } catch (NoClassDefFoundError e) { 247 e.printStackTrace(System.err); 248 failed.add(s); 249 } could be combined into one using multi-catch: 243 } catch (Exception | NoClassDefFoundError t) { 244 t.printStackTrace(System.err); 245 failed.add(s); 246 } Cheers, -Joe On 5/17/2016 6:26 AM, Sundararajan Athijegannathan wrote: > Please review the updated webrev: > http://cr.openjdk.java.net/~sundar/8157146/webrev.01/ > > Thanks, > > -Sundar > > > On 5/17/2016 6:42 PM, Alan Bateman wrote: >> On 17/05/2016 14:08, Aleksey Shipilev wrote: >>> On 05/17/2016 03:54 PM, Sundararajan Athijegannathan wrote: >>>> Please review http://cr.openjdk.java.net/~sundar/8157146/webrev.00/ for >>>> https://bugs.openjdk.java.net/browse/JDK-8157146 >>> Shouldn't it follow the same pattern other catch blocks? Surely you want >>> to run all test cases, and not abort on the first VerifyError? >>> >>> 239 } catch (VerifyError ve) { >>> 240 System.err.println("VerifyError for " + clsName); >>> 241 throw ve; >>> >>> Should be: >>> >>> 239 } catch (VerifyError ve) { >>> 240 ve.printStackTrace(System.err); >>> 241 failed.add(s); >>> 242 } catch (Exception t) { >>> 243 t.printStackTrace(System.err); >>> 244 failed.add(s); >>> 245 } catch (NoClassDefFoundError e) { >>> 246 e.printStackTrace(System.err); >>> 247 failed.add(s); >>> >>> >>> Also I think this should be before the attempt to load the class, to >>> capture even the failing attempt: >>> >>> 237 System.out.println("Loading " + clsName); >>> >>> Ditto for VerifyJimage.java. >>> >> I agree, best to keep the test consistent. That said, something is >> very broken if we have .class files in the jimage that are failing >> verification so I am curious what this is. >> >> -Alan From xueming.shen at oracle.com Tue May 17 15:15:49 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 17 May 2016 08:15:49 -0700 Subject: Can an object be finalized while still weakly reachable? In-Reply-To: References: <298d69ca-a7bc-2798-7f88-2bdff21b78a7@gmail.com> Message-ID: <7737177b-8791-3d87-dcbc-ae6f5167efa7@oracle.com> On 5/17/16 12:55 AM, Martin Buchholz wrote: > Thanks, Peter. > > My current theory is indeed that I made a mistake, and have > encountered my first real finalization resurrection bug. > ZipFile + Inflater have 4 finalize methods and a WeakHashMap in play! there was a long discussion when we touched that part of the code last time. just for your reference:-) http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-April/thread.html#6545 -sherman > My static reference was finalized because it used to be unreachable, > not because it is now weakly reachable! > > On Mon, May 16, 2016 at 11:49 PM, Peter Levart wrote: >> Hi Martin, >> >> >> >> On 05/17/2016 05:19 AM, Martin Buchholz wrote: >>> I have some evidence that an object's finalize method can run while a >>> weak reference pointing to it is not yet cleared, which surprised me. >>> >>> E.g. >>> class F { protected void finalize() { assert wref.get() != this; } } >>> static WeakReference wref = new WeakReference(new F()); >>> >>> If this is a bug, I can try to give y'all a repro recipe. >>> If not, we should fix the docs >>> """When the weak references to a weakly-reachable object are cleared, >>> the object becomes eligible for finalization.""" >>> >>> (It's also quite possible I made a mistake diagnosing this) >> >> What can happen with above code is that you get a NPE from dereferencing >> wref in finlailze(). In case NPE is not thrown and the program constructs >> only a single instance of F then assert should succeed. >> >> It is possible that you made a mistake. Can you post the real code? >> >> Regards, Peter >> From joe.darcy at oracle.com Tue May 17 16:29:24 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 17 May 2016 09:29:24 -0700 Subject: JDK 9 RFR of JDK-8157006/8157011: Problem list java/io/pathNames/GeneralWin32.java and tools/pack200/TestNormal.java In-Reply-To: <573AD083.7010202@oracle.com> References: <57397948.2020401@oracle.com> <573AD083.7010202@oracle.com> Message-ID: <6dedcfb1-c945-f0d3-d300-d5a284ddde07@oracle.com> Look fine Hamlin; cheers, -Joe On 5/17/2016 1:04 AM, Hamlin Li wrote: > Would you please review the change to problem list 2 frequently > failing tests. > > Thank you > -Hamlin > > On 2016/5/16 15:39, Hamlin Li wrote: >> java/io/pathNames/GeneralWin32.java >> has been seen to fail with high frequency on windows. Until >> JDK-8156595 is addressed, the test should be problem listed. >> bug: https://bugs.openjdk.java.net/browse/JDK-8157006 >> >> tools/pack200/TestNormal.java >> has been seen to fail with some frequency on windows. Until >> JDK-8156807 is addressed, the test should be problem listed. >> bug: https://bugs.openjdk.java.net/browse/JDK-8157011 >> >> webrev: http://cr.openjdk.java.net/~mli/8157006/webrev.00/ >> >> Thank you >> -Hamlin > From huizhe.wang at oracle.com Tue May 17 16:42:34 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 17 May 2016 09:42:34 -0700 Subject: RFR (JAXP) 8156845: Uri is getting incorrectly unwrapped Message-ID: <573B49FA.50402@oracle.com> Hi, This patch fixes a missing feature in CatalogUriResolver where an uri entry can be referenced by a publicid (urn:publicid), similar to that of the public entry. The fix then is basically sharing the process for a public entry. JBS: https://bugs.openjdk.java.net/browse/JDK-8156845 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8156845/webrev/ Thanks, Joe From aleksey.shipilev at oracle.com Tue May 17 16:46:03 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 17 May 2016 19:46:03 +0300 Subject: RFR (S) 8157171: Hook up Unsafe.weakCompareAndSetVolatile to VarHandles Message-ID: <573B4ACB.6040607@oracle.com> Hi, Now that jdk9/hs merged to jdk9/dev, we can finally make a move to connect new Unsafe.weakCompareAndSetVolatile intrinsics with VarHandles: https://bugs.openjdk.java.net/browse/JDK-8157171 Webrev: http://cr.openjdk.java.net/~shade/8157171/webrev.01/ The core changes are in the template files, actual .java files were generated from templates. I also fixed up the few missing VarHandles tests for weakCASVolatile. Testing: local Linux x86_64 build; java/lang/invoke/VarHandles jtregs. Thanks, -Aleksey From shilpi.rastogi at oracle.com Tue May 17 16:50:08 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Tue, 17 May 2016 22:20:08 +0530 Subject: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode In-Reply-To: <573B2755.6080301@oracle.com> References: <5733165C.6090305@oracle.com> <94710EE3-E8C4-4B0D-A21C-4458B1E905C3@oracle.com> <573339BF.4060107@oracle.com> <573B0CAF.9020309@oracle.com> <573B1A8F.3080802@oracle.com> <573B2755.6080301@oracle.com> Message-ID: <573B4BC0.1060500@oracle.com> On 5/17/2016 7:44 PM, Alan Bateman wrote: > > On 17/05/2016 14:34, Martin Buchholz wrote: >> In jdk8 the /othervm is missing. >> http://mail.openjdk.java.net/pipermail/jtreg-use/2016-May/000478.html >> > Ah, I assumed we were discussing the version in jdk9/dev. > > BTW: My interest here is to make sure we didn't break anything with > the module system refresh two weeks ago. We are currently joined at > the hip to jtreg and so had to force an update to jtreg as part of the > update. We updated many tests as part of this and I don't recall any > tests failing when we pushed. Could someone please explain why it is not required for this test as i saw we are updating other tests ( http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0e2a2be60453 ) ? Regards, Shilpi > > -Alan From aleksey.shipilev at oracle.com Tue May 17 16:57:06 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 17 May 2016 19:57:06 +0300 Subject: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode In-Reply-To: <573B4BC0.1060500@oracle.com> References: <5733165C.6090305@oracle.com> <94710EE3-E8C4-4B0D-A21C-4458B1E905C3@oracle.com> <573339BF.4060107@oracle.com> <573B0CAF.9020309@oracle.com> <573B1A8F.3080802@oracle.com> <573B2755.6080301@oracle.com> <573B4BC0.1060500@oracle.com> Message-ID: <573B4D62.3040607@oracle.com> On 05/17/2016 07:50 PM, shilpi.rastogi at oracle.com wrote: > On 5/17/2016 7:44 PM, Alan Bateman wrote: >> >> On 17/05/2016 14:34, Martin Buchholz wrote: >>> In jdk8 the /othervm is missing. >>> http://mail.openjdk.java.net/pipermail/jtreg-use/2016-May/000478.html >>> >> Ah, I assumed we were discussing the version in jdk9/dev. >> >> BTW: My interest here is to make sure we didn't break anything with >> the module system refresh two weeks ago. We are currently joined at >> the hip to jtreg and so had to force an update to jtreg as part of the >> update. We updated many tests as part of this and I don't recall any >> tests failing when we pushed. > > Could someone please explain why it is not required for this test as i > saw we are updating other tests ( > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0e2a2be60453 ) ? Look, the change above adds "/othervm" (I think those tests already have "/bootclasspath" because they access WhiteBox API): http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0e2a2be60453 Your change, OTOH, adds "/bootclasspath": http://cr.openjdk.java.net/~srastogi/8155791/webrev.00/test/java/lang/invoke/CustomizedLambdaFormTest.java.sdiff.html Is this the intent? Does the test fail without "/bootclasspath"? Thanks, -Aleksey From vladimir.x.ivanov at oracle.com Tue May 17 16:58:45 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 17 May 2016 19:58:45 +0300 Subject: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode In-Reply-To: <573B4BC0.1060500@oracle.com> References: <5733165C.6090305@oracle.com> <94710EE3-E8C4-4B0D-A21C-4458B1E905C3@oracle.com> <573339BF.4060107@oracle.com> <573B0CAF.9020309@oracle.com> <573B1A8F.3080802@oracle.com> <573B2755.6080301@oracle.com> <573B4BC0.1060500@oracle.com> Message-ID: > Could someone please explain why it is not required for this test as i > saw we are updating other tests ( > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0e2a2be60453 ) ? The test was fixed in Jigsaw repo [1] in a different way. Before the fix, the test class should be put on boot class path (hence main/bootclasspath), since MethodHandles.Lookup.IMPL_LOOKUP was used. After the fix, MethodHandleHelper is part of java.base module and the test fetches the lookup from it: * @compile/module=java.base java/lang/invoke/MethodHandleHelper.java * @run main/othervm -esa CustomizedLambdaFormTest ... MethodHandle mh = MethodHandleHelper.IMPL_LOOKUP.findVirtual(String.class, "concat", So, main/othervm is enough and there's no need in main/bootclasspath/othervm anymore. Hope it helps. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk9/dev/jdk/diff/b2a69d66dc65/test/java/lang/invoke/CustomizedLambdaFormTest.java From paul.sandoz at oracle.com Tue May 17 17:00:51 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 17 May 2016 19:00:51 +0200 Subject: RFR (S) 8157171: Hook up Unsafe.weakCompareAndSetVolatile to VarHandles In-Reply-To: <573B4ACB.6040607@oracle.com> References: <573B4ACB.6040607@oracle.com> Message-ID: <93EFD6F1-4BC8-4DFC-A397-FD98B095355B@oracle.com> > On 17 May 2016, at 18:46, Aleksey Shipilev wrote: > > Hi, > > Now that jdk9/hs merged to jdk9/dev, we can finally make a move to > connect new Unsafe.weakCompareAndSetVolatile intrinsics with VarHandles: > https://bugs.openjdk.java.net/browse/JDK-8157171 > > Webrev: > http://cr.openjdk.java.net/~shade/8157171/webrev.01/ > > The core changes are in the template files, actual .java files were > generated from templates. I also fixed up the few missing VarHandles > tests for weakCASVolatile. > > Testing: local Linux x86_64 build; java/lang/invoke/VarHandles jtregs. > +1 Paul. From shilpi.rastogi at oracle.com Tue May 17 17:14:36 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Tue, 17 May 2016 22:44:36 +0530 Subject: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode In-Reply-To: References: <5733165C.6090305@oracle.com> <94710EE3-E8C4-4B0D-A21C-4458B1E905C3@oracle.com> <573339BF.4060107@oracle.com> <573B0CAF.9020309@oracle.com> <573B1A8F.3080802@oracle.com> <573B2755.6080301@oracle.com> <573B4BC0.1060500@oracle.com> Message-ID: <573B517C.1000306@oracle.com> On 5/17/2016 10:28 PM, Vladimir Ivanov wrote: >> Could someone please explain why it is not required for this test as i >> saw we are updating other tests ( >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0e2a2be60453 ) ? > The test was fixed in Jigsaw repo [1] in a different way. > > Before the fix, the test class should be put on boot class path (hence > main/bootclasspath), since MethodHandles.Lookup.IMPL_LOOKUP was used. > > After the fix, MethodHandleHelper is part of java.base module and the > test fetches the lookup from it: > > * @compile/module=java.base java/lang/invoke/MethodHandleHelper.java > * @run main/othervm -esa CustomizedLambdaFormTest > ... > MethodHandle mh = > MethodHandleHelper.IMPL_LOOKUP.findVirtual(String.class, "concat", > > So, main/othervm is enough and there's no need in > main/bootclasspath/othervm anymore. > > Hope it helps. Thank You Vladimir! > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/diff/b2a69d66dc65/test/java/lang/invoke/CustomizedLambdaFormTest.java From stuart.marks at oracle.com Tue May 17 18:24:19 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 17 May 2016 11:24:19 -0700 Subject: RFR(s): 8133977 add specification for serial form of immutable collections In-Reply-To: <562b5874-bfaf-c2d7-d498-b084f67253df@gmail.com> References: <704c44ef-e3e7-d483-5dcd-b7e19bbbf6fc@oracle.com> <562b5874-bfaf-c2d7-d498-b084f67253df@gmail.com> Message-ID: <12160f9e-ce36-d7b9-7718-0e9e0d179750@oracle.com> On 5/17/16 3:33 AM, Peter Levart wrote: > On 05/17/2016 10:55 AM, Stephen Colebourne wrote: >> CollSer should not be public, especially not just for serialization >> reasons. > > I don't see a compelling reason why. Javadocs mention it by name. By making it > Serializable, it is effectively public, so it can't go away or be renamed. What > is gained by hiding it? CollSer should be kept private in the API. I think we need to be careful about terminology here. The 'P' in API stands for *programming* and CollSer is not used by applications or by higher-level libraries. The serialization format is "public" but in a wholly different sense from the API. The format is specified so that it's compatible across different JDK implementations and versions. By necessity, the string names of classes are visible in this format, but this isn't a programming interface. I'm happy to remove mention of CollSer from the API specification. s'marks From lance.andersen at oracle.com Tue May 17 18:26:07 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 17 May 2016 14:26:07 -0400 Subject: RFR (JAXP) 8156845: Uri is getting incorrectly unwrapped In-Reply-To: <573B49FA.50402@oracle.com> References: <573B49FA.50402@oracle.com> Message-ID: Hi Joe It looks OK. The formatting is a bit off where you encased existing code with new if statements so I would consider fixing that before you push Best Lance > On May 17, 2016, at 12:42 PM, huizhe wang wrote: > > Hi, > > This patch fixes a missing feature in CatalogUriResolver where an uri entry can be referenced by a publicid (urn:publicid), similar to that of the public entry. The fix then is basically sharing the process for a public entry. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8156845 > webrev: http://cr.openjdk.java.net/~joehw/jdk9/8156845/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 stuart.marks at oracle.com Tue May 17 18:46:34 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 17 May 2016 11:46:34 -0700 Subject: RFR(s): 8133977 add specification for serial form of immutable collections In-Reply-To: References: <704c44ef-e3e7-d483-5dcd-b7e19bbbf6fc@oracle.com> Message-ID: On 5/17/16 1:55 AM, Stephen Colebourne wrote: > Stuart, I disagree with using an int for the flags, it should be a byte. If > you need future expansion you can use 0xff to indicate it with the parser > reacting accordingly. That is the strategy for JSR 310 These techniques have different goals. I don't see 0xff used at all in the current java.time.Ser class. (Did I miss something?) What I think you mean is that, in a future JDK, a sentinel value like 0xff could be used as the type value, indicating the presence of some additional or changed values following in the data stream. That's fine, but such usage is necessarily forward-incompatible. By this I mean that the JDK 8 implementation of java.time.Ser is incompatible with a future JDK's serialized form that uses this new 0xff type value (or in fact with any other new type value). Deserializing such a thing on JDK 8 would result in an exception. That might be exactly what you want, if some future java.time class cannot possibly be handled on JDK 8. For the proposed java.util.CollSer, exactly the same technique would apply by using a different "kind" value in the low order 8 bits. A future JDK might have some new kind of collection that can't be represented in JDK 9. The future JDK would use a new "kind" value, and deserializing it on JDK 9 should throw an exception. The other 24 bits are for *forward compatible* uses by future JDKs. Suppose a future JDK has a variation on List that uses a different internal storage format that works better in some cases. The future JDK might want to set a hint somewhere when serializing it, so that another instance of a future JDK could pick up this hint when deserializing. If a JDK 9 were to deserialize this, it would ignore the hint and deserialize an ordinary (immutable) List. It's always possible for a serialized form to add fields, which are specified to be ignored by older versions. But sometimes you don't want to add an entire new field, and you just need an extra bit. That's what the extra bits in the flags field are for. s'marks From stuart.marks at oracle.com Tue May 17 19:03:43 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 17 May 2016 12:03:43 -0700 Subject: RFR(s): 8133977 add specification for serial form of immutable collections In-Reply-To: <90EB34AC-5AFC-4972-9EAB-04072F54F640@oracle.com> References: <704c44ef-e3e7-d483-5dcd-b7e19bbbf6fc@oracle.com> <90EB34AC-5AFC-4972-9EAB-04072F54F640@oracle.com> Message-ID: <3642425c-378e-1904-7046-76967b014c75@oracle.com> On 5/17/16 3:43 AM, Chris Hegarty wrote: > The JSR 310 Serialization framework is a little more involved, as you know. > I wonder if it is worth following that pattern more closely here? That way > java.util.Ser could be a generic proxy for all new Serializable types in the > java.util package, and not just the immutable collections. The 310 pattern > also results in a reasonable place to document the serial form. The proposed java.util.CollSer follows the java.time.Ser pattern in that they're both common serialization proxies for several different implementation classes. I'm not sure exactly what you have in mind by suggesting that the pattern be followed "more closely" though. I don't think it's possible to have a single form for all new serializable objects in java.util. The java.util package isn't as cohesive as java.time. There's a bunch of random stuff in it. Consider the non-serializable things currently in java.util: *SummaryStatistics, Optional, Formatter, ResourceBundle, Scanner, ServiceLoader, StringJoiner, Timer If any of these were to be made serializable, I don't think it would make sense for it to share the serialized form with CollSer. Now, for new *collection* classes that might be added to java.util, sure. I can imagine adding new collections, immutable or mutable, and they could use CollSer as their serialized form. Those could be accommodated easily by adding new values for the "kind" bits of the flags field. What other changes would need to be made to CollSer to prepare for that? s'marks From claes.redestad at oracle.com Tue May 17 19:16:46 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 17 May 2016 21:16:46 +0200 Subject: RFR (S) 8157171: Hook up Unsafe.weakCompareAndSetVolatile to VarHandles In-Reply-To: <573B4ACB.6040607@oracle.com> References: <573B4ACB.6040607@oracle.com> Message-ID: <573B6E1E.4010802@oracle.com> +1 On 2016-05-17 18:46, Aleksey Shipilev wrote: > Hi, > > Now that jdk9/hs merged to jdk9/dev, we can finally make a move to > connect new Unsafe.weakCompareAndSetVolatile intrinsics with VarHandles: > https://bugs.openjdk.java.net/browse/JDK-8157171 > > Webrev: > http://cr.openjdk.java.net/~shade/8157171/webrev.01/ > > The core changes are in the template files, actual .java files were > generated from templates. I also fixed up the few missing VarHandles > tests for weakCASVolatile. > > Testing: local Linux x86_64 build; java/lang/invoke/VarHandles jtregs. > > Thanks, > -Aleksey > From aleksey.shipilev at oracle.com Tue May 17 19:28:45 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 17 May 2016 22:28:45 +0300 Subject: RFR (S) 8157171: Hook up Unsafe.weakCompareAndSetVolatile to VarHandles In-Reply-To: <573B6E1E.4010802@oracle.com> References: <573B4ACB.6040607@oracle.com> <573B6E1E.4010802@oracle.com> Message-ID: <573B70ED.4040800@oracle.com> Thanks Paul and Claes, pushed. -Aleksey On 05/17/2016 10:16 PM, Claes Redestad wrote: > +1 > > On 2016-05-17 18:46, Aleksey Shipilev wrote: >> Hi, >> >> Now that jdk9/hs merged to jdk9/dev, we can finally make a move to >> connect new Unsafe.weakCompareAndSetVolatile intrinsics with VarHandles: >> https://bugs.openjdk.java.net/browse/JDK-8157171 >> >> Webrev: >> http://cr.openjdk.java.net/~shade/8157171/webrev.01/ >> >> The core changes are in the template files, actual .java files were >> generated from templates. I also fixed up the few missing VarHandles >> tests for weakCASVolatile. >> >> Testing: local Linux x86_64 build; java/lang/invoke/VarHandles jtregs. >> >> Thanks, >> -Aleksey >> > From huizhe.wang at oracle.com Tue May 17 19:37:29 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 17 May 2016 12:37:29 -0700 Subject: RFR (JAXP) 8156845: Uri is getting incorrectly unwrapped In-Reply-To: References: <573B49FA.50402@oracle.com> Message-ID: <573B72F9.5000603@oracle.com> Thanks Lance! On 5/17/2016 11:26 AM, Lance Andersen wrote: > Hi Joe > > It looks OK. The formatting is a bit off where you encased existing > code with new if statements so I would consider fixing that before > you push It seems it has something to do with whitespaces. I re-generated the webrev. Also, I was missing a new file "uri.xml" in the webrev. http://cr.openjdk.java.net/~joehw/jdk9/8156845/webrev/ Best, Joe > > Best > Lance >> On May 17, 2016, at 12:42 PM, huizhe wang > > wrote: >> >> Hi, >> >> This patch fixes a missing feature in CatalogUriResolver where an uri >> entry can be referenced by a publicid (urn:publicid), similar to that >> of the public entry. The fix then is basically sharing the process >> for a public entry. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8156845 >> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8156845/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 peter.levart at gmail.com Tue May 17 20:09:02 2016 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 17 May 2016 22:09:02 +0200 Subject: RFR(s): 8133977 add specification for serial form of immutable collections In-Reply-To: <3642425c-378e-1904-7046-76967b014c75@oracle.com> References: <704c44ef-e3e7-d483-5dcd-b7e19bbbf6fc@oracle.com> <90EB34AC-5AFC-4972-9EAB-04072F54F640@oracle.com> <3642425c-378e-1904-7046-76967b014c75@oracle.com> Message-ID: <1c7ceba4-470a-0315-df38-ff07b127c2ff@gmail.com> Hi Stuart, On 05/17/2016 09:03 PM, Stuart Marks wrote: > On 5/17/16 3:43 AM, Chris Hegarty wrote: >> The JSR 310 Serialization framework is a little more involved, as you >> know. >> I wonder if it is worth following that pattern more closely here? >> That way >> java.util.Ser could be a generic proxy for all new Serializable types >> in the >> java.util package, and not just the immutable collections. The 310 >> pattern >> also results in a reasonable place to document the serial form. > > The proposed java.util.CollSer follows the java.time.Ser pattern in > that they're both common serialization proxies for several different > implementation classes. I'm not sure exactly what you have in mind by > suggesting that the pattern be followed "more closely" though. > > I don't think it's possible to have a single form for all new > serializable objects in java.util. The java.util package isn't as > cohesive as java.time. There's a bunch of random stuff in it. Consider > the non-serializable things currently in java.util: > > *SummaryStatistics, Optional, Formatter, ResourceBundle, > Scanner, ServiceLoader, StringJoiner, Timer > > If any of these were to be made serializable, I don't think it would > make sense for it to share the serialized form with CollSer. They would not share the form. The java.time.Ser does not specify serialized form by itself (short of a single byte stream prefix that selects the sub-format/implementaion typically hosted in the implementation classes themselves). java.time.Ser is just an adapter that allows for Externalizable-like functionality of implementations but not requiring them to implement a public no-arg constructor that constructs uninitialized instances. So all above mentioned classes could simply share a single java.util.Ser serialization proxy however different they are. But there's a different problem I see with java.time.Ser as is. Namely, how does it provide for serialization format to evolve over time. Suppose, hypothetically, that java.time.Duration would like to have picosecond precision in JDK 16. How would you change the serialization format/implementation that it would be backwards and forwards compatible? Having different values in the serialization format "tagged" with field names provides for that functionality. So in that respect, java.util.CollSer is more evolvable than java.time.Ser. Regards, Peter From paul.sandoz at oracle.com Tue May 17 20:23:17 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 17 May 2016 22:23:17 +0200 Subject: RFR 8130023 API java.util.stream: explicitly specify guaranteed execution of the pipeline Message-ID: Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8130023-stream-elide-ops-side-effects/webrev/ This is a spec tweak to streams to state that implementations are free to elide some or all operations in a pipeline as long as it does not affect the result of the stream computation i.e. side-effects beware! Paul. From lance.andersen at oracle.com Tue May 17 20:23:43 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 17 May 2016 16:23:43 -0400 Subject: RFR (JAXP) 8156845: Uri is getting incorrectly unwrapped In-Reply-To: <573B72F9.5000603@oracle.com> References: <573B49FA.50402@oracle.com> <573B72F9.5000603@oracle.com> Message-ID: <61B1388B-24E4-4D80-9BC6-471A6C97A127@oracle.com> Ok to push joe > On May 17, 2016, at 3:37 PM, huizhe wang wrote: > > Thanks Lance! > > On 5/17/2016 11:26 AM, Lance Andersen wrote: >> Hi Joe >> >> It looks OK. The formatting is a bit off where you encased existing code with new if statements so I would consider fixing that before you push > > It seems it has something to do with whitespaces. I re-generated the webrev. Also, I was missing a new file "uri.xml" in the webrev. > > http://cr.openjdk.java.net/~joehw/jdk9/8156845/webrev/ > > Best, > Joe > >> >> Best >> Lance >>> On May 17, 2016, at 12:42 PM, huizhe wang > wrote: >>> >>> Hi, >>> >>> This patch fixes a missing feature in CatalogUriResolver where an uri entry can be referenced by a publicid (urn:publicid), similar to that of the public entry. The fix then is basically sharing the process for a public entry. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8156845 >>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8156845/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 >> >> >> > > 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 claes.redestad at oracle.com Tue May 17 21:15:55 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 17 May 2016 23:15:55 +0200 Subject: RFR 8130023 API java.util.stream: explicitly specify guaranteed execution of the pipeline In-Reply-To: References: Message-ID: <573B8A0B.9010206@oracle.com> Hi, the first block in Stream.java bothers me: + *

A stream implementation is permitted significant latitude in optimizing + * the computation of the result. For example, a stream implementation is free + * to elide operations (or entire stages) from a stream pipeline -- and + * therefore elide invocation of behavioral parameters -- if it can prove that + * it would not affect the result of the computation. This means, that unless + * otherwise specified (such as by the terminal operations {@code forEach} and + * {@code forEachOrdered}), that side-effects of behavioral parameters may not + * always be executed and should not be relied upon. (For a specific example of + * such an optimization, see the API note documented on the {@link #count} + * operation. For more detail, see the + * side-effects section of the + * strean package documentation.) + * The first sentence in particular is hard to read and interpret, and after reading it twice I'm not sure if it's entirely redundant or if you need to better specify what other freedoms are given to a stream implementation? How about this: + *

Astream implementation is free to elide operations (or entire stages) + * from a stream pipeline -- andtherefore elide invocation of behavioral + * parameters -- if it can prove that it would not affect the result of the + * computation. This means that side-effects of behavioral parameters may not + * always be executed and should not be relied upon, unless otherwise specified + * (such as by the terminal operations {@code forEach} and + * {@code forEachOrdered}).(For a specific example ofsuch an optimization, + * see the API note documented on the {@link #count} operation. For more + * details, see the side-effects + * section of the stream package documentation.) + * Thanks! /Claes On 2016-05-17 22:23, Paul Sandoz wrote: > Hi, > > Please review: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8130023-stream-elide-ops-side-effects/webrev/ > > This is a spec tweak to streams to state that implementations are free to elide some or all operations in a pipeline as long as it does not affect the result of the stream computation i.e. side-effects beware! > > Paul. From stuart.marks at oracle.com Tue May 17 23:33:40 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 17 May 2016 16:33:40 -0700 Subject: RFR(s): 8133977 add specification for serial form of immutable collections In-Reply-To: <1c7ceba4-470a-0315-df38-ff07b127c2ff@gmail.com> References: <704c44ef-e3e7-d483-5dcd-b7e19bbbf6fc@oracle.com> <90EB34AC-5AFC-4972-9EAB-04072F54F640@oracle.com> <3642425c-378e-1904-7046-76967b014c75@oracle.com> <1c7ceba4-470a-0315-df38-ff07b127c2ff@gmail.com> Message-ID: <7bb8bc40-ffe2-491f-8378-46f8cf835043@oracle.com> On 5/17/16 1:09 PM, Peter Levart wrote: >> I don't think it's possible to have a single form for all new serializable >> objects in java.util. The java.util package isn't as cohesive as java.time. >> There's a bunch of random stuff in it. Consider the non-serializable things >> currently in java.util: >> >> *SummaryStatistics, Optional, Formatter, ResourceBundle, >> Scanner, ServiceLoader, StringJoiner, Timer >> >> If any of these were to be made serializable, I don't think it would make >> sense for it to share the serialized form with CollSer. > They would not share the form. The java.time.Ser does not specify serialized > form by itself (short of a single byte stream prefix that selects the > sub-format/implementaion typically hosted in the implementation classes > themselves). java.time.Ser is just an adapter that allows for > Externalizable-like functionality of implementations but not requiring them to > implement a public no-arg constructor that constructs uninitialized instances. > So all above mentioned classes could simply share a single java.util.Ser > serialization proxy however different they are. OK, I guess I overstated this by saying that I didn't think it was possible. Of course it's possible, given sufficient hacking. But a unified "java.util.Ser" proxy for everything in java.util would have the objects share the same serialized form in that they'd share the serialized object header, serial version UID, class descriptor, and fields (if any). Clearly the responsibility for handling actual instance data would be delegated back to the classes themselves. I just don't think there's any advantage to doing this for unrelated classes. Indeed, it's a disadvantage to couple together the serial forms of classes that are otherwise unrelated. s'marks From brent.christian at oracle.com Wed May 18 01:46:40 2016 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 17 May 2016 18:46:40 -0700 Subject: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival In-Reply-To: References: <55479A4F.4060806@oracle.com> <5550FE5A.4070607@oracle.com> <55513EA7.1050700@oracle.com> <555192A4.3080305@gmail.com> <5551A0AA.6050800@gmail.com> <5552674E.4030009@oracle.com> <55526FF5.9000509@gmail.com> <55564473.3010704@oracle.com> <8DD50D66-D2C1-43E4-B7C5-992FE785958B@oracle.com> <57325921.9090100@oracle.com> <5734EF6C.5090603@oracle.com> Message-ID: <573BC980.9000100@oracle.com> Hi! Here's the final(?) webrev: http://cr.openjdk.java.net/~bchristi/8029891/webrev.6/webrev/ with the following changes since the last one: * The @hidden JavaDoc tag has been removed. It can't be used due to methods disappearing from the API page. Living with the additional JavaDoc is the best option for now. The situation should be improved by JDK-8157000 (thanks for filing, Mandy). * I also firmed up the doc update regarding iterators (using words from the java.util.concurrent package description of "weakly-consistent"). Line 170. New specdiff views: http://cr.openjdk.java.net/~bchristi/8029891/webrev.6/specdiff-javadoc/Properties.html http://cr.openjdk.java.net/~bchristi/8029891/webrev.6/specdiff-plain/Properties.html * I did make one real code change, making the new Properties.EntrySet inner class static. Line 1250. * I added a new test of unsynchronized, as suggested by Peter, and expanded coverage to all newly-unsynchronized methods. Thanks, -Brent On 5/13/16 8:01 AM, Mandy Chung wrote: > >> On May 12, 2016, at 5:58 PM, David Holmes wrote: >>> >>> With all of the inherited methods @hidden, it looks like that section >>> is left out altogether. >> >> Okay, so I have to say @hidden seems to me to be seriously flawed! If a class has a method that can be called then IMHO that has to be documented in that class as either being first defined, overridden, or inherited - it can't just say nothing as-if the method were not there! >> >> If we are overriding in a trivial way that does not change the specification at all then there should be a simple way to show that - perhaps the "Methods inherited from ..." should be split into two parts: method implementations inherited from ..., and method specifications inherited from ... ?? >> > > I agree for this case these methods should not be hidden as if it?s not there (that?s probably carried from the original @treatAsPrivate request). > >> I guess I need to raise this with the javadoc folk :( Is there a mailing list for that? > > Can you file a JBS issue? Kumar is on vacation and will talk with him when he?s back. > > Mandy > From mandy.chung at oracle.com Wed May 18 02:20:03 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 17 May 2016 19:20:03 -0700 Subject: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival In-Reply-To: <573BC980.9000100@oracle.com> References: <55479A4F.4060806@oracle.com> <5550FE5A.4070607@oracle.com> <55513EA7.1050700@oracle.com> <555192A4.3080305@gmail.com> <5551A0AA.6050800@gmail.com> <5552674E.4030009@oracle.com> <55526FF5.9000509@gmail.com> <55564473.3010704@oracle.com> <8DD50D66-D2C1-43E4-B7C5-992FE785958B@oracle.com> <57325921.9090100@oracle.com> <5734EF6C.5090603@oracle.com> <573BC980.9000100@oracle.com> Message-ID: > On May 17, 2016, at 6:46 PM, Brent Christian wrote: > > Hi! > > Here's the final(?) webrev: > http://cr.openjdk.java.net/~bchristi/8029891/webrev.6/webrev/ +1 Nit: line 132, 134 in PropertiesSerialization.java test are long lines that should be wrapped to next line. Mandy From david.holmes at oracle.com Wed May 18 02:24:57 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 May 2016 12:24:57 +1000 Subject: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival In-Reply-To: <573BC980.9000100@oracle.com> References: <55479A4F.4060806@oracle.com> <5550FE5A.4070607@oracle.com> <55513EA7.1050700@oracle.com> <555192A4.3080305@gmail.com> <5551A0AA.6050800@gmail.com> <5552674E.4030009@oracle.com> <55526FF5.9000509@gmail.com> <55564473.3010704@oracle.com> <8DD50D66-D2C1-43E4-B7C5-992FE785958B@oracle.com> <57325921.9090100@oracle.com> <5734EF6C.5090603@oracle.com> <573BC980.9000100@oracle.com> Message-ID: On 18/05/2016 11:46 AM, Brent Christian wrote: > Hi! > > Here's the final(?) webrev: > http://cr.openjdk.java.net/~bchristi/8029891/webrev.6/webrev/ > with the following changes since the last one: No further comments from me. Thanks, David > * The @hidden JavaDoc tag has been removed. It can't be used due to > methods disappearing from the API page. Living with the additional > JavaDoc is the best option for now. The situation should be improved by > JDK-8157000 (thanks for filing, Mandy). > > * I also firmed up the doc update regarding iterators (using words from > the java.util.concurrent package description of "weakly-consistent"). > Line 170. > > New specdiff views: > > http://cr.openjdk.java.net/~bchristi/8029891/webrev.6/specdiff-javadoc/Properties.html > > > http://cr.openjdk.java.net/~bchristi/8029891/webrev.6/specdiff-plain/Properties.html > > > * I did make one real code change, making the new Properties.EntrySet > inner class static. Line 1250. > > * I added a new test of unsynchronized, as suggested by Peter, and > expanded coverage to all newly-unsynchronized methods. > > Thanks, > -Brent > > On 5/13/16 8:01 AM, Mandy Chung wrote: >> >>> On May 12, 2016, at 5:58 PM, David Holmes >>> wrote: >>>> >>>> With all of the inherited methods @hidden, it looks like that section >>>> is left out altogether. >>> >>> Okay, so I have to say @hidden seems to me to be seriously flawed! If >>> a class has a method that can be called then IMHO that has to be >>> documented in that class as either being first defined, overridden, >>> or inherited - it can't just say nothing as-if the method were not >>> there! >>> >>> If we are overriding in a trivial way that does not change the >>> specification at all then there should be a simple way to show that - >>> perhaps the "Methods inherited from ..." should be split into two >>> parts: method implementations inherited from ..., and method >>> specifications inherited from ... ?? >>> >> >> I agree for this case these methods should not be hidden as if it?s >> not there (that?s probably carried from the original @treatAsPrivate >> request). >> >>> I guess I need to raise this with the javadoc folk :( Is there a >>> mailing list for that? >> >> Can you file a JBS issue? Kumar is on vacation and will talk with him >> when he?s back. >> >> Mandy >> From huizhe.wang at oracle.com Wed May 18 03:59:01 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 17 May 2016 20:59:01 -0700 Subject: RFR [9]: 8072579: XjcOptionalPropertyTest.java creates files in test.src In-Reply-To: <573A5A3F.7050702@oracle.com> References: <573A5A3F.7050702@oracle.com> Message-ID: <573BE885.9090707@oracle.com> Hi Aleksej, The change looks good to me. Best, Joe On 5/16/2016 4:39 PM, Aleks Efimov wrote: > Hi, > > Please, help to review XjcOptionalPropertyTest test modification bug [1]. > The list of applied changes: > 1. Test files are now generated in jtreg work directory (scratch), > instead of test source folder. > 2. Shell script was replaced with java code: xjc tool is now invoked > via jdk.testlibrary.JDKToolLauncher. > 3. Compilation of xjc generated classes is done with usage of > JDKToolLauncher. > > Webrev: http://cr.openjdk.java.net/~aefimov/8072579/9/00 > > With Best Regards, > Aleksej > > [1] https://bugs.openjdk.java.net/browse/JDK-8072579 From huizhe.wang at oracle.com Wed May 18 04:03:07 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 17 May 2016 21:03:07 -0700 Subject: RFR [9]: 8157096: [TEST_BUG] test/javax/xml/bind/xjc/8145039/JaxbMarshallTest.java is skipped by jtreg In-Reply-To: <573A5E6B.2070202@oracle.com> References: <573A5E6B.2070202@oracle.com> Message-ID: <573BE97B.8090005@oracle.com> Looks good, Aleksej. -Joe On 5/16/2016 4:57 PM, Aleks Efimov wrote: > Hi, > > Please review the changes to > test/javax/xml/bind/xjc/8145039/JaxbMarshallTest.java: > 1. The test is skipped by JTREG due to incorrect module name in jtreg > @modules tag: javax.xml.bind -> java.xml.bind > > 2. The compilation of XJC generated classes now requires "-addmods > java.xml.bind" argument to be passed to javac tool. > > The test was executed with JTREG and passed. > > Webrev: http://cr.openjdk.java.net/~aefimov/8157096/9/00 > JBS: https://bugs.openjdk.java.net/browse/JDK-8157096 > > With Best Regards, > Aleksej From huaming.li at oracle.com Wed May 18 04:52:20 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 18 May 2016 12:52:20 +0800 Subject: JDK 9 RFR of JDK-8157211: Mark tools/launcher/FXLauncherTest.java as intermittently failing Message-ID: <573BF504.1000601@oracle.com> tools/launcher/FXLauncherTest.java This test is known to fail intermittently (JDK-8130392 ), it should be marked accordingly with at key intermittentjtreg tag in the test file. bug: https://bugs.openjdk.java.net/browse/JDK-8157211 webrev: http://cr.openjdk.java.net/~mli/8157211/webrev.00/ Thank you -Hamlin --- a/test/tools/launcher/FXLauncherTest.java Tue May 17 19:20:05 2016 -0700 +++ b/test/tools/launcher/FXLauncherTest.java Tue May 17 21:44:18 2016 -0700 @@ -29,6 +29,7 @@ * jfx app class, a main-class for the manifest, a bogus one and none. * All should execute except the incorrect fx app class entries. * @run main/othervm FXLauncherTest + * @key intermittent */ import java.io.File; import java.io.IOException; From peter.levart at gmail.com Wed May 18 06:07:00 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 18 May 2016 08:07:00 +0200 Subject: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival In-Reply-To: <573BC980.9000100@oracle.com> References: <55479A4F.4060806@oracle.com> <5550FE5A.4070607@oracle.com> <55513EA7.1050700@oracle.com> <555192A4.3080305@gmail.com> <5551A0AA.6050800@gmail.com> <5552674E.4030009@oracle.com> <55526FF5.9000509@gmail.com> <55564473.3010704@oracle.com> <8DD50D66-D2C1-43E4-B7C5-992FE785958B@oracle.com> <57325921.9090100@oracle.com> <5734EF6C.5090603@oracle.com> <573BC980.9000100@oracle.com> Message-ID: Hi Brent, The unsynchronized test looks good. Let's hope that we didn't miss any hidden detail. We'll see how this works out when people get hold of new build containing this change. Regards, Peter On 05/18/2016 03:46 AM, Brent Christian wrote: > Hi! > > Here's the final(?) webrev: > http://cr.openjdk.java.net/~bchristi/8029891/webrev.6/webrev/ > with the following changes since the last one: > > * The @hidden JavaDoc tag has been removed. It can't be used due to > methods disappearing from the API page. Living with the additional > JavaDoc is the best option for now. The situation should be improved > by JDK-8157000 (thanks for filing, Mandy). > > * I also firmed up the doc update regarding iterators (using words > from the java.util.concurrent package description of > "weakly-consistent"). Line 170. > > New specdiff views: > > http://cr.openjdk.java.net/~bchristi/8029891/webrev.6/specdiff-javadoc/Properties.html > > > http://cr.openjdk.java.net/~bchristi/8029891/webrev.6/specdiff-plain/Properties.html > > > * I did make one real code change, making the new Properties.EntrySet > inner class static. Line 1250. > > * I added a new test of unsynchronized, as suggested by Peter, and > expanded coverage to all newly-unsynchronized methods. > > Thanks, > -Brent > > On 5/13/16 8:01 AM, Mandy Chung wrote: >> >>> On May 12, 2016, at 5:58 PM, David Holmes >>> wrote: >>>> >>>> With all of the inherited methods @hidden, it looks like that section >>>> is left out altogether. >>> >>> Okay, so I have to say @hidden seems to me to be seriously flawed! >>> If a class has a method that can be called then IMHO that has to be >>> documented in that class as either being first defined, overridden, >>> or inherited - it can't just say nothing as-if the method were not >>> there! >>> >>> If we are overriding in a trivial way that does not change the >>> specification at all then there should be a simple way to show that >>> - perhaps the "Methods inherited from ..." should be split into two >>> parts: method implementations inherited from ..., and method >>> specifications inherited from ... ?? >>> >> >> I agree for this case these methods should not be hidden as if it?s >> not there (that?s probably carried from the original @treatAsPrivate >> request). >> >>> I guess I need to raise this with the javadoc folk :( Is there a >>> mailing list for that? >> >> Can you file a JBS issue? Kumar is on vacation and will talk with >> him when he?s back. >> >> Mandy >> From michael.haupt at oracle.com Wed May 18 07:52:40 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 18 May 2016 09:52:40 +0200 Subject: RFR(M): 8156915: introduce MethodHandle factory for array length Message-ID: <52930F20-0F98-40C8-9B61-554F73CE960B@oracle.com> Dear all, please review this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8156915 Webrev: http://cr.openjdk.java.net/~mhaupt/8156915/webrev.00/ Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Wed May 18 07:54:13 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 18 May 2016 09:54:13 +0200 Subject: MethodHandle for array length In-Reply-To: <036d01d1acfd$7b0a48f0$711edad0$@apache.org> References: <00a601d1abbc$4a907ec0$dfb17c40$@apache.org> <3FD85BA6-799F-465F-8B33-BD75635D33AE@oracle.com> <01d301d1ac4a$a65264b0$f2f72e10$@apache.org> <1843689259.97223.1463128603038.JavaMail.zimbra@u-pem.fr> <036d01d1acfd$7b0a48f0$711edad0$@apache.org> Message-ID: <99B72204-6F00-47D9-B108-6979E15EB9DD@oracle.com> Hi Uwe, you're welcome. Note it's up for review now: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/041211.html Best, Michael > Am 13.05.2016 um 11:54 schrieb Uwe Schindler : > > Hi, > > OK, thanks for creating an issue! > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > >> -----Original Message----- >> From: Remi Forax [mailto:forax at univ-mlv.fr] >> Sent: Friday, May 13, 2016 10:37 AM >> To: Uwe Schindler >> Cc: Michael Haupt ; Core-Libs-Dev > dev at openjdk.java.net> >> Subject: Re: MethodHandle for array length >> >> Hi Uwe, >> I was planning to add a bug for this feature but it seems that Michael was >> faster than me, >> https://bugs.openjdk.java.net/browse/JDK-8156915 >> >> regards, >> R?mi >> >> ----- Mail original ----- >>> De: "Uwe Schindler" >>> ?: "Michael Haupt" , "Core-Libs-Dev" > libs-dev at openjdk.java.net> >>> Envoy?: Jeudi 12 Mai 2016 14:34:34 >>> Objet: RE: MethodHandle for array length >>> >>> Hi Michael, >>> >>>>> Am 11.05.2016 um 21:35 schrieb Uwe Schindler >> : >>>>> With Java 9 this gets a bit worse: There is no "easy way" with the >>>> MethodHanldes class to generate a MethodHandles.countedLoop() on all >>>> elements of an array: >>>>> >>>>> public static MethodHandle countedLoop(MethodHandle iterations, >>>> MethodHandle init, MethodHandle body) [new in Java 9] >>>> >>>> this isn't a remedy when you need the index in each iteration, but you >> can >>>> generate a loop over all elements of an array using iteratedLoop(), as >>>> illustrated by this test from LoopCombinatorTest: >>>> >>>> @Test >>>> public static void testIterateSum() throws Throwable { >>>> // Integer[] a = new Integer[]{1,2,3,4,5,6}; int sum = 0; for (int e : >>>> a) { sum >>>> += e; } return sum; => 21 >>>> MethodHandle loop = >>>> MethodHandles.iteratedLoop(Iterate.MH_sumIterator, >> Iterate.MH_sumInit, >>>> Iterate.MH_sumStep); >>>> assertEquals(Iterate.MT_sum, loop.type()); >>>> assertEquals(21, loop.invoke(new Integer[]{1, 2, 3, 4, 5, 6})); >>>> } >>>> >>>> ... where MH_sumIterator is a handle to this method: >>>> >>>> static Iterator sumIterator(Integer[] a) { >>>> return Arrays.asList(a).iterator(); >>>> } >>> >>> Of course this works, too. >>> >>> My proposal or question here was more about the API inconsistency in >> general. >>> You can do a lot here and there, you can implement effective or >>> non-effective loops with MethodHandles, but still the following holds true: >>> java.lang.invoke.MethodHandles is missing an accessor for "array.length", >>> which is not understandable. The "countedLoop" here was just an example >> use >>> case (if that one is great or not does not matter), it was just posted to >>> actually show the API and how it *could* be used. >>> >>> The real example from our script engine was not related to loops, it was an >>> actual invokedynamic callsite implementation where it was not possible to >>> figure out how to get a method handle to the very special arraylength byte >>> code, aka "array.length javac sugar". Everything else to handle arrays is >>> there at one single place, but the array length is missing and you get very >>> annoyed. If you are not so familiar to bytecode and the mechanics behind, >>> you have a very hard time to find out how to do this: the intuitive >>> solutions does not work: "array.length" -> aha it?s a field, so let's try >>> Lookup.findGetter(long[].class, "length", int.class) -> does not work! >>> >>> What is so hard to accept the proposal to have >>> MethodHandles.arrayLengthGetter, implemented in the most effective >> way (as a >>> methodhandle that solely calls the special bytecode "arraylength")? In fact >>> thais is like a 10 liner to implement + Javadocs. No need to delay a >>> release, there are still changes in JDK 9 going on that are far more risky >>> than this. >>> >>> Best, >>> Uwe -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From sundararajan.athijegannathan at oracle.com Wed May 18 07:55:01 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 18 May 2016 13:25:01 +0530 Subject: RFR 8154192: Deprivilege java.scripting module In-Reply-To: <573B0D7F.9080907@oracle.com> References: <3e1bed67-ae64-00c2-2e99-21af225e2b30@oracle.com> <573B0D7F.9080907@oracle.com> Message-ID: Please review the updated webrevs. * Fixed Modules.gmk for order of modules: http://cr.openjdk.java.net/~sundar/8154192/top/webrev.01/ * From quick reading of j.u.ServiceLoader: AccessControlContext is captured in ServiceLoader constructor & used for iteration (RestrictedIterator). So, ScriptEngineManager calling only ServiceLoader constructor inside doPrivileged block seems fine. Also, I turned ProviderTest javax.script API test to use security manager - this tests loads a dummy script engine from a jar file in classpath. This test passes with security manager on. http://cr.openjdk.java.net/~sundar/8154192/jdk/webrev.01/ Yes, we can still revisit AllPermission for java.scripting module in a future change. Thanks, -Sundar On 5/17/2016 5:54 PM, Alan Bateman wrote: > On 17/05/2016 13:04, Sundararajan Athijegannathan wrote: >> Please review fix for https://bugs.openjdk.java.net/browse/JDK-8154192 >> >> java.scripting module is assigned to platform class loader (instead of >> boot loader). And java.scripting module is given AllPermission >> [previously it had AllPermission implicitly because of being boot loader >> code] >> >> jdk repo: >> >> http://cr.openjdk.java.net/~sundar/8154192/jdk/webrev.00/ >> >> top level repo: >> >> http://cr.openjdk.java.net/~sundar/8154192/top/webrev.00/ >> >> > Would it be possible to keep the PLATFORM_MODULES sorted? Otherwise it > looks okay as a first patch. I think we also need to understand why > this module needs AllPermission. From a quick look then it creates the > SL with all permissions but the iteration will be restricted by > whatever is on the stack so I just wonder if it works as intended. > > -Alan From sundararajan.athijegannathan at oracle.com Wed May 18 08:07:11 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 18 May 2016 13:37:11 +0530 Subject: RFR(M): 8156915: introduce MethodHandle factory for array length In-Reply-To: <52930F20-0F98-40C8-9B61-554F73CE960B@oracle.com> References: <52930F20-0F98-40C8-9B61-554F73CE960B@oracle.com> Message-ID: <614830a3-5d23-f704-9deb-633436432ea6@oracle.com> +1 Minor comment: File: MethodHandleImpl.java If "checks" can be inside the assert. + if (access == ArrayAccess.SET) assert(mh.type().parameterType(2) == Object.class); + if (access == ArrayAccess.GET) { + assert(mh.type().returnType() == Object.class); + assert(correctType.parameterType(0).getComponentType() == correctType.returnType()); + } -Sundar On 5/18/2016 1:22 PM, Michael Haupt wrote: > Dear all, > > please review this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8156915 > Webrev: http://cr.openjdk.java.net/~mhaupt/8156915/webrev.00/ > > Thanks, > > Michael > From michael.haupt at oracle.com Wed May 18 08:11:22 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 18 May 2016 10:11:22 +0200 Subject: MethodHandle for array length In-Reply-To: <037401d1ad00$4f275cc0$ed761640$@apache.org> References: <00a601d1abbc$4a907ec0$dfb17c40$@apache.org> <3FD85BA6-799F-465F-8B33-BD75635D33AE@oracle.com> <01d301d1ac4a$a65264b0$f2f72e10$@apache.org> <1843689259.97223.1463128603038.JavaMail.zimbra@u-pem.fr> <037401d1ad00$4f275cc0$ed761640$@apache.org> Message-ID: <9417F6E3-3113-4DC3-B8A5-FD197EFA6322@oracle.com> Hi Uwe, it's a different issue, but still: https://bugs.openjdk.java.net/browse/JDK-8157225 Best, Michael > Am 13.05.2016 um 12:14 schrieb Uwe Schindler : > > Hi, > > One addition, maybe add to issue: > > If this was added, jdk.dynalink module could use it, too - this was mentioned by Attila already: http://hg.openjdk.java.net/jdk9/dev/nashorn/file/4b118e012ac4/src/jdk.dynalink/share/classes/jdk/dynalink/beans/BeanLinker.java > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > >> -----Original Message----- >> From: Uwe Schindler [mailto:uschindler at apache.org] >> Sent: Friday, May 13, 2016 11:55 AM >> To: 'Remi Forax' >> Cc: 'Michael Haupt' ; 'Core-Libs-Dev' > dev at openjdk.java.net> >> Subject: RE: MethodHandle for array length >> >> Hi, >> >> OK, thanks for creating an issue! >> >> Uwe >> >> ----- >> Uwe Schindler >> uschindler at apache.org >> ASF Member, Apache Lucene PMC / Committer >> Bremen, Germany >> http://lucene.apache.org/ >> >>> -----Original Message----- >>> From: Remi Forax [mailto:forax at univ-mlv.fr] >>> Sent: Friday, May 13, 2016 10:37 AM >>> To: Uwe Schindler >>> Cc: Michael Haupt ; Core-Libs-Dev >> dev at openjdk.java.net> >>> Subject: Re: MethodHandle for array length >>> >>> Hi Uwe, >>> I was planning to add a bug for this feature but it seems that Michael was >>> faster than me, >>> https://bugs.openjdk.java.net/browse/JDK-8156915 >>> >>> regards, >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "Uwe Schindler" >>>> ?: "Michael Haupt" , "Core-Libs-Dev" >> >> libs-dev at openjdk.java.net> >>>> Envoy?: Jeudi 12 Mai 2016 14:34:34 >>>> Objet: RE: MethodHandle for array length >>>> >>>> Hi Michael, >>>> >>>>>> Am 11.05.2016 um 21:35 schrieb Uwe Schindler >>> : >>>>>> With Java 9 this gets a bit worse: There is no "easy way" with the >>>>> MethodHanldes class to generate a MethodHandles.countedLoop() on >> all >>>>> elements of an array: >>>>>> >>>>>> public static MethodHandle countedLoop(MethodHandle iterations, >>>>> MethodHandle init, MethodHandle body) [new in Java 9] >>>>> >>>>> this isn't a remedy when you need the index in each iteration, but you >>> can >>>>> generate a loop over all elements of an array using iteratedLoop(), as >>>>> illustrated by this test from LoopCombinatorTest: >>>>> >>>>> @Test >>>>> public static void testIterateSum() throws Throwable { >>>>> // Integer[] a = new Integer[]{1,2,3,4,5,6}; int sum = 0; for (int e : >>>>> a) { sum >>>>> += e; } return sum; => 21 >>>>> MethodHandle loop = >>>>> MethodHandles.iteratedLoop(Iterate.MH_sumIterator, >>> Iterate.MH_sumInit, >>>>> Iterate.MH_sumStep); >>>>> assertEquals(Iterate.MT_sum, loop.type()); >>>>> assertEquals(21, loop.invoke(new Integer[]{1, 2, 3, 4, 5, 6})); >>>>> } >>>>> >>>>> ... where MH_sumIterator is a handle to this method: >>>>> >>>>> static Iterator sumIterator(Integer[] a) { >>>>> return Arrays.asList(a).iterator(); >>>>> } >>>> >>>> Of course this works, too. >>>> >>>> My proposal or question here was more about the API inconsistency in >>> general. >>>> You can do a lot here and there, you can implement effective or >>>> non-effective loops with MethodHandles, but still the following holds >> true: >>>> java.lang.invoke.MethodHandles is missing an accessor for >> "array.length", >>>> which is not understandable. The "countedLoop" here was just an >> example >>> use >>>> case (if that one is great or not does not matter), it was just posted to >>>> actually show the API and how it *could* be used. >>>> >>>> The real example from our script engine was not related to loops, it was >> an >>>> actual invokedynamic callsite implementation where it was not possible >> to >>>> figure out how to get a method handle to the very special arraylength >> byte >>>> code, aka "array.length javac sugar". Everything else to handle arrays is >>>> there at one single place, but the array length is missing and you get very >>>> annoyed. If you are not so familiar to bytecode and the mechanics >> behind, >>>> you have a very hard time to find out how to do this: the intuitive >>>> solutions does not work: "array.length" -> aha it?s a field, so let's try >>>> Lookup.findGetter(long[].class, "length", int.class) -> does not work! >>>> >>>> What is so hard to accept the proposal to have >>>> MethodHandles.arrayLengthGetter, implemented in the most effective >>> way (as a >>>> methodhandle that solely calls the special bytecode "arraylength")? In >> fact >>>> thais is like a 10 liner to implement + Javadocs. No need to delay a >>>> release, there are still changes in JDK 9 going on that are far more risky >>>> than this. >>>> >>>> Best, >>>> Uwe -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From Alan.Bateman at oracle.com Wed May 18 08:47:32 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 May 2016 09:47:32 +0100 Subject: RFR 8154192: Deprivilege java.scripting module In-Reply-To: References: <3e1bed67-ae64-00c2-2e99-21af225e2b30@oracle.com> <573B0D7F.9080907@oracle.com> Message-ID: <573C2C24.6000005@oracle.com> On 18/05/2016 08:55, Sundararajan Athijegannathan wrote: > Please review the updated webrevs. > > * Fixed Modules.gmk for order of modules: > > http://cr.openjdk.java.net/~sundar/8154192/top/webrev.01/ > > * From quick reading of j.u.ServiceLoader: AccessControlContext is > captured in ServiceLoader constructor & used for iteration > (RestrictedIterator). So, ScriptEngineManager calling only ServiceLoader > constructor inside doPrivileged block seems fine. Also, I turned > ProviderTest javax.script API test to use security manager - this tests > loads a dummy script engine from a jar file in classpath. This test > passes with security manager on. > > http://cr.openjdk.java.net/~sundar/8154192/jdk/webrev.01/ > > Yes, we can still revisit AllPermission for java.scripting module in a > future change. > One suggestion is to run ProviderTest twice, both with and without SM. The rest looks okay. -Alan. From sundararajan.athijegannathan at oracle.com Wed May 18 08:53:58 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 18 May 2016 14:23:58 +0530 Subject: RFR 8154192: Deprivilege java.scripting module In-Reply-To: <573C2C24.6000005@oracle.com> References: <3e1bed67-ae64-00c2-2e99-21af225e2b30@oracle.com> <573B0D7F.9080907@oracle.com> <573C2C24.6000005@oracle.com> Message-ID: <4f9e0afd-a268-fe11-4478-16335f38725d@oracle.com> Thanks. I'll make that change and push it. -Sundar On 5/18/2016 2:17 PM, Alan Bateman wrote: > On 18/05/2016 08:55, Sundararajan Athijegannathan wrote: >> Please review the updated webrevs. >> >> * Fixed Modules.gmk for order of modules: >> >> http://cr.openjdk.java.net/~sundar/8154192/top/webrev.01/ >> >> * From quick reading of j.u.ServiceLoader: AccessControlContext is >> captured in ServiceLoader constructor & used for iteration >> (RestrictedIterator). So, ScriptEngineManager calling only ServiceLoader >> constructor inside doPrivileged block seems fine. Also, I turned >> ProviderTest javax.script API test to use security manager - this tests >> loads a dummy script engine from a jar file in classpath. This test >> passes with security manager on. >> >> http://cr.openjdk.java.net/~sundar/8154192/jdk/webrev.01/ >> >> Yes, we can still revisit AllPermission for java.scripting module in a >> future change. >> > One suggestion is to run ProviderTest twice, both with and without SM. > The rest looks okay. > > -Alan. From scolebourne at joda.org Wed May 18 09:42:22 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 18 May 2016 10:42:22 +0100 Subject: RFR(s): 8133977 add specification for serial form of immutable collections In-Reply-To: <7bb8bc40-ffe2-491f-8378-46f8cf835043@oracle.com> References: <704c44ef-e3e7-d483-5dcd-b7e19bbbf6fc@oracle.com> <90EB34AC-5AFC-4972-9EAB-04072F54F640@oracle.com> <3642425c-378e-1904-7046-76967b014c75@oracle.com> <1c7ceba4-470a-0315-df38-ff07b127c2ff@gmail.com> <7bb8bc40-ffe2-491f-8378-46f8cf835043@oracle.com> Message-ID: My original blog on the topic was in 2010: http://blog.joda.org/2010/02/serialization-shared-delegates_9131.html Bear in mind that a key reason for sharing the serialization proxy is to share the "serialized object header, serial version UID, class descriptor" etc. It is that header overhead that is the main reason for serialization being so space inefficient on the wire. It is thus a positive thing that "unrelated classes" share the proxy. JSR-310 goes to great lengths to save bytes in the stream - see LocalTime for example. IMO, it would be really good to see serialization move to a single package-level shared proxy in java.util as well, as it would dramatically reduce many stream sizes (as per the blog post). So, the key aspects of the pattern that I see are: - shared between multiple classes - use a flag (byte) to distinguish classes - top level class with a short name - externalizable, not serializable JSR-310 chooses to delegate the actual logic back to the class itself, but this is not required by the pattern. What CollSer does not do is implement Externalizable. And as I've argued, I believe it is a *good* thing to share a Ser class across a package (to overcome the limitations of the ancient Serialization spec). Anyway, I've done half the work for you ;-) https://gist.github.com/jodastephen/2bb70e1f1180b030d46b5a6366c0a0c4 With a collection of 1 string, CollSer uses 136 bytes while my Externalizable Ser uses 58. With a collection of 3 strings, CollSer uses 171 bytes while my Externalizable Ser uses 87. These are the contents of the stream. As can be seen, the Externalizable form avoids two java.lang.Object references. CollSer: 136 [ac][ed][0][5]sr[0]!com.opengamma.strata.calc.CollSerW[8e][ab][b6]:[1b][a8][11][2][0][2]I[0][5]flags[[0][5]arrayt[0][13][Ljava/lang/Object;xp[0][0][0][1]ur[0][13][Ljava.lang.Object;[90][ce]X[9f][10]s)l[2][0][0]xp[0][0][0][0] 171 [ac][ed][0][5]sr[0]!com.opengamma.strata.calc.CollSerW[8e][ab][b6]:[1b][a8][11][2][0][2]I[0][5]flags[[0][5]arrayt[0][13][Ljava/lang/Object;xp[0][0][0][1]ur[0][13][Ljava.lang.Object;[90][ce]X[9f][10]s)l[2][0][0]xp[0][0][0][0]sq[0]~[0][0][0][0][0][1]uq[0]~[0][3][0][0][0][3]t[0][1]at[0][2]bbt[0][3]ccc Ser: 58 [ac][ed][0][5]sr[0][1d]com.opengamma.strata.calc.SerW[8e][ab][b6]:[1b][a8][11][c][0][0]xpw[5][1][0][0][0][0]x 87 [ac][ed][0][5]sr[0][1d]com.opengamma.strata.calc.SerW[8e][ab][b6]:[1b][a8][11][c][0][0]xpw[5][1][0][0][0][0]xsq[0]~[0][0]w[5][1][0][0][0][3]t[0][1]at[0][2]bbt[0][3]cccx While I understand the forward/backward compatibility argument of (int & 0xff) however I'm unconvinced of the need. If things change, I don't expect the new format to be loadable in an earlier JDK version. What is not in doubt is that what is proposed is incredibly wasteful. In all current known cases, just 2 bits out of 32 are being used. Altering the current logic to use (byte & 0xf) would have the same effect. Unless you have some specific future changes in mind that need 24 bits of flag/data, the likelihood is that YAGNI applies. (The main question for the future is going to be value types, and how the serialized form evolves to support reified collections. I suspect that this will require writing out the class reference of the reified collection content, something that will need more than 24 bits anyway). Stephen On 18 May 2016 at 00:33, Stuart Marks wrote: > On 5/17/16 1:09 PM, Peter Levart wrote: >>> >>> I don't think it's possible to have a single form for all new >>> serializable objects in java.util. The java.util package isn't as cohesive >>> as java.time. There's a bunch of random stuff in it. Consider the >>> non-serializable things currently in java.util: >>> >>> *SummaryStatistics, Optional, Formatter, ResourceBundle, >>> Scanner, ServiceLoader, StringJoiner, Timer >>> >>> If any of these were to be made serializable, I don't think it would make >>> sense for it to share the serialized form with CollSer. >> >> They would not share the form. The java.time.Ser does not specify >> serialized form by itself (short of a single byte stream prefix that selects >> the sub-format/implementaion typically hosted in the implementation classes >> themselves). java.time.Ser is just an adapter that allows for >> Externalizable-like functionality of implementations but not requiring them >> to implement a public no-arg constructor that constructs uninitialized >> instances. So all above mentioned classes could simply share a single >> java.util.Ser serialization proxy however different they are. > > OK, I guess I overstated this by saying that I didn't think it was possible. > Of course it's possible, given sufficient hacking. > > But a unified "java.util.Ser" proxy for everything in java.util would have > the objects share the same serialized form in that they'd share the > serialized object header, serial version UID, class descriptor, and fields > (if any). Clearly the responsibility for handling actual instance data would > be delegated back to the classes themselves. > > I just don't think there's any advantage to doing this for unrelated > classes. Indeed, it's a disadvantage to couple together the serial forms of > classes that are otherwise unrelated. > > s'marks > From vladimir.x.ivanov at oracle.com Wed May 18 09:47:43 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 18 May 2016 12:47:43 +0300 Subject: RFR(M): 8156915: introduce MethodHandle factory for array length In-Reply-To: <52930F20-0F98-40C8-9B61-554F73CE960B@oracle.com> References: <52930F20-0F98-40C8-9B61-554F73CE960B@oracle.com> Message-ID: <5e0419a0-8000-9cea-128a-b42d12ca65a2@oracle.com> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java + throw new AssertionError(); + throw new IllegalStateException("should not reach here"); Please, use InternalError to signal about error conditions (there's MHS.newInternalError(String)) and put a message containing description of problematic parameters to simplify problem diagnostics. Otherwise, looks good! Best regards, Vladimir Ivanov On 5/18/16 10:52 AM, Michael Haupt wrote: > Dear all, > > please review this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8156915 > Webrev: http://cr.openjdk.java.net/~mhaupt/8156915/webrev.00/ > > Thanks, > > Michael > From uschindler at apache.org Wed May 18 09:49:39 2016 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 18 May 2016 11:49:39 +0200 Subject: RFR(M): 8156915: introduce MethodHandle factory for array length In-Reply-To: <614830a3-5d23-f704-9deb-633436432ea6@oracle.com> References: <52930F20-0F98-40C8-9B61-554F73CE960B@oracle.com> <614830a3-5d23-f704-9deb-633436432ea6@oracle.com> Message-ID: <01be01d1b0ea$9a872900$cf957b00$@apache.org> Hi, I noticed the same when skimming through the patch! I'd change this, too. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf Of Sundararajan Athijegannathan > Sent: Wednesday, May 18, 2016 10:07 AM > To: core-libs-dev at openjdk.java.net > Subject: Re: RFR(M): 8156915: introduce MethodHandle factory for array > length > > +1 > > Minor comment: > > File: MethodHandleImpl.java > > If "checks" can be inside the assert. + if (access == ArrayAccess.SET) > assert(mh.type().parameterType(2) == Object.class); > + if (access == ArrayAccess.GET) { > + assert(mh.type().returnType() == Object.class); > + assert(correctType.parameterType(0).getComponentType() == > correctType.returnType()); > + } -Sundar > > > On 5/18/2016 1:22 PM, Michael Haupt wrote: > > Dear all, > > > > please review this change. > > RFE: https://bugs.openjdk.java.net/browse/JDK-8156915 > > Webrev: http://cr.openjdk.java.net/~mhaupt/8156915/webrev.00/ > > > > Thanks, > > > > Michael > > From michael.haupt at oracle.com Wed May 18 10:11:28 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 18 May 2016 12:11:28 +0200 Subject: RFR(M): 8156915: introduce MethodHandle factory for array length In-Reply-To: <5e0419a0-8000-9cea-128a-b42d12ca65a2@oracle.com> References: <52930F20-0F98-40C8-9B61-554F73CE960B@oracle.com> <5e0419a0-8000-9cea-128a-b42d12ca65a2@oracle.com> Message-ID: <3B95F01F-77C1-42B5-BE34-5D8105943DEE@oracle.com> Hi Vladimir, pushed already. I'll piggyback this on a future change. Best, Michael > Am 18.05.2016 um 11:47 schrieb Vladimir Ivanov : > > src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java > + throw new AssertionError(); > > + throw new IllegalStateException("should not reach here"); > > Please, use InternalError to signal about error conditions (there's MHS.newInternalError(String)) and put a message containing description of problematic parameters to simplify problem diagnostics. > > Otherwise, looks good! > > Best regards, > Vladimir Ivanov > > On 5/18/16 10:52 AM, Michael Haupt wrote: >> Dear all, >> >> please review this change. >> RFE: https://bugs.openjdk.java.net/browse/JDK-8156915 >> Webrev: http://cr.openjdk.java.net/~mhaupt/8156915/webrev.00/ >> >> Thanks, >> >> Michael >> -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From uschindler at apache.org Wed May 18 10:39:37 2016 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 18 May 2016 12:39:37 +0200 Subject: RFR(M): 8156915: introduce MethodHandle factory for array length In-Reply-To: <52930F20-0F98-40C8-9B61-554F73CE960B@oracle.com> References: <52930F20-0F98-40C8-9B61-554F73CE960B@oracle.com> Message-ID: <01d101d1b0f1$95b26b40$c11741c0$@apache.org> Hi, looks good to me! I am also fine with the method name arrayLength() - my original proposal was arrayLengthGetter(); to be consistent with the element accessors: arrayElementGetter, arrayElementSetter. Uwe P.S.: I am not so familiar with the intrinsic stuff, so here is my question: The intrinsic for the array accesses is always created before caching the MH; so why do we need the static implementation methods at all? I had the same question also about the old element getters and setters. Or is the intrinsic only used after the MH is called multiple times as "optimization"? If the latter is the case, the test should ensure that the intrinsics are tested, too. ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf Of Michael Haupt > Sent: Wednesday, May 18, 2016 9:53 AM > To: Core-Libs-Dev > Subject: RFR(M): 8156915: introduce MethodHandle factory for array length > > Dear all, > > please review this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8156915 > Webrev: http://cr.openjdk.java.net/~mhaupt/8156915/webrev.00/ > > Thanks, > > Michael > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | LangTools Team | Nashorn > Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, > Germany > > ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D- > 80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering > 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > Oracle is committed to > developing practices and products that help protect the environment From stanislav.lukyanov at oracle.com Wed May 18 10:52:30 2016 From: stanislav.lukyanov at oracle.com (stanislav lukyanov) Date: Wed, 18 May 2016 13:52:30 +0300 Subject: RFR(M): 8156915: introduce MethodHandle factory for array length In-Reply-To: <52930F20-0F98-40C8-9B61-554F73CE960B@oracle.com> References: <52930F20-0F98-40C8-9B61-554F73CE960B@oracle.com> Message-ID: <5bd674ec-8a69-f7b9-78a4-ad992d951ba4@oracle.com> Hi Michael, I've noticed that neither the new method nor its friends, arrayElementGetter and arrayElementSetter, discuss the invocation-time behavior. It seems important since there are exceptions to be documented. I think the best way would be to make a connection between the methods and corresponding instructions, so as not to explain every NPE and, especially, ArrayStoreException in Javadoc. Probably no need to go deep in details on how, for example, arrayElementGetter(T) maps on 8 Taload instructions, but just give a basic notion of that. WDYT? Should I file a separate RFE for that? (for arrayElementGetter/Setter? for all three?) Thanks, Stanislav On 18.05.2016 10:52, Michael Haupt wrote: > Dear all, > > please review this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8156915 > Webrev: http://cr.openjdk.java.net/~mhaupt/8156915/webrev.00/ > > Thanks, > > Michael > From paul.sandoz at oracle.com Wed May 18 11:24:11 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 18 May 2016 13:24:11 +0200 Subject: RFR 8157152: Atomic add for VarHandle byte[]/ByteBuffer views is incorrect for endian conversion Message-ID: Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8157152-vh-array-views-atomic-add-endianness/webrev/ The implementation for the atomic add methods for array and byte buffer views were incorrect when the native endianness differs from the requested endianness (an embarrassing oversight). The tests did not catch this due to values used for addition, since there was no carrying over of bits from a byte to it's subsequent higher-order byte. If there is a mismatch in endianness then a weak+volatile CAS loop is used. Credit goes to Frank (Yaun) for finding this and verifying. Paul. From vladimir.x.ivanov at oracle.com Wed May 18 11:32:30 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 18 May 2016 14:32:30 +0300 Subject: RFR(M): 8156915: introduce MethodHandle factory for array length In-Reply-To: <01d101d1b0f1$95b26b40$c11741c0$@apache.org> References: <52930F20-0F98-40C8-9B61-554F73CE960B@oracle.com> <01d101d1b0f1$95b26b40$c11741c0$@apache.org> Message-ID: <70c3d5db-ceb1-2421-c67d-b8b4b59eac0d@oracle.com> Uwe, > P.S.: I am not so familiar with the intrinsic stuff, so here is my question: The intrinsic for the array accesses is always created before caching the MH; so why do we need the static implementation methods at all? I had the same question also about the old element getters and setters. Or is the intrinsic only used after the MH is called multiple times as "optimization"? If the latter is the case, the test should ensure that the intrinsics are tested, too. Intrinsics (in j.l.i sense) are just markers for bytecode generator (j.l.i.InvokerBytecodeGenerator or IBG) which signals there's a more efficient way to represent the behavior on bytecode level. There are 2 execution modes supported for LambdaForms: - interpreter (LFI) - compiled (to bytecode by IGB) Static implementation methods are needed for LFI. Since 8u40, all LFs are always precompiled to bytecode before usage ( invocation threshold == 0) thus bypassing interpretation phase. The test case could be extended to test LFI scenario, but I don't think it's worth it. It's more productive to include additional test configuration with -Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD=30 when testing j.l.i changes to ensure LFI isn't broken. Best regards, Vladimir Ivanov >> -----Original Message----- >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On >> Behalf Of Michael Haupt >> Sent: Wednesday, May 18, 2016 9:53 AM >> To: Core-Libs-Dev >> Subject: RFR(M): 8156915: introduce MethodHandle factory for array length >> >> Dear all, >> >> please review this change. >> RFE: https://bugs.openjdk.java.net/browse/JDK-8156915 >> Webrev: http://cr.openjdk.java.net/~mhaupt/8156915/webrev.00/ >> >> Thanks, >> >> Michael >> >> -- >> >> >> Dr. Michael Haupt | Principal Member of Technical Staff >> Phone: +49 331 200 7277 | Fax: +49 331 200 7561 >> Oracle Java Platform Group | LangTools Team | Nashorn >> Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, >> Germany >> >> ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D- >> 80992 M?nchen >> Registergericht: Amtsgericht M?nchen, HRA 95603 >> >> Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering >> 163/167, 3543 AS Utrecht, Niederlande >> Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 >> Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher >> Oracle is committed to >> developing practices and products that help protect the environment > From michael.haupt at oracle.com Wed May 18 11:36:11 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 18 May 2016 13:36:11 +0200 Subject: RFR(M): 8156915: introduce MethodHandle factory for array length In-Reply-To: <5bd674ec-8a69-f7b9-78a4-ad992d951ba4@oracle.com> References: <52930F20-0F98-40C8-9B61-554F73CE960B@oracle.com> <5bd674ec-8a69-f7b9-78a4-ad992d951ba4@oracle.com> Message-ID: Hi Stanislav, yes please, file and assign to me. Best, Michael > Am 18.05.2016 um 12:52 schrieb stanislav lukyanov : > > Hi Michael, > > I've noticed that neither the new method nor its friends, arrayElementGetter and arrayElementSetter, > discuss the invocation-time behavior. > It seems important since there are exceptions to be documented. > > I think the best way would be to make a connection between the methods and corresponding instructions, > so as not to explain every NPE and, especially, ArrayStoreException in Javadoc. > Probably no need to go deep in details on how, for example, arrayElementGetter(T) maps on 8 Taload instructions, > but just give a basic notion of that. > > WDYT? Should I file a separate RFE for that? (for arrayElementGetter/Setter? for all three?) > > Thanks, > Stanislav > > On 18.05.2016 10:52, Michael Haupt wrote: >> Dear all, >> >> please review this change. >> RFE: https://bugs.openjdk.java.net/browse/JDK-8156915 >> Webrev: http://cr.openjdk.java.net/~mhaupt/8156915/webrev.00/ >> >> Thanks, >> >> Michael >> > -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From aleksey.shipilev at oracle.com Wed May 18 11:44:40 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 18 May 2016 14:44:40 +0300 Subject: RFR 8157152: Atomic add for VarHandle byte[]/ByteBuffer views is incorrect for endian conversion In-Reply-To: References: Message-ID: <573C55A8.2030104@oracle.com> On 05/18/2016 02:24 PM, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8157152-vh-array-views-atomic-add-endianness/webrev/ Looks horrible (as many other endianness fixes), but correct. Reviewed. Thanks, -Aleksey From paul.sandoz at oracle.com Wed May 18 11:56:20 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 18 May 2016 13:56:20 +0200 Subject: RFR 8157152: Atomic add for VarHandle byte[]/ByteBuffer views is incorrect for endian conversion In-Reply-To: <573C55A8.2030104@oracle.com> References: <573C55A8.2030104@oracle.com> Message-ID: <806FC6BE-3F30-4A77-B1E2-C21A7809B6E0@oracle.com> > On 18 May 2016, at 13:44, Aleksey Shipilev wrote: > > On 05/18/2016 02:24 PM, Paul Sandoz wrote: >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8157152-vh-array-views-atomic-add-endianness/webrev/ > > Looks horrible (as many other endianness fixes), but correct. Reviewed. > John would say there is a byte odor about this code: https://twitter.com/JohnRose00/status/725453000844541952 Paul. From aleksey.shipilev at oracle.com Wed May 18 12:09:38 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 18 May 2016 15:09:38 +0300 Subject: RFR (M) 8148604: JEP 280, Switch to more optimal concatenation strategy Message-ID: <573C5B82.4010208@oracle.com> Hi, We have been waiting for this for at least 8 weeks, waiting for Jigsaw to settle in, and hs-main -> jdk9/dev integration to happen that brings a few testbug fixes into the jdk9/dev. Bug: https://bugs.openjdk.java.net/browse/JDK-8148604 Webrev: http://cr.openjdk.java.net/~shade/8148604/webrev.01/ (the change is XS, but impact is M) Targeted benchmarks show significant improvements with the MH_INLINE_SIZED_EXACT strategy, see the bug for the test results. Performance improvements are due to these reasons: *) it does not rely on OptimizeStringConcat in C2, but instead does lift up the concatenation into the Java code, spelling it out with java.lang.invoke building blocks. This also helps to improve C1 performance significantly; *) it uniformly covers the cases that OptimizeStringConcat does not cover, e.g. non-int/char arguments where OptimizeStringConcat bails, etc; *) it uniformly covers the Compact Strings (JEP 254) changes, e.g. selecting the final coder for the concatenated String, and calling appropriate coder-specific routines from JDK. Doing this in Java has the apparent benefit of piggy-backing on normal Java code profiling to figure out the hot branches -- a luxury OptimizeStringConcat-constructed code lacks. Unfortunately, we cannot test this with our regular performance testing, because it requires tests compiled with -target 9. The only easy target we have now is javac, and switching the concat strategy does not regress it (see JDK-8148605). MH_INLINE_SIZED_EXACT is functionally tested routinely with java/lang/String/concat/ jtregs on all platforms. Testing: java/lang/String/ jtregs; JPRT -testset hotspot Thanks, -Aleksey From paul.sandoz at oracle.com Wed May 18 12:43:10 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 18 May 2016 14:43:10 +0200 Subject: RFR (M) 8148604: JEP 280, Switch to more optimal concatenation strategy In-Reply-To: <573C5B82.4010208@oracle.com> References: <573C5B82.4010208@oracle.com> Message-ID: <8FDBB005-F3BE-4695-97B3-B7956C057BB9@oracle.com> > On 18 May 2016, at 14:09, Aleksey Shipilev wrote: > > Hi, > > We have been waiting for this for at least 8 weeks, waiting for Jigsaw > to settle in, and hs-main -> jdk9/dev integration to happen that brings > a few testbug fixes into the jdk9/dev. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8148604 > > Webrev: > http://cr.openjdk.java.net/~shade/8148604/webrev.01/ > (the change is XS, but impact is M) > +1 I think this is reasonable as this execution mode has been soaking for a while with existing tests, and is easy to revert if there are issues. Paul. > Targeted benchmarks show significant improvements with the > MH_INLINE_SIZED_EXACT strategy, see the bug for the test results. > Performance improvements are due to these reasons: > > *) it does not rely on OptimizeStringConcat in C2, but instead does > lift up the concatenation into the Java code, spelling it out with > java.lang.invoke building blocks. This also helps to improve C1 > performance significantly; > > *) it uniformly covers the cases that OptimizeStringConcat does not > cover, e.g. non-int/char arguments where OptimizeStringConcat bails, etc; > > *) it uniformly covers the Compact Strings (JEP 254) changes, e.g. > selecting the final coder for the concatenated String, and calling > appropriate coder-specific routines from JDK. Doing this in Java has the > apparent benefit of piggy-backing on normal Java code profiling to > figure out the hot branches -- a luxury OptimizeStringConcat-constructed > code lacks. > > Unfortunately, we cannot test this with our regular performance testing, > because it requires tests compiled with -target 9. The only easy target > we have now is javac, and switching the concat strategy does not regress > it (see JDK-8148605). > > MH_INLINE_SIZED_EXACT is functionally tested routinely with > java/lang/String/concat/ jtregs on all platforms. > > Testing: java/lang/String/ jtregs; JPRT -testset hotspot > > Thanks, > -Aleksey > From uschindler at apache.org Wed May 18 12:48:21 2016 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 18 May 2016 14:48:21 +0200 Subject: RFR(M): 8156915: introduce MethodHandle factory for array length In-Reply-To: <70c3d5db-ceb1-2421-c67d-b8b4b59eac0d@oracle.com> References: <52930F20-0F98-40C8-9B61-554F73CE960B@oracle.com> <01d101d1b0f1$95b26b40$c11741c0$@apache.org> <70c3d5db-ceb1-2421-c67d-b8b4b59eac0d@oracle.com> Message-ID: <01f501d1b103$91fbc6b0$b5f35410$@apache.org> Hi, > > P.S.: I am not so familiar with the intrinsic stuff, so here is my question: The > intrinsic for the array accesses is always created before caching the MH; so > why do we need the static implementation methods at all? I had the same > question also about the old element getters and setters. Or is the intrinsic > only used after the MH is called multiple times as "optimization"? If the latter > is the case, the test should ensure that the intrinsics are tested, too. > Intrinsics (in j.l.i sense) are just markers for bytecode generator > (j.l.i.InvokerBytecodeGenerator or IBG) which signals there's a more > efficient way to represent the behavior on bytecode level. > > There are 2 execution modes supported for LambdaForms: > - interpreter (LFI) > - compiled (to bytecode by IGB) > > Static implementation methods are needed for LFI. > > Since 8u40, all LFs are always precompiled to bytecode before usage ( > invocation threshold == 0) thus bypassing interpretation phase. > > The test case could be extended to test LFI scenario, but I don't think > it's worth it. > > It's more productive to include additional test configuration with > -Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD=30 when testing > j.l.i > changes to ensure LFI isn't broken. Thanks Vladimir! This is how I understood it, but I did not see the place in code where the actual switch between those "modes" is done, as I have seen they are compiled-up-front. Theoretically at some point, the LFI code could be removed from JDK, right? Uwe From claes.redestad at oracle.com Wed May 18 12:57:06 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 18 May 2016 14:57:06 +0200 Subject: RFR (M) 8148604: JEP 280, Switch to more optimal concatenation strategy In-Reply-To: <573C5B82.4010208@oracle.com> References: <573C5B82.4010208@oracle.com> Message-ID: <573C66A2.6050508@oracle.com> +1 I think it's a good time to enable this. I do expect some impact to various startup tests based on some earlier experiments, but that will help us pinpoint areas to focus startup optimization efforts on going forward. Thanks! /Claes On 2016-05-18 14:09, Aleksey Shipilev wrote: > Hi, > > We have been waiting for this for at least 8 weeks, waiting for Jigsaw > to settle in, and hs-main -> jdk9/dev integration to happen that brings > a few testbug fixes into the jdk9/dev. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8148604 > > Webrev: > http://cr.openjdk.java.net/~shade/8148604/webrev.01/ > (the change is XS, but impact is M) > > Targeted benchmarks show significant improvements with the > MH_INLINE_SIZED_EXACT strategy, see the bug for the test results. > Performance improvements are due to these reasons: > > *) it does not rely on OptimizeStringConcat in C2, but instead does > lift up the concatenation into the Java code, spelling it out with > java.lang.invoke building blocks. This also helps to improve C1 > performance significantly; > > *) it uniformly covers the cases that OptimizeStringConcat does not > cover, e.g. non-int/char arguments where OptimizeStringConcat bails, etc; > > *) it uniformly covers the Compact Strings (JEP 254) changes, e.g. > selecting the final coder for the concatenated String, and calling > appropriate coder-specific routines from JDK. Doing this in Java has the > apparent benefit of piggy-backing on normal Java code profiling to > figure out the hot branches -- a luxury OptimizeStringConcat-constructed > code lacks. > > Unfortunately, we cannot test this with our regular performance testing, > because it requires tests compiled with -target 9. The only easy target > we have now is javac, and switching the concat strategy does not regress > it (see JDK-8148605). > > MH_INLINE_SIZED_EXACT is functionally tested routinely with > java/lang/String/concat/ jtregs on all platforms. > > Testing: java/lang/String/ jtregs; JPRT -testset hotspot > > Thanks, > -Aleksey > From vladimir.x.ivanov at oracle.com Wed May 18 13:24:03 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 18 May 2016 16:24:03 +0300 Subject: RFR(M): 8156915: introduce MethodHandle factory for array length In-Reply-To: <01f501d1b103$91fbc6b0$b5f35410$@apache.org> References: <52930F20-0F98-40C8-9B61-554F73CE960B@oracle.com> <01d101d1b0f1$95b26b40$c11741c0$@apache.org> <70c3d5db-ceb1-2421-c67d-b8b4b59eac0d@oracle.com> <01f501d1b103$91fbc6b0$b5f35410$@apache.org> Message-ID: <5fb9f3f1-c408-0ff5-28cb-0ab70022d715@oracle.com> > > Thanks Vladimir! This is how I understood it, but I did not see the place in code where the actual switch between those "modes" is done, as I have seen they are compiled-up-front. The decision is made in LambdaForm.prepare() and LF.checkInvocationCounter(). MethodHandleStatics.COMPILE_THRESHOLD controls when the switch happens. > > Theoretically at some point, the LFI code could be removed from JDK, right? Yes, it's optional now. But LFI comprises tiny fraction of j.l.i code and it's invaluable when debugging LambdaForm issues. So, I expect it to stay. Also, LambdaForm instances are still much more lightweight than classes they are compiled to. So, if we face a situation when too many LambdaForms are created, it's better so switch back to LFI than flooding the system with classes. Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Wed May 18 13:32:18 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 18 May 2016 16:32:18 +0300 Subject: RFR 8157152: Atomic add for VarHandle byte[]/ByteBuffer views is incorrect for endian conversion In-Reply-To: References: Message-ID: <180b9b9a-5058-ea73-52e6-45797d35100a@oracle.com> Looks good. Best regards, Vladimir Ivanov On 5/18/16 2:24 PM, Paul Sandoz wrote: > Hi, > > Please review: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8157152-vh-array-views-atomic-add-endianness/webrev/ > > The implementation for the atomic add methods for array and byte buffer views were incorrect when the native endianness differs from the requested endianness (an embarrassing oversight). > > The tests did not catch this due to values used for addition, since there was no carrying over of bits from a byte to it's subsequent higher-order byte. > > If there is a mismatch in endianness then a weak+volatile CAS loop is used. > > Credit goes to Frank (Yaun) for finding this and verifying. > > Paul. > From jason_mehrens at hotmail.com Wed May 18 14:00:17 2016 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Wed, 18 May 2016 14:00:17 +0000 Subject: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival In-Reply-To: <573BC980.9000100@oracle.com> References: <55479A4F.4060806@oracle.com> <5550FE5A.4070607@oracle.com> <55513EA7.1050700@oracle.com> <555192A4.3080305@gmail.com> <5551A0AA.6050800@gmail.com> <5552674E.4030009@oracle.com> <55526FF5.9000509@gmail.com> <55564473.3010704@oracle.com> <8DD50D66-D2C1-43E4-B7C5-992FE785958B@oracle.com> <57325921.9090100@oracle.com> <5734EF6C.5090603@oracle.com> , <573BC980.9000100@oracle.com> Message-ID: Brent, Have you considered increasing the visibility of just the EntrySet constructor from private to default access? This should get rid an extra generated class file if you compare the javac output since you are accessing just the constructor from the enclosing class. Jason ________________________________________ From: core-libs-dev on behalf of Brent Christian Sent: Tuesday, May 17, 2016 8:46 PM To: Mandy Chung; David Holmes Cc: core-libs-dev Subject: Re: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival Hi! Here's the final(?) webrev: http://cr.openjdk.java.net/~bchristi/8029891/webrev.6/webrev/ with the following changes since the last one: * The @hidden JavaDoc tag has been removed. It can't be used due to methods disappearing from the API page. Living with the additional JavaDoc is the best option for now. The situation should be improved by JDK-8157000 (thanks for filing, Mandy). * I also firmed up the doc update regarding iterators (using words from the java.util.concurrent package description of "weakly-consistent"). Line 170. New specdiff views: http://cr.openjdk.java.net/~bchristi/8029891/webrev.6/specdiff-javadoc/Properties.html http://cr.openjdk.java.net/~bchristi/8029891/webrev.6/specdiff-plain/Properties.html * I did make one real code change, making the new Properties.EntrySet inner class static. Line 1250. * I added a new test of unsynchronized, as suggested by Peter, and expanded coverage to all newly-unsynchronized methods. Thanks, -Brent On 5/13/16 8:01 AM, Mandy Chung wrote: > >> On May 12, 2016, at 5:58 PM, David Holmes wrote: >>> >>> With all of the inherited methods @hidden, it looks like that section >>> is left out altogether. >> >> Okay, so I have to say @hidden seems to me to be seriously flawed! If a class has a method that can be called then IMHO that has to be documented in that class as either being first defined, overridden, or inherited - it can't just say nothing as-if the method were not there! >> >> If we are overriding in a trivial way that does not change the specification at all then there should be a simple way to show that - perhaps the "Methods inherited from ..." should be split into two parts: method implementations inherited from ..., and method specifications inherited from ... ?? >> > > I agree for this case these methods should not be hidden as if it?s not there (that?s probably carried from the original @treatAsPrivate request). > >> I guess I need to raise this with the javadoc folk :( Is there a mailing list for that? > > Can you file a JBS issue? Kumar is on vacation and will talk with him when he?s back. > > Mandy > From kumar.x.srinivasan at oracle.com Wed May 18 14:20:26 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 18 May 2016 07:20:26 -0700 Subject: RFR: 8156807: Pack200 must support v53.0 class files Message-ID: <573C7A2A.2030509@oracle.com> Hi, Alex or someone please review this simple fix, the first part is simply bumping the class file version number, and some cleanup of redundant constants in the native unpacker. The second part is fixing up the test, which does not read the process streams correctly and causes a test hang, simplified the test with time tested utilities. http://cr.openjdk.java.net/~ksrini/8156807/webrev.00/ Thanks Kumar PS: Appreciate a quick turnaround as this is causing intermittent test failures in our internal CI systems. From jaroslav at kamenik.cz Wed May 18 14:50:12 2016 From: jaroslav at kamenik.cz (=?UTF-8?Q?Jaroslav_Kamen=C3=ADk?=) Date: Wed, 18 May 2016 16:50:12 +0200 Subject: Helpers for MethodHandles.byteArrayViewVarHandle VarHandle In-Reply-To: References: Message-ID: Hi, thank you for response! > I would prefer not to spread such functionality beyond that of ByteBuffer > and the VarHandle producing methods on MethodHandles. It?s an advanced > feature so think ok if less visible. > > On the other side, this would be easier to use and understand than ByteBuffer in simple cases, I think. I have looked into JVM sources briefly, and this functionality is implemented often there, both inlined and methods as intAt/readLong/... So it could be helpful even as private api. > Separately, i may revisit the signatures for access to also include an > alignment-offset argument (which is expected to be constant when looping) > in addition to the index (e.g. byte-index = ao + (i << LOG_2_UNIT_SIZE)). > Thus bringing alignment into the foreground where it is harder to forget > about or ignore. > It is nice idea. So it could look like: getLongFrom[LE/BE](byte[] data, int firstByteIndex) - for direct access getLongFrom[LE/BE](byte[] data, int firstByteOffset, int longArrayIndex) - for loops/shifted array access etc. I'd like to ask about performance - how does wrapping of VH to another call affect optimization to simple memory load? Jaroslav From martinrb at google.com Wed May 18 14:52:14 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 18 May 2016 07:52:14 -0700 Subject: Can an object be finalized while still weakly reachable? In-Reply-To: <7737177b-8791-3d87-dcbc-ae6f5167efa7@oracle.com> References: <298d69ca-a7bc-2798-7f88-2bdff21b78a7@gmail.com> <7737177b-8791-3d87-dcbc-ae6f5167efa7@oracle.com> Message-ID: Sherman, Thank you very much for pointing me at that old thread. I was indeed going down the same path and stumbling over the same obstacles! I still think we can do better, but it's definitely not easy. On Tue, May 17, 2016 at 8:15 AM, Xueming Shen wrote: > On 5/17/16 12:55 AM, Martin Buchholz wrote: >> >> Thanks, Peter. >> >> My current theory is indeed that I made a mistake, and have >> encountered my first real finalization resurrection bug. >> ZipFile + Inflater have 4 finalize methods and a WeakHashMap in play! > > there was a long discussion when we touched that part of the code last time. > just > for your reference:-) > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-April/thread.html#6545 > > -sherman > >> My static reference was finalized because it used to be unreachable, >> not because it is now weakly reachable! >> >> On Mon, May 16, 2016 at 11:49 PM, Peter Levart >> wrote: >>> >>> Hi Martin, >>> >>> >>> >>> On 05/17/2016 05:19 AM, Martin Buchholz wrote: >>>> >>>> I have some evidence that an object's finalize method can run while a >>>> weak reference pointing to it is not yet cleared, which surprised me. >>>> >>>> E.g. >>>> class F { protected void finalize() { assert wref.get() != this; } } >>>> static WeakReference wref = new WeakReference(new F()); >>>> >>>> If this is a bug, I can try to give y'all a repro recipe. >>>> If not, we should fix the docs >>>> """When the weak references to a weakly-reachable object are cleared, >>>> the object becomes eligible for finalization.""" >>>> >>>> (It's also quite possible I made a mistake diagnosing this) >>> >>> >>> What can happen with above code is that you get a NPE from dereferencing >>> wref in finlailze(). In case NPE is not thrown and the program constructs >>> only a single instance of F then assert should succeed. >>> >>> It is possible that you made a mistake. Can you post the real code? >>> >>> Regards, Peter >>> > From mandy.chung at oracle.com Wed May 18 15:35:03 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 18 May 2016 08:35:03 -0700 Subject: RFR: 8156807: Pack200 must support v53.0 class files In-Reply-To: <573C7A2A.2030509@oracle.com> References: <573C7A2A.2030509@oracle.com> Message-ID: <81C7176D-219C-4628-8AFE-6273FC5E9678@oracle.com> > On May 18, 2016, at 7:20 AM, Kumar Srinivasan wrote: > > Hi, > > Alex or someone please review this simple fix, the first part is > simply bumping the class file version number, and some cleanup > of redundant constants in the native unpacker. > > The second part is fixing up the test, which does not read the > process streams correctly and causes a test hang, simplified > the test with time tested utilities. > > http://cr.openjdk.java.net/~ksrini/8156807/webrev.00/ Looks okay to me. Mandy From paul.sandoz at oracle.com Wed May 18 15:40:38 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 18 May 2016 17:40:38 +0200 Subject: Helpers for MethodHandles.byteArrayViewVarHandle VarHandle In-Reply-To: References: Message-ID: > On 18 May 2016, at 16:50, Jaroslav Kamen?k wrote: > > Hi, > > thank you for response! > > I would prefer not to spread such functionality beyond that of ByteBuffer and the VarHandle producing methods on MethodHandles. It?s an advanced feature so think ok if less visible. > > > On the other side, this would be easier to use and understand than ByteBuffer in simple cases, I think. > > I have looked into JVM sources briefly, and this functionality is implemented often there, both inlined and methods as intAt/readLong/... > So it could be helpful even as private api. There certainly is in nio buffer sources (and may be for encoding/decoding in other areas, i am speculating as i have not looked), but for buffer sources we can actually remove much if not all of Bits.java via use of the internal Unsafe unaligned accessors. > > > Separately, i may revisit the signatures for access to also include an alignment-offset argument (which is expected to be constant when looping) in addition to the index (e.g. byte-index = ao + (i << LOG_2_UNIT_SIZE)). Thus bringing alignment into the foreground where it is harder to forget about or ignore. > > It is nice idea. So it could look like: > > getLongFrom[LE/BE](byte[] data, int firstByteIndex) - for direct access > getLongFrom[LE/BE](byte[] data, int firstByteOffset, int longArrayIndex) - for loops/shifted array access > > etc. I was proposing just the latter, and just for VarHandles :-) it?s not just for loops but also to bring alignment issues to the foreground. (It also it fits in with something we have been pondering about for the unsafe unaligned accessors on systems that don?t support unaligned access, such as SPARC). > > I'd like to ask about performance - how does wrapping of VH to another call affect optimization to simple memory load? > Same as that of a MethodHandle getter/setter to a field. The compiler should strip away the all the ?ceremony? and inline the access as if Unsafe was used directly (but with safety checks in place most of which are optimized away, although hard to fully elide array bounds checks in certain cases, but we try our best!) Paul. From aleksey.shipilev at oracle.com Wed May 18 16:10:52 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 18 May 2016 19:10:52 +0300 Subject: RFR: 8156807: Pack200 must support v53.0 class files In-Reply-To: <573C7A2A.2030509@oracle.com> References: <573C7A2A.2030509@oracle.com> Message-ID: <573C940C.2060402@oracle.com> On 05/18/2016 05:20 PM, Kumar Srinivasan wrote: > The second part is fixing up the test, which does not read the > process streams correctly and causes a test hang, simplified > the test with time tested utilities. > > http://cr.openjdk.java.net/~ksrini/8156807/webrev.00/ A very minor snag in Constants.java: 41 /* 42 Java Class Version numbers history 43 1.0 to 1.3.X 45,3 44 1.4 to 1.4.X 46,0 45 1.5 to 1.5.X 49,0 46 1.6 to 1.6.X 50,0 47 1.7 to 1.7.X 51,0 48 1.8 to 1.8.X 52,0 49 1.9 to 1.9.X 53.0 50 */ Should be "53,0"? Notice the comma. Fix as you deem appropriate, no need for re-review. Otherwise looks good. Thanks, -Aleksey From mandy.chung at oracle.com Wed May 18 16:11:54 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 18 May 2016 09:11:54 -0700 Subject: RFR 8154192: Deprivilege java.scripting module In-Reply-To: References: <3e1bed67-ae64-00c2-2e99-21af225e2b30@oracle.com> <573B0D7F.9080907@oracle.com> Message-ID: > On May 18, 2016, at 12:55 AM, Sundararajan Athijegannathan wrote: > > Please review the updated webrevs. > > * Fixed Modules.gmk for order of modules: > > http://cr.openjdk.java.net/~sundar/8154192/top/webrev.01/ > > * From quick reading of j.u.ServiceLoader: AccessControlContext is > captured in ServiceLoader constructor & used for iteration > (RestrictedIterator). So, ScriptEngineManager calling only ServiceLoader > constructor inside doPrivileged block seems fine. Also, I turned > ProviderTest javax.script API test to use security manager - this tests > loads a dummy script engine from a jar file in classpath. This test > passes with security manager on. > > http://cr.openjdk.java.net/~sundar/8154192/jdk/webrev.01/ > > Yes, we can still revisit AllPermission for java.scripting module in a > future change. +1 I saw you updated the test to run with and without SM which is good. Mandy From kumar.x.srinivasan at oracle.com Wed May 18 16:36:21 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 18 May 2016 09:36:21 -0700 Subject: RFR: 8156807: Pack200 must support v53.0 class files In-Reply-To: <573C940C.2060402@oracle.com> References: <573C7A2A.2030509@oracle.com> <573C940C.2060402@oracle.com> Message-ID: <573C9A05.3010001@oracle.com> Will fix that, thanks for the reviews!. I was told by Amy, meanwhile this test has been added to ProblemList.txt so I will have to remove that line as well. Thanks Kumar > On 05/18/2016 05:20 PM, Kumar Srinivasan wrote: >> The second part is fixing up the test, which does not read the >> process streams correctly and causes a test hang, simplified >> the test with time tested utilities. >> >> http://cr.openjdk.java.net/~ksrini/8156807/webrev.00/ > A very minor snag in Constants.java: > > 41 /* > 42 Java Class Version numbers history > 43 1.0 to 1.3.X 45,3 > 44 1.4 to 1.4.X 46,0 > 45 1.5 to 1.5.X 49,0 > 46 1.6 to 1.6.X 50,0 > 47 1.7 to 1.7.X 51,0 > 48 1.8 to 1.8.X 52,0 > 49 1.9 to 1.9.X 53.0 > 50 */ > > Should be "53,0"? Notice the comma. Fix as you deem appropriate, no need > for re-review. > > Otherwise looks good. > > Thanks, > -Aleksey > From mandy.chung at oracle.com Wed May 18 17:40:27 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 18 May 2016 10:40:27 -0700 Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version In-Reply-To: References: Message-ID: <29AA7813-44E0-4BB1-937E-1BCAB46F9367@oracle.com> > On May 13, 2016, at 4:20 PM, Iris Clark wrote: > > Hi. > > Reviving this work from a few months back. > > Please review the following changes to move jdk.Version to > jdk.lang.Runtime.Version. > > Bug > > 8144062: Move jdk.Version to java.lang.Runtime.Version > https://bugs.openjdk.java.net/browse/JDK-8144062 > > webrev > > http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/ The change looks fine. Minor comments: 1178 * @throws IllegalArgumentException 1179 * If the given string cannot be interpreted as a valid 1180 * version 1185 * @throws NumberFormatException 1186 * If an element of the version number or the build number 1187 * cannot be represented as an {@link Integer} It?s okay to specify @throws NumberFormatException while @throws IAE (merging the description) should be adequate (the implementation stays the same). Something you can consider in the future. 1189 * @return This version It seems clearer to say "@return the Version of the given string? (this is a static method and no ?This version?) Mandy From brent.christian at oracle.com Wed May 18 18:24:23 2016 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 18 May 2016 11:24:23 -0700 Subject: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed In-Reply-To: References: <5D245EC6-47C6-4BF1-A505-89934731A814@oracle.com> <360DDB44-FDFC-41DE-8DF9-9BBA3AF28581@oracle.com> <07C5EC23-C429-4961-B7D3-92B7C32FB535@dslextreme.com> <90BF6135-B457-4BD4-8DFF-9DE94F6D8DC7@oracle.com> Message-ID: <573CB357.6050704@oracle.com> Hi, I compared 8u65 and 9b116 performance on a simple Throwable.getStackTrace() JMH benchmark that I have, using a variety of call stack depths. Performance looks very similar between the two; if anything, 9b116 has a slight edge for larger stack depths. So I don't think the difference is due to the walking of the stack itself, at least based on what I measured. HTH, -Brent On 5/10/16 9:49 AM, Ralph Goers wrote: > I just ran one of the Log4j performance tests that specifically captures location information. To run the test I do > > java -jar log4j-perf/target/benchmarks.jar ".*AsyncAppenderLog4j2LocationBenchmark.*" -f 1 -wi 10 -i 20 -t 4 -si true > > And the results are: > > java version "1.7.0_80 > > Benchmark Mode Samples Score Error Units > o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 124819.285 ? 3003.918 ops/s > > java version "1.8.0_65" > > Benchmark Mode Samples Score Error Units > o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 123209.746 ? 3064.672 ops/s > > > java version "9-ea" > Java(TM) SE Runtime Environment (build 9-ea+116) > > Benchmark Mode Samples Score Error Units > o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple thrpt 20 96090.261 ? 4565.763 ops/s > > > This tells me that Java 9 is about 23% slower than previous versions in walking the stack trace elements. > > Ralph From jonathan.gibbons at oracle.com Wed May 18 18:25:22 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 18 May 2016 11:25:22 -0700 Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version In-Reply-To: References: Message-ID: <573CB392.9050301@oracle.com> Langtools changes are OK, including the indirect use of the revised Version in jar-fs. -- Jon On 05/13/2016 04:20 PM, Iris Clark wrote: > Hi. > > Reviving this work from a few months back. > > Please review the following changes to move jdk.Version to > jdk.lang.Runtime.Version. > > Bug > > 8144062: Move jdk.Version to java.lang.Runtime.Version > https://bugs.openjdk.java.net/browse/JDK-8144062 > > webrev > > http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/ > > When jdk.Version was initially pushed in jdk-9+1-5, it was > Improperly exported by java.base. After exploring a few > options, the best choice was to move jdk.Version to > java.lang.Runtime.Version (a nested class of Runtime). By > making Version an SE API, it may be exported by the java.base > module. > > As part of the move, a limited number of chnages were > made to the Version class: > > - Change package name and class declaration (to static) > - Eliminate use of "JDK" when describing a Java SE API > - Initial clarifications related to zeros (trailing vs. > Internal components) > - Small typographical and grammatical enhancements > - Indentation > > The complete Runtime.Version specification is available here: > > http://cr.openjdk.java.net/~iris/verona/8144062/doc.1/java/lang/Runtime.Version.html > > The old jdk.Version.current() was replaced with > Runtime.version(). > > In System.getProperties(), we indicate which version-related > system properties may be supported by Runtime.Version. > > The remaining jdk and langtools file changes are all > side-effects of changing jdk.Version.current() to > Runtime.version(). > > Thanks, > Iris From brian.burkhalter at oracle.com Wed May 18 19:06:36 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 18 May 2016 12:06:36 -0700 Subject: [PING] Re: [9] RFR of 8023217: Additional floorDiv/floorMod/multiplyExact methods for java.lang.Math In-Reply-To: References: <604C9A0D-D55D-4962-A007-D188E9077063@oracle.com> <5609F4CA.2010605@oracle.com> <836DC71E-B3E6-45DE-BDA4-39617AC4CAC4@oracle.com> <108C6774-3965-4340-A448-033B3651E263@oracle.com> Message-ID: <58C4BA23-BF2F-4264-8FF3-057AE0A291B9@oracle.com> Following up on the as yet unresolved thread initiated here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035468.html Thanks, Brian On Sep 29, 2015, at 5:49 PM, Brian Burkhalter wrote: > I revised floorMod(long x, int y) not to check explicitly check for integer overflow as it does not look as if this is even possible. I also updated the appropriate tests for these versions of the three methods at issue. > > In testing I still found discrepancies between the existing implementations and the ones suggested earlier in this thread. Therefore those implementations have not been used. If it is desired to move to different implementations at a later date a separate enhancement issue may be filed. > > The updated webrev is here: > > http://cr.openjdk.java.net/~bpb/8023217/webrev.01/ > > Thanks, > > Brian > > On Sep 29, 2015, at 8:16 AM, Brian Burkhalter wrote: > >> On Sep 29, 2015, at 8:05 AM, Stephen Colebourne wrote: >> >>>> I tested the code which was in the original issue description and found some >>>> discrepancies. I?ll need to revisit this to see what happened. >>> >>> Yes, the code in the issue for floorDiv() fails when the divisor is >>> negative. The one in my email today works though. >> >> Excellent! I?ll double check it as part of the ?fit and finish." > From brian.burkhalter at oracle.com Wed May 18 19:09:15 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 18 May 2016 12:09:15 -0700 Subject: [PING] Re: [9] RFR of 5100935: No way to access the 64-bit integer multiplication of 64-bit CPUs efficiently In-Reply-To: References: <3B559334-8ED3-4BEA-85E9-7AA9CD57AA91@oracle.com> <55FDBCC1.8060708@oracle.com> Message-ID: Following up on the as yet unresolved thread initiated here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035289.html Thanks, Brian On Sep 21, 2015, at 11:15 AM, Brian Burkhalter wrote: > Hello, Sergey, > > On Sep 19, 2015, at 12:51 PM, Sergey Bylokhov wrote: > >> Hello, I have a related question about the adding of methods to the Math class. Some methods **Exact methods were added to the Math class in jdk8, which throws an exceptions in case of overflow. Is it possible to add the similar saturation arithmetic? It would be quite good to realize a full range of these methods, and give the chance to hotspot to use an intrinsic. > > If there are particular methods of interest and there are no corresponding issues on file, then one or more issues should be filed in the Java Bug System so that we may consider and track them according to the usual process. As there is currently an attempt to address some of the omissions in the Math area, now would be a good time to get these issues on record. So I suggest that the interested parties do just that. I think that one issue containing several method requests would be sufficient if it concerns the same area of code. > > As to the compiler intrinsics, we are looking into adding a few math-related things here as well. This would be tracked by a separate issue which we would file ourselves. > > Regards, > > Brian > >> This is mostly request from the java2d team: >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-December/000954.html >> "I currently use an utility-class heavily for the XRender Java2D >> backend, which performs saturated casts: >> >> 1.) return (short) (x > Short.MAX_VALUE ? Short.MAX_VALUE : (x < >> Short.MIN_VALUE ? Short.MIN_VALUE : x)); >> 2.) return (short) (x > 65535 ? 65535 : (x < 0) ? 0 : x); >> >> I spent quite some time benchmarking/tuning the >> protocol-generation-methods, and a lot of cycles are spent in those >> saturated casts, even if the utility methods are static. >> E.g. XRenderFillRectangle takes 40 cycles without clamping, but >> already 70 cycles with on my core2duo with hotspot-server/jdk 14.0. >> Hotspot seems to solve the problem always with conditional jumps, >> although well predictable ones. >> >> Modern processors seem to have support for this kind of operation, in >> x86 there's packssdw in MMX/SSE2. >> I think something like a saturated cast could be quite useful, there >> are already cast-methods in Long/Integer/Short - what do you think >> about adding saturated casts to that API? >> Those could be instrified to use MMX/SSE2 if available. >> >> If that would be too specific how hard would it be to add this kind of >> optimization to hotspot? >> How far does SIMD support in hotspot go (I read some time ago there've >> been some optimizations), if SIMD would be supported 4 casts could be >> done in a single cycle :) > From iris.clark at oracle.com Wed May 18 21:04:34 2016 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 18 May 2016 14:04:34 -0700 (PDT) Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version In-Reply-To: <573CB392.9050301@oracle.com> References: <573CB392.9050301@oracle.com> Message-ID: <0133a4b9-17cc-4ba9-96ce-ec4b523067af@default> Hi, Jon. >> http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/ > Langtools changes are OK, including the indirect use of the revised > Version in jar-fs. Thanks for the Review. Regards, Iris From stuart.marks at oracle.com Wed May 18 21:21:10 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 18 May 2016 14:21:10 -0700 Subject: RFR(s): 8133977 add specification for serial form of immutable collections In-Reply-To: References: <704c44ef-e3e7-d483-5dcd-b7e19bbbf6fc@oracle.com> <90EB34AC-5AFC-4972-9EAB-04072F54F640@oracle.com> <3642425c-378e-1904-7046-76967b014c75@oracle.com> <1c7ceba4-470a-0315-df38-ff07b127c2ff@gmail.com> <7bb8bc40-ffe2-491f-8378-46f8cf835043@oracle.com> Message-ID: <5cda45f0-d36a-123d-dfaf-36a3d9bed5fc@oracle.com> On 5/18/16 2:42 AM, Stephen Colebourne wrote: > My original blog on the topic was in 2010: > http://blog.joda.org/2010/02/serialization-shared-delegates_9131.html > > Bear in mind that a key reason for sharing the serialization proxy is > to share the "serialized object header, serial version UID, class > descriptor" etc. It is that header overhead that is the main reason > for serialization being so space inefficient on the wire. It is thus a > positive thing that "unrelated classes" share the proxy. > > JSR-310 goes to great lengths to save bytes in the stream - see > LocalTime for example. IMO, it would be really good to see > serialization move to a single package-level shared proxy in java.util > as well, as it would dramatically reduce many stream sizes (as per the > blog post). > So, the key aspects of the pattern that I see are: > - shared between multiple classes > - use a flag (byte) to distinguish classes > - top level class with a short name > - externalizable, not serializable The primary goal of the serialization proxy in this case is to prevent the concrete collections implementation classes from leaking into the serial format. Another major goal is to provide for backward *and* forward compatibility. Minimizing the serial stream size is nice, but is less important than compatibility. I'd like to set aside this notion of a "single package-level shared proxy" for java.util. There are too many other unrelated things already in java.util that have their own serial formats that cannot be changed. It's too much of a blanket statement to say that "all new serializable things in java.util" should use a single proxy, since we have zero examples of this, and they potentially could have arbitrarily different requirements for their serial formats. Future-proofing the serial proxy for future *collections* implementations in java.util is quite sensible, though. > JSR-310 chooses to delegate the actual logic back to the class itself, > but this is not required by the pattern. What CollSer does not do is > implement Externalizable. And as I've argued, I believe it is a *good* > thing to share a Ser class across a package (to overcome the > limitations of the ancient Serialization spec). OK, it's good to know you don't consider the back-delegation to be required. It's a fairly prominent feature of the java.time classes. I was concerned that was what was being proposed here, and it would be a fairly intrusive change. > Anyway, I've done half the work for you ;-) > https://gist.github.com/jodastephen/2bb70e1f1180b030d46b5a6366c0a0c4 > > With a collection of 1 string, CollSer uses 136 bytes while my > Externalizable Ser uses 58. > With a collection of 3 strings, CollSer uses 171 bytes while my > Externalizable Ser uses 87. > > These are the contents of the stream. As can be seen, the > Externalizable form avoids two java.lang.Object references. > > CollSer: > 136 [ac][ed][0][5]sr[0]!com.opengamma.strata.calc.CollSerW[8e][ab][b6]:[1b][a8][11][2][0][2]I[0][5]flags[[0][5]arrayt[0][13][Ljava/lang/Object;xp[0][0][0][1]ur[0][13][Ljava.lang.Object;[90][ce]X[9f][10]s)l[2][0][0]xp[0][0][0][0] > 171 [ac][ed][0][5]sr[0]!com.opengamma.strata.calc.CollSerW[8e][ab][b6]:[1b][a8][11][2][0][2]I[0][5]flags[[0][5]arrayt[0][13][Ljava/lang/Object;xp[0][0][0][1]ur[0][13][Ljava.lang.Object;[90][ce]X[9f][10]s)l[2][0][0]xp[0][0][0][0]sq[0]~[0][0][0][0][0][1]uq[0]~[0][3][0][0][0][3]t[0][1]at[0][2]bbt[0][3]ccc > > Ser: > 58 [ac][ed][0][5]sr[0][1d]com.opengamma.strata.calc.SerW[8e][ab][b6]:[1b][a8][11][c][0][0]xpw[5][1][0][0][0][0]x > 87 [ac][ed][0][5]sr[0][1d]com.opengamma.strata.calc.SerW[8e][ab][b6]:[1b][a8][11][c][0][0]xpw[5][1][0][0][0][0]xsq[0]~[0][0]w[5][1][0][0][0][3]t[0][1]at[0][2]bbt[0][3]cccx Interesting, nice testbed, thanks. It turns out the main culprit here is the field "Object[] array" which is responsible for most of the bulk. (For others' edification, the serial stream contains descriptions of fields including the type names, which is "[Ljava/lang/Object;". And when the array is serialized, its class descriptor, including its name -- again -- is included.) This suggests an easy way to reduce the bulk of the serial data, which is to make the Object[] field transient and to use custom serial data to write the array's length followed by its contents. (This is similar to what the other collections' serial forms do.) After renaming the modified class "Se3" to match the length of the name "Ser", and renaming the "flags" field to "tag" to save a couple more bytes, running the serialization tester gets the following: 63 [ac][ed][0][5]sr[0][1d]com.opengamma.strata.calc.Se3W[8e][ab][b6]:[1b][a8][11][3][0][1]I[0][3]tagxpw[4][0][0][0][0]x 91 [ac][ed][0][5]sr[0][1d]com.opengamma.strata.calc.Se3W[8e][ab][b6]:[1b][a8][11][3][0][1]I[0][3]tagxpw[4][0][0][0][0]xsq[0]~[0][0]w[4][0][0][0][3]t[0][1]at[0][2]bbt[0][3]cccx This is only a handful of bytes larger than the Externalizable alternative. > While I understand the forward/backward compatibility argument of (int > & 0xff) however I'm unconvinced of the need. If things change, I don't > expect the new format to be loadable in an earlier JDK version. Backward and forward serial compatibility has historically been an issue for serializable classes in the JDK. I'm not willing to shave off a few more bytes in order to compromise this. s'marks From iris.clark at oracle.com Wed May 18 21:52:49 2016 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 18 May 2016 14:52:49 -0700 (PDT) Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version In-Reply-To: <29AA7813-44E0-4BB1-937E-1BCAB46F9367@oracle.com> References: <29AA7813-44E0-4BB1-937E-1BCAB46F9367@oracle.com> Message-ID: <0452bb32-8bd4-4236-83e9-912f9055ddbc@default> Hi, Mandy. Thanks for taking the time to Review. >> http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/ > The change looks fine. Minor comments: > > 1178 * @throws IllegalArgumentException > 1179 * If the given string cannot be interpreted as a valid > 1180 * version > 1185 * @throws NumberFormatException > 1186 * If an element of the version number or the build number > 1187 * cannot be represented as an {@link Integer} > > It?s okay to specify @throws NumberFormatException while @throws IAE (merging > the description) should be adequate (the implementation stays the same). > Something you can consider in the future. Sounds good as a future update. > 1189 * @return This version > It seems clearer to say "@return the Version of the given string? (this is a > static method and no ?This version?) Nice catch. Updated: 1189c1189 < * @return This version --- > * @return The Version of the given string Thank you so much for volunteering to Sponsor this change for me. I'll send you the changesets as soon as I've finished testing my sync with jdk9/dev. Regards, Iris From stuart.marks at oracle.com Thu May 19 00:28:35 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 18 May 2016 17:28:35 -0700 Subject: RFR(s): 8133977u1 add specification for serial form of immutable collections Message-ID: Hi all, Please review this updated webrev/specdiff. Changes since previous: - removal of mention of CollSer from the API specification - make CollSer's Object[] field transient, and handle its contents as custom serial data in readObject/writeObject - specification changes to reflect the above Webrev: http://cr.openjdk.java.net/~smarks/reviews/8133977/webrev.1/ API specdiff: http://cr.openjdk.java.net/~smarks/reviews/8133977/specdiff.1/api.specdiff/overview-summary.html serialized-form.html diff: http://cr.openjdk.java.net/~smarks/reviews/8133977/specdiff.1/serial.specdiff/specdiff-summary.html Thanks, s'marks From joe.darcy at oracle.com Thu May 19 00:37:48 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 18 May 2016 17:37:48 -0700 Subject: [PING] Re: [9] RFR of 5100935: No way to access the 64-bit integer multiplication of 64-bit CPUs efficiently In-Reply-To: References: <3B559334-8ED3-4BEA-85E9-7AA9CD57AA91@oracle.com> <55FDBCC1.8060708@oracle.com> Message-ID: <48070a6e-40af-4748-4fc1-2c76c75d7371@oracle.com> Hi Brian, Sorry for the belated review. For multiplyFull, currently the wording is 833 * Returns the product of the arguments allowing overflowed values within 834 * the range of {@code long}. I think it would work about as something like "Returns the exact mathematical product of the arguments." Otherwise, looks okay. Thanks, -Joe On 5/18/2016 12:09 PM, Brian Burkhalter wrote: > Following up on the as yet unresolved thread initiated here: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035289.html > > Thanks, > > Brian > > On Sep 21, 2015, at 11:15 AM, Brian Burkhalter wrote: > >> Hello, Sergey, >> >> On Sep 19, 2015, at 12:51 PM, Sergey Bylokhov wrote: >> >>> Hello, I have a related question about the adding of methods to the Math class. Some methods **Exact methods were added to the Math class in jdk8, which throws an exceptions in case of overflow. Is it possible to add the similar saturation arithmetic? It would be quite good to realize a full range of these methods, and give the chance to hotspot to use an intrinsic. >> If there are particular methods of interest and there are no corresponding issues on file, then one or more issues should be filed in the Java Bug System so that we may consider and track them according to the usual process. As there is currently an attempt to address some of the omissions in the Math area, now would be a good time to get these issues on record. So I suggest that the interested parties do just that. I think that one issue containing several method requests would be sufficient if it concerns the same area of code. >> >> As to the compiler intrinsics, we are looking into adding a few math-related things here as well. This would be tracked by a separate issue which we would file ourselves. >> >> Regards, >> >> Brian >> >>> This is mostly request from the java2d team: >>> >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-December/000954.html >>> "I currently use an utility-class heavily for the XRender Java2D >>> backend, which performs saturated casts: >>> >>> 1.) return (short) (x > Short.MAX_VALUE ? Short.MAX_VALUE : (x < >>> Short.MIN_VALUE ? Short.MIN_VALUE : x)); >>> 2.) return (short) (x > 65535 ? 65535 : (x < 0) ? 0 : x); >>> >>> I spent quite some time benchmarking/tuning the >>> protocol-generation-methods, and a lot of cycles are spent in those >>> saturated casts, even if the utility methods are static. >>> E.g. XRenderFillRectangle takes 40 cycles without clamping, but >>> already 70 cycles with on my core2duo with hotspot-server/jdk 14.0. >>> Hotspot seems to solve the problem always with conditional jumps, >>> although well predictable ones. >>> >>> Modern processors seem to have support for this kind of operation, in >>> x86 there's packssdw in MMX/SSE2. >>> I think something like a saturated cast could be quite useful, there >>> are already cast-methods in Long/Integer/Short - what do you think >>> about adding saturated casts to that API? >>> Those could be instrified to use MMX/SSE2 if available. >>> >>> If that would be too specific how hard would it be to add this kind of >>> optimization to hotspot? >>> How far does SIMD support in hotspot go (I read some time ago there've >>> been some optimizations), if SIMD would be supported 4 casts could be >>> done in a single cycle :) From martinrb at google.com Thu May 19 02:27:39 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 18 May 2016 19:27:39 -0700 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters Message-ID: Another batch of ZipFile hackery. I think I finally understand how weak references and finalizers interact. We could eliminate the Inflater cache entirely, but this proposal keeps a one-element Inflater cache. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ZipFile-Inflater-cache/ https://bugs.openjdk.java.net/browse/JDK-8156484 - fixes the memory bloat from cached Inflaters - removes small races in close - various other minor improvements From brian.burkhalter at oracle.com Thu May 19 03:16:14 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 18 May 2016 20:16:14 -0700 Subject: [PING] [9] RFR of 5100935: No way to access the 64-bit integer multiplication of 64-bit CPUs efficiently In-Reply-To: <48070a6e-40af-4748-4fc1-2c76c75d7371@oracle.com> References: <3B559334-8ED3-4BEA-85E9-7AA9CD57AA91@oracle.com> <55FDBCC1.8060708@oracle.com> <48070a6e-40af-4748-4fc1-2c76c75d7371@oracle.com> Message-ID: Hi Joe, On May 18, 2016, at 5:37 PM, joe darcy wrote: > Sorry for the belated review. No worries. > For multiplyFull, currently the wording is > > 833 * Returns the product of the arguments allowing overflowed values within > 834 * the range of {@code long}. > > I think it would work about as something like "Returns the exact mathematical product of the arguments." > > Otherwise, looks okay. I shall update it to that. I suppose no need to provide another webrev? Thanks, Brian From joe.darcy at oracle.com Thu May 19 04:22:33 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 18 May 2016 21:22:33 -0700 Subject: [PING] [9] RFR of 5100935: No way to access the 64-bit integer multiplication of 64-bit CPUs efficiently In-Reply-To: References: <3B559334-8ED3-4BEA-85E9-7AA9CD57AA91@oracle.com> <55FDBCC1.8060708@oracle.com> <48070a6e-40af-4748-4fc1-2c76c75d7371@oracle.com> Message-ID: Hi Brian, On 5/18/2016 8:16 PM, Brian Burkhalter wrote: > Hi Joe, > > On May 18, 2016, at 5:37 PM, joe darcy > wrote: > >> Sorry for the belated review. > > No worries. > >> For multiplyFull, currently the wording is >> >> 833 * Returns the product of the arguments allowing overflowed >> values within >> 834 * the range of {@code long}. >> >> I think it would work about as something like "Returns the exact >> mathematical product of the arguments." >> >> Otherwise, looks okay. > > I shall update it to that. I suppose no need to provide another webrev? > Right; no need for a second webrev. Thanks, -Joe From david.holmes at oracle.com Thu May 19 04:52:50 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 May 2016 14:52:50 +1000 Subject: RFR (XS): 8157188: 2 test failures in demo/jvmti due to unexpected class file version 53 Message-ID: Not sure who really owns this file so cc'ing core-libs and serviceability. bug: https://bugs.openjdk.java.net/browse/JDK-8157188 The file src/java.base/share/native/include/classfile_constants.h describes information about classfiles and is used by libverify and ./demo/share/jvmti/java_crw_demo/java_crw_demo.c This file has not been updated for classfile version 53 and so asserts will fail in java_crw_demo.c when it encounters classes compiled for version 53 - as they now are. This version change caused test failures in the hotspot forest when it was pulled down earlier this week. This fix trivially bumps the current version number to 53 to fix the failing tests. It is a separate issue as to whether other changes are needed in this file to reflect what is new with classfile version 53. Diff below. Thanks, David ------ diff -r 3eea6819cc1f src/java.base/share/native/include/classfile_constants.h --- a/src/java.base/share/native/include/classfile_constants.h +++ b/src/java.base/share/native/include/classfile_constants.h @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -31,7 +31,7 @@ #endif /* Classfile version number for this information */ -#define JVM_CLASSFILE_MAJOR_VERSION 52 +#define JVM_CLASSFILE_MAJOR_VERSION 53 #define JVM_CLASSFILE_MINOR_VERSION 0 /* Flags */ From dmitry.samersoff at oracle.com Thu May 19 05:01:25 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 19 May 2016 08:01:25 +0300 Subject: RFR (XS): 8157188: 2 test failures in demo/jvmti due to unexpected class file version 53 In-Reply-To: References: Message-ID: <573D48A5.6040505@oracle.com> David, Looks good for me. Probably I was the last person who do something with java_crw_demo.c. -Dmitry On 2016-05-19 07:52, David Holmes wrote: > Not sure who really owns this file so cc'ing core-libs and serviceability. > > bug: https://bugs.openjdk.java.net/browse/JDK-8157188 > > The file src/java.base/share/native/include/classfile_constants.h > describes information about classfiles and is used by libverify and > ./demo/share/jvmti/java_crw_demo/java_crw_demo.c > > This file has not been updated for classfile version 53 and so asserts > will fail in java_crw_demo.c when it encounters classes compiled for > version 53 - as they now are. This version change caused test failures > in the hotspot forest when it was pulled down earlier this week. > > This fix trivially bumps the current version number to 53 to fix the > failing tests. It is a separate issue as to whether other changes are > needed in this file to reflect what is new with classfile version 53. > > Diff below. > > Thanks, > David > ------ > > diff -r 3eea6819cc1f > src/java.base/share/native/include/classfile_constants.h > --- a/src/java.base/share/native/include/classfile_constants.h > +++ b/src/java.base/share/native/include/classfile_constants.h > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2004, 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2004, 2016, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -31,7 +31,7 @@ > #endif > > /* Classfile version number for this information */ > -#define JVM_CLASSFILE_MAJOR_VERSION 52 > +#define JVM_CLASSFILE_MAJOR_VERSION 53 > #define JVM_CLASSFILE_MINOR_VERSION 0 > > /* Flags */ -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From Alan.Bateman at oracle.com Thu May 19 05:37:38 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 May 2016 06:37:38 +0100 Subject: RFR (XS): 8157188: 2 test failures in demo/jvmti due to unexpected class file version 53 In-Reply-To: References: Message-ID: <573D5122.8030207@oracle.com> On 19/05/2016 05:52, David Holmes wrote: > Not sure who really owns this file so cc'ing core-libs and > serviceability. > > bug: https://bugs.openjdk.java.net/browse/JDK-8157188 > > The file src/java.base/share/native/include/classfile_constants.h > describes information about classfiles and is used by libverify and > ./demo/share/jvmti/java_crw_demo/java_crw_demo.c > > This file has not been updated for classfile version 53 and so asserts > will fail in java_crw_demo.c when it encounters classes compiled for > version 53 - as they now are. This version change caused test failures > in the hotspot forest when it was pulled down earlier this week. > > This fix trivially bumps the current version number to 53 to fix the > failing tests. It is a separate issue as to whether other changes are > needed in this file to reflect what is new with classfile version 53. It's the serviceability area that has historically maintained this. The change looks fine. -Alan From david.holmes at oracle.com Thu May 19 07:48:12 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 May 2016 17:48:12 +1000 Subject: RFR (XS): 8157188: 2 test failures in demo/jvmti due to unexpected class file version 53 In-Reply-To: <573D48A5.6040505@oracle.com> References: <573D48A5.6040505@oracle.com> Message-ID: <52fe8557-7600-4123-9862-8823c8fa9b9f@oracle.com> Thanks Dmitry! David On 19/05/2016 3:01 PM, Dmitry Samersoff wrote: > David, > > Looks good for me. > > Probably I was the last person who do something with java_crw_demo.c. > > -Dmitry > > On 2016-05-19 07:52, David Holmes wrote: >> Not sure who really owns this file so cc'ing core-libs and serviceability. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8157188 >> >> The file src/java.base/share/native/include/classfile_constants.h >> describes information about classfiles and is used by libverify and >> ./demo/share/jvmti/java_crw_demo/java_crw_demo.c >> >> This file has not been updated for classfile version 53 and so asserts >> will fail in java_crw_demo.c when it encounters classes compiled for >> version 53 - as they now are. This version change caused test failures >> in the hotspot forest when it was pulled down earlier this week. >> >> This fix trivially bumps the current version number to 53 to fix the >> failing tests. It is a separate issue as to whether other changes are >> needed in this file to reflect what is new with classfile version 53. >> >> Diff below. >> >> Thanks, >> David >> ------ >> >> diff -r 3eea6819cc1f >> src/java.base/share/native/include/classfile_constants.h >> --- a/src/java.base/share/native/include/classfile_constants.h >> +++ b/src/java.base/share/native/include/classfile_constants.h >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2004, 2012, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2004, 2016, Oracle and/or its affiliates. All rights >> reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -31,7 +31,7 @@ >> #endif >> >> /* Classfile version number for this information */ >> -#define JVM_CLASSFILE_MAJOR_VERSION 52 >> +#define JVM_CLASSFILE_MAJOR_VERSION 53 >> #define JVM_CLASSFILE_MINOR_VERSION 0 >> >> /* Flags */ > > From david.holmes at oracle.com Thu May 19 07:51:32 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 May 2016 17:51:32 +1000 Subject: RFR (XS): 8157188: 2 test failures in demo/jvmti due to unexpected class file version 53 In-Reply-To: <573D5122.8030207@oracle.com> References: <573D5122.8030207@oracle.com> Message-ID: <3944d8fa-7ac3-6a90-da16-aec7006c7805@oracle.com> Thanks Alan! David On 19/05/2016 3:37 PM, Alan Bateman wrote: > On 19/05/2016 05:52, David Holmes wrote: >> Not sure who really owns this file so cc'ing core-libs and >> serviceability. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8157188 >> >> The file src/java.base/share/native/include/classfile_constants.h >> describes information about classfiles and is used by libverify and >> ./demo/share/jvmti/java_crw_demo/java_crw_demo.c >> >> This file has not been updated for classfile version 53 and so asserts >> will fail in java_crw_demo.c when it encounters classes compiled for >> version 53 - as they now are. This version change caused test failures >> in the hotspot forest when it was pulled down earlier this week. >> >> This fix trivially bumps the current version number to 53 to fix the >> failing tests. It is a separate issue as to whether other changes are >> needed in this file to reflect what is new with classfile version 53. > It's the serviceability area that has historically maintained this. The > change looks fine. > > -Alan From serguei.spitsyn at oracle.com Thu May 19 08:09:26 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 19 May 2016 01:09:26 -0700 Subject: RFR (XS): 8157188: 2 test failures in demo/jvmti due to unexpected class file version 53 In-Reply-To: References: Message-ID: <573D74B6.10401@oracle.com> David, The change looks good but you already have enough reviewers. :) Just wanted to thank you for taking steps on this issue. Thanks, Serguei On 5/18/16 21:52, David Holmes wrote: > Not sure who really owns this file so cc'ing core-libs and > serviceability. > > bug: https://bugs.openjdk.java.net/browse/JDK-8157188 > > The file src/java.base/share/native/include/classfile_constants.h > describes information about classfiles and is used by libverify and > ./demo/share/jvmti/java_crw_demo/java_crw_demo.c > > This file has not been updated for classfile version 53 and so asserts > will fail in java_crw_demo.c when it encounters classes compiled for > version 53 - as they now are. This version change caused test failures > in the hotspot forest when it was pulled down earlier this week. > > This fix trivially bumps the current version number to 53 to fix the > failing tests. It is a separate issue as to whether other changes are > needed in this file to reflect what is new with classfile version 53. > > Diff below. > > Thanks, > David > ------ > > diff -r 3eea6819cc1f > src/java.base/share/native/include/classfile_constants.h > --- a/src/java.base/share/native/include/classfile_constants.h > +++ b/src/java.base/share/native/include/classfile_constants.h > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2004, 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2004, 2016, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -31,7 +31,7 @@ > #endif > > /* Classfile version number for this information */ > -#define JVM_CLASSFILE_MAJOR_VERSION 52 > +#define JVM_CLASSFILE_MAJOR_VERSION 53 > #define JVM_CLASSFILE_MINOR_VERSION 0 > > /* Flags */ From aph at redhat.com Thu May 19 09:44:52 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 May 2016 10:44:52 +0100 Subject: [PING] [9] RFR of 5100935: No way to access the 64-bit integer multiplication of 64-bit CPUs efficiently In-Reply-To: References: <3B559334-8ED3-4BEA-85E9-7AA9CD57AA91@oracle.com> <55FDBCC1.8060708@oracle.com> <48070a6e-40af-4748-4fc1-2c76c75d7371@oracle.com> Message-ID: <573D8B14.5040109@redhat.com> This is described as being to help RSA, etc., but it will be very hard to use for that purpose without an add with carry. There are many ways to do the product, but a simple version of the core is like this: for i=0 to s-1 C := 0 for j=0 to s-1 (C,S) := t[i+j] + a[j] * b[i] + C t[i+j] := S t[i+s] := C for i=0 to s-1 C := 0 m := t i *n' 0 mod W for j=0 to s-1 (C,S) := t[i+j] + m*n[j] + C t[i+j] := S ADD(t[i+s],C) ... the result is in the carry flag and t . The logic in the x86 version of SharedRuntime::montgomery_multiply uses a primitive which multiplies two longs and accumulates the result into a triple-length sum. x86 can do this in four instructions. I guess a primitive like this will fit nicely with value types, but I'm not sure how it's possible to do this with Java today. (My apologies: I'm sure you know this already, but I didn't think it was wise not to say anything.) Andrew. [Algorithm from http://koclab.cs.ucsb.edu/docs/koc/j37.pdf] From paul.sandoz at oracle.com Thu May 19 09:47:04 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 19 May 2016 11:47:04 +0200 Subject: RFR 8157239 java/lang/invoke/VarHandles/ tests fail by timeout with -Xcomp with lambda form linkage Message-ID: <4FB7C539-6EEF-4882-A8BF-B3A7D5460C0B@oracle.com> Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8157239-vh-tests-xcomp-timeout/webrev/ A recent change modified the VH tests to test the lambda form linkage route: -Djava.lang.invoke.VarHandle.VAR_HANDLE_GUARDS=false However this causes test timeouts when the tests are run with -Xcomp. I think this is due to -Xcomp triggering recompilation storms due to lack of caching of linking lambda forms (which will be sorted out later on). The solution for the moment is to remove that test execution mode on iteration-based tests, and the mode will be added back once -Xcomp execution issues have been resolved. Paul. From paul.sandoz at oracle.com Thu May 19 10:02:22 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 19 May 2016 12:02:22 +0200 Subject: RFR 8130023 API java.util.stream: explicitly specify guaranteed execution of the pipeline In-Reply-To: <573B8A0B.9010206@oracle.com> References: <573B8A0B.9010206@oracle.com> Message-ID: <9B780869-3D86-4FCF-8AB8-5B931115BE44@oracle.com> > On 17 May 2016, at 23:15, Claes Redestad wrote: > > Hi, > > the first block in Stream.java bothers me: > > + *

A stream implementation is permitted significant latitude in optimizing > + * the computation of the result. For example, a stream implementation is free > + * to elide operations (or entire stages) from a stream pipeline -- and > + * therefore elide invocation of behavioral parameters -- if it can prove that > + * it would not affect the result of the computation. This means, that unless > + * otherwise specified (such as by the terminal operations {@code forEach} and > + * {@code forEachOrdered}), that side-effects of behavioral parameters may not > + * always be executed and should not be relied upon. (For a specific example of > + * such an optimization, see the API note documented on the {@link #count} > + * operation. For more detail, see the > + * side-effects section of the > + * strean package documentation.) > + * > > > The first sentence in particular is hard to read and interpret, and after reading it twice I'm not sure if it's entirely redundant or if you need to better specify what other freedoms are given to a stream implementation? > The first sentence is setting the stage that it is the result and not the computation that is key and we want to get across that this is not a limitation but a feature, since streams are about specifying a computation declaratively (and if side-effects are present then watch out!). We cannot specify the degrees of freedom, we can only specify the result be the same. Perhaps the "For example, ? in the following sentence can be removed or replaced with ?As such ?.? ? > How about this: > > + *

Astream implementation is free to elide operations (or entire stages) + * from a stream pipeline -- andtherefore elide invocation of behavioral + * parameters -- if it can prove that it would not affect the result of the + * computation. This means that side-effects of behavioral parameters may not + * always be executed and should not be relied upon, unless otherwise specified + * (such as by the terminal operations {@code forEach} and > + * {@code forEachOrdered}).(For a specific example ofsuch an optimization, + * see the API note documented on the {@link #count} operation. For more + * details, see the side-effects + * section of the stream package documentation.) > + * > I like the move of the ?unless ?? to the end of the sentence, that reads better. Thanks, Paul. From vladimir.x.ivanov at oracle.com Thu May 19 10:09:49 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 19 May 2016 13:09:49 +0300 Subject: RFR 8157239 java/lang/invoke/VarHandles/ tests fail by timeout with -Xcomp with lambda form linkage In-Reply-To: <4FB7C539-6EEF-4882-A8BF-B3A7D5460C0B@oracle.com> References: <4FB7C539-6EEF-4882-A8BF-B3A7D5460C0B@oracle.com> Message-ID: Reviewed. Best regards, Vladimir Ivanov On 5/19/16 12:47 PM, Paul Sandoz wrote: > Hi, > > Please review: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8157239-vh-tests-xcomp-timeout/webrev/ > > A recent change modified the VH tests to test the lambda form linkage route: > > -Djava.lang.invoke.VarHandle.VAR_HANDLE_GUARDS=false > > However this causes test timeouts when the tests are run with -Xcomp. I think this is due to -Xcomp triggering recompilation storms due to lack of caching of linking lambda forms (which will be sorted out later on). > > The solution for the moment is to remove that test execution mode on iteration-based tests, and the mode will be added back once -Xcomp execution issues have been resolved. > > Paul. > From bhanu.prakash.gopularam at oracle.com Thu May 19 10:34:46 2016 From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam) Date: Thu, 19 May 2016 03:34:46 -0700 (PDT) Subject: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields In-Reply-To: References: <573A9B92.60201@oracle.com> Message-ID: <7bf185b0-ceb0-4329-bb7e-6555383eaa67@default> Thank you Nadeesh and Stephen. Here is the updated webrev link: http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.01 Please review. Bhanu -----Original Message----- From: Stephen Colebourne [mailto:scolebourne at joda.org] Sent: Tuesday, May 17, 2016 5:11 PM To: core-libs-dev Subject: Re: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields I would also like to see the test case methods be named "getFrom" not "getfrom". Stephen On 17 May 2016 at 05:18, nadeesh tv wrote: > Hi Bhanu, > > I think you should add a test case comparing the return value of > getFrom() > > ( Not an official reviewer) > > Regards, > Nadeesh > > On 5/16/2016 11:46 AM, Bhanu Gopularam wrote: >> >> Hi all, >> >> Could you please review fix for following issue. >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8156718 >> >> Solution: Added tck tests for validating getFrom method for >> unsupported non-Iso temporal fields >> >> Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.00/ >> >> Thanks, >> Bhanu > > > -- > Thanks and Regards, > Nadeesh TV > From me at noctarius.com Thu May 19 10:35:23 2016 From: me at noctarius.com (Christoph Engelbert) Date: Thu, 19 May 2016 12:35:23 +0200 Subject: Cleaner cleanup In-Reply-To: <8b4dd573-da7b-fd6c-eb49-24f2b15a11cc@gmail.com> References: <8b4dd573-da7b-fd6c-eb49-24f2b15a11cc@gmail.com> Message-ID: <332C5AD1-F421-41D3-A416-BE883BBC9334@noctarius.com> Hey Peter, I just realized, there are two mistakes in the Javadoc code example inside the Cleaner Javadoc: private final State; -> private final State state; private final Cleaner.Cleanable cleanable -> private final Cleaner.Cleanable cleanable; Chris > On 16 May 2016, at 00:08, Peter Levart wrote: > > Hi Roger and others, > > When the new Cleaner API was created the implementation of Cleanable(s) was split into the low-level abstract [Soft|Weak|Phantom]Cleanable classes to be used internally for purposes where the footprint matters and their corresponding CleanerImpl.[Soft|Weak|Phantom]CleanableRef subclasses used as implementations that take a Runnable cleanup action and are exposed via the public Cleaner API. > > When thinking of possible JDK internal use cases for the low-level API, I came to the conclusion that [Soft|Weak|Phantom]Cleanable classes are not suitable as is, because in cases where footprint matters, it is usually also the case that the number of [Soft|Weak|Phantom]Cleanable instances created is larger and that construction performance also matters. Especially multi-threaded construction. I'm thinking of the use cases of auto-cleanable concurrent data structures. In such use cases, the present features of [Soft|Weak|Phantom]Cleanable classes, namely the guaranteed just-once cleanup action invocation and keeping the Cleanable instance reachable until the cleanup action is performed, are actually not needed and just present footprint and performance (contention) overhead. They also present an overhead as they don't allow GC to automatically collect the Cleanable instances if the data structure containing them becomes unreachable and corresponding registered cleanup actions obsolete. > > The mentioned features are important for public Cleaner.Cleanable instances as they are usually used for cleanup of native resources where the performance of their creation is not so drastically important and where there is no intrinsic data structure to hold them reachable. > > I propose to move those features from the [Soft|Weak|Phantom]Cleanable classes down the hierarchy to the CleanerImpl.[Soft|Weak|Phantom]CleanableRef subclasses: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner.cleanup/webrev.01/ > > > In this change I also removed the CleanerImpl.[Soft|Weak]CleanableRef subclasses as they are not needed and I believe will never be. I also renamed the CleanerImpl.PhantomCleanableRef subclass to CleanerImpl.PhantomCleanableImpl. > > Changes to the implementation are straightforward. The most work was put into the corresponding test. I did some clean-up to it and also changed it to accommodate for the new behavior of [Soft|Weak|Phantom]Cleanable classes. The changes speak for itself. One of the not-so obvious changes was to replace the CleanableCase.clearRef() action with the CleanableCase.releaseReferent() action. The old clearRef() action did not serve any purpose. Whether this method was called or not, the behavior of the corresponding Cleanable was unchanged as the Reference instance (referenced from the 'ref' field) was always of the same strength as the Cleanable itself. So clearing it could not affect the behavior of the Cleanable. > > I changed 'ref' to hold a direct reference to the referent and renamed the field to 'referent'. I changed the EV_XXX int constants to Event enum constants with helper methods used in CleanableCase.expectedCleanups() method that now returns the number of expected cleanup invocations - in the PhantomCleanableImpl case this is the number of expected cleanup action invocations while in the plain XxxCleanable subclass cases it is the number of Cleanable.clean() method invocations. I added the no-actions case to both PhantomCleanableImpl and XxxCleanable cases and extended the number and combinations of XxxCleanable cases. > > The checkCleaned() method was extended to verify that the number of cleanup invocations is *no more* and no less then the expected. > > See how WeakKey test is now simplified. This is the typical use-case for WeakCleanable I was talking about. > > > So, what do you think of this cleanup? > > > Regards, Peter > From nadeesh.tv at oracle.com Thu May 19 10:57:37 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Thu, 19 May 2016 16:27:37 +0530 Subject: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields In-Reply-To: <7bf185b0-ceb0-4329-bb7e-6555383eaa67@default> References: <573A9B92.60201@oracle.com> <7bf185b0-ceb0-4329-bb7e-6555383eaa67@default> Message-ID: <573D9C21.1060504@oracle.com> Hi Bhanu, Looking fine to me. Thanks and Regards, Nadeesh On 5/19/2016 4:04 PM, Bhanu Gopularam wrote: > Thank you Nadeesh and Stephen. > > Here is the updated webrev link: > http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.01 > > Please review. > > Bhanu > > -----Original Message----- > From: Stephen Colebourne [mailto:scolebourne at joda.org] > Sent: Tuesday, May 17, 2016 5:11 PM > To: core-libs-dev > Subject: Re: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields > > I would also like to see the test case methods be named "getFrom" not "getfrom". > > Stephen > > On 17 May 2016 at 05:18, nadeesh tv wrote: >> Hi Bhanu, >> >> I think you should add a test case comparing the return value of >> getFrom() >> >> ( Not an official reviewer) >> >> Regards, >> Nadeesh >> >> On 5/16/2016 11:46 AM, Bhanu Gopularam wrote: >>> Hi all, >>> >>> Could you please review fix for following issue. >>> >>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8156718 >>> >>> Solution: Added tck tests for validating getFrom method for >>> unsupported non-Iso temporal fields >>> >>> Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.00/ >>> >>> Thanks, >>> Bhanu >> >> -- >> Thanks and Regards, >> Nadeesh TV >> -- Thanks and Regards, Nadeesh TV From scolebourne at joda.org Thu May 19 11:16:27 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 19 May 2016 12:16:27 +0100 Subject: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields In-Reply-To: <7bf185b0-ceb0-4329-bb7e-6555383eaa67@default> References: <573A9B92.60201@oracle.com> <7bf185b0-ceb0-4329-bb7e-6555383eaa67@default> Message-ID: Fine by me Stephen On 19 May 2016 at 11:34, Bhanu Gopularam wrote: > Thank you Nadeesh and Stephen. > > Here is the updated webrev link: > http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.01 > > Please review. > > Bhanu > > -----Original Message----- > From: Stephen Colebourne [mailto:scolebourne at joda.org] > Sent: Tuesday, May 17, 2016 5:11 PM > To: core-libs-dev > Subject: Re: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields > > I would also like to see the test case methods be named "getFrom" not "getfrom". > > Stephen > > On 17 May 2016 at 05:18, nadeesh tv wrote: >> Hi Bhanu, >> >> I think you should add a test case comparing the return value of >> getFrom() >> >> ( Not an official reviewer) >> >> Regards, >> Nadeesh >> >> On 5/16/2016 11:46 AM, Bhanu Gopularam wrote: >>> >>> Hi all, >>> >>> Could you please review fix for following issue. >>> >>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8156718 >>> >>> Solution: Added tck tests for validating getFrom method for >>> unsupported non-Iso temporal fields >>> >>> Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.00/ >>> >>> Thanks, >>> Bhanu >> >> >> -- >> Thanks and Regards, >> Nadeesh TV >> From martinrb at google.com Thu May 19 12:54:57 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 19 May 2016 05:54:57 -0700 Subject: Can an object be finalized while still weakly reachable? In-Reply-To: References: <298d69ca-a7bc-2798-7f88-2bdff21b78a7@gmail.com> <7737177b-8791-3d87-dcbc-ae6f5167efa7@oracle.com> Message-ID: Martin's law of object pools in the presence of finalizers: Resurrecting a pooled object with a finalizer can be disastrous as it can be finalized later while in active use. Returning an object to the pool is a common thing to do in close() methods, and close() methods are reasonable things to call in foreign code finalizers. So you keep it behind a weak reference at all times, even when in use. As long as the object remains reachable through the weak reference, it is safe from finalization. But the weak reference also permits finalization for resource reclamation. On Wed, May 18, 2016 at 7:52 AM, Martin Buchholz wrote: > Sherman, > > Thank you very much for pointing me at that old thread. I was indeed > going down the same path and stumbling over the same obstacles! I > still think we can do better, but it's definitely not easy. > > On Tue, May 17, 2016 at 8:15 AM, Xueming Shen wrote: >> On 5/17/16 12:55 AM, Martin Buchholz wrote: >>> >>> Thanks, Peter. >>> >>> My current theory is indeed that I made a mistake, and have >>> encountered my first real finalization resurrection bug. >>> ZipFile + Inflater have 4 finalize methods and a WeakHashMap in play! >> >> there was a long discussion when we touched that part of the code last time. >> just >> for your reference:-) >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-April/thread.html#6545 >> >> -sherman >> >>> My static reference was finalized because it used to be unreachable, >>> not because it is now weakly reachable! >>> >>> On Mon, May 16, 2016 at 11:49 PM, Peter Levart >>> wrote: >>>> >>>> Hi Martin, >>>> >>>> >>>> >>>> On 05/17/2016 05:19 AM, Martin Buchholz wrote: >>>>> >>>>> I have some evidence that an object's finalize method can run while a >>>>> weak reference pointing to it is not yet cleared, which surprised me. >>>>> >>>>> E.g. >>>>> class F { protected void finalize() { assert wref.get() != this; } } >>>>> static WeakReference wref = new WeakReference(new F()); >>>>> >>>>> If this is a bug, I can try to give y'all a repro recipe. >>>>> If not, we should fix the docs >>>>> """When the weak references to a weakly-reachable object are cleared, >>>>> the object becomes eligible for finalization.""" >>>>> >>>>> (It's also quite possible I made a mistake diagnosing this) >>>> >>>> >>>> What can happen with above code is that you get a NPE from dereferencing >>>> wref in finlailze(). In case NPE is not thrown and the program constructs >>>> only a single instance of F then assert should succeed. >>>> >>>> It is possible that you made a mistake. Can you post the real code? >>>> >>>> Regards, Peter >>>> >> From Roger.Riggs at Oracle.com Thu May 19 13:19:25 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 19 May 2016 09:19:25 -0400 Subject: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields In-Reply-To: References: <573A9B92.60201@oracle.com> <7bf185b0-ceb0-4329-bb7e-6555383eaa67@default> Message-ID: Hi Bhanu, Can you remind me why the value from line: 459 field.rangeRefinedBy(LocalDate.now()); is not checked also? Is looks odd to see a value passed to a test and not have it verified. It would need to use a fixed date (the same), but that is fine for that test. Thanks, Roger On 5/19/2016 7:16 AM, Stephen Colebourne wrote: > Fine by me > Stephen > > On 19 May 2016 at 11:34, Bhanu Gopularam > wrote: >> Thank you Nadeesh and Stephen. >> >> Here is the updated webrev link: >> http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.01 >> >> Please review. >> >> Bhanu >> >> -----Original Message----- >> From: Stephen Colebourne [mailto:scolebourne at joda.org] >> Sent: Tuesday, May 17, 2016 5:11 PM >> To: core-libs-dev >> Subject: Re: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields >> >> I would also like to see the test case methods be named "getFrom" not "getfrom". >> >> Stephen >> >> On 17 May 2016 at 05:18, nadeesh tv wrote: >>> Hi Bhanu, >>> >>> I think you should add a test case comparing the return value of >>> getFrom() >>> >>> ( Not an official reviewer) >>> >>> Regards, >>> Nadeesh >>> >>> On 5/16/2016 11:46 AM, Bhanu Gopularam wrote: >>>> Hi all, >>>> >>>> Could you please review fix for following issue. >>>> >>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8156718 >>>> >>>> Solution: Added tck tests for validating getFrom method for >>>> unsupported non-Iso temporal fields >>>> >>>> Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.00/ >>>> >>>> Thanks, >>>> Bhanu >>> >>> -- >>> Thanks and Regards, >>> Nadeesh TV >>> From Roger.Riggs at Oracle.com Thu May 19 13:23:20 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 19 May 2016 09:23:20 -0400 Subject: Cleaner cleanup In-Reply-To: <332C5AD1-F421-41D3-A416-BE883BBC9334@noctarius.com> References: <8b4dd573-da7b-fd6c-eb49-24f2b15a11cc@gmail.com> <332C5AD1-F421-41D3-A416-BE883BBC9334@noctarius.com> Message-ID: Hi, I haven't had time to look into this thoroughly, but since the at-most-once semantics have been removed from the Phantom|Weak|SoftCleanable classes and they are not used anywhere, they should be completely removed also, completing the cleanup. The only function being used (except by the tests) is the primary support for Cleaner.register(). Roger On 5/19/2016 6:35 AM, Christoph Engelbert wrote: > Hey Peter, > > I just realized, there are two mistakes in the Javadoc code example > inside the Cleaner Javadoc: > > private final State; -> private final Statestate; > private final Cleaner.Cleanable cleanable -> private final Cleaner.Cleanable cleanable; > > Chris > >> On 16 May 2016, at 00:08, Peter Levart > > wrote: >> >> Hi Roger and others, >> >> When the new Cleaner API was created the implementation of >> Cleanable(s) was split into the low-level abstract >> [Soft|Weak|Phantom]Cleanable classes to be used internally for >> purposes where the footprint matters and their corresponding >> CleanerImpl.[Soft|Weak|Phantom]CleanableRef subclasses used as >> implementations that take a Runnable cleanup action and are exposed >> via the public Cleaner API. >> >> When thinking of possible JDK internal use cases for the low-level >> API, I came to the conclusion that [Soft|Weak|Phantom]Cleanable >> classes are not suitable as is, because in cases where footprint >> matters, it is usually also the case that the number of >> [Soft|Weak|Phantom]Cleanable instances created is larger and that >> construction performance also matters. Especially multi-threaded >> construction. I'm thinking of the use cases of auto-cleanable >> concurrent data structures. In such use cases, the present features >> of [Soft|Weak|Phantom]Cleanable classes, namely the guaranteed >> just-once cleanup action invocation and keeping the Cleanable >> instance reachable until the cleanup action is performed, are >> actually not needed and just present footprint and performance >> (contention) overhead. They also present an overhead as they don't >> allow GC to automatically collect the Cleanable instances if the data >> structure containing them becomes unreachable and corresponding >> registered cleanup actions obsolete. >> >> The mentioned features are important for public Cleaner.Cleanable >> instances as they are usually used for cleanup of native resources >> where the performance of their creation is not so drastically >> important and where there is no intrinsic data structure to hold them >> reachable. >> >> I propose to move those features from the >> [Soft|Weak|Phantom]Cleanable classes down the hierarchy to the >> CleanerImpl.[Soft|Weak|Phantom]CleanableRef subclasses: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner.cleanup/webrev.01/ >> >> >> >> In this change I also removed the CleanerImpl.[Soft|Weak]CleanableRef >> subclasses as they are not needed and I believe will never be. I also >> renamed the CleanerImpl.PhantomCleanableRef subclass to >> CleanerImpl.PhantomCleanableImpl. >> >> Changes to the implementation are straightforward. The most work was >> put into the corresponding test. I did some clean-up to it and also >> changed it to accommodate for the new behavior of >> [Soft|Weak|Phantom]Cleanable classes. The changes speak for itself. >> One of the not-so obvious changes was to replace the >> CleanableCase.clearRef() action with the >> CleanableCase.releaseReferent() action. The old clearRef() action did >> not serve any purpose. Whether this method was called or not, the >> behavior of the corresponding Cleanable was unchanged as the >> Reference instance (referenced from the 'ref' field) was always of >> the same strength as the Cleanable itself. So clearing it could not >> affect the behavior of the Cleanable. >> >> I changed 'ref' to hold a direct reference to the referent and >> renamed the field to 'referent'. I changed the EV_XXX int constants >> to Event enum constants with helper methods used in >> CleanableCase.expectedCleanups() method that now returns the number >> of expected cleanup invocations - in the PhantomCleanableImpl case >> this is the number of expected cleanup action invocations while in >> the plain XxxCleanable subclass cases it is the number of >> Cleanable.clean() method invocations. I added the no-actions case to >> both PhantomCleanableImpl and XxxCleanable cases and extended the >> number and combinations of XxxCleanable cases. >> >> The checkCleaned() method was extended to verify that the number of >> cleanup invocations is *no more* and no less then the expected. >> >> See how WeakKey test is now simplified. This is the typical use-case >> for WeakCleanable I was talking about. >> >> >> So, what do you think of this cleanup? >> >> >> Regards, Peter >> > From aleksey.shipilev at oracle.com Thu May 19 14:01:31 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 19 May 2016 17:01:31 +0300 Subject: RFR (M) 8148604: JEP 280, Switch to more optimal concatenation strategy In-Reply-To: <573C66A2.6050508@oracle.com> References: <573C5B82.4010208@oracle.com> <573C66A2.6050508@oracle.com> Message-ID: <573DC73B.5070001@oracle.com> Thanks Paul and Claes! Hearing no objections for 24 hours now, I have pushed this change. Thanks, -Aleksey On 05/18/2016 03:57 PM, Claes Redestad wrote: > +1 > > I think it's a good time to enable this. I do expect some impact to > various startup tests based on some earlier experiments, but that will > help us pinpoint areas to focus startup optimization efforts on going > forward. > > Thanks! > > /Claes > > On 2016-05-18 14:09, Aleksey Shipilev wrote: >> Hi, >> >> We have been waiting for this for at least 8 weeks, waiting for Jigsaw >> to settle in, and hs-main -> jdk9/dev integration to happen that brings >> a few testbug fixes into the jdk9/dev. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8148604 >> >> Webrev: >> http://cr.openjdk.java.net/~shade/8148604/webrev.01/ >> (the change is XS, but impact is M) >> >> Targeted benchmarks show significant improvements with the >> MH_INLINE_SIZED_EXACT strategy, see the bug for the test results. >> Performance improvements are due to these reasons: >> >> *) it does not rely on OptimizeStringConcat in C2, but instead does >> lift up the concatenation into the Java code, spelling it out with >> java.lang.invoke building blocks. This also helps to improve C1 >> performance significantly; >> >> *) it uniformly covers the cases that OptimizeStringConcat does not >> cover, e.g. non-int/char arguments where OptimizeStringConcat bails, etc; >> >> *) it uniformly covers the Compact Strings (JEP 254) changes, e.g. >> selecting the final coder for the concatenated String, and calling >> appropriate coder-specific routines from JDK. Doing this in Java has the >> apparent benefit of piggy-backing on normal Java code profiling to >> figure out the hot branches -- a luxury OptimizeStringConcat-constructed >> code lacks. >> >> Unfortunately, we cannot test this with our regular performance testing, >> because it requires tests compiled with -target 9. The only easy target >> we have now is javac, and switching the concat strategy does not regress >> it (see JDK-8148605). >> >> MH_INLINE_SIZED_EXACT is functionally tested routinely with >> java/lang/String/concat/ jtregs on all platforms. >> >> Testing: java/lang/String/ jtregs; JPRT -testset hotspot >> >> Thanks, >> -Aleksey >> > From jaroslav at kamenik.cz Thu May 19 14:26:36 2016 From: jaroslav at kamenik.cz (=?UTF-8?Q?Jaroslav_Kamen=C3=ADk?=) Date: Thu, 19 May 2016 16:26:36 +0200 Subject: Helpers for MethodHandles.byteArrayViewVarHandle VarHandle In-Reply-To: References: Message-ID: > > > There certainly is in nio buffer sources (and may be for encoding/decoding > in other areas, i am speculating as i have not looked), but for buffer > sources we can actually remove much if not all of Bits.java via use of the > internal Unsafe unaligned accessors. > I made some notes when I was looking at it, I am attaching it if you want look at it. > getLongFrom[LE/BE](byte[] data, int firstByteIndex) > - for direct access > > getLongFrom[LE/BE](byte[] data, int firstByteOffset, int > longArrayIndex) - for loops/shifted array access > > > > etc. > > I was proposing just the latter, and just for VarHandles :-) it?s not just > for loops but also to bring alignment issues to the foreground. (It also it > fits in with something we have been pondering about for the unsafe > unaligned accessors on systems that don?t support unaligned access, such as > SPARC). > What do you mean by 'just for VarHandles'? Add it between VarHandle methods? Jaroslav From peter.levart at gmail.com Thu May 19 14:29:00 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 19 May 2016 16:29:00 +0200 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: References: Message-ID: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> Hi Martin, On 05/19/2016 04:27 AM, Martin Buchholz wrote: > Another batch of ZipFile hackery. I think I finally understand how > weak references and finalizers interact. > We could eliminate the Inflater cache entirely, but this proposal > keeps a one-element Inflater cache. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ZipFile-Inflater-cache/ > https://bugs.openjdk.java.net/browse/JDK-8156484 > > - fixes the memory bloat from cached Inflaters > - removes small races in close > - various other minor improvements The fixes to races are (almost) good. Also other minor improvements and cleanups. But I have reservation for the implementation of one-element global cache of Inflater. This cache can't be efficient. In order for cache to be efficient, majority of calls to ZipFile.getInputStream(zipEntry) would have to be accompanied by a corresponding explicit close() for the input stream before the WeakReference to the cached Inflater is cleared. We know that all WeakReference(s) to a referent are 1st cleared and then the finalize() method is called on it. GC clears all WeakReference(s) to interconnected graph of weakly-reachable referents atomically, so if the ZipFileInflaterInputStream is closed implicitly by the finalize() invocation which then tries to releaseInflater(), the inflater will not be released as the 'cachedInflater' WeakReference will already be cleared. It is too late to release inflater into cache anyway because if the input stream is already being finalized, then the associated inflater has either already been finalized or will be shortly as GC discovers and enqueues the FinalReference(s) pointing to inflater and corresponding input stream in the same GC cycle - Inflater and corresponding input stream become eligible for finalization at the same time. The "assert !inf.ended()" in releaseInflater() can therefore fail as final() methods on individual objects that are eligible for finalization may be invoked in arbitrary order. To correct that and improve the efficiency of cache, we have to do two things: - we can't fix all the usages of ZipFile.getInputStream(zipEntry) out there, but we can at least fix the usages in URLClassLoader and BuiltinClassLoader which amount to most getInputStream() invocations without corresponding close()s when classes are being loaded (one stream for each class). - we can make the Inflater cache a bit smarter. http://cr.openjdk.java.net/~plevart/jdk9-dev/ZipFile_Inflater.cleanup/webrev.01/ We don't actually need to cache the Inflater objects themselves, but rather Inflater's internal ZStreamRef(s) which are just objects holding address to native zlib's z_stream structure. I also suggest using new Cleaner API for tracking reachability of Inflater(s) so that Inflater.end() that results from explicit stream close() clears the PhantomCleanable and allows GC to refrain from pushing already end()-ed Inflater(s)/FinalReference(s) through the finalization pipeline. I also took the liberty to create a trusted package-private InflaterInputStream constructor so that trusted subclasses can use it and so that usesDefaultInflater flag can be private and final. Deflater is using ZStreamRef(s) too, so I also had to modify Deflater, but there's no caching of ZStreamRef(s) in deflater as there are too many different kinds of them and this is not critical. By making ZStreamRef(s) take care of themselves, corresponding logic in ZipFile's streams is much simpler - no need for finalize() method any more on ZipFileInflaterInputStream. finalize() is also not needed on ZipFileInputStream any more as 'streams' WeakHashMap is not holding Inflater instances as values any more and so finalize() would serve only to remove finalized ZipFile[Inflater]InputStream(s) from the WeakHashMap which the map is doing by itself already (expunging). java.util.zip tests pass with this patch except 2 tests that are ignored and ZipFile/TestZipFile.java that prints: java.lang.OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects ...which seems unrelated and the test passes when executed alone. This touches quite a number of other classes, but it seems necessary. So Martin, what do you think? Regards, Peter From martinrb at google.com Thu May 19 15:00:45 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 19 May 2016 08:00:45 -0700 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> References: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> Message-ID: On Thu, May 19, 2016 at 7:29 AM, Peter Levart wrote: > But I have reservation for the implementation of one-element global cache of > Inflater. This cache can't be efficient. In order for cache to be efficient, > majority of calls to ZipFile.getInputStream(zipEntry) would have to be > accompanied by a corresponding explicit close() for the input stream before > the WeakReference to the cached Inflater is cleared. That's my assumption. In most cases, failure to close something that can be closed is a bug. If there's code in the JDK that fails to do that, it should be fixed independently. > The "assert !inf.ended()" in > releaseInflater() can therefore fail as final() methods on individual > objects that are eligible for finalization may be invoked in arbitrary > order. Yeah, that's a bug. We can only assert after we verify that the Inflater is still weakly reachable. Updating my webrev with: * Releases the Inflater for possible later reuse. */ private static void releaseInflater(Inflater inf) { - assert !inf.ended(); CachedInflater cachedInflater = inflaterCache.get(); if (inf != cachedInflater.get()) { inf.end(); } else { // "return" the Inflater to the "pool". + assert !inf.ended(); inf.reset(); assert cachedInflater.inUse.get(); cachedInflater.inUse.set(false); From peter.levart at gmail.com Thu May 19 15:17:38 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 19 May 2016 17:17:38 +0200 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: References: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> Message-ID: <1f19a9a8-70ae-4143-affc-38bd620a860d@gmail.com> Hi Martin, To make it simpler to compare your and mine changes, here's the diff between your changed ZipFile.java and mine (mostly just removal of code): diff -r 45dcd8ef14a7 src/java.base/share/classes/java/util/zip/ZipFile.java --- a/src/java.base/share/classes/java/util/zip/ZipFile.java Thu May 19 17:10:12 2016 +0200 +++ b/src/java.base/share/classes/java/util/zip/ZipFile.java Thu May 19 17:12:54 2016 +0200 @@ -31,11 +31,9 @@ import java.io.EOFException; import java.io.File; import java.io.RandomAccessFile; -import java.lang.ref.WeakReference; import java.nio.charset.Charset; import java.nio.charset.StandardCharsets; import java.nio.file.attribute.BasicFileAttributes; -import java.nio.file.Path; import java.nio.file.Files; import java.util.ArrayList; @@ -43,21 +41,18 @@ import java.util.Enumeration; import java.util.HashMap; import java.util.Iterator; -import java.util.Map; import java.util.Objects; import java.util.NoSuchElementException; import java.util.Spliterator; import java.util.Spliterators; import java.util.WeakHashMap; import java.util.concurrent.atomic.AtomicBoolean; -import java.util.concurrent.atomic.AtomicReference; import java.util.stream.Stream; import java.util.stream.StreamSupport; import jdk.internal.misc.JavaUtilZipFileAccess; import jdk.internal.misc.SharedSecrets; import jdk.internal.perf.PerfCounter; -import static java.util.zip.ZipConstants.*; import static java.util.zip.ZipConstants64.*; import static java.util.zip.ZipUtils.*; @@ -370,7 +365,7 @@ private boolean eof = false; ZipFileInflaterInputStream(ZipFileInputStream zfin, int size) { - super(zfin, getInflater(), size); + super(zfin, new Inflater(true), size, true); } public void close() throws IOException { @@ -379,7 +374,6 @@ synchronized (streams) { streams.remove(this); } - releaseInflater(inf); } } @@ -408,72 +402,6 @@ ? Integer.MAX_VALUE : (int) avail; } - - protected void finalize() throws Throwable { - close(); - } - } - - /** - * A "pooled" inflater. The weak reference does not prevent finalization - * of the Inflater, but if get() returns non-null, then the referent is - * surely not yet eligible for finalization (which would otherwise be a - * rich source of bugs). - */ - static class CachedInflater extends WeakReference { - final AtomicBoolean inUse; - CachedInflater(Inflater inf, boolean inUse) { - super(inf); - this.inUse = new AtomicBoolean(inUse); - } - } - - /** - * Cache of Inflaters. We use a simple one-element "pool". - * Performance measurements show that it's barely profitable to - * cache an Inflater (which consumes around 32kb of native memory) - * while iterating through a zip file and decompressing many small - * entries. - */ - private static final AtomicReference inflaterCache - = new AtomicReference<>(new CachedInflater(new Inflater(true), false)); - - /** - * Returns an Inflater, either a new one, or cached and reset. - */ - private static Inflater getInflater() { - CachedInflater cachedInflater = inflaterCache.get(); - Inflater inf = cachedInflater.get(); - if (inf == null) { - inf = new Inflater(true); - // attempt to install as the new cache, but failure is OK. - inflaterCache.compareAndSet(cachedInflater, - new CachedInflater(inf, true)); - return inf; - } else if (!cachedInflater.inUse.get() - && cachedInflater.inUse.compareAndSet(false, true)) { - assert !inf.ended(); - // we now "own" this Inflater, but must keep it weakly referenced. - return inf; - } else { - return new Inflater(true); - } - } - - /** - * Releases the Inflater for possible later reuse. - */ - private static void releaseInflater(Inflater inf) { - assert !inf.ended(); - CachedInflater cachedInflater = inflaterCache.get(); - if (inf != cachedInflater.get()) { - inf.end(); - } else { - // "return" the Inflater to the "pool". - inf.reset(); - assert cachedInflater.inUse.get(); - cachedInflater.inUse.set(false); - } } /** @@ -804,10 +732,6 @@ } } } - - protected void finalize() { - close(); - } } static { Regards, Peter On 05/19/2016 05:00 PM, Martin Buchholz wrote: > On Thu, May 19, 2016 at 7:29 AM, Peter Levart wrote: >> But I have reservation for the implementation of one-element global cache of >> Inflater. This cache can't be efficient. In order for cache to be efficient, >> majority of calls to ZipFile.getInputStream(zipEntry) would have to be >> accompanied by a corresponding explicit close() for the input stream before >> the WeakReference to the cached Inflater is cleared. > That's my assumption. In most cases, failure to close something that > can be closed is a bug. > If there's code in the JDK that fails to do that, it should be fixed > independently. > >> The "assert !inf.ended()" in >> releaseInflater() can therefore fail as final() methods on individual >> objects that are eligible for finalization may be invoked in arbitrary >> order. > Yeah, that's a bug. We can only assert after we verify that the > Inflater is still weakly reachable. > Updating my webrev with: > > * Releases the Inflater for possible later reuse. > */ > private static void releaseInflater(Inflater inf) { > - assert !inf.ended(); > CachedInflater cachedInflater = inflaterCache.get(); > if (inf != cachedInflater.get()) { > inf.end(); > } else { > // "return" the Inflater to the "pool". > + assert !inf.ended(); > inf.reset(); > assert cachedInflater.inUse.get(); > cachedInflater.inUse.set(false); From daniel.fuchs at oracle.com Thu May 19 15:20:37 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 19 May 2016 17:20:37 +0200 Subject: Review request for JDK-8156575: Add jdeps -addmods, -system, -inverse options In-Reply-To: <8C15B5A6-0E24-44C3-9788-F21D0D5B6BAB@oracle.com> References: <6D81F159-5607-4BDA-94AB-6C9FD0FF1BD8@oracle.com> <113b916e-7c89-179c-5140-170db1c40811@oracle.com> <8C15B5A6-0E24-44C3-9788-F21D0D5B6BAB@oracle.com> Message-ID: Hi Mandy, I played with that a bit (-I/-addmods) and it looks good. 92 main.opt.I=\ 93 \ -I -inverse Analyzes the dependences per other given options\n\ 94 \ and then find all artifacts that directly\n\ 95 \ and indirectly depend on the matching nodes.\n\ 96 \ This is equivalent to the inverse of\n\ 97 \ compile-time view analysis and print\n\ 98 \ dependency summary. This option must use\n\ 99 \ with -requires, -package or -regex option. Maybe it would be useful to clarify that the 'artifacts' found by the -I option are jars and modules (not classes and packages). That was not clear for me when I started playing with it, until you explained it. Also it's not clear if there's any difference between -m and -addmods (if you give a single module to addmods). Maybe there isn't and maybe it's fine. No need for a new webrev - I'll let you decide whether you want to bring in the above clarifications... best regards, -- daniel On 14/05/16 06:48, Mandy Chung wrote: > Daniel, > > I have added more tests and fixed a few issues > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8156575/webrev.02/ > > I also created a test case similar to yours. > > This patch applies on top of: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8156680/webrev.02/ > > for JDK-8156680: jdeps implementation refresh > > Thanks > Mandy > From paul.sandoz at oracle.com Thu May 19 16:06:42 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 19 May 2016 18:06:42 +0200 Subject: Helpers for MethodHandles.byteArrayViewVarHandle VarHandle In-Reply-To: References: Message-ID: > On 19 May 2016, at 16:26, Jaroslav Kamen?k wrote: > > > There certainly is in nio buffer sources (and may be for encoding/decoding in other areas, i am speculating as i have not looked), but for buffer sources we can actually remove much if not all of Bits.java via use of the internal Unsafe unaligned accessors. > > I made some notes when I was looking at it, I am attaching it if you want look at it. > Thanks, that is helpful. > > getLongFrom[LE/BE](byte[] data, int firstByteIndex) - for direct access > > getLongFrom[LE/BE](byte[] data, int firstByteOffset, int longArrayIndex) - for loops/shifted array access > > > > etc. > > I was proposing just the latter, and just for VarHandles :-) it?s not just for loops but also to bring alignment issues to the foreground. (It also it fits in with something we have been pondering about for the unsafe unaligned accessors on systems that don?t support unaligned access, such as SPARC). > > What do you mean by 'just for VarHandles'? Add it between VarHandle methods? > I meant change the shape of the VarHandle produced by: MethodHandles.byteArrayViewVarHandle MethodHandles.byteBufferViewVarHandle The problem is feature complete is very close and it will be hard, but not impossible, to make changes afterwards. Paul. > > Jaroslav > > > > From peter.levart at gmail.com Thu May 19 16:13:27 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 19 May 2016 18:13:27 +0200 Subject: Cleaner cleanup In-Reply-To: References: <8b4dd573-da7b-fd6c-eb49-24f2b15a11cc@gmail.com> <332C5AD1-F421-41D3-A416-BE883BBC9334@noctarius.com> Message-ID: Hi Roger, Here's the same webrev with an example of use of WeakCleanable that I have been thinking to propose later (I have done this in 5 minutes): http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner.cleanup/webrev_with_ClassLoader_exmaple/ This example uses WeakCleanable as a lightweight cleanup mechanism that removes entries from ClassLoader's lock map as soon as they are not needed any more - usually this is immediately after the class has been loaded. This keeps the map size from growing and has a nice impact on final VM footprint. So the question is whether it is worth keeping those superclass(es) for such and similar cases. It's not difficult to add them back if/when needed. The most work is in the test. Regards, Peter On 05/19/2016 03:23 PM, Roger Riggs wrote: > > Hi, > > I haven't had time to look into this thoroughly, but since the > at-most-once semantics > have been removed from the Phantom|Weak|SoftCleanable classes and they > are not > used anywhere, they should be completely removed also, completing the > cleanup. > > The only function being used (except by the tests) is the primary > support for Cleaner.register(). > > Roger > > On 5/19/2016 6:35 AM, Christoph Engelbert wrote: >> Hey Peter, >> >> I just realized, there are two mistakes in the Javadoc code example >> inside the Cleaner Javadoc: >> >> private final State; -> private final Statestate; >> private final Cleaner.Cleanable cleanable -> private final Cleaner.Cleanable cleanable; >> >> Chris >> >>> On 16 May 2016, at 00:08, Peter Levart wrote: >>> >>> Hi Roger and others, >>> >>> When the new Cleaner API was created the implementation of >>> Cleanable(s) was split into the low-level abstract >>> [Soft|Weak|Phantom]Cleanable classes to be used internally for >>> purposes where the footprint matters and their corresponding >>> CleanerImpl.[Soft|Weak|Phantom]CleanableRef subclasses used as >>> implementations that take a Runnable cleanup action and are exposed >>> via the public Cleaner API. >>> >>> When thinking of possible JDK internal use cases for the low-level >>> API, I came to the conclusion that [Soft|Weak|Phantom]Cleanable >>> classes are not suitable as is, because in cases where footprint >>> matters, it is usually also the case that the number of >>> [Soft|Weak|Phantom]Cleanable instances created is larger and that >>> construction performance also matters. Especially multi-threaded >>> construction. I'm thinking of the use cases of auto-cleanable >>> concurrent data structures. In such use cases, the present features >>> of [Soft|Weak|Phantom]Cleanable classes, namely the guaranteed >>> just-once cleanup action invocation and keeping the Cleanable >>> instance reachable until the cleanup action is performed, are >>> actually not needed and just present footprint and performance >>> (contention) overhead. They also present an overhead as they don't >>> allow GC to automatically collect the Cleanable instances if the >>> data structure containing them becomes unreachable and corresponding >>> registered cleanup actions obsolete. >>> >>> The mentioned features are important for public Cleaner.Cleanable >>> instances as they are usually used for cleanup of native resources >>> where the performance of their creation is not so drastically >>> important and where there is no intrinsic data structure to hold >>> them reachable. >>> >>> I propose to move those features from the >>> [Soft|Weak|Phantom]Cleanable classes down the hierarchy to the >>> CleanerImpl.[Soft|Weak|Phantom]CleanableRef subclasses: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Cleaner.cleanup/webrev.01/ >>> >>> >>> >>> In this change I also removed the >>> CleanerImpl.[Soft|Weak]CleanableRef subclasses as they are not >>> needed and I believe will never be. I also renamed the >>> CleanerImpl.PhantomCleanableRef subclass to >>> CleanerImpl.PhantomCleanableImpl. >>> >>> Changes to the implementation are straightforward. The most work was >>> put into the corresponding test. I did some clean-up to it and also >>> changed it to accommodate for the new behavior of >>> [Soft|Weak|Phantom]Cleanable classes. The changes speak for itself. >>> One of the not-so obvious changes was to replace the >>> CleanableCase.clearRef() action with the >>> CleanableCase.releaseReferent() action. The old clearRef() action >>> did not serve any purpose. Whether this method was called or not, >>> the behavior of the corresponding Cleanable was unchanged as the >>> Reference instance (referenced from the 'ref' field) was always of >>> the same strength as the Cleanable itself. So clearing it could not >>> affect the behavior of the Cleanable. >>> >>> I changed 'ref' to hold a direct reference to the referent and >>> renamed the field to 'referent'. I changed the EV_XXX int constants >>> to Event enum constants with helper methods used in >>> CleanableCase.expectedCleanups() method that now returns the number >>> of expected cleanup invocations - in the PhantomCleanableImpl case >>> this is the number of expected cleanup action invocations while in >>> the plain XxxCleanable subclass cases it is the number of >>> Cleanable.clean() method invocations. I added the no-actions case to >>> both PhantomCleanableImpl and XxxCleanable cases and extended the >>> number and combinations of XxxCleanable cases. >>> >>> The checkCleaned() method was extended to verify that the number of >>> cleanup invocations is *no more* and no less then the expected. >>> >>> See how WeakKey test is now simplified. This is the typical use-case >>> for WeakCleanable I was talking about. >>> >>> >>> So, what do you think of this cleanup? >>> >>> >>> Regards, Peter >>> >> > From xueming.shen at oracle.com Thu May 19 16:31:33 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 19 May 2016 09:31:33 -0700 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: References: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> Message-ID: <8abc7743-2b54-297d-7f89-acf252dc6c9d@oracle.com> Martin, Given we now only cache one deflater per Zip/JarFile object, is WeakReference here really necessary? Basically wr is based on the vm heap memory and deflater is a native memory, arguably we are using the wrong measurement to decide whether or not to give up the deflater's native memory. Given someone (classloader) is keeping hundreds and thousands of jar/zip files alive, is it reasonable to assume it'd better to keep the 32k cache for each of them? -Sherman On 5/19/16 8:00 AM, Martin Buchholz wrote: > On Thu, May 19, 2016 at 7:29 AM, Peter Levart wrote: >> But I have reservation for the implementation of one-element global cache of >> Inflater. This cache can't be efficient. In order for cache to be efficient, >> majority of calls to ZipFile.getInputStream(zipEntry) would have to be >> accompanied by a corresponding explicit close() for the input stream before >> the WeakReference to the cached Inflater is cleared. > That's my assumption. In most cases, failure to close something that > can be closed is a bug. > If there's code in the JDK that fails to do that, it should be fixed > independently. > >> The "assert !inf.ended()" in >> releaseInflater() can therefore fail as final() methods on individual >> objects that are eligible for finalization may be invoked in arbitrary >> order. > Yeah, that's a bug. We can only assert after we verify that the > Inflater is still weakly reachable. > Updating my webrev with: > > * Releases the Inflater for possible later reuse. > */ > private static void releaseInflater(Inflater inf) { > - assert !inf.ended(); > CachedInflater cachedInflater = inflaterCache.get(); > if (inf != cachedInflater.get()) { > inf.end(); > } else { > // "return" the Inflater to the "pool". > + assert !inf.ended(); > inf.reset(); > assert cachedInflater.inUse.get(); > cachedInflater.inUse.set(false); From peter.levart at gmail.com Thu May 19 16:49:20 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 19 May 2016 18:49:20 +0200 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: <8abc7743-2b54-297d-7f89-acf252dc6c9d@oracle.com> References: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> <8abc7743-2b54-297d-7f89-acf252dc6c9d@oracle.com> Message-ID: <0a49f1f8-4cbd-99e3-fcb0-95be60d1b7a3@gmail.com> On 05/19/2016 06:31 PM, Xueming Shen wrote: > > Martin, > > Given we now only cache one deflater per Zip/JarFile object, is > WeakReference here really > necessary? Basically wr is based on the vm heap memory and deflater is > a native memory, > arguably we are using the wrong measurement to decide whether or not > to give up the > deflater's native memory. Given someone (classloader) is keeping > hundreds and thousands > of jar/zip files alive, is it reasonable to assume it'd better to keep > the 32k cache for each > of them? It would perhaps make more sense to keep a 32k native object for each thread - not each jar file, don't you think? Regards, Peter > > -Sherman > > On 5/19/16 8:00 AM, Martin Buchholz wrote: >> On Thu, May 19, 2016 at 7:29 AM, Peter Levart >> wrote: >>> But I have reservation for the implementation of one-element global >>> cache of >>> Inflater. This cache can't be efficient. In order for cache to be >>> efficient, >>> majority of calls to ZipFile.getInputStream(zipEntry) would have to be >>> accompanied by a corresponding explicit close() for the input stream >>> before >>> the WeakReference to the cached Inflater is cleared. >> That's my assumption. In most cases, failure to close something that >> can be closed is a bug. >> If there's code in the JDK that fails to do that, it should be fixed >> independently. >> >>> The "assert !inf.ended()" in >>> releaseInflater() can therefore fail as final() methods on individual >>> objects that are eligible for finalization may be invoked in arbitrary >>> order. >> Yeah, that's a bug. We can only assert after we verify that the >> Inflater is still weakly reachable. >> Updating my webrev with: >> >> * Releases the Inflater for possible later reuse. >> */ >> private static void releaseInflater(Inflater inf) { >> - assert !inf.ended(); >> CachedInflater cachedInflater = inflaterCache.get(); >> if (inf != cachedInflater.get()) { >> inf.end(); >> } else { >> // "return" the Inflater to the "pool". >> + assert !inf.ended(); >> inf.reset(); >> assert cachedInflater.inUse.get(); >> cachedInflater.inUse.set(false); > > From mandy.chung at oracle.com Thu May 19 17:47:37 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 May 2016 10:47:37 -0700 Subject: Review request for JDK-8156575: Add jdeps -addmods, -system, -inverse options In-Reply-To: References: <6D81F159-5607-4BDA-94AB-6C9FD0FF1BD8@oracle.com> <113b916e-7c89-179c-5140-170db1c40811@oracle.com> <8C15B5A6-0E24-44C3-9788-F21D0D5B6BAB@oracle.com> Message-ID: <22DF54BD-218F-46DE-AC13-9B8FB0EF92FB@oracle.com> > On May 19, 2016, at 8:20 AM, Daniel Fuchs wrote: > > Hi Mandy, > > I played with that a bit (-I/-addmods) and it looks good. > > 92 main.opt.I=\ > 93 \ -I -inverse Analyzes the dependences per other given options\n\ > 94 \ and then find all artifacts that directly\n\ > 95 \ and indirectly depend on the matching nodes.\n\ > 96 \ This is equivalent to the inverse of\n\ > 97 \ compile-time view analysis and print\n\ > 98 \ dependency summary. This option must use\n\ > 99 \ with -requires, -package or -regex option. > > Maybe it would be useful to clarify that the 'artifacts' > found by the -I option are jars and modules (not classes and packages). > That was not clear for me when I started playing with it, until > you explained it. > -ct -compile-time Compile-time view of transitive dependencies i.e. compile-time view of -R option. Analyzes the dependences per other given options If a dependence is found from a directory, a JAR file or a module, all classes in that containing archive are analyzed. This defines what compile-time view analysis means. > Also it's not clear if there's any difference between > -m and > -addmods > (if you give a single module to addmods). > Maybe there isn't and maybe it's fine. > -m specifies the root module to be analyzed. In some cases, you will need to specify -addmods to include more modules in the graph for analysis or needed for the resolution (e.g. java.se.ee is not in the default policy as specified in JEP 261). > No need for a new webrev - I'll let you decide whether you want > to bring in the above clarifications... Thanks. I?ll push as is and we could tweak the help message as a follow-up issue. Mandy From jaroslav at kamenik.cz Thu May 19 18:36:34 2016 From: jaroslav at kamenik.cz (=?UTF-8?Q?Jaroslav_Kamen=C3=ADk?=) Date: Thu, 19 May 2016 20:36:34 +0200 Subject: Helpers for MethodHandles.byteArrayViewVarHandle VarHandle In-Reply-To: References: Message-ID: > > I meant change the shape of the VarHandle produced by: > > MethodHandles.byteArrayViewVarHandle > MethodHandles.byteBufferViewVarHandle > Aaaha:) I must say, one reason, why I'd like to have it wrapped is that VarHandle.get/set do not have fixed typed signature. Helper.longAt(arr, index) looks much better than SOME_STRANGE_CONSTANT.get(i can write here what I want and compiler says nothing:); > The problem is feature complete is very close and it will be hard, but not > impossible, to make changes afterwards. > I should have started to write here earlier;). So, what will we do with it? Jaroslav From iris.clark at oracle.com Thu May 19 19:42:53 2016 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 19 May 2016 12:42:53 -0700 (PDT) Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version In-Reply-To: <0452bb32-8bd4-4236-83e9-912f9055ddbc@default> References: <29AA7813-44E0-4BB1-937E-1BCAB46F9367@oracle.com> <0452bb32-8bd4-4236-83e9-912f9055ddbc@default> Message-ID: <54fe3060-f264-4cc1-8a5c-be0cc1b0f2d0@default> Hi, Mandy. Thank you so much for pushing the changesets [0,1] for this bug. Regards, Iris [0]: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3976fadb091d [1]: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2a49d47a37d8 From martinrb at google.com Thu May 19 19:56:40 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 19 May 2016 12:56:40 -0700 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: <0a49f1f8-4cbd-99e3-fcb0-95be60d1b7a3@gmail.com> References: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> <8abc7743-2b54-297d-7f89-acf252dc6c9d@oracle.com> <0a49f1f8-4cbd-99e3-fcb0-95be60d1b7a3@gmail.com> Message-ID: Peter and Sherman, I'm still quixotic fighting java memory bloat. Caching Inflaters at all is only barely profitable; a one-element Inflater cache is probably fine for those apps that occasionally iterate through the classpath. I don't want ThreadLocal bloat; I want _all_ the Inflaters to go away by themselves after a while e.g. in a long-running server. I'm open to having the cache contain more than one element, as long as they go away eventually. If so, I would choose a design based on linked nodes, still with a WeakReference to make them go away. On Thu, May 19, 2016 at 9:49 AM, Peter Levart wrote: > > > On 05/19/2016 06:31 PM, Xueming Shen wrote: > > > Martin, > > Given we now only cache one deflater per Zip/JarFile object, is > WeakReference here really > necessary? Basically wr is based on the vm heap memory and deflater is a > native memory, > arguably we are using the wrong measurement to decide whether or not to give > up the > deflater's native memory. Given someone (classloader) is keeping hundreds > and thousands > of jar/zip files alive, is it reasonable to assume it'd better to keep the > 32k cache for each > of them? > > > It would perhaps make more sense to keep a 32k native object for each thread > - not each jar file, don't you think? > > Regards, Peter > > > > -Sherman > > On 5/19/16 8:00 AM, Martin Buchholz wrote: > > On Thu, May 19, 2016 at 7:29 AM, Peter Levart > wrote: > > But I have reservation for the implementation of one-element global cache of > Inflater. This cache can't be efficient. In order for cache to be efficient, > majority of calls to ZipFile.getInputStream(zipEntry) would have to be > accompanied by a corresponding explicit close() for the input stream before > the WeakReference to the cached Inflater is cleared. > > That's my assumption. In most cases, failure to close something that > can be closed is a bug. > If there's code in the JDK that fails to do that, it should be fixed > independently. > > The "assert !inf.ended()" in > releaseInflater() can therefore fail as final() methods on individual > objects that are eligible for finalization may be invoked in arbitrary > order. > > Yeah, that's a bug. We can only assert after we verify that the > Inflater is still weakly reachable. > Updating my webrev with: > > * Releases the Inflater for possible later reuse. > */ > private static void releaseInflater(Inflater inf) { > - assert !inf.ended(); > CachedInflater cachedInflater = inflaterCache.get(); > if (inf != cachedInflater.get()) { > inf.end(); > } else { > // "return" the Inflater to the "pool". > + assert !inf.ended(); > inf.reset(); > assert cachedInflater.inUse.get(); > cachedInflater.inUse.set(false); > > > > From chris.hegarty at oracle.com Thu May 19 21:20:38 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 19 May 2016 22:20:38 +0100 Subject: RFR [9] 8157154: jmod jlink properties file need copyright header Message-ID: <13E22208-30BF-4212-B44D-FFADE30989D8@oracle.com> Quite trivially, the copyright headers were omitted from these new property files. This review request simply adds the standard header to: jdk/src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties jdk/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties jdk/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties jdk/src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties -Chris. $ hg diff diff --git a/src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties b/src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties --- a/src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties +++ b/src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties @@ -1,3 +1,28 @@ +# +# Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. +# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. +# +# This code is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License version 2 only, as +# published by the Free Software Foundation. Oracle designates this +# particular file as subject to the "Classpath" exception as provided +# by Oracle in the LICENSE file that accompanied this code. +# +# This code is distributed in the hope that it will be useful, but WITHOUT +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or +# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +# version 2 for more details (a copy is included in the LICENSE file that +# accompanied this code). +# +# You should have received a copy of the GNU General Public License version +# 2 along with this work; if not, write to the Free Software Foundation, +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. +# +# Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA +# or visit www.oracle.com if you need additional information or have any +# questions. +# + main.usage.summary=\ Usage: {0} jimage...\n\ use --help for a list of possible options diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties b/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties @@ -1,3 +1,28 @@ +# +# Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. +# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. +# +# This code is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License version 2 only, as +# published by the Free Software Foundation. Oracle designates this +# particular file as subject to the "Classpath" exception as provided +# by Oracle in the LICENSE file that accompanied this code. +# +# This code is distributed in the hope that it will be useful, but WITHOUT +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or +# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +# version 2 for more details (a copy is included in the LICENSE file that +# accompanied this code). +# +# You should have received a copy of the GNU General Public License version +# 2 along with this work; if not, write to the Free Software Foundation, +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. +# +# Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA +# or visit www.oracle.com if you need additional information or have any +# questions. +# + main.usage.summary=\ Usage: {0} --modulepath --addmods --output \n\ use --help for a list of possible options diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties b/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties @@ -1,3 +1,28 @@ +# +# Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. +# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. +# +# This code is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License version 2 only, as +# published by the Free Software Foundation. Oracle designates this +# particular file as subject to the "Classpath" exception as provided +# by Oracle in the LICENSE file that accompanied this code. +# +# This code is distributed in the hope that it will be useful, but WITHOUT +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or +# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +# version 2 for more details (a copy is included in the LICENSE file that +# accompanied this code). +# +# You should have received a copy of the GNU General Public License version +# 2 along with this work; if not, write to the Free Software Foundation, +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. +# +# Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA +# or visit www.oracle.com if you need additional information or have any +# questions. +# + release-info.argument=|add:=:=:...|del: release-info.description=\ diff --git a/src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties b/src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties --- a/src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties +++ b/src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties @@ -1,3 +1,28 @@ +# +# Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. +# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. +# +# This code is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License version 2 only, as +# published by the Free Software Foundation. Oracle designates this +# particular file as subject to the "Classpath" exception as provided +# by Oracle in the LICENSE file that accompanied this code. +# +# This code is distributed in the hope that it will be useful, but WITHOUT +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or +# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +# version 2 for more details (a copy is included in the LICENSE file that +# accompanied this code). +# +# You should have received a copy of the GNU General Public License version +# 2 along with this work; if not, write to the Free Software Foundation, +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. +# +# Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA +# or visit www.oracle.com if you need additional information or have any +# questions. +# + main.usage.summary=\ Usage: {0} (create|list|describe|hash) \n\ use --help for a list of possible options From mandy.chung at oracle.com Thu May 19 21:26:01 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 May 2016 14:26:01 -0700 Subject: RFR [9] 8157154: jmod jlink properties file need copyright header In-Reply-To: <13E22208-30BF-4212-B44D-FFADE30989D8@oracle.com> References: <13E22208-30BF-4212-B44D-FFADE30989D8@oracle.com> Message-ID: Should the start year be 2015? You can fix up before you push. Mandy > On May 19, 2016, at 2:20 PM, Chris Hegarty wrote: > > Quite trivially, the copyright headers were omitted from these new > property files. This review request simply adds the standard header > to: > > jdk/src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties > jdk/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties > jdk/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties > jdk/src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties > > -Chris. > From chris.hegarty at oracle.com Thu May 19 21:56:51 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 19 May 2016 22:56:51 +0100 Subject: RFR [9] 8157154: jmod jlink properties file need copyright header In-Reply-To: References: <13E22208-30BF-4212-B44D-FFADE30989D8@oracle.com> Message-ID: <169A0963-10CE-412C-B6BC-7AC035A5065D@oracle.com> Yes of course. I'll add the year range before pushing. -Chris > On 19 May 2016, at 22:26, Mandy Chung wrote: > > Should the start year be 2015? You can fix up before you push. > > Mandy > >> On May 19, 2016, at 2:20 PM, Chris Hegarty wrote: >> >> Quite trivially, the copyright headers were omitted from these new >> property files. This review request simply adds the standard header >> to: >> >> jdk/src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties >> jdk/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties >> jdk/src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties >> jdk/src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties >> >> -Chris. >> > From martinrb at google.com Thu May 19 22:04:04 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 19 May 2016 15:04:04 -0700 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> References: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> Message-ID: Hi Peter, I would make e.g. the change to Resource an independent change. Below you declare that you throw IOException, but you actually swallow it, which is not good. /** + * Closes cached input stream used for getBytes / getByteBuffer + * @throws IOException + */ + @Override + public synchronized void close() { From huizhe.wang at oracle.com Thu May 19 22:35:55 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 19 May 2016 15:35:55 -0700 Subject: RFR (JAXP) 8139585: Typo: "APIi" instead of "API" Message-ID: <573E3FCB.6030105@oracle.com> Hi, Replaced the texts with the titles of the documents they are referring to. JBS: https://bugs.openjdk.java.net/browse/JDK-8139585 Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8139585/webrev/ Thanks, Joe From mandy.chung at oracle.com Thu May 19 22:44:23 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 May 2016 15:44:23 -0700 Subject: RFR (JAXP) 8139585: Typo: "APIi" instead of "API" In-Reply-To: <573E3FCB.6030105@oracle.com> References: <573E3FCB.6030105@oracle.com> Message-ID: <289443E5-E52C-4786-B4BC-A02CBB5F82BC@oracle.com> > On May 19, 2016, at 3:35 PM, huizhe wang wrote: > > Hi, > > Replaced the texts with the titles of the documents they are referring to. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8139585 > Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8139585/webrev/ +1 Mandy From huizhe.wang at oracle.com Thu May 19 23:16:04 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 19 May 2016 16:16:04 -0700 Subject: RFR (JAXP) 8139585: Typo: "APIi" instead of "API" In-Reply-To: <289443E5-E52C-4786-B4BC-A02CBB5F82BC@oracle.com> References: <573E3FCB.6030105@oracle.com> <289443E5-E52C-4786-B4BC-A02CBB5F82BC@oracle.com> Message-ID: <573E4934.2010604@oracle.com> Thanks Mandy! Joe On 5/19/2016 3:44 PM, Mandy Chung wrote: >> On May 19, 2016, at 3:35 PM, huizhe wang wrote: >> >> Hi, >> >> Replaced the texts with the titles of the documents they are referring to. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8139585 >> Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8139585/webrev/ > +1 > > Mandy > From mandy.chung at oracle.com Thu May 19 23:50:23 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 May 2016 16:50:23 -0700 Subject: Review request: 8152502: tools/jdeps/modules/GenModuleInfo.java and TransitiveDeps fails on windows Message-ID: These jdeps tests fails running on windows ?Error. failed clean up files after test?. A bug in the tests and implementation that calls Files.walk without try-with-resources. Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152502/webrev.00/index.html This fix calls Files::walk with try-with-resources. I wasn?t quite able to reproduce the error on my windows machine. I?d like to push this fix and address any issue, if any. Mandy From jonathan.gibbons at oracle.com Thu May 19 23:55:32 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 19 May 2016 16:55:32 -0700 Subject: Review request: 8152502: tools/jdeps/modules/GenModuleInfo.java and TransitiveDeps fails on windows In-Reply-To: References: Message-ID: <573E5274.5070505@oracle.com> Looks good to me. -- Jon On 05/19/2016 04:50 PM, Mandy Chung wrote: > These jdeps tests fails running on windows ?Error. failed clean up files after test?. A bug in the tests and implementation that calls Files.walk without try-with-resources. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152502/webrev.00/index.html > > This fix calls Files::walk with try-with-resources. I wasn?t quite able to reproduce the error on my windows machine. I?d like to push this fix and address any issue, if any. > > Mandy From martinrb at google.com Fri May 20 00:51:51 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 19 May 2016 17:51:51 -0700 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> References: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> Message-ID: On Thu, May 19, 2016 at 7:29 AM, Peter Levart wrote: > So Martin, what do you think? I studied your code and we are fundamentally in agreement! ... Except for need for periodic cleanup of the cache... Maybe we should do CompletableFuture.runAsync(purgeCache, CompletableFuture.delayedExecutor(1, SECONDS)) as a periodic task while cache is non-empty instead of my strategy of relying on a weak reference. Purging a cache on quiescence in the optimal way seems to be a hard problem. Time to write ObjectPool (as many others have done before us)? ObjectPool(Supplier factory, Consumer releaser, maxCacheSize, keepAliveTime) Except this time we'll do it right! With jdk9 machinery! From xueming.shen at oracle.com Fri May 20 02:21:52 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 19 May 2016 19:21:52 -0700 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: References: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> Message-ID: <7f90b5b4-a05f-4482-5078-3b6fe1ca560f@oracle.com> On 5/19/16 5:51 PM, Martin Buchholz wrote: > On Thu, May 19, 2016 at 7:29 AM, Peter Levart wrote: >> So Martin, what do you think? > I studied your code and we are fundamentally in agreement! > ... Except for need for periodic cleanup of the cache... > Maybe we should do > CompletableFuture.runAsync(purgeCache, > CompletableFuture.delayedExecutor(1, SECONDS)) > as a periodic task while cache is non-empty instead of my strategy of > relying on a weak reference. > > Purging a cache on quiescence in the optimal way seems to be a hard problem. > Time to write ObjectPool (as many others have done before us)? > > ObjectPool(Supplier factory, Consumer releaser, maxCacheSize, > keepAliveTime) > > Except this time we'll do it right! With jdk9 machinery! personally i agree a non-weak-reference based solution is attractive here :-) From mandy.chung at oracle.com Fri May 20 03:55:56 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 May 2016 20:55:56 -0700 Subject: Review Request: 8157391: jdeps left JarFile open Message-ID: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157391/webrev.00/index.html tools/jdeps/modules/GenModuleInfo.java tools/jdeps/modules/TransitiveDeps.java tools/jdeps/modules/InverseDeps.java These tests still failed on windows after JDK-8152502. Now I have the jtreg logs showing that JAR files can?t be deleted although I still can?t reproduce them locally and on JPRT (will find out what?s the difference tomorrow). Mandy From martinrb at google.com Fri May 20 04:07:32 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 19 May 2016 21:07:32 -0700 Subject: Review Request: 8157391: jdeps left JarFile open In-Reply-To: References: Message-ID: We should have a debugging version of the JDK that fails whenever an AutoCloseable object is not properly closed in JDK code! On Thu, May 19, 2016 at 8:55 PM, Mandy Chung wrote: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157391/webrev.00/index.html > > tools/jdeps/modules/GenModuleInfo.java > tools/jdeps/modules/TransitiveDeps.java > tools/jdeps/modules/InverseDeps.java > > These tests still failed on windows after JDK-8152502. > > Now I have the jtreg logs showing that JAR files can?t be deleted although I still can?t reproduce them locally and on JPRT (will find out what?s the difference tomorrow). > > Mandy From mandy.chung at oracle.com Fri May 20 04:21:46 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 May 2016 21:21:46 -0700 Subject: Review request 8153042: jdeps should continue to report JDK internal APIs that are removed/renamed in JDK 9 Message-ID: <61802595-0131-43E3-B868-FD9C5EF1CC4E@oracle.com> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153042/webrev.00/index.html Several JDK internal APIs have been removed JDK 9. It?d be helpful to continue to flag those internal APIs if they are used by existing libraries. This fix is an interim solution. A longer-term solution may be for jdeps to support -release option (something for the future). Mandy From huaming.li at oracle.com Fri May 20 05:40:56 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 20 May 2016 13:40:56 +0800 Subject: JDK 9 RFR of JDK-8151904: test/java/lang/StackWalker/VerifyStackTrace.java needs to handle update releases Message-ID: <573EA368.2060203@oracle.com> The test currently hardcodes the version number "9". We should build a JDK with a different release number e.g. 9.1 and checks if this test handles it properly. Test run successfully on 9-ea+118, dummybundles(9-ea+255, 9.1-ea+255, 9.0.1-ea+255, 9.0.0.1-ea+255). bug: https://bugs.openjdk.java.net/browse/JDK-8151904 webrev: http://cr.openjdk.java.net/~mli/8151904/webrev.00/ Thank you -Hamlin From joe.darcy at oracle.com Fri May 20 05:42:37 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 19 May 2016 22:42:37 -0700 Subject: [PING] Re: [9] RFR of 8023217: Additional floorDiv/floorMod/multiplyExact methods for java.lang.Math In-Reply-To: <58C4BA23-BF2F-4264-8FF3-057AE0A291B9@oracle.com> References: <604C9A0D-D55D-4962-A007-D188E9077063@oracle.com> <5609F4CA.2010605@oracle.com> <836DC71E-B3E6-45DE-BDA4-39617AC4CAC4@oracle.com> <108C6774-3965-4340-A448-033B3651E263@oracle.com> <58C4BA23-BF2F-4264-8FF3-057AE0A291B9@oracle.com> Message-ID: Hi Brian, Looks okay; thanks, -Joe On 5/18/2016 12:06 PM, Brian Burkhalter wrote: > Following up on the as yet unresolved thread initiated here: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035468.html > > Thanks, > > Brian > > On Sep 29, 2015, at 5:49 PM, Brian Burkhalter wrote: > >> I revised floorMod(long x, int y) not to check explicitly check for integer overflow as it does not look as if this is even possible. I also updated the appropriate tests for these versions of the three methods at issue. >> >> In testing I still found discrepancies between the existing implementations and the ones suggested earlier in this thread. Therefore those implementations have not been used. If it is desired to move to different implementations at a later date a separate enhancement issue may be filed. >> >> The updated webrev is here: >> >> http://cr.openjdk.java.net/~bpb/8023217/webrev.01/ >> >> Thanks, >> >> Brian >> >> On Sep 29, 2015, at 8:16 AM, Brian Burkhalter wrote: >> >>> On Sep 29, 2015, at 8:05 AM, Stephen Colebourne wrote: >>> >>>>> I tested the code which was in the original issue description and found some >>>>> discrepancies. I?ll need to revisit this to see what happened. >>>> Yes, the code in the issue for floorDiv() fails when the divisor is >>>> negative. The one in my email today works though. >>> Excellent! I?ll double check it as part of the ?fit and finish." From huaming.li at oracle.com Fri May 20 05:48:13 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 20 May 2016 13:48:13 +0800 Subject: JDK 9 RFR of JDK-8157211: Mark tools/launcher/FXLauncherTest.java as intermittently failing In-Reply-To: <573BF504.1000601@oracle.com> References: <573BF504.1000601@oracle.com> Message-ID: <573EA51D.8000800@oracle.com> Would you please help to review the code change? Thank you -Hamlin On 2016/5/18 12:52, Hamlin Li wrote: > tools/launcher/FXLauncherTest.java > This test is known to fail intermittently (JDK-8130392 > ), it should be > marked accordingly with at key intermittentjtreg tag in the test file. > > bug: https://bugs.openjdk.java.net/browse/JDK-8157211 > webrev: http://cr.openjdk.java.net/~mli/8157211/webrev.00/ > > Thank you > -Hamlin > > --- a/test/tools/launcher/FXLauncherTest.java Tue May 17 19:20:05 > 2016 -0700 > +++ b/test/tools/launcher/FXLauncherTest.java Tue May 17 21:44:18 > 2016 -0700 > @@ -29,6 +29,7 @@ > * jfx app class, a main-class for the manifest, a bogus one and none. > * All should execute except the incorrect fx app class entries. > * @run main/othervm FXLauncherTest > + * @key intermittent > */ > import java.io.File; > import java.io.IOException; > > From Alan.Bateman at oracle.com Fri May 20 05:50:29 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 May 2016 06:50:29 +0100 Subject: RFR [9] 8157154: jmod jlink properties file need copyright header In-Reply-To: <169A0963-10CE-412C-B6BC-7AC035A5065D@oracle.com> References: <13E22208-30BF-4212-B44D-FFADE30989D8@oracle.com> <169A0963-10CE-412C-B6BC-7AC035A5065D@oracle.com> Message-ID: <573EA5A5.50002@oracle.com> On 19/05/2016 22:56, Chris Hegarty wrote: > Yes of course. I'll add the year range before pushing. > > -Chris > > Looks fine. There is someone on jdk9-dev with translations of this file where the missing headers came up too. -Alan. From peter.levart at gmail.com Fri May 20 06:25:24 2016 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 20 May 2016 08:25:24 +0200 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: References: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> Message-ID: Hi Martin, On 05/20/2016 12:04 AM, Martin Buchholz wrote: > Hi Peter, > > I would make e.g. the change to Resource an independent change. I agree. It's just that if we measure the impact of ZipFile changes to class loading, for example, we should measure them with this change included so that we get the optimal caching strategy implemented. After we settle on the ZipFile changes, we can strip-off this independent change and propose it separately. > > Below you declare that you throw IOException, but you actually swallow > it, which is not good. > > /** > + * Closes cached input stream used for getBytes / getByteBuffer > + * @throws IOException > + */ > + @Override > + public synchronized void close() { Yes, I forgot to remove the @throws. I think it is OK to swallow the IOException here, as what is currently done, when the input stream(s) are finalized, such IOException(s) are ignored (if they ever get thrown). It's also nothing we can do here since this exception would get thrown after the class has already been defined and we can't propagate the exception or unsuccessful class loading result to the caller after successfully defining the class. Regards, Peter From Alan.Bateman at oracle.com Fri May 20 06:32:37 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 May 2016 07:32:37 +0100 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: References: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> Message-ID: <573EAF85.2020003@oracle.com> On 20/05/2016 07:25, Peter Levart wrote: > Hi Martin, > > > On 05/20/2016 12:04 AM, Martin Buchholz wrote: >> Hi Peter, >> >> I would make e.g. the change to Resource an independent change. > > I agree. It's just that if we measure the impact of ZipFile changes to > class loading, for example, we should measure them with this change > included so that we get the optimal caching strategy implemented. > After we settle on the ZipFile changes, we can strip-off this > independent change and propose it separately. I agree too. Also it would be good to keep the follow on changes to code like BuiltinClassLoader to a minimum as we have quite a few changes come that will replace sections of this. -Alan From Alan.Bateman at oracle.com Fri May 20 06:39:07 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 May 2016 07:39:07 +0100 Subject: Review Request: 8157391: jdeps left JarFile open In-Reply-To: References: Message-ID: <573EB10B.3090202@oracle.com> On 20/05/2016 04:55, Mandy Chung wrote: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157391/webrev.00/index.html > > tools/jdeps/modules/GenModuleInfo.java > tools/jdeps/modules/TransitiveDeps.java > tools/jdeps/modules/InverseDeps.java > > These tests still failed on windows after JDK-8152502. > > Now I have the jtreg logs showing that JAR files can?t be deleted although I still can?t reproduce them locally and on JPRT (will find out what?s the difference tomorrow). > This looks okay to me. One thing you could do in the test is have JdepsUtil.Command be Closeable so that the tests can use try-with-resources and avoid failing with a file open. -Alan. From joe.darcy at oracle.com Fri May 20 06:43:30 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 19 May 2016 23:43:30 -0700 Subject: JDK 9 RFR of JDK-4851777 Add BigDecimal sqrt method Message-ID: Hello, Please review the addition of BigDecimal.sqrt: JDK-4851777 Add BigDecimal sqrt method http://cr.openjdk.java.net/~darcy/4851777.5/ Thanks, -Joe From uschindler at apache.org Fri May 20 07:42:09 2016 From: uschindler at apache.org (Uwe Schindler) Date: Fri, 20 May 2016 09:42:09 +0200 Subject: RFR(M): 8156915: introduce MethodHandle factory for array length In-Reply-To: <52930F20-0F98-40C8-9B61-554F73CE960B@oracle.com> References: <52930F20-0F98-40C8-9B61-554F73CE960B@oracle.com> Message-ID: <00db01d1b26b$1fc9d1e0$5f5d75a0$@apache.org> Hi, I just noticed that there is the @since missing in javadocs: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fd39cefc5c8f#l3.13 arrayConstructor has @since 9, but arrayLength() not. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf Of Michael Haupt > Sent: Wednesday, May 18, 2016 9:53 AM > To: Core-Libs-Dev > Subject: RFR(M): 8156915: introduce MethodHandle factory for array length > > Dear all, > > please review this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8156915 > Webrev: http://cr.openjdk.java.net/~mhaupt/8156915/webrev.00/ > > Thanks, > > Michael > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | LangTools Team | Nashorn > Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, > Germany > > ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D- > 80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering > 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > Oracle is committed to > developing practices and products that help protect the environment From daniel.fuchs at oracle.com Fri May 20 09:18:01 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 20 May 2016 11:18:01 +0200 Subject: Review request 8153042: jdeps should continue to report JDK internal APIs that are removed/renamed in JDK 9 In-Reply-To: <61802595-0131-43E3-B868-FD9C5EF1CC4E@oracle.com> References: <61802595-0131-43E3-B868-FD9C5EF1CC4E@oracle.com> Message-ID: <7ff3f292-9412-a858-030a-2070b859ce1a@oracle.com> On 5/20/16 6:21 AM, Mandy Chung wrote: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153042/webrev.00/index.html > > Several JDK internal APIs have been removed JDK 9. It?d be helpful to continue to flag those internal APIs if they are used by existing libraries. This fix is an interim solution. A longer-term solution may be for jdeps to support -release option (something for the future). > > Mandy > Hi Mandy, This looks reasonable to me. best regards, -- daniel From bhanu.prakash.gopularam at oracle.com Fri May 20 09:22:27 2016 From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam) Date: Fri, 20 May 2016 02:22:27 -0700 (PDT) Subject: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields In-Reply-To: References: <573A9B92.60201@oracle.com> <7bf185b0-ceb0-4329-bb7e-6555383eaa67@default> Message-ID: <39a4cfc7-a245-492d-a684-3b7aba416671@default> Hi Roger, Thanks for the comments. Earlier as part of JDK-8062804 we considered scenarios for support of isofields and non isofields (positive case to check isofield works and negative case to check UnsupportedTemporalTypeException is thrown only. Here is the updated webrev, I have added data check for field.rangeRefinedBy method. http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.02 Please review the changes. Thanks, Bhanu -----Original Message----- From: Roger Riggs Sent: Thursday, May 19, 2016 6:49 PM To: core-libs-dev at openjdk.java.net Subject: Re: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields Hi Bhanu, Can you remind me why the value from line: 459 field.rangeRefinedBy(LocalDate.now()); is not checked also? Is looks odd to see a value passed to a test and not have it verified. It would need to use a fixed date (the same), but that is fine for that test. Thanks, Roger On 5/19/2016 7:16 AM, Stephen Colebourne wrote: > Fine by me > Stephen > > On 19 May 2016 at 11:34, Bhanu Gopularam > wrote: >> Thank you Nadeesh and Stephen. >> >> Here is the updated webrev link: >> http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.01 >> >> Please review. >> >> Bhanu >> >> -----Original Message----- >> From: Stephen Colebourne [mailto:scolebourne at joda.org] >> Sent: Tuesday, May 17, 2016 5:11 PM >> To: core-libs-dev >> Subject: Re: RFR 8156718: Need tests for IsoFields getFrom for >> unsupported non-Iso Temporal fields >> >> I would also like to see the test case methods be named "getFrom" not "getfrom". >> >> Stephen >> >> On 17 May 2016 at 05:18, nadeesh tv wrote: >>> Hi Bhanu, >>> >>> I think you should add a test case comparing the return value of >>> getFrom() >>> >>> ( Not an official reviewer) >>> >>> Regards, >>> Nadeesh >>> >>> On 5/16/2016 11:46 AM, Bhanu Gopularam wrote: >>>> Hi all, >>>> >>>> Could you please review fix for following issue. >>>> >>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8156718 >>>> >>>> Solution: Added tck tests for validating getFrom method for >>>> unsupported non-Iso temporal fields >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.00/ >>>> >>>> Thanks, >>>> Bhanu >>> >>> -- >>> Thanks and Regards, >>> Nadeesh TV >>> From paul.sandoz at oracle.com Fri May 20 10:01:32 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 20 May 2016 12:01:32 +0200 Subject: JDK 9 RFR of JDK-8157211: Mark tools/launcher/FXLauncherTest.java as intermittently failing In-Reply-To: <573EA51D.8000800@oracle.com> References: <573BF504.1000601@oracle.com> <573EA51D.8000800@oracle.com> Message-ID: > On 20 May 2016, at 07:48, Hamlin Li wrote: > > Would you please help to review the code change? > +1 Paul. > Thank you > -Hamlin > > On 2016/5/18 12:52, Hamlin Li wrote: >> tools/launcher/FXLauncherTest.java >> This test is known to fail intermittently (JDK-8130392 ), it should be marked accordingly with at key intermittentjtreg tag in the test file. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8157211 >> webrev: http://cr.openjdk.java.net/~mli/8157211/webrev.00/ >> >> Thank you >> -Hamlin >> >> --- a/test/tools/launcher/FXLauncherTest.java Tue May 17 19:20:05 2016 -0700 >> +++ b/test/tools/launcher/FXLauncherTest.java Tue May 17 21:44:18 2016 -0700 >> @@ -29,6 +29,7 @@ >> * jfx app class, a main-class for the manifest, a bogus one and none. >> * All should execute except the incorrect fx app class entries. >> * @run main/othervm FXLauncherTest >> + * @key intermittent >> */ >> import java.io.File; >> import java.io.IOException; >> >> > From paul.sandoz at oracle.com Fri May 20 10:29:59 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 20 May 2016 12:29:59 +0200 Subject: RFR 8130023 API java.util.stream: explicitly specify guaranteed execution of the pipeline In-Reply-To: <9B780869-3D86-4FCF-8AB8-5B931115BE44@oracle.com> References: <573B8A0B.9010206@oracle.com> <9B780869-3D86-4FCF-8AB8-5B931115BE44@oracle.com> Message-ID: > On 19 May 2016, at 12:02, Paul Sandoz wrote: > > >> On 17 May 2016, at 23:15, Claes Redestad wrote: >> >> Hi, >> >> the first block in Stream.java bothers me: >> >> + *

A stream implementation is permitted significant latitude in optimizing >> + * the computation of the result. For example, a stream implementation is free >> + * to elide operations (or entire stages) from a stream pipeline -- and >> + * therefore elide invocation of behavioral parameters -- if it can prove that >> + * it would not affect the result of the computation. This means, that unless >> + * otherwise specified (such as by the terminal operations {@code forEach} and >> + * {@code forEachOrdered}), that side-effects of behavioral parameters may not >> + * always be executed and should not be relied upon. (For a specific example of >> + * such an optimization, see the API note documented on the {@link #count} >> + * operation. For more detail, see the >> + * side-effects section of the >> + * strean package documentation.) >> + * >> >> >> The first sentence in particular is hard to read and interpret, and after reading it twice I'm not sure if it's entirely redundant or if you need to better specify what other freedoms are given to a stream implementation? >> > > The first sentence is setting the stage that it is the result and not the computation that is key and we want to get across that this is not a limitation but a feature, since streams are about specifying a computation declaratively (and if side-effects are present then watch out!). > > We cannot specify the degrees of freedom, we can only specify the result be the same. Perhaps the "For example, ? in the following sentence can be removed or replaced with ?As such ?.? ? > Since it?s getting really really close to FC deadlines i left this paragraph as is and pushed, sorry to steam roll this though a little. We can revisit later, if necessary, as i expect any such updates should not change the meaning (or be non-normative). > >> How about this: >> >> + *

Astream implementation is free to elide operations (or entire stages) + * from a stream pipeline -- andtherefore elide invocation of behavioral + * parameters -- if it can prove that it would not affect the result of the + * computation. This means that side-effects of behavioral parameters may not + * always be executed and should not be relied upon, unless otherwise specified + * (such as by the terminal operations {@code forEach} and >> + * {@code forEachOrdered}).(For a specific example ofsuch an optimization, + * see the API note documented on the {@link #count} operation. For more + * details, see the side-effects + * section of the stream package documentation.) >> + * >> > > I like the move of the ?unless ?? to the end of the sentence, that reads better. > I included that. Thanks, Paul. From paul.sandoz at oracle.com Fri May 20 11:47:09 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 20 May 2016 13:47:09 +0200 Subject: RFR: 8157437 Typos in Stream JavaDoc Message-ID: <01ED9548-8A7D-431F-ABDE-C67B0E5694D9@oracle.com> Hi, I introduced some typos in my haste to push the fix for JDK-8130023 (API java.util.stream: explicitly specify guaranteed execution of the pipeline) (I am reminded of the phrase ?Go slow and you?ll get there faster?.) So to slow my self down i did a search for spelling errors in all of the stream package and found a few in internal comments. Paul. diff -r 871cb8793270 src/java.base/share/classes/java/util/stream/AbstractTask.java --- a/src/java.base/share/classes/java/util/stream/AbstractTask.java Fri May 20 11:47:39 2016 +0200 +++ b/src/java.base/share/classes/java/util/stream/AbstractTask.java Fri May 20 13:37:14 2016 +0200 @@ -106,7 +106,7 @@ protected Spliterator spliterator; /** Target leaf size, common to all tasks in a computation */ - protected long targetSize; // may be laziliy initialized + protected long targetSize; // may be lazily initialized /** * The left child. diff -r 871cb8793270 src/java.base/share/classes/java/util/stream/DoubleStream.java --- a/src/java.base/share/classes/java/util/stream/DoubleStream.java Fri May 20 11:47:39 2016 +0200 +++ b/src/java.base/share/classes/java/util/stream/DoubleStream.java Fri May 20 13:37:14 2016 +0200 @@ -211,7 +211,7 @@ * .sum(); * } * - *

In cases where stream implementation is able to optimize away the + *

In cases where the stream implementation is able to optimize away the * production of some or all the elements (such as with short-circuiting * operations like {@code findFirst}, or in the example described in * {@link #count}), the action will not be invoked for those elements. diff -r 871cb8793270 src/java.base/share/classes/java/util/stream/IntStream.java --- a/src/java.base/share/classes/java/util/stream/IntStream.java Fri May 20 11:47:39 2016 +0200 +++ b/src/java.base/share/classes/java/util/stream/IntStream.java Fri May 20 13:37:14 2016 +0200 @@ -209,7 +209,7 @@ * .sum(); * } * - *

In cases where stream implementation is able to optimize away the + *

In cases where the stream implementation is able to optimize away the * production of some or all the elements (such as with short-circuiting * operations like {@code findFirst}, or in the example described in * {@link #count}), the action will not be invoked for those elements. diff -r 871cb8793270 src/java.base/share/classes/java/util/stream/LongStream.java --- a/src/java.base/share/classes/java/util/stream/LongStream.java Fri May 20 11:47:39 2016 +0200 +++ b/src/java.base/share/classes/java/util/stream/LongStream.java Fri May 20 13:37:14 2016 +0200 @@ -209,7 +209,7 @@ * .sum(); * } * - *

In cases where stream implementation is able to optimize away the + *

In cases where the stream implementation is able to optimize away the * production of some or all the elements (such as with short-circuiting * operations like {@code findFirst}, or in the example described in * {@link #count}), the action will not be invoked for those elements. diff -r 871cb8793270 src/java.base/share/classes/java/util/stream/Stream.java --- a/src/java.base/share/classes/java/util/stream/Stream.java Fri May 20 11:47:39 2016 +0200 +++ b/src/java.base/share/classes/java/util/stream/Stream.java Fri May 20 13:37:14 2016 +0200 @@ -93,7 +93,7 @@ * example of such an optimization, see the API note documented on the * {@link #count} operation. For more detail, see the * side-effects section of the - * strean package documentation.) + * stream package documentation.) * *

Collections and streams, while bearing some superficial similarities, * have different goals. Collections are primarily concerned with the efficient @@ -428,7 +428,7 @@ * .collect(Collectors.toList()); * } * - *

In cases where stream implementation is able to optimize away the + *

In cases where the stream implementation is able to optimize away the * production of some or all the elements (such as with short-circuiting * operations like {@code findFirst}, or in the example described in * {@link #count}), the action will not be invoked for those elements. diff -r 871cb8793270 src/java.base/share/classes/java/util/stream/StreamSpliterators.java --- a/src/java.base/share/classes/java/util/stream/StreamSpliterators.java Fri May 20 11:47:39 2016 +0200 +++ b/src/java.base/share/classes/java/util/stream/StreamSpliterators.java Fri May 20 13:37:14 2016 +0200 @@ -28,7 +28,6 @@ import java.util.Objects; import java.util.Spliterator; import java.util.concurrent.ConcurrentHashMap; -import java.util.concurrent.ForkJoinPool; import java.util.concurrent.atomic.AtomicLong; import java.util.function.BooleanSupplier; import java.util.function.Consumer; @@ -104,7 +103,7 @@ T_BUFFER buffer; /** - * True if full traversal has occurred (with possible cancelation). + * True if full traversal has occurred (with possible cancellation). * If doing a partial traversal, there may be still elements in buffer. */ boolean finished; From aleksey.shipilev at oracle.com Fri May 20 11:48:49 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 20 May 2016 14:48:49 +0300 Subject: RFR: 8157437 Typos in Stream JavaDoc In-Reply-To: <01ED9548-8A7D-431F-ABDE-C67B0E5694D9@oracle.com> References: <01ED9548-8A7D-431F-ABDE-C67B0E5694D9@oracle.com> Message-ID: <573EF9A1.8010500@oracle.com> Looks good. Thanks, -Aleksey On 05/20/2016 02:47 PM, Paul Sandoz wrote: > Hi, > > I introduced some typos in my haste to push the fix for JDK-8130023 (API java.util.stream: explicitly specify guaranteed execution of the pipeline) (I am reminded of the phrase ?Go slow and you?ll get there faster?.) > > So to slow my self down i did a search for spelling errors in all of the stream package and found a few in internal comments. > > Paul. > > diff -r 871cb8793270 src/java.base/share/classes/java/util/stream/AbstractTask.java > --- a/src/java.base/share/classes/java/util/stream/AbstractTask.java Fri May 20 11:47:39 2016 +0200 > +++ b/src/java.base/share/classes/java/util/stream/AbstractTask.java Fri May 20 13:37:14 2016 +0200 > @@ -106,7 +106,7 @@ > protected Spliterator spliterator; > > /** Target leaf size, common to all tasks in a computation */ > - protected long targetSize; // may be laziliy initialized > + protected long targetSize; // may be lazily initialized > > /** > * The left child. > diff -r 871cb8793270 src/java.base/share/classes/java/util/stream/DoubleStream.java > --- a/src/java.base/share/classes/java/util/stream/DoubleStream.java Fri May 20 11:47:39 2016 +0200 > +++ b/src/java.base/share/classes/java/util/stream/DoubleStream.java Fri May 20 13:37:14 2016 +0200 > @@ -211,7 +211,7 @@ > * .sum(); > * } > * > - *

In cases where stream implementation is able to optimize away the > + *

In cases where the stream implementation is able to optimize away the > * production of some or all the elements (such as with short-circuiting > * operations like {@code findFirst}, or in the example described in > * {@link #count}), the action will not be invoked for those elements. > diff -r 871cb8793270 src/java.base/share/classes/java/util/stream/IntStream.java > --- a/src/java.base/share/classes/java/util/stream/IntStream.java Fri May 20 11:47:39 2016 +0200 > +++ b/src/java.base/share/classes/java/util/stream/IntStream.java Fri May 20 13:37:14 2016 +0200 > @@ -209,7 +209,7 @@ > * .sum(); > * } > * > - *

In cases where stream implementation is able to optimize away the > + *

In cases where the stream implementation is able to optimize away the > * production of some or all the elements (such as with short-circuiting > * operations like {@code findFirst}, or in the example described in > * {@link #count}), the action will not be invoked for those elements. > diff -r 871cb8793270 src/java.base/share/classes/java/util/stream/LongStream.java > --- a/src/java.base/share/classes/java/util/stream/LongStream.java Fri May 20 11:47:39 2016 +0200 > +++ b/src/java.base/share/classes/java/util/stream/LongStream.java Fri May 20 13:37:14 2016 +0200 > @@ -209,7 +209,7 @@ > * .sum(); > * } > * > - *

In cases where stream implementation is able to optimize away the > + *

In cases where the stream implementation is able to optimize away the > * production of some or all the elements (such as with short-circuiting > * operations like {@code findFirst}, or in the example described in > * {@link #count}), the action will not be invoked for those elements. > diff -r 871cb8793270 src/java.base/share/classes/java/util/stream/Stream.java > --- a/src/java.base/share/classes/java/util/stream/Stream.java Fri May 20 11:47:39 2016 +0200 > +++ b/src/java.base/share/classes/java/util/stream/Stream.java Fri May 20 13:37:14 2016 +0200 > @@ -93,7 +93,7 @@ > * example of such an optimization, see the API note documented on the > * {@link #count} operation. For more detail, see the > * side-effects section of the > - * strean package documentation.) > + * stream package documentation.) > * > *

Collections and streams, while bearing some superficial similarities, > * have different goals. Collections are primarily concerned with the efficient > @@ -428,7 +428,7 @@ > * .collect(Collectors.toList()); > * } > * > - *

In cases where stream implementation is able to optimize away the > + *

In cases where the stream implementation is able to optimize away the > * production of some or all the elements (such as with short-circuiting > * operations like {@code findFirst}, or in the example described in > * {@link #count}), the action will not be invoked for those elements. > diff -r 871cb8793270 src/java.base/share/classes/java/util/stream/StreamSpliterators.java > --- a/src/java.base/share/classes/java/util/stream/StreamSpliterators.java Fri May 20 11:47:39 2016 +0200 > +++ b/src/java.base/share/classes/java/util/stream/StreamSpliterators.java Fri May 20 13:37:14 2016 +0200 > @@ -28,7 +28,6 @@ > import java.util.Objects; > import java.util.Spliterator; > import java.util.concurrent.ConcurrentHashMap; > -import java.util.concurrent.ForkJoinPool; > import java.util.concurrent.atomic.AtomicLong; > import java.util.function.BooleanSupplier; > import java.util.function.Consumer; > @@ -104,7 +103,7 @@ > T_BUFFER buffer; > > /** > - * True if full traversal has occurred (with possible cancelation). > + * True if full traversal has occurred (with possible cancellation). > * If doing a partial traversal, there may be still elements in buffer. > */ > boolean finished; > From Alan.Bateman at oracle.com Fri May 20 11:50:44 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 May 2016 12:50:44 +0100 Subject: RFR: 8157437 Typos in Stream JavaDoc In-Reply-To: <01ED9548-8A7D-431F-ABDE-C67B0E5694D9@oracle.com> References: <01ED9548-8A7D-431F-ABDE-C67B0E5694D9@oracle.com> Message-ID: <573EFA14.3060208@oracle.com> On 20/05/2016 12:47, Paul Sandoz wrote: > Hi, > > I introduced some typos in my haste to push the fix for JDK-8130023 (API java.util.stream: explicitly specify guaranteed execution of the pipeline) (I am reminded of the phrase ?Go slow and you?ll get there faster?.) > > So to slow my self down i did a search for spelling errors in all of the stream package and found a few in internal comments. > Looks okay to me. -Alan From lance.andersen at oracle.com Fri May 20 11:50:56 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 20 May 2016 07:50:56 -0400 Subject: RFR: 8157437 Typos in Stream JavaDoc In-Reply-To: <01ED9548-8A7D-431F-ABDE-C67B0E5694D9@oracle.com> References: <01ED9548-8A7D-431F-ABDE-C67B0E5694D9@oracle.com> Message-ID: <363DA268-4B51-4AFB-875B-003023BFE238@oracle.com> +1 > On May 20, 2016, at 7:47 AM, Paul Sandoz wrote: > > Hi, > > I introduced some typos in my haste to push the fix for JDK-8130023 (API java.util.stream: explicitly specify guaranteed execution of the pipeline) (I am reminded of the phrase ?Go slow and you?ll get there faster?.) > > So to slow my self down i did a search for spelling errors in all of the stream package and found a few in internal comments. > > Paul. > > diff -r 871cb8793270 src/java.base/share/classes/java/util/stream/AbstractTask.java > --- a/src/java.base/share/classes/java/util/stream/AbstractTask.java Fri May 20 11:47:39 2016 +0200 > +++ b/src/java.base/share/classes/java/util/stream/AbstractTask.java Fri May 20 13:37:14 2016 +0200 > @@ -106,7 +106,7 @@ > protected Spliterator spliterator; > > /** Target leaf size, common to all tasks in a computation */ > - protected long targetSize; // may be laziliy initialized > + protected long targetSize; // may be lazily initialized > > /** > * The left child. > diff -r 871cb8793270 src/java.base/share/classes/java/util/stream/DoubleStream.java > --- a/src/java.base/share/classes/java/util/stream/DoubleStream.java Fri May 20 11:47:39 2016 +0200 > +++ b/src/java.base/share/classes/java/util/stream/DoubleStream.java Fri May 20 13:37:14 2016 +0200 > @@ -211,7 +211,7 @@ > * .sum(); > * } > * > - *

In cases where stream implementation is able to optimize away the > + *

In cases where the stream implementation is able to optimize away the > * production of some or all the elements (such as with short-circuiting > * operations like {@code findFirst}, or in the example described in > * {@link #count}), the action will not be invoked for those elements. > diff -r 871cb8793270 src/java.base/share/classes/java/util/stream/IntStream.java > --- a/src/java.base/share/classes/java/util/stream/IntStream.java Fri May 20 11:47:39 2016 +0200 > +++ b/src/java.base/share/classes/java/util/stream/IntStream.java Fri May 20 13:37:14 2016 +0200 > @@ -209,7 +209,7 @@ > * .sum(); > * } > * > - *

In cases where stream implementation is able to optimize away the > + *

In cases where the stream implementation is able to optimize away the > * production of some or all the elements (such as with short-circuiting > * operations like {@code findFirst}, or in the example described in > * {@link #count}), the action will not be invoked for those elements. > diff -r 871cb8793270 src/java.base/share/classes/java/util/stream/LongStream.java > --- a/src/java.base/share/classes/java/util/stream/LongStream.java Fri May 20 11:47:39 2016 +0200 > +++ b/src/java.base/share/classes/java/util/stream/LongStream.java Fri May 20 13:37:14 2016 +0200 > @@ -209,7 +209,7 @@ > * .sum(); > * } > * > - *

In cases where stream implementation is able to optimize away the > + *

In cases where the stream implementation is able to optimize away the > * production of some or all the elements (such as with short-circuiting > * operations like {@code findFirst}, or in the example described in > * {@link #count}), the action will not be invoked for those elements. > diff -r 871cb8793270 src/java.base/share/classes/java/util/stream/Stream.java > --- a/src/java.base/share/classes/java/util/stream/Stream.java Fri May 20 11:47:39 2016 +0200 > +++ b/src/java.base/share/classes/java/util/stream/Stream.java Fri May 20 13:37:14 2016 +0200 > @@ -93,7 +93,7 @@ > * example of such an optimization, see the API note documented on the > * {@link #count} operation. For more detail, see the > * side-effects section of the > - * strean package documentation.) > + * stream package documentation.) > * > *

Collections and streams, while bearing some superficial similarities, > * have different goals. Collections are primarily concerned with the efficient > @@ -428,7 +428,7 @@ > * .collect(Collectors.toList()); > * } > * > - *

In cases where stream implementation is able to optimize away the > + *

In cases where the stream implementation is able to optimize away the > * production of some or all the elements (such as with short-circuiting > * operations like {@code findFirst}, or in the example described in > * {@link #count}), the action will not be invoked for those elements. > diff -r 871cb8793270 src/java.base/share/classes/java/util/stream/StreamSpliterators.java > --- a/src/java.base/share/classes/java/util/stream/StreamSpliterators.java Fri May 20 11:47:39 2016 +0200 > +++ b/src/java.base/share/classes/java/util/stream/StreamSpliterators.java Fri May 20 13:37:14 2016 +0200 > @@ -28,7 +28,6 @@ > import java.util.Objects; > import java.util.Spliterator; > import java.util.concurrent.ConcurrentHashMap; > -import java.util.concurrent.ForkJoinPool; > import java.util.concurrent.atomic.AtomicLong; > import java.util.function.BooleanSupplier; > import java.util.function.Consumer; > @@ -104,7 +103,7 @@ > T_BUFFER buffer; > > /** > - * True if full traversal has occurred (with possible cancelation). > + * True if full traversal has occurred (with possible cancellation). > * If doing a partial traversal, there may be still elements in buffer. > */ > boolean finished; > 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 tomasz.kowalczewski at gmail.com Fri May 20 13:19:25 2016 From: tomasz.kowalczewski at gmail.com (Tomasz Kowalczewski) Date: Fri, 20 May 2016 15:19:25 +0200 Subject: TreeMap specific override of putIfAbsent/merge Message-ID: Hi all, TreeMap does not have its own specific overrides of Map methods that were added in java 8. In our specific usage we do what is effective a merge operation: For incoming K and V: 1. get value from map 2. if present - merge with incoming value V 3. if absent - associate K with V in the map For case where K is not in the map we traverse the tree map it twice. Implementing TreeMap specific override of putIfAbsent would allow as to avoid this cost. Was such change considered in past and rejected? Is anyone interested in a patch that implements it? -- Regards, Tomasz Kowalczewski From claes.redestad at oracle.com Fri May 20 14:16:30 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 20 May 2016 16:16:30 +0200 Subject: RFR: 8157449: Adjust link-time generated Species classes to match JDK-8148604 usage Message-ID: <573F1C3E.2000206@oracle.com> Hi, I noticed that the BMH$Species classes generated at link time slightly mismatch the classes generated when concatenating things. Updating this to match reality helps mitigate a small fraction of the startup penalty to enabling the optimal string concatenation strategy: Bug: https://bugs.openjdk.java.net/browse/JDK-8157449 Webrev: http://cr.openjdk.java.net/~redestad/8157449/webrev.00/ Note that the plan is to generate this list of defaults automatically in a profiling step, either during build or as part of the ongoing development process. Apologies for not having gotten to that yet. :-) Thanks! /Claes From mandy.chung at oracle.com Fri May 20 14:24:22 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 20 May 2016 07:24:22 -0700 Subject: Review Request: 8157391: jdeps left JarFile open In-Reply-To: <573EB10B.3090202@oracle.com> References: <573EB10B.3090202@oracle.com> Message-ID: <751B5BD2-53EF-4405-82FA-2DCF9668D208@oracle.com> > On May 19, 2016, at 11:39 PM, Alan Bateman wrote: > > > > On 20/05/2016 04:55, Mandy Chung wrote: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157391/webrev.00/index.html >> >> tools/jdeps/modules/GenModuleInfo.java >> tools/jdeps/modules/TransitiveDeps.java >> tools/jdeps/modules/InverseDeps.java >> >> These tests still failed on windows after JDK-8152502. >> >> Now I have the jtreg logs showing that JAR files can?t be deleted although I still can?t reproduce them locally and on JPRT (will find out what?s the difference tomorrow). >> > This looks okay to me. One thing you could do in the test is have JdepsUtil.Command be Closeable so that the tests can use try-with-resources and avoid failing with a file open. Good point. I?ll update that. Mandy From peter.levart at gmail.com Fri May 20 14:31:05 2016 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 20 May 2016 16:31:05 +0200 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: References: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> Message-ID: <8526fa40-f9ee-2c5d-4373-e9e0ceb40577@gmail.com> Hi Martin, On 05/20/2016 02:51 AM, Martin Buchholz wrote: > On Thu, May 19, 2016 at 7:29 AM, Peter Levart wrote: >> So Martin, what do you think? > I studied your code and we are fundamentally in agreement! > ... Except for need for periodic cleanup of the cache... > Maybe we should do > CompletableFuture.runAsync(purgeCache, > CompletableFuture.delayedExecutor(1, SECONDS)) > as a periodic task while cache is non-empty instead of my strategy of > relying on a weak reference. > > Purging a cache on quiescence in the optimal way seems to be a hard problem. > Time to write ObjectPool (as many others have done before us)? > > ObjectPool(Supplier factory, Consumer releaser, maxCacheSize, > keepAliveTime) > > Except this time we'll do it right! With jdk9 machinery! Something like the following? http://cr.openjdk.java.net/~plevart/jdk9-dev/ZipFile_Inflater.cleanup/webrev.02/ I still must debug the cause of OutOfMemoryError in java/util/zip/ZipFile/TestZipFile.java. Regards, Peter From paul.sandoz at oracle.com Fri May 20 14:57:18 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 20 May 2016 16:57:18 +0200 Subject: TreeMap specific override of putIfAbsent/merge In-Reply-To: References: Message-ID: Hi Tomasz, If there was any rejection it was probably due to time constraints than for any technical reasons. It should be easy to refactor the TreeMap.put implementation into say a private putVal accepting a boolean argument and both put and putIfAbsent call putVal (same pattern as in HashMap). The compute* methods may require separate implementations with almost duplicated kind of patterns. An OCA [1] compliant patch would be appreciated, which should also include updates to relevant tests where appropriate. Thanks, Paul. [1] http://www.oracle.com/technetwork/community/oca-486395.html > On 20 May 2016, at 15:19, Tomasz Kowalczewski wrote: > > Hi all, > > TreeMap does not have its own specific overrides of Map methods that were > added in java 8. In our specific usage we do what is effective a merge > operation: > > For incoming K and V: > 1. get value from map > 2. if present - merge with incoming value V > 3. if absent - associate K with V in the map > > For case where K is not in the map we traverse the tree map it twice. > Implementing TreeMap specific override of putIfAbsent would allow as to > avoid this cost. > > Was such change considered in past and rejected? Is anyone interested in a > patch that implements it? > > -- > Regards, > Tomasz Kowalczewski From mandy.chung at oracle.com Fri May 20 15:12:22 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 20 May 2016 08:12:22 -0700 Subject: Review Request: 8157391: jdeps left JarFile open In-Reply-To: <751B5BD2-53EF-4405-82FA-2DCF9668D208@oracle.com> References: <573EB10B.3090202@oracle.com> <751B5BD2-53EF-4405-82FA-2DCF9668D208@oracle.com> Message-ID: <00EB1619-9CB1-4382-BFE9-428F1F75C948@oracle.com> > On May 20, 2016, at 7:24 AM, Mandy Chung wrote: > >> >> On May 19, 2016, at 11:39 PM, Alan Bateman wrote: >> >> >> >> On 20/05/2016 04:55, Mandy Chung wrote: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157391/webrev.00/index.html >>> >>> tools/jdeps/modules/GenModuleInfo.java >>> tools/jdeps/modules/TransitiveDeps.java >>> tools/jdeps/modules/InverseDeps.java >>> >>> These tests still failed on windows after JDK-8152502. >>> >>> Now I have the jtreg logs showing that JAR files can?t be deleted although I still can?t reproduce them locally and on JPRT (will find out what?s the difference tomorrow). >>> >> This looks okay to me. One thing you could do in the test is have JdepsUtil.Command be Closeable so that the tests can use try-with-resources and avoid failing with a file open. > > Good point. I?ll update that. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157391/webrev.01/index.html Mandy From xueming.shen at oracle.com Fri May 20 15:44:35 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 20 May 2016 08:44:35 -0700 Subject: RFR: JDK-8143282: \p{Cn} unassigned code points should be included in \p{C} Message-ID: <4da39bfe-5cc2-9e8a-f0ce-07b26a9f6ab0@oracle.com> Hi, Please help review the change for 8143282. issue: https://bugs.openjdk.java.net/browse/JDK-8143282 webrev: http://cr.openjdk.java.net/~sherman/8143282 thanks, Sherman From aleksey.shipilev at oracle.com Fri May 20 16:01:58 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 20 May 2016 19:01:58 +0300 Subject: RFR: 8157449: Adjust link-time generated Species classes to match JDK-8148604 usage In-Reply-To: <573F1C3E.2000206@oracle.com> References: <573F1C3E.2000206@oracle.com> Message-ID: <573F34F6.6070101@oracle.com> On 05/20/2016 05:16 PM, Claes Redestad wrote: > Webrev: http://cr.openjdk.java.net/~redestad/8157449/webrev.00/ Looks good. Thanks, -Aleksey From martinrb at google.com Fri May 20 16:11:22 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 20 May 2016 09:11:22 -0700 Subject: RFR: JDK-8143282: \p{Cn} unassigned code points should be included in \p{C} In-Reply-To: <4da39bfe-5cc2-9e8a-f0ce-07b26a9f6ab0@oracle.com> References: <4da39bfe-5cc2-9e8a-f0ce-07b26a9f6ab0@oracle.com> Message-ID: Here is a duplicate check: 4422 (Character.CONTROL == type || Character.CONTROL == type || I don't see any tests for corresponding p{Cn} I expected to see general category Other "C" in Character.java I'd like to see tests that p{C} is the same as p{Other} is the same as p{isOther} and similar with other categories. You could add a test assertion that checks that p{C} has identical effect to [p{Cn}p{Cs}p{C....] The matcher("") with reset idiom looks weird to me. I'd just create Patterns and then keep creating new Matchers, at least in test code. On Fri, May 20, 2016 at 8:44 AM, Xueming Shen wrote: > Hi, > > Please help review the change for 8143282. > > issue: https://bugs.openjdk.java.net/browse/JDK-8143282 > webrev: http://cr.openjdk.java.net/~sherman/8143282 > > thanks, > Sherman From xueming.shen at oracle.com Fri May 20 16:55:24 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 20 May 2016 09:55:24 -0700 Subject: RFR: JDK-8143282: \p{Cn} unassigned code points should be included in \p{C} In-Reply-To: References: <4da39bfe-5cc2-9e8a-f0ce-07b26a9f6ab0@oracle.com> Message-ID: <757376ec-9b58-e1d4-f7d6-94dd88b99e94@oracle.com> On 5/20/16 9:11 AM, Martin Buchholz wrote: > Here is a duplicate check: > > 4422 (Character.CONTROL == type || Character.CONTROL > == type || > > I don't see any tests for corresponding p{Cn} It appears we don't have any regex test for the gc in current test cases. Not a surprise though. I added the tests for block and script when adding script support ... > > I expected to see general category Other "C" in Character.java can open a rfe for that if needed. > > I'd like to see tests that p{C} is the same as p{Other} is the same as > p{isOther} and similar with other categories. Did you mean you want to add the "long name" support for unicode category? > You could add a test assertion that checks that p{C} has identical > effect to [p{Cn}p{Cs}p{C....] > > The matcher("") with reset idiom looks weird to me. I'd just create > Patterns and then keep creating new Matchers, at least in test code. just tried to speed up the loop, which is iterating on 0x30000 cps. the property tests are taking longer and longer. -Sherman > > > > On Fri, May 20, 2016 at 8:44 AM, Xueming Shen wrote: >> Hi, >> >> Please help review the change for 8143282. >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8143282 >> webrev: http://cr.openjdk.java.net/~sherman/8143282 >> >> thanks, >> Sherman From huizhe.wang at oracle.com Fri May 20 17:12:49 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 20 May 2016 10:12:49 -0700 Subject: RFR (JAXP) 8054632: [since-tag]: javadoc for xml classes has invalid @since tag Message-ID: <573F4590.9040202@oracle.com> Hi, This patch applies similar change[1] made to the DOM sources under java.xml for those under jdk.xml.dom, replacing "@since DOM Level 2" with "@since 1.4, DOM Level 2", and adding "@since 1.4, DOM Level 2" to the ones (under html package) that missed the @since tag. JBS: https://bugs.openjdk.java.net/browse/JDK-8054632 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8054632/webrev/ [1] https://bugs.openjdk.java.net/browse/JDK-8047723 Thanks, Joe From martinrb at google.com Fri May 20 17:13:27 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 20 May 2016 10:13:27 -0700 Subject: RFR: JDK-8143282: \p{Cn} unassigned code points should be included in \p{C} In-Reply-To: <757376ec-9b58-e1d4-f7d6-94dd88b99e94@oracle.com> References: <4da39bfe-5cc2-9e8a-f0ce-07b26a9f6ab0@oracle.com> <757376ec-9b58-e1d4-f7d6-94dd88b99e94@oracle.com> Message-ID: On Fri, May 20, 2016 at 9:55 AM, Xueming Shen wrote: > On 5/20/16 9:11 AM, Martin Buchholz wrote: >> >> Here is a duplicate check: >> >> 4422 (Character.CONTROL == type || Character.CONTROL >> == type || >> >> I don't see any tests for corresponding p{Cn} > > > It appears we don't have any regex test for the gc in current test cases. > Not a surprise > though. I added the tests for block and script when adding script support > ... > >> >> I expected to see general category Other "C" in Character.java > > > can open a rfe for that if needed. Well, don't we want complete correspondence between Unicode standard, Character, and regex? Anything missing seems like a bug, not rfe! > >> >> I'd like to see tests that p{C} is the same as p{Other} is the same as >> p{isOther} and similar with other categories. > > > Did you mean you want to add the "long name" support for unicode category? I expect \p{C} and \p{Other} and \p{isOther} all to work (haven't tried it). Is that not a reasonable expectation? >> >> You could add a test assertion that checks that p{C} has identical >> effect to [p{Cn}p{Cs}p{C....] >> >> The matcher("") with reset idiom looks weird to me. I'd just create >> Patterns and then keep creating new Matchers, at least in test code. > > > just tried to speed up the loop, which is iterating on 0x30000 cps. the > property tests are > taking longer and longer. Having done test performance work, I am sympathetic! I'm surprised reusing a Matcher helps significantly, but OK! From Roger.Riggs at Oracle.com Fri May 20 17:56:13 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 20 May 2016 13:56:13 -0400 Subject: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields In-Reply-To: <39a4cfc7-a245-492d-a684-3b7aba416671@default> References: <573A9B92.60201@oracle.com> <7bf185b0-ceb0-4329-bb7e-6555383eaa67@default> <39a4cfc7-a245-492d-a684-3b7aba416671@default> Message-ID: Hi Bhanu, Looks good. Thanks for including the tests of the values so the tests look complete. Roger On 5/20/2016 5:22 AM, Bhanu Gopularam wrote: > Hi Roger, > > Thanks for the comments. Earlier as part of JDK-8062804 we considered scenarios for support of isofields and non isofields (positive case to check isofield works and negative case to check UnsupportedTemporalTypeException is thrown only. > > Here is the updated webrev, I have added data check for field.rangeRefinedBy method. > http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.02 > > Please review the changes. > > Thanks, > Bhanu > > -----Original Message----- > From: Roger Riggs > Sent: Thursday, May 19, 2016 6:49 PM > To: core-libs-dev at openjdk.java.net > Subject: Re: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields > > Hi Bhanu, > > Can you remind me why the value from line: 459 > > field.rangeRefinedBy(LocalDate.now()); > > is not checked also? Is looks odd to see a value passed to a test and not have it verified. > > It would need to use a fixed date (the same), but that is fine for that test. > > Thanks, Roger > > On 5/19/2016 7:16 AM, Stephen Colebourne wrote: >> Fine by me >> Stephen >> >> On 19 May 2016 at 11:34, Bhanu Gopularam >> wrote: >>> Thank you Nadeesh and Stephen. >>> >>> Here is the updated webrev link: >>> http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.01 >>> >>> Please review. >>> >>> Bhanu >>> >>> -----Original Message----- >>> From: Stephen Colebourne [mailto:scolebourne at joda.org] >>> Sent: Tuesday, May 17, 2016 5:11 PM >>> To: core-libs-dev >>> Subject: Re: RFR 8156718: Need tests for IsoFields getFrom for >>> unsupported non-Iso Temporal fields >>> >>> I would also like to see the test case methods be named "getFrom" not "getfrom". >>> >>> Stephen >>> >>> On 17 May 2016 at 05:18, nadeesh tv wrote: >>>> Hi Bhanu, >>>> >>>> I think you should add a test case comparing the return value of >>>> getFrom() >>>> >>>> ( Not an official reviewer) >>>> >>>> Regards, >>>> Nadeesh >>>> >>>> On 5/16/2016 11:46 AM, Bhanu Gopularam wrote: >>>>> Hi all, >>>>> >>>>> Could you please review fix for following issue. >>>>> >>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8156718 >>>>> >>>>> Solution: Added tck tests for validating getFrom method for >>>>> unsupported non-Iso temporal fields >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.00/ >>>>> >>>>> Thanks, >>>>> Bhanu >>>> -- >>>> Thanks and Regards, >>>> Nadeesh TV >>>> From lance.andersen at oracle.com Fri May 20 18:07:53 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 20 May 2016 14:07:53 -0400 Subject: RFR (JAXP) 8054632: [since-tag]: javadoc for xml classes has invalid @since tag In-Reply-To: <573F4590.9040202@oracle.com> References: <573F4590.9040202@oracle.com> Message-ID: <8E87F6C1-B77A-475F-8CAB-B3224438E24F@oracle.com> looks ok joe > On May 20, 2016, at 1:12 PM, huizhe wang wrote: > > Hi, > > This patch applies similar change[1] made to the DOM sources under java.xml for those under jdk.xml.dom, replacing "@since DOM Level 2" with "@since 1.4, DOM Level 2", and adding "@since 1.4, DOM Level 2" to the ones (under html package) that missed the @since tag. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8054632 > webrev: http://cr.openjdk.java.net/~joehw/jdk9/8054632/webrev/ > > > [1] https://bugs.openjdk.java.net/browse/JDK-8047723 > > 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 xueming.shen at oracle.com Fri May 20 18:10:28 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 20 May 2016 11:10:28 -0700 Subject: RFR: JDK-8143282: \p{Cn} unassigned code points should be included in \p{C} In-Reply-To: References: <4da39bfe-5cc2-9e8a-f0ce-07b26a9f6ab0@oracle.com> <757376ec-9b58-e1d4-f7d6-94dd88b99e94@oracle.com> Message-ID: <5b6c7920-ddb4-47cb-e331-6cc9e6a728a3@oracle.com> On 5/20/16 10:13 AM, Martin Buchholz wrote: > On Fri, May 20, 2016 at 9:55 AM, Xueming Shen wrote: >>> I expected to see general category Other "C" in Character.java >> >> can open a rfe for that if needed. > Well, don't we want complete correspondence between Unicode standard, > Character, and regex? > Anything missing seems like a bug, not rfe! > >>> I'd like to see tests that p{C} is the same as p{Other} is the same as >>> p{isOther} and similar with other categories. >> >> Did you mean you want to add the "long name" support for unicode category? > I expect \p{C} and \p{Other} and \p{isOther} all to work (haven't tried it). > Is that not a reasonable expectation? > I'm the big fan of regex unicode support :-) LC/L/M/N/P/S/Z/C are special gc, they are "groupings of related gc values". While j.l.Character does support the general category via getType() == gc_xyz, it does not explicitly have support for such grouping values for obvious reason (1:2), we have various isXXXXX() methods, but they are not specified as the equivalent to those gc_groupings. So yes, it would be a rfe, if you want them supported in j.u.Character class (such as Character.isType(int cp, int type)) Though lots of properties supported have been added in j.u.regex, it's still not completed. Names, such as "Other", "Number" are not supported, yet. "Letter" is ok as it falls back into the same posix name. The supported "property name" list is limited, as listed with CharPredicates.defUProp. It should be fine to add "Other", and other "long name" for the unicode gc, but it appears we might have a name space conflict for "letter" (posix or unicode). It should be safe to do \p{gc=xyz}. Again, it is more like a rfe now :-) -Sherman From martinrb at google.com Fri May 20 18:21:34 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 20 May 2016 11:21:34 -0700 Subject: RFR: JDK-8143282: \p{Cn} unassigned code points should be included in \p{C} In-Reply-To: <5b6c7920-ddb4-47cb-e331-6cc9e6a728a3@oracle.com> References: <4da39bfe-5cc2-9e8a-f0ce-07b26a9f6ab0@oracle.com> <757376ec-9b58-e1d4-f7d6-94dd88b99e94@oracle.com> <5b6c7920-ddb4-47cb-e331-6cc9e6a728a3@oracle.com> Message-ID: Consider your change reviewed if you fix the duplication here: + (Character.CONTROL == type || Character.CONTROL == type || On Fri, May 20, 2016 at 11:10 AM, Xueming Shen wrote: > it is more like a rfe now :-) Yup, that's a RFE! From martinrb at google.com Fri May 20 18:53:45 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 20 May 2016 11:53:45 -0700 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: <8526fa40-f9ee-2c5d-4373-e9e0ceb40577@gmail.com> References: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> <8526fa40-f9ee-2c5d-4373-e9e0ceb40577@gmail.com> Message-ID: Peter, You keep impressing me with your development speed! Looking at ObjectPool ... looking pretty good keepalivetime should be > 0. (also very small keepalive times are a bad idea, but what's "very small"?) I'm thinking one second for ZipFile keep alive time. Thread pools have 60 seconds. Maybe we need a Consumer resetter in addition to a releaser. I'm opposed to creating a new STPE. jdk 9 CompletableFuture comes with a hidden thread scheduler, so the idea is to use delayedExecutor to share that one thread for all common scheduling. I think you want to call pop poll instead, since it can return null? We want a purger task to be created at most once per keep alive period, and never after the pool is quiescent. Not sure if we're there yet. On Fri, May 20, 2016 at 7:31 AM, Peter Levart wrote: > Hi Martin, > > > > On 05/20/2016 02:51 AM, Martin Buchholz wrote: >> >> On Thu, May 19, 2016 at 7:29 AM, Peter Levart >> wrote: >>> >>> So Martin, what do you think? >> >> I studied your code and we are fundamentally in agreement! >> ... Except for need for periodic cleanup of the cache... >> Maybe we should do >> CompletableFuture.runAsync(purgeCache, >> CompletableFuture.delayedExecutor(1, SECONDS)) >> as a periodic task while cache is non-empty instead of my strategy of >> relying on a weak reference. >> >> Purging a cache on quiescence in the optimal way seems to be a hard >> problem. >> Time to write ObjectPool (as many others have done before us)? >> >> ObjectPool(Supplier factory, Consumer releaser, maxCacheSize, >> keepAliveTime) >> >> Except this time we'll do it right! With jdk9 machinery! > > > Something like the following? > > http://cr.openjdk.java.net/~plevart/jdk9-dev/ZipFile_Inflater.cleanup/webrev.02/ > > I still must debug the cause of OutOfMemoryError in > java/util/zip/ZipFile/TestZipFile.java. > > Regards, Peter > From artem.smotrakov at oracle.com Fri May 20 20:05:35 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 20 May 2016 13:05:35 -0700 Subject: [9] RFR: 8152207: Perform array bound checks while getting a length of bytecode instructions In-Reply-To: <57324965.1090905@oracle.com> References: <572A8A57.5080907@oracle.com> <57324965.1090905@oracle.com> Message-ID: <573F6E0F.2020509@oracle.com> Hello, Could someone review this fix, please? http://cr.openjdk.java.net/~asmotrak/8152207/hotspot/webrev.01/ http://cr.openjdk.java.net/~asmotrak/8152207/jdk/webrev.00/ Artem On 05/10/2016 01:49 PM, Artem Smotrakov wrote: > Hi Christian, > > Thank you for review. Here is updated webrev > > http://cr.openjdk.java.net/~asmotrak/8152207/hotspot/webrev.01/ > > Artem > > On 05/09/2016 01:24 PM, Christian Thalinger wrote: >> >>> On May 4, 2016, at 1:48 PM, Artem Smotrakov >>> > wrote: >>> >>> Hello, >>> >>> Please review two small patches for jdk and hotspot repos which add >>> array bound checks to functions which return a length of bytecode >>> instruction. >>> >>> Please see details in https://bugs.openjdk.java.net/browse/JDK-8152207 >>> >>> http://cr.openjdk.java.net/~asmotrak/8152207/jdk/webrev.00/ >>> >>> http://cr.openjdk.java.net/~asmotrak/8152207/hotspot/webrev.00/ >> >> static bool is_defined (int code) { return 0 <= code >> && code < number_of_codes && flags(code, false) != 0; } >> + static int length_for (Code code) { return 0 <= code && code < >> number_of_codes ? _lengths[code] & 0xF : -1; } >> + static int wide_length_for(Code code) { return 0 <= code && code < >> number_of_codes ? _lengths[code] >> 4 : -1; } >> You should factor the bound check into a separate method. >> >>> >>> Artem >> > From brian.burkhalter at oracle.com Fri May 20 20:39:38 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 20 May 2016 13:39:38 -0700 Subject: JDK 9 RFR of JDK-4851777 Add BigDecimal sqrt method In-Reply-To: References: Message-ID: <70452462-5EF4-42C1-90D3-FFBAFC6C398E@oracle.com> Hi Joe, I?ve a few comments / questions, mostly picayune. On May 19, 2016, at 11:43 PM, joe darcy wrote: > Please review the addition of BigDecimal.sqrt: > > JDK-4851777 Add BigDecimal sqrt method > > http://cr.openjdk.java.net/~darcy/4851777.5/ 2023 *

  • The square root of a number numerically equal to {@code Extraneous space after ?
  • ?. 2057 * The main steps of the algorithm below are as follow, first ?follow? -> ?follows? 2104 // root, it is helpful to instead normalize this as so I think the ?as? is unneeded. 2110 int scale = stripped.scale() - stripped.precision() + 1; The ?+ 1? here is I suppose because in the referenced ACM paper they work with a normalized fraction ?f? in the range [0.1,1.0) whereas here unscaledValue is a BigInteger. Then the analog of ?f? in the BigDecimal case is the variable ?working.? 2226 * the computed result for the chosen rounding mode . Extraneous space before period. In terms of additional testing, did you contemplate comparing the consistency of the results versus BigInteger.sqrt()? Obviously one would not be looking for equality in most cases. All in all I think this looks good insofar as my reading can tell. Reviewed +1. Thanks, Brian From huizhe.wang at oracle.com Fri May 20 20:44:02 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 20 May 2016 13:44:02 -0700 Subject: RFR (JAXP) 8054632: [since-tag]: javadoc for xml classes has invalid @since tag In-Reply-To: <8E87F6C1-B77A-475F-8CAB-B3224438E24F@oracle.com> References: <573F4590.9040202@oracle.com> <8E87F6C1-B77A-475F-8CAB-B3224438E24F@oracle.com> Message-ID: <573F7712.1060401@oracle.com> Thanks Lance! Joe On 5/20/2016 11:07 AM, Lance Andersen wrote: > looks ok joe >> On May 20, 2016, at 1:12 PM, huizhe wang > > wrote: >> >> Hi, >> >> This patch applies similar change[1] made to the DOM sources under >> java.xml for those under jdk.xml.dom, replacing "@since DOM Level 2" >> with "@since 1.4, DOM Level 2", and adding "@since 1.4, DOM Level 2" >> to the ones (under html package) that missed the @since tag. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8054632 >> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8054632/webrev/ >> >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8047723 >> >> 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 brian.burkhalter at oracle.com Fri May 20 21:48:53 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 20 May 2016 14:48:53 -0700 Subject: [PING] [9] RFR of 5100935: No way to access the 64-bit integer multiplication of 64-bit CPUs efficiently In-Reply-To: <573D8B14.5040109@redhat.com> References: <3B559334-8ED3-4BEA-85E9-7AA9CD57AA91@oracle.com> <55FDBCC1.8060708@oracle.com> <48070a6e-40af-4748-4fc1-2c76c75d7371@oracle.com> <573D8B14.5040109@redhat.com> Message-ID: Hello Andrew, Thank you for your comments. I went ahead and integrated the existing code as reviewed but created a new issue https://bugs.openjdk.java.net/browse/JDK-8157485 to track the possible improvement you suggested. Thanks for citing the appropriate reference material as well. Cheers, Brian On May 19, 2016, at 2:44 AM, Andrew Haley wrote: > This is described as being to help RSA, etc., but it will be very hard > to use for that purpose without an add with carry. There are many ways > to do the product, but a simple version of the core is like this: > > for i=0 to s-1 > C := 0 > for j=0 to s-1 > (C,S) := t[i+j] + a[j] * b[i] + C > t[i+j] := S > t[i+s] := C > > for i=0 to s-1 > C := 0 > m := t i *n' 0 mod W > for j=0 to s-1 > (C,S) := t[i+j] + m*n[j] + C > t[i+j] := S > ADD(t[i+s],C) > > ... the result is in the carry flag and t . The logic in the x86 > version of SharedRuntime::montgomery_multiply uses a primitive which > multiplies two longs and accumulates the result into a triple-length > sum. x86 can do this in four instructions. I guess a primitive like > this will fit nicely with value types, but I'm not sure how it's > possible to do this with Java today. > > (My apologies: I'm sure you know this already, but I didn't think it > was wise not to say anything.) > > Andrew. > > [Algorithm from http://koclab.cs.ucsb.edu/docs/koc/j37.pdf] From joe.darcy at oracle.com Fri May 20 21:55:31 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Fri, 20 May 2016 14:55:31 -0700 Subject: JDK 9 RFR of JDK-8157487: Mark ZoneId.java as intermittently failing Message-ID: <573F87D3.6070306@oracle.com> Hello, The test sun/net/www/protocol/http/ZoneId.java has been seen to intermittently fail (JDK-8085785) and should be marked accordingly. Please review the patch below which does this. Thanks, -Joe --- a/test/sun/net/www/protocol/http/ZoneId.java Fri May 20 14:41:41 2016 -0700 +++ b/test/sun/net/www/protocol/http/ZoneId.java Fri May 20 14:53:51 2016 -0700 @@ -24,6 +24,7 @@ /* * @test * @bug 8027308 + * @key intermittent * @modules java.base/sun.net.www.protocol.http * @summary verifies that HttpURLConnection does not send the zone id in the * 'Host' field of the header: From naoto.sato at oracle.com Fri May 20 22:58:21 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 20 May 2016 15:58:21 -0700 Subject: JDK 9 RFR of JDK-8157487: Mark ZoneId.java as intermittently failing In-Reply-To: <573F87D3.6070306@oracle.com> References: <573F87D3.6070306@oracle.com> Message-ID: Looks fine to me. Naoto On 5/20/16 2:55 PM, Joseph D. Darcy wrote: > Hello, > > The test > > sun/net/www/protocol/http/ZoneId.java > > has been seen to intermittently fail (JDK-8085785) and should be marked > accordingly. Please review the patch below which does this. > > Thanks, > > -Joe > > --- a/test/sun/net/www/protocol/http/ZoneId.java Fri May 20 14:41:41 > 2016 -0700 > +++ b/test/sun/net/www/protocol/http/ZoneId.java Fri May 20 14:53:51 > 2016 -0700 > @@ -24,6 +24,7 @@ > /* > * @test > * @bug 8027308 > + * @key intermittent > * @modules java.base/sun.net.www.protocol.http > * @summary verifies that HttpURLConnection does not send the zone id > in the > * 'Host' field of the header: > From naoto.sato at oracle.com Fri May 20 23:16:03 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 20 May 2016 16:16:03 -0700 Subject: [9] RFR: Static build of libzip is missing JNI_OnLoad_zip entry point Message-ID: <1529814e-b041-a3bd-29e2-a5ca80ee7ed4@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8150179 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8150179/webrev.00/ The fix is to simply bring the JNI OnLoad entry point back from ZipFile.c which was removed. Naoto From joe.darcy at oracle.com Sat May 21 03:09:56 2016 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 20 May 2016 20:09:56 -0700 Subject: JDK 9 RFR of JDK-4851777 Add BigDecimal sqrt method In-Reply-To: <70452462-5EF4-42C1-90D3-FFBAFC6C398E@oracle.com> References: <70452462-5EF4-42C1-90D3-FFBAFC6C398E@oracle.com> Message-ID: <55b9d509-2f6e-bde0-a5d8-230d4128eaf9@oracle.com> Hi Brian, On 5/20/2016 1:39 PM, Brian Burkhalter wrote: > Hi Joe, > > I?ve a few comments / questions, mostly picayune. > > On May 19, 2016, at 11:43 PM, joe darcy > wrote: > >> Please review the addition of BigDecimal.sqrt: >> >> JDK-4851777 Add BigDecimal sqrt method >> >> http://cr.openjdk.java.net/~darcy/4851777.5/ >> > > 2023 *
  • The square root of a number numerically equal to {@code > Extraneous space after ?
  • ?. > 2057 * The main steps of the algorithm below are as*follow*, first > ?follow? -> ?follows? > 2104 // root, it is helpful to instead normalize this*as* so > I think the ?as? is unneeded. > 2110 int scale = stripped.scale() - stripped.precision() + 1; > The ?+ 1? here is I suppose because in the referenced ACM paper they > work with a normalized fraction ?f? in the range [0.1,1.0) whereas > here unscaledValue is a BigInteger. Then the analog of ?f? in the > BigDecimal case is the variable ?working.? Right; BigDecimal values are naturally normalized with the decimal point to the right of the digit block as opposed to the left of the digit block (meaning the value is fractional) as is commonly done in binary floating-point. To make sure the value is in the range for double, since BigDecimal can encode truly huge values that would overflow, I normalize the working/f BigDecimal to be a fraction. > 2226 * the computed result for the chosen rounding mode . > Extraneous space before period. Grammatical error will be fixed being pushing. > > In terms of additional testing, did you contemplate comparing the > consistency of the results versus BigInteger.sqrt()? Obviously one > would not be looking for equality in most cases. That is a natural extension and a fine idea for future additional testing :-) > > All in all I think this looks good insofar as my reading can tell. > > Reviewed +1. > > Thanks, -Joe From jan.lahoda at oracle.com Sat May 21 06:07:47 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Sat, 21 May 2016 08:07:47 +0200 Subject: RFR: 8157502: make docs broken after JDK-5100935 Message-ID: <573FFB33.1000306@oracle.com> Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8157502 make docs appears to be currently broken, fails with: --- # Running javadoc for support/javadoc/api/index.html .../jdk/src/java.base/share/classes/java/lang/StrictMath.java:855: error: reference not found * @see Math#multiplyFull(long,long) ^ 1 error --- As Math#multiplyFull(long,long) does not appear to exist, I assume the reference should be to Math#multiplyFull(int,int): diff -r 4cd0d71cf20e src/java.base/share/classes/java/lang/StrictMath.java --- a/src/java.base/share/classes/java/lang/StrictMath.java Fri May 20 16:34:14 2016 -0700 +++ b/src/java.base/share/classes/java/lang/StrictMath.java Sat May 21 07:29:57 2016 +0200 @@ -852,7 +852,7 @@ * @param x the first value * @param y the second value * @return the result - * @see Math#multiplyFull(long,long) + * @see Math#multiplyFull(int,int) * @since 1.9 */ public static long multiplyFull(int x, int y) { Does this seem OK? Thanks, Jan From Alan.Bateman at oracle.com Sat May 21 06:25:27 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 21 May 2016 07:25:27 +0100 Subject: RFR: 8157502: make docs broken after JDK-5100935 In-Reply-To: <573FFB33.1000306@oracle.com> References: <573FFB33.1000306@oracle.com> Message-ID: <573FFF57.50704@oracle.com> Looks fine. On 21/05/2016 07:07, Jan Lahoda wrote: > Hi, > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8157502 > > make docs appears to be currently broken, fails with: > --- > # Running javadoc for support/javadoc/api/index.html > .../jdk/src/java.base/share/classes/java/lang/StrictMath.java:855: > error: reference not found > * @see Math#multiplyFull(long,long) > ^ > 1 error > --- > > As Math#multiplyFull(long,long) does not appear to exist, I assume the > reference should be to Math#multiplyFull(int,int): > > diff -r 4cd0d71cf20e > src/java.base/share/classes/java/lang/StrictMath.java > --- a/src/java.base/share/classes/java/lang/StrictMath.java Fri May 20 > 16:34:14 2016 -0700 > +++ b/src/java.base/share/classes/java/lang/StrictMath.java Sat May 21 > 07:29:57 2016 +0200 > @@ -852,7 +852,7 @@ > * @param x the first value > * @param y the second value > * @return the result > - * @see Math#multiplyFull(long,long) > + * @see Math#multiplyFull(int,int) > * @since 1.9 > */ > public static long multiplyFull(int x, int y) { > > > Does this seem OK? > > Thanks, > Jan From naufal11 at gmail.com Sun May 22 10:10:41 2016 From: naufal11 at gmail.com (Mohamed Naufal) Date: Sun, 22 May 2016 15:40:41 +0530 Subject: [PATCH] Implement a noop clear() for Collections#EMPTY_LIST Message-ID: Hi, A call to clear() on Collections#EMPTY_LIST is currently redirected to AbstractList#clear(), which performs a bunch of checks and creates a ListItr object, all of which is unnecessary for an EmptyList. PFA a patch that implements a noop clear() for EmptyList. Thanks, Naufal -------------- next part -------------- # HG changeset patch # User Mohamed Naufal # Date 1463909563 -19800 # Sun May 22 15:02:43 2016 +0530 # Node ID df323f5c5f30ae3443063d5a2c40ee780cacce78 # Parent f8a3c1510f9525398d41bce83d79265762288e18 Collections: Implement a noop clear() for EmptyList diff -r f8a3c1510f95 -r df323f5c5f30 src/java.base/share/classes/java/util/Collections.java --- a/src/java.base/share/classes/java/util/Collections.java Thu May 19 17:48:02 2016 +0000 +++ b/src/java.base/share/classes/java/util/Collections.java Sun May 22 15:02:43 2016 +0530 @@ -4447,6 +4447,7 @@ public int size() {return 0;} public boolean isEmpty() {return true;} + public void clear() {} public boolean contains(Object obj) {return false;} public boolean containsAll(Collection c) { return c.isEmpty(); } From joe.darcy at oracle.com Sun May 22 16:51:27 2016 From: joe.darcy at oracle.com (joe darcy) Date: Sun, 22 May 2016 09:51:27 -0700 Subject: JDK 9 RFR Replace @since 1.9 with @since 9 on new math methods Message-ID: <31d6e156-e470-fadb-4f94-7b77b2e23a8d@oracle.com> Hello, Some recently added math methods since "@since 1.9" rather than "@since 9"; please review the patch below to use "@since 9" instead. Thanks, -Joe diff -r 997dcff5075f src/java.base/share/classes/java/lang/Math.java --- a/src/java.base/share/classes/java/lang/Math.java Sat May 21 13:18:15 2016 +0200 +++ b/src/java.base/share/classes/java/lang/Math.java Sun May 22 09:47:55 2016 -0700 @@ -916,7 +916,7 @@ * @param y the second value * @return the result * @throws ArithmeticException if the result overflows a long - * @since 1.9 + * @since 9 */ public static long multiplyExact(long x, int y) { return multiplyExact(x, (long)y); @@ -1186,7 +1186,7 @@ * @throws ArithmeticException if the divisor {@code y} is zero * @see #floorMod(long, int) * @see #floor(double) - * @since 1.9 + * @since 9 */ public static long floorDiv(long x, int y) { return floorDiv(x, (long)y); @@ -1294,7 +1294,7 @@ * @return the floor modulus {@code x - (floorDiv(x, y) * y)} * @throws ArithmeticException if the divisor {@code y} is zero * @see #floorDiv(long, int) - * @since 1.9 + * @since 9 */ public static int floorMod(long x, int y) { // Result cannot overflow the range of int. diff -r 997dcff5075f src/java.base/share/classes/java/lang/StrictMath.java --- a/src/java.base/share/classes/java/lang/StrictMath.java Sat May 21 13:18:15 2016 +0200 +++ b/src/java.base/share/classes/java/lang/StrictMath.java Sun May 22 09:47:55 2016 -0700 @@ -811,7 +811,7 @@ * @return the result * @throws ArithmeticException if the result overflows a long * @see Math#multiplyExact(long,int) - * @since 1.9 + * @since 9 */ public static long multiplyExact(long x, int y) { return Math.multiplyExact(x, y); @@ -853,7 +853,7 @@ * @param y the second value * @return the result * @see Math#multiplyFull(int,int) - * @since 1.9 + * @since 9 */ public static long multiplyFull(int x, int y) { return Math.multiplyFull(x, y); @@ -867,7 +867,7 @@ * @param y the second value * @return the result * @see Math#multiplyHigh(long,long) - * @since 1.9 + * @since 9 */ public static long multiplyHigh(long x, long y) { return Math.multiplyHigh(x, y); @@ -915,7 +915,7 @@ * @throws ArithmeticException if the divisor {@code y} is zero * @see Math#floorDiv(long, int) * @see Math#floor(double) - * @since 1.9 + * @since 9 */ public static long floorDiv(long x, int y) { return Math.floorDiv(x, y); @@ -994,7 +994,7 @@ * @throws ArithmeticException if the divisor {@code y} is zero * @see Math#floorMod(long, int) * @see StrictMath#floorDiv(long, int) - * @since 1.9 + * @since 9 */ public static int floorMod(long x, int y) { return Math.floorMod(x , y); From chris.hegarty at oracle.com Sun May 22 18:00:16 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 22 May 2016 19:00:16 +0100 Subject: JDK 9 RFR Replace @since 1.9 with @since 9 on new math methods In-Reply-To: <31d6e156-e470-fadb-4f94-7b77b2e23a8d@oracle.com> References: <31d6e156-e470-fadb-4f94-7b77b2e23a8d@oracle.com> Message-ID: <8C42C20F-33C1-4B6B-BC3A-4C68DB9389F0@oracle.com> > On 22 May 2016, at 17:51, joe darcy wrote: > > Hello, > > Some recently added math methods since "@since 1.9" rather than "@since 9"; please review the patch below to use "@since 9" instead. Looks fine Joe. -Chris. > Thanks, > > -Joe > > diff -r 997dcff5075f src/java.base/share/classes/java/lang/Math.java > --- a/src/java.base/share/classes/java/lang/Math.java Sat May 21 13:18:15 2016 +0200 > +++ b/src/java.base/share/classes/java/lang/Math.java Sun May 22 09:47:55 2016 -0700 > @@ -916,7 +916,7 @@ > * @param y the second value > * @return the result > * @throws ArithmeticException if the result overflows a long > - * @since 1.9 > + * @since 9 > */ > public static long multiplyExact(long x, int y) { > return multiplyExact(x, (long)y); > @@ -1186,7 +1186,7 @@ > * @throws ArithmeticException if the divisor {@code y} is zero > * @see #floorMod(long, int) > * @see #floor(double) > - * @since 1.9 > + * @since 9 > */ > public static long floorDiv(long x, int y) { > return floorDiv(x, (long)y); > @@ -1294,7 +1294,7 @@ > * @return the floor modulus {@code x - (floorDiv(x, y) * y)} > * @throws ArithmeticException if the divisor {@code y} is zero > * @see #floorDiv(long, int) > - * @since 1.9 > + * @since 9 > */ > public static int floorMod(long x, int y) { > // Result cannot overflow the range of int. > diff -r 997dcff5075f src/java.base/share/classes/java/lang/StrictMath.java > --- a/src/java.base/share/classes/java/lang/StrictMath.java Sat May 21 13:18:15 2016 +0200 > +++ b/src/java.base/share/classes/java/lang/StrictMath.java Sun May 22 09:47:55 2016 -0700 > @@ -811,7 +811,7 @@ > * @return the result > * @throws ArithmeticException if the result overflows a long > * @see Math#multiplyExact(long,int) > - * @since 1.9 > + * @since 9 > */ > public static long multiplyExact(long x, int y) { > return Math.multiplyExact(x, y); > @@ -853,7 +853,7 @@ > * @param y the second value > * @return the result > * @see Math#multiplyFull(int,int) > - * @since 1.9 > + * @since 9 > */ > public static long multiplyFull(int x, int y) { > return Math.multiplyFull(x, y); > @@ -867,7 +867,7 @@ > * @param y the second value > * @return the result > * @see Math#multiplyHigh(long,long) > - * @since 1.9 > + * @since 9 > */ > public static long multiplyHigh(long x, long y) { > return Math.multiplyHigh(x, y); > @@ -915,7 +915,7 @@ > * @throws ArithmeticException if the divisor {@code y} is zero > * @see Math#floorDiv(long, int) > * @see Math#floor(double) > - * @since 1.9 > + * @since 9 > */ > public static long floorDiv(long x, int y) { > return Math.floorDiv(x, y); > @@ -994,7 +994,7 @@ > * @throws ArithmeticException if the divisor {@code y} is zero > * @see Math#floorMod(long, int) > * @see StrictMath#floorDiv(long, int) > - * @since 1.9 > + * @since 9 > */ > public static int floorMod(long x, int y) { > return Math.floorMod(x , y); > From shilpi.rastogi at oracle.com Mon May 23 06:27:37 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Mon, 23 May 2016 11:57:37 +0530 Subject: RFR[9]: 8156868 MethodHandles.zero(Class) doc issues Message-ID: <5742A2D9.7020501@oracle.com> Hi All, Please review small doc changes- http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/ Fixed following doc issues in same patch https://bugs.openjdk.java.net/browse/JDK-8138599 http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/src/java.base/share/classes/java/lang/invoke/MemberName.java.sdiff.html https://bugs.openjdk.java.net/browse/JDK-8138597 http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/src/java.base/share/classes/java/lang/invoke/MethodHandle.java.sdiff.html https://bugs.openjdk.java.net/browse/JDK-8156868 http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/src/java.base/share/classes/java/lang/invoke/MethodHandles.java.sdiff.html https://bugs.openjdk.java.net/browse/JDK-8075283 http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/src/java.base/share/classes/jdk/internal/misc/Unsafe.java.sdiff.html Thanks, Shilpi From paul.sandoz at oracle.com Mon May 23 10:43:55 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 23 May 2016 12:43:55 +0200 Subject: [PATCH] Implement a noop clear() for Collections#EMPTY_LIST In-Reply-To: References: Message-ID: Hi Naufal, Thanks for looking at this. For us to accept your patch (no matter how small) you need to become a contributor, which requires that you agree to the Oracle Contributor Agreement (OCA), see: http://openjdk.java.net/contribute/ Thanks, Paul. > On 22 May 2016, at 12:10, Mohamed Naufal wrote: > > Hi, > > A call to clear() on Collections#EMPTY_LIST is currently redirected to > AbstractList#clear(), which performs a bunch of checks and creates a > ListItr object, all of which is unnecessary for an EmptyList. > > PFA a patch that implements a noop clear() for EmptyList. > > Thanks, > Naufal > From naufal11 at gmail.com Mon May 23 10:53:14 2016 From: naufal11 at gmail.com (Mohamed Naufal) Date: Mon, 23 May 2016 16:23:14 +0530 Subject: [PATCH] Implement a noop clear() for Collections#EMPTY_LIST In-Reply-To: References: Message-ID: Hi Paul, I've already sent a signed copy of the OCA to oracle-ca_us at oracle.com. Thanks, Naufal On 23 May 2016 at 16:13, Paul Sandoz wrote: > Hi Naufal, > > Thanks for looking at this. > > For us to accept your patch (no matter how small) you need to become a > contributor, which requires that you agree to the Oracle Contributor > Agreement (OCA), see: > > http://openjdk.java.net/contribute/ > > Thanks, > Paul. > > > On 22 May 2016, at 12:10, Mohamed Naufal wrote: > > > > Hi, > > > > A call to clear() on Collections#EMPTY_LIST is currently redirected to > > AbstractList#clear(), which performs a bunch of checks and creates a > > ListItr object, all of which is unnecessary for an EmptyList. > > > > PFA a patch that implements a noop clear() for EmptyList. > > > > Thanks, > > Naufal > > > > From david.holmes at oracle.com Mon May 23 11:25:57 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 23 May 2016 21:25:57 +1000 Subject: [PATCH] Implement a noop clear() for Collections#EMPTY_LIST In-Reply-To: References: Message-ID: <5e6d8838-7245-fb73-572f-b4af530389f1@oracle.com> On 23/05/2016 8:43 PM, Paul Sandoz wrote: > Hi Naufal, > > Thanks for looking at this. > > For us to accept your patch (no matter how small) you need to become a contributor, which requires that you agree to the Oracle Contributor Agreement (OCA), see: > > http://openjdk.java.net/contribute/ Simple patches can be accepted without an OCA http://openjdk.java.net/bylaws#participant Cheers, David > Thanks, > Paul. > >> On 22 May 2016, at 12:10, Mohamed Naufal wrote: >> >> Hi, >> >> A call to clear() on Collections#EMPTY_LIST is currently redirected to >> AbstractList#clear(), which performs a bunch of checks and creates a >> ListItr object, all of which is unnecessary for an EmptyList. >> >> PFA a patch that implements a noop clear() for EmptyList. >> >> Thanks, >> Naufal >> > From paul.sandoz at oracle.com Mon May 23 11:28:59 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 23 May 2016 13:28:59 +0200 Subject: [PATCH] Implement a noop clear() for Collections#EMPTY_LIST In-Reply-To: <5e6d8838-7245-fb73-572f-b4af530389f1@oracle.com> References: <5e6d8838-7245-fb73-572f-b4af530389f1@oracle.com> Message-ID: Hmm? apparently simple patches can be accepted without OCA as pointed out by David: http://openjdk.java.net/bylaws#participant Paul. > On 23 May 2016, at 13:25, David Holmes wrote: > > On 23/05/2016 8:43 PM, Paul Sandoz wrote: >> Hi Naufal, >> >> Thanks for looking at this. >> >> For us to accept your patch (no matter how small) you need to become a contributor, which requires that you agree to the Oracle Contributor Agreement (OCA), see: >> >> http://openjdk.java.net/contribute/ > > Simple patches can be accepted without an OCA > > http://openjdk.java.net/bylaws#participant > > Cheers, > David > >> Thanks, >> Paul. >> >>> On 22 May 2016, at 12:10, Mohamed Naufal wrote: >>> >>> Hi, >>> >>> A call to clear() on Collections#EMPTY_LIST is currently redirected to >>> AbstractList#clear(), which performs a bunch of checks and creates a >>> ListItr object, all of which is unnecessary for an EmptyList. >>> >>> PFA a patch that implements a noop clear() for EmptyList. >>> >>> Thanks, >>> Naufal >>> >> From paul.sandoz at oracle.com Mon May 23 11:30:59 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 23 May 2016 13:30:59 +0200 Subject: [PATCH] Implement a noop clear() for Collections#EMPTY_LIST In-Reply-To: References: <5e6d8838-7245-fb73-572f-b4af530389f1@oracle.com> Message-ID: Argh email address completion fail? that was meant for someone else? sorry for the noise, Paul. > On 23 May 2016, at 13:28, Paul Sandoz wrote: > > Hmm? apparently simple patches can be accepted without OCA as pointed out by David: > > http://openjdk.java.net/bylaws#participant > > Paul. > > >> On 23 May 2016, at 13:25, David Holmes > wrote: >> >> On 23/05/2016 8:43 PM, Paul Sandoz wrote: >>> Hi Naufal, >>> >>> Thanks for looking at this. >>> >>> For us to accept your patch (no matter how small) you need to become a contributor, which requires that you agree to the Oracle Contributor Agreement (OCA), see: >>> >>> http://openjdk.java.net/contribute/ >> >> Simple patches can be accepted without an OCA >> >> http://openjdk.java.net/bylaws#participant >> >> Cheers, >> David >> From peter.levart at gmail.com Mon May 23 14:56:22 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 23 May 2016 16:56:22 +0200 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: References: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> <8526fa40-f9ee-2c5d-4373-e9e0ceb40577@gmail.com> Message-ID: Hi Martin, On 05/20/2016 08:53 PM, Martin Buchholz wrote: > Peter, > > You keep impressing me with your development speed! > Looking at ObjectPool ... looking pretty good Thanks. > > keepalivetime should be > 0. Right. ScheduledThreadPoolExecutor.scheduleWithFixedDelay throws IllegalArgumentException when the 'delay' argument is not positive. ObjectPool should have the same check. > (also very small keepalive times are a > bad idea, but what's "very small"?) > I'm thinking one second for ZipFile keep alive time. Thread pools > have 60 seconds. Exactly. I set 1 second of keep-alive for the two pools in Inflater. > > Maybe we need a Consumer resetter in addition to a releaser. I've been thinking of that too. It makes the usages nicer as they don't have to deal with resetting the object before returning it to the pool. In addition, the pool could reset the object lazily just before handing it out again. The "resetter" could also serve as an object "validator" - either being a Predicate or a Consumer throwing an exception. Thinking of objects like Connection(s). In case validation fails, the pool would release the object and try another one. > > I'm opposed to creating a new STPE. jdk 9 CompletableFuture comes > with a hidden thread scheduler, so the idea is to use delayedExecutor > to share that one thread for all common scheduling. Nice. It even simplifies the ObjectPool that way. I peeked at code and I see it uses an internal shared STPE under the hood. > > I think you want to call pop poll instead, since it can return null? That's better yes. > > We want a purger task to be created at most once per keep alive > period, and never after the pool is quiescent. Not sure if we're > there yet. The task itself can be reused, yes. I wanted to respect the keepAliveTime so that pooled objects are released as soon as keepAliveTime is reached after last object was returned to the pool. I also wanted, as optimization, to schedule a task for periodic invocation, which only guarantees that objects are released sometime between keepAliveTime ... 2 * keepAliveTime after the last object is returned to the pool. But then I realized that periodic scheduling with constant delay is just a fancy API facade for scheduling next invocation at the end of the previous one. In either case the internal "heap" queue has to be updated at every firing of the task. So this is much simpler now with CompletableFuture: http://cr.openjdk.java.net/~plevart/jdk9-dev/ZipFile_Inflater.cleanup/webrev.03/ The only change from webrev.02 is in ObjectPool implementation. java/util/zip tests pass with this patch. The TestZipFile.java was failing for me with OOME and I had to increase the heap to 4G to make it pass. Heap dump shows that the test really needs that much. It keeps ZipEntries arround in a LinkedHashMap with associated byte[] arrays holding the contents of the zip-ed files. So, Martin, what do you think of this one? Regards, Peter > > On Fri, May 20, 2016 at 7:31 AM, Peter Levart wrote: >> Hi Martin, >> >> >> >> On 05/20/2016 02:51 AM, Martin Buchholz wrote: >>> On Thu, May 19, 2016 at 7:29 AM, Peter Levart >>> wrote: >>>> So Martin, what do you think? >>> I studied your code and we are fundamentally in agreement! >>> ... Except for need for periodic cleanup of the cache... >>> Maybe we should do >>> CompletableFuture.runAsync(purgeCache, >>> CompletableFuture.delayedExecutor(1, SECONDS)) >>> as a periodic task while cache is non-empty instead of my strategy of >>> relying on a weak reference. >>> >>> Purging a cache on quiescence in the optimal way seems to be a hard >>> problem. >>> Time to write ObjectPool (as many others have done before us)? >>> >>> ObjectPool(Supplier factory, Consumer releaser, maxCacheSize, >>> keepAliveTime) >>> >>> Except this time we'll do it right! With jdk9 machinery! >> >> Something like the following? >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZipFile_Inflater.cleanup/webrev.02/ >> >> I still must debug the cause of OutOfMemoryError in >> java/util/zip/ZipFile/TestZipFile.java. >> >> Regards, Peter >> From michael.haupt at oracle.com Mon May 23 14:58:42 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 23 May 2016 16:58:42 +0200 Subject: RFR(XS): 8157590: MethodHandles.arrayLength() lacks @since tag, implementation throws wrong exception Message-ID: <44888CD7-1C71-439A-BB7E-06D6219E48CE@oracle.com> Dear all, please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8157590 Webrev: http://cr.openjdk.java.net/~mhaupt/8157590/webrev.00/ Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Mon May 23 14:59:25 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 23 May 2016 16:59:25 +0200 Subject: RFR(M): 8156915: introduce MethodHandle factory for array length In-Reply-To: <00db01d1b26b$1fc9d1e0$5f5d75a0$@apache.org> References: <52930F20-0F98-40C8-9B61-554F73CE960B@oracle.com> <00db01d1b26b$1fc9d1e0$5f5d75a0$@apache.org> Message-ID: <0AFDCB4F-C408-4EC2-9280-3CECE4C1A734@oracle.com> ... thank you so much, Uwe - it's up for review now. Best, Michael > Am 20.05.2016 um 09:42 schrieb Uwe Schindler : > > Hi, > > I just noticed that there is the @since missing in javadocs: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fd39cefc5c8f#l3.13 > arrayConstructor has @since 9, but arrayLength() not. > > Uwe -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From paul.sandoz at oracle.com Mon May 23 15:38:40 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 23 May 2016 17:38:40 +0200 Subject: RFR[9]: 8156868 MethodHandles.zero(Class) doc issues In-Reply-To: <5742A2D9.7020501@oracle.com> References: <5742A2D9.7020501@oracle.com> Message-ID: <5F8C3A4C-3D8E-430B-A085-7B82E7D18D18@oracle.com> > On 23 May 2016, at 08:27, shilpi.rastogi at oracle.com wrote: > > Hi All, > > Please review small doc changes- > > http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/ > > Fixed following doc issues in same patch > > https://bugs.openjdk.java.net/browse/JDK-8138599 > http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/src/java.base/share/classes/java/lang/invoke/MemberName.java.sdiff.html > I think that?s an correct educated guess at completing the trailing sentence. > https://bugs.openjdk.java.net/browse/JDK-8138597 > http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/src/java.base/share/classes/java/lang/invoke/MethodHandle.java.sdiff.html > > https://bugs.openjdk.java.net/browse/JDK-8156868 > http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/src/java.base/share/classes/java/lang/invoke/MethodHandles.java.sdiff.html > +1 > https://bugs.openjdk.java.net/browse/JDK-8075283 > http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/src/java.base/share/classes/jdk/internal/misc/Unsafe.java.sdiff.html > Can you also update the same method on sun.misc.Unsafe in the jdk.unsupported module? Thanks, Paul. From daniel.fuchs at oracle.com Mon May 23 15:39:37 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 23 May 2016 17:39:37 +0200 Subject: RFR: 8146389: java/util/logging/XMLFormatterDate.java fails during year switch Message-ID: Hi, Please find below a patch for: 8146389: java/util/logging/XMLFormatterDate.java fails during year switch http://cr.openjdk.java.net/~dfuchs/webrev_8146389/webrev.00/index.html https://bugs.openjdk.java.net/browse/JDK-8146389 When JDK-8072645 (java.util.logging should use java.time to get more precise time stamps) the XML LogRecord content was changed to print by default the date using the instant in UTC and avoid the penalty to convert to the default time zone. A new logging property was defined to revert to the old format if needed. XMLFormatterDate.java then started to fail during the year switch, because it was expecting the year to be in the local time zone, which introduced a few hours lag compared to UTC. This patch fixes the test to test the correctness of the year in both new (UTC) and old (Local) date format. best regards, -- daniel From xueming.shen at oracle.com Mon May 23 15:44:06 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 23 May 2016 08:44:06 -0700 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: References: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> <8526fa40-f9ee-2c5d-4373-e9e0ceb40577@gmail.com> Message-ID: <3087f133-69a8-58b2-cc57-8f9854ae91b2@oracle.com> It appears the scope of the change is bigger than the problem we are trying to solve here. The problem we are having here is that in certain use scenario the vm keeps a huge number of zip/jar files open and in which makes even the minimal cache mechanism (keep even one deflater for one zip file) not desirable. It might be desirable to have a better cache mechanism, such as the "ObjectPool" approach you're proposing here, to help in this situation. But I doubt if it is necessary to extend the "functionality" to the rest of the package. For example, In most use scenario, we don't have such cache issue with the deflater/inflater, a usual "open-end+finalize()" mechanism appears just fine for now, I don't see a compelling reason to replace the existing mechanism with a new one. It might be better to be conservative here to not make big change to something not proven broken. It does not seem really necessary to have Deflater to be aware of the "ObjectPool" and the cleaner/ dealloctor, maybe all of these should be kept as an implementation inside the ObjectPool? which can have a cleaner to just invoke deflater.end() when needed? -Sherman On 5/23/16 7:56 AM, Peter Levart wrote: > Hi Martin, > > > On 05/20/2016 08:53 PM, Martin Buchholz wrote: >> Peter, >> >> You keep impressing me with your development speed! >> Looking at ObjectPool ... looking pretty good > > Thank > >> >> keepalivetime should be > 0. > > Right. ScheduledThreadPoolExecutor.scheduleWithFixedDelay throws > IllegalArgumentException when the 'delay' argument is not positive. > ObjectPool should have the same check. > >> (also very small keepalive times are a >> bad idea, but what's "very small"?) >> I'm thinking one second for ZipFile keep alive time. Thread pools >> have 60 seconds. > > Exactly. I set 1 second of keep-alive for the two pools in Inflater. > >> >> Maybe we need a Consumer resetter in addition to a releaser. > > I've been thinking of that too. It makes the usages nicer as they > don't have to deal with resetting the object before returning it to > the pool. In addition, the pool could reset the object lazily just > before handing it out again. The "resetter" could also serve as an > object "validator" - either being a Predicate or a Consumer throwing > an exception. Thinking of objects like Connection(s). In case > validation fails, the pool would release the object and try another one. > >> >> I'm opposed to creating a new STPE. jdk 9 CompletableFuture comes >> with a hidden thread scheduler, so the idea is to use delayedExecutor >> to share that one thread for all common scheduling. > > Nice. It even simplifies the ObjectPool that way. I peeked at code and > I see it uses an internal shared STPE under the hood. > >> >> I think you want to call pop poll instead, since it can return null? > > That's better yes. > >> >> We want a purger task to be created at most once per keep alive >> period, and never after the pool is quiescent. Not sure if we're >> there yet. > > The task itself can be reused, yes. I wanted to respect the > keepAliveTime so that pooled objects are released as soon as > keepAliveTime is reached after last object was returned to the pool. I > also wanted, as optimization, to schedule a task for periodic > invocation, which only guarantees that objects are released sometime > between keepAliveTime ... 2 * keepAliveTime after the last object is > returned to the pool. But then I realized that periodic scheduling > with constant delay is just a fancy API facade for scheduling next > invocation at the end of the previous one. In either case the internal > "heap" queue has to be updated at every firing of the task. > > So this is much simpler now with CompletableFuture: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/ZipFile_Inflater.cleanup/webrev.03/ > > > The only change from webrev.02 is in ObjectPool implementation. > > java/util/zip tests pass with this patch. The TestZipFile.java was > failing for me with OOME and I had to increase the heap to 4G to make > it pass. Heap dump shows that the test really needs that much. It > keeps ZipEntries arround in a LinkedHashMap with associated byte[] > arrays holding the contents of the zip-ed files. > > So, Martin, what do you think of this one? > > Regards, Peter > >> >> On Fri, May 20, 2016 at 7:31 AM, Peter Levart >> wrote: >>> Hi Martin, >>> >>> >>> >>> On 05/20/2016 02:51 AM, Martin Buchholz wrote: >>>> On Thu, May 19, 2016 at 7:29 AM, Peter Levart >>>> wrote: >>>>> So Martin, what do you think? >>>> I studied your code and we are fundamentally in agreement! >>>> ... Except for need for periodic cleanup of the cache... >>>> Maybe we should do >>>> CompletableFuture.runAsync(purgeCache, >>>> CompletableFuture.delayedExecutor(1, SECONDS)) >>>> as a periodic task while cache is non-empty instead of my strategy of >>>> relying on a weak reference. >>>> >>>> Purging a cache on quiescence in the optimal way seems to be a hard >>>> problem. >>>> Time to write ObjectPool (as many others have done before us)? >>>> >>>> ObjectPool(Supplier factory, Consumer releaser, maxCacheSize, >>>> keepAliveTime) >>>> >>>> Except this time we'll do it right! With jdk9 machinery! >>> >>> Something like the following? >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZipFile_Inflater.cleanup/webrev.02/ >>> >>> >>> I still must debug the cause of OutOfMemoryError in >>> java/util/zip/ZipFile/TestZipFile.java. >>> >>> Regards, Peter >>> > From paul.sandoz at oracle.com Mon May 23 16:12:50 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 23 May 2016 18:12:50 +0200 Subject: RFR(XS): 8157590: MethodHandles.arrayLength() lacks @since tag, implementation throws wrong exception In-Reply-To: <44888CD7-1C71-439A-BB7E-06D6219E48CE@oracle.com> References: <44888CD7-1C71-439A-BB7E-06D6219E48CE@oracle.com> Message-ID: > On 23 May 2016, at 16:58, Michael Haupt wrote: > > Dear all, > > please review this fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8157590 > Webrev: http://cr.openjdk.java.net/~mhaupt/8157590/webrev.00/ > +1 Paul. From huizhe.wang at oracle.com Mon May 23 17:17:18 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 23 May 2016 10:17:18 -0700 Subject: RFR: 8146389: java/util/logging/XMLFormatterDate.java fails during year switch In-Reply-To: References: Message-ID: <57433B1E.70007@oracle.com> Looks good, Daniel. -Joe On 5/23/2016 8:39 AM, Daniel Fuchs wrote: > Hi, > > Please find below a patch for: > 8146389: java/util/logging/XMLFormatterDate.java fails during > year switch > > http://cr.openjdk.java.net/~dfuchs/webrev_8146389/webrev.00/index.html > https://bugs.openjdk.java.net/browse/JDK-8146389 > > When JDK-8072645 (java.util.logging should use java.time to get > more precise time stamps) the XML LogRecord content was changed to print > by default the date using the instant in UTC and avoid the penalty > to convert to the default time zone. A new logging property was > defined to revert to the old format if needed. > > XMLFormatterDate.java then started to fail during the year switch, > because it was expecting the year to be in the local time zone, which > introduced a few hours lag compared to UTC. > > This patch fixes the test to test the correctness of the year in both > new (UTC) and old (Local) date format. > > best regards, > > -- daniel From peter.levart at gmail.com Mon May 23 18:00:38 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 23 May 2016 20:00:38 +0200 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: <3087f133-69a8-58b2-cc57-8f9854ae91b2@oracle.com> References: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> <8526fa40-f9ee-2c5d-4373-e9e0ceb40577@gmail.com> <3087f133-69a8-58b2-cc57-8f9854ae91b2@oracle.com> Message-ID: Hi Sherman, On 05/23/2016 05:44 PM, Xueming Shen wrote: > It appears the scope of the change is bigger than the problem we are > trying to solve here. The ClassLoader(s)/Resource changes are there just to measure the impact if input streams opened from a jar file are closed explicitly as soon as possible when loading classes. This makes the cache/pool of Inflater's native resources more efficient. Those changes are not meant to be included in this patch - will be stripped off and proposed as a separate enhancement later. There are also cleanups that are not absolutely necessary such as InflaterInputStream's package-private constructor with trusted subclasses using it so that usesDefaultInflater flag can be private and final in InflaterInputStream. They can be reverted if you don't like them. > > The problem we are having here is that in certain use scenario the vm > keeps a huge number > of zip/jar files open and in which makes even the minimal cache > mechanism (keep even one > deflater for one zip file) not desirable. Right. Even if vm keeps huge number of jar files open, it doesn't read from all of them at the same time, but typically a single thread only reads from one entry of one jar file at a time before going to the next one. So keeping an isolated cache of native resource that could be re-used to read from multiple jar files, per jar file, is not the most efficient way to cache it. It doesn't matter until the number of jar files is large and VMs with gigantic classpaths are an important use case. > > It might be desirable to have a better cache mechanism, such as the > "ObjectPool" approach you're > proposing here, to help in this situation. But I doubt if it is > necessary to extend the "functionality" > to the rest of the package. For example, In most use scenario, we > don't have such cache issue with > the deflater/inflater, a usual "open-end+finalize()" mechanism appears > just fine for now, I don't > see a compelling reason to replace the existing mechanism with a new > one. It might be better > to be conservative here to not make big change to something not proven > broken. As presented in my 1st message in the thread, what Martin is seeing is a combination of several issues: - class loading is not closing streams explicitly - caching is not effective for Inflaters for which the streams are closed with finalizers because when finalizer invokes close() on stream, the WeakHashMap is not keeping the InputStream any more, so the associated Inflater, while maybe still reachable in object graph, can not be retrieved (map.remove(stream) returns null). - caching of Inflaters for streams that happen to be explicitly closed is not bounded so they may pile-up. I claim that we must solve all 3 issues to make Martin happy again. :-) > > It does not seem really necessary to have Deflater to be aware of the > "ObjectPool" and the cleaner/ > dealloctor, maybe all of these should be kept as an implementation > inside the ObjectPool? which > can have a cleaner to just invoke deflater.end() when needed? Deflater is not aware of ObjectPool. It just uses Cleaner instead of finalize() because as a twin brother of Inflater, it would be nice for it to have the same cleanup mechanism. Cleaner is more efficient than finalization when the Deflater is explicitly end()-ed which is also a nice property. Otherwise the mechanism of Cleaner is similar to finalization. Cleaner is using PhantomReference(s) which are cleared when discovered and enqueued, while finalization is using FinalReference(s) which are not cleared and so present additional burden to CPU even in cases where Deflater is not explicitly end()ed. But if you don't like that, the changes to Deflater could be reverted back to using finalize(). Even Inflater could use finalize() for what it is worth, combined with ObjectPool, but why would we not take an opportunity and replace finalize() as we go? It's plain and simple. And Cleaner API was developed for just that purpose. > > -Sherman Regards, Peter > > > > On 5/23/16 7:56 AM, Peter Levart wrote: >> Hi Martin, >> >> >> On 05/20/2016 08:53 PM, Martin Buchholz wrote: >>> Peter, >>> >>> You keep impressing me with your development speed! >>> Looking at ObjectPool ... looking pretty good >> >> Thank >> >>> >>> keepalivetime should be > 0. >> >> Right. ScheduledThreadPoolExecutor.scheduleWithFixedDelay throws >> IllegalArgumentException when the 'delay' argument is not positive. >> ObjectPool should have the same check. >> >>> (also very small keepalive times are a >>> bad idea, but what's "very small"?) >>> I'm thinking one second for ZipFile keep alive time. Thread pools >>> have 60 seconds. >> >> Exactly. I set 1 second of keep-alive for the two pools in Inflater. >> >>> >>> Maybe we need a Consumer resetter in addition to a releaser. >> >> I've been thinking of that too. It makes the usages nicer as they >> don't have to deal with resetting the object before returning it to >> the pool. In addition, the pool could reset the object lazily just >> before handing it out again. The "resetter" could also serve as an >> object "validator" - either being a Predicate or a Consumer throwing >> an exception. Thinking of objects like Connection(s). In case >> validation fails, the pool would release the object and try another one. >> >>> >>> I'm opposed to creating a new STPE. jdk 9 CompletableFuture comes >>> with a hidden thread scheduler, so the idea is to use delayedExecutor >>> to share that one thread for all common scheduling. >> >> Nice. It even simplifies the ObjectPool that way. I peeked at code >> and I see it uses an internal shared STPE under the hood. >> >>> >>> I think you want to call pop poll instead, since it can return null? >> >> That's better yes. >> >>> >>> We want a purger task to be created at most once per keep alive >>> period, and never after the pool is quiescent. Not sure if we're >>> there yet. >> >> The task itself can be reused, yes. I wanted to respect the >> keepAliveTime so that pooled objects are released as soon as >> keepAliveTime is reached after last object was returned to the pool. >> I also wanted, as optimization, to schedule a task for periodic >> invocation, which only guarantees that objects are released sometime >> between keepAliveTime ... 2 * keepAliveTime after the last object is >> returned to the pool. But then I realized that periodic scheduling >> with constant delay is just a fancy API facade for scheduling next >> invocation at the end of the previous one. In either case the >> internal "heap" queue has to be updated at every firing of the task. >> >> So this is much simpler now with CompletableFuture: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZipFile_Inflater.cleanup/webrev.03/ >> >> >> The only change from webrev.02 is in ObjectPool implementation. >> >> java/util/zip tests pass with this patch. The TestZipFile.java was >> failing for me with OOME and I had to increase the heap to 4G to make >> it pass. Heap dump shows that the test really needs that much. It >> keeps ZipEntries arround in a LinkedHashMap with associated byte[] >> arrays holding the contents of the zip-ed files. >> >> So, Martin, what do you think of this one? >> >> Regards, Peter >> >>> >>> On Fri, May 20, 2016 at 7:31 AM, Peter Levart >>> wrote: >>>> Hi Martin, >>>> >>>> >>>> >>>> On 05/20/2016 02:51 AM, Martin Buchholz wrote: >>>>> On Thu, May 19, 2016 at 7:29 AM, Peter Levart >>>>> >>>>> wrote: >>>>>> So Martin, what do you think? >>>>> I studied your code and we are fundamentally in agreement! >>>>> ... Except for need for periodic cleanup of the cache... >>>>> Maybe we should do >>>>> CompletableFuture.runAsync(purgeCache, >>>>> CompletableFuture.delayedExecutor(1, SECONDS)) >>>>> as a periodic task while cache is non-empty instead of my strategy of >>>>> relying on a weak reference. >>>>> >>>>> Purging a cache on quiescence in the optimal way seems to be a hard >>>>> problem. >>>>> Time to write ObjectPool (as many others have done before us)? >>>>> >>>>> ObjectPool(Supplier factory, Consumer releaser, maxCacheSize, >>>>> keepAliveTime) >>>>> >>>>> Except this time we'll do it right! With jdk9 machinery! >>>> >>>> Something like the following? >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZipFile_Inflater.cleanup/webrev.02/ >>>> >>>> >>>> I still must debug the cause of OutOfMemoryError in >>>> java/util/zip/ZipFile/TestZipFile.java. >>>> >>>> Regards, Peter >>>> >> > From xueming.shen at oracle.com Mon May 23 18:28:33 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 23 May 2016 11:28:33 -0700 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: References: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> <8526fa40-f9ee-2c5d-4373-e9e0ceb40577@gmail.com> <3087f133-69a8-58b2-cc57-8f9854ae91b2@oracle.com> Message-ID: <57434BD1.4080009@oracle.com> On 05/23/2016 11:00 AM, Peter Levart wrote: > Hi Sherman, > > On 05/23/2016 05:44 PM, Xueming Shen wrote: >> It appears the scope of the change is bigger than the problem we are trying to solve here. > > The ClassLoader(s)/Resource changes are there just to measure the impact if input streams opened from a jar file are closed explicitly as soon as possible when loading classes. This makes the cache/pool of Inflater's native resources more efficient. Those changes are not meant to be included in this patch - will be stripped off and proposed as a separate enhancement later. > > There are also cleanups that are not absolutely necessary such as InflaterInputStream's package-private constructor with trusted subclasses using it so that usesDefaultInflater flag can be private and final in InflaterInputStream. They can be reverted if you don't like them. > >> >> The problem we are having here is that in certain use scenario the vm keeps a huge number >> of zip/jar files open and in which makes even the minimal cache mechanism (keep even one >> deflater for one zip file) not desirable. > > Right. Even if vm keeps huge number of jar files open, it doesn't read from all of them at the same time, but typically a single thread only reads from one entry of one jar file at a time before going to the next one. So keeping an isolated cache of native resource that could be re-used to read from multiple jar files, per jar file, is not the most efficient way to cache it. It doesn't matter until the number of jar files is large and VMs with gigantic classpaths are an important use case. > >> >> It might be desirable to have a better cache mechanism, such as the "ObjectPool" approach you're >> proposing here, to help in this situation. But I doubt if it is necessary to extend the "functionality" >> to the rest of the package. For example, In most use scenario, we don't have such cache issue with >> the deflater/inflater, a usual "open-end+finalize()" mechanism appears just fine for now, I don't >> see a compelling reason to replace the existing mechanism with a new one. It might be better >> to be conservative here to not make big change to something not proven broken. > > As presented in my 1st message in the thread, what Martin is seeing is a combination of several issues: > > - class loading is not closing streams explicitly > - caching is not effective for Inflaters for which the streams are closed with finalizers because when finalizer invokes close() on stream, the WeakHashMap is not keeping the InputStream any more, so the associated Inflater, while maybe still reachable in object graph, can not be retrieved (map.remove(stream) returns null). > - caching of Inflaters for streams that happen to be explicitly closed is not bounded so they may pile-up. > > I claim that we must solve all 3 issues to make Martin happy again. :-) > >> >> It does not seem really necessary to have Deflater to be aware of the "ObjectPool" and the cleaner/ >> dealloctor, maybe all of these should be kept as an implementation inside the ObjectPool? which >> can have a cleaner to just invoke deflater.end() when needed? > > Deflater is not aware of ObjectPool. It just uses Cleaner instead of finalize() because as a twin brother of Inflater, it would be nice for it to have the same cleanup mechanism. Cleaner is more efficient than finalization when the Deflater is explicitly end()-ed which is also a nice property. Otherwise the mechanism of Cleaner is similar to finalization. Cleaner is using PhantomReference(s) which are cleared when discovered and enqueued, while finalization is using FinalReference(s) which are not cleared and so present additional burden to CPU even in cases where Deflater is not explicitly end()ed. But if you don't like that, the changes to Deflater could be reverted back to using finalize(). > My apology. I meant to say "to have Inflater to be aware of the ObjectPool...". The proposed change switches from the finalizer to the ObjectPool to clean up the native resource for Inflater. It appears to be a bigger change. Which has a default 32/maxCacheSize and 1 secod keepAliveTime setting. It might have a big impact to existing applications on how to use the Inflater. It would be fine to have the ZipFile to arrange how to use the Inflater based on its use scenario, but I'm concerned if it's the correct approach to change the default behavior of Inflater, which might have nothing to do with ZipFile. sherman > Even Inflater could use finalize() for what it is worth, combined with ObjectPool, but why would we not take an opportunity and replace finalize() as we go? It's plain and simple. And Cleaner API was developed for just that purpose. From gilleshabran at gmail.com Fri May 20 09:38:45 2016 From: gilleshabran at gmail.com (Gilles Habran) Date: Fri, 20 May 2016 11:38:45 +0200 Subject: Fwd: Files.walk() is unusable because of AccessDeniedException In-Reply-To: References: Message-ID: Hello, why is my message still waiting for approval after a month ? Thank you. Best regards, Gilles ---------- Forwarded message ---------- From: Gilles Habran Date: 16 April 2016 at 07:33 Subject: Files.walk() is unusable because of AccessDeniedException To: core-libs-dev at openjdk.java.net Good morning, I am trying to use Files.walk() in a Java 8 way but it is broken. I am trying to create an app to manage files and size on all my Linux system (so I would walk from the root directory and show the 5 biggest files of each directory for example). *JDK-8039910* has been raised for this issue but it is closed (2014-11-22). Alan Bateman wrote that the method is working as intended but I don't see how this could be intended because at the moment, it is unusable in a Java 8 way and for me. When we use a terminal operations on the Stream returned by Files.walk(), we get a crash because of AccessDeniedException For example, here is the directory (rules.d) that makes everything crash : [9:51:20 - ghabran at arch:/tmp/chromium-pepper-flash]$ ll /usr/share/polkit-1 total 8.0K drwxr-xr-x 2 root root 4.0K Apr 14 09:18 actions *drwxr-x--- 2 root polkitd 4.0K Apr 14 09:18 rules.d* As you can see, as a simple user, I don't have access. It is not possible to apply a filter to check the attributes to manage the file/directory to see if we have the rights because an exception is thrown before we get to check the attributes. Here are several scenarios : 1) This doesn't crash (there seems to have no exception thrown). I get error code 0, no exception is printed on my terminal. try { Stream directoryTree = Files.walk(*Paths.get("/")*); directoryTree .filter(p -> { try { return Files.isRegularFile(p) && Files.isReadable(p); } catch (Exception e) { return false; } }); } catch (IOException ioe) { System.out.println(ioe); } 2) this raises the exception AccessDeniedException (this goes in the catch) try { Stream directoryTree = Files.walk( *Paths.get("/usr/share/polkit-1/rules.d")*); directoryTree .filter(p -> { try { return Files.isRegularFile(p) && Files.isReadable(p); } catch (Exception e) { return false; } }); *} catch (IOException ioe) {* * System.out.println(ioe);* *}* 3) this crashes with a stack trace : AccessDeniedException *(this doesn't go in the catch)* try { Stream directoryTree = Files.walk(*Paths.get("/")*); directoryTree .filter(p -> { try { return Files.isRegularFile(p) && Files.isReadable(p); } catch (Exception e) { return false; } })*.forEach(System.out::println);* } catch (IOException ioe) { System.out.println(ioe); } 4) this crashes but goes into the catch try { Stream directoryTree = Files.walk( *Paths.get("/usr/share/polkit-1/rules.d")*); directoryTree .filter(p -> { try { return Files.isRegularFile(p) && Files.isReadable(p); } catch (Exception e) { return false; } })*.forEach(System.out::println)*; *} catch (IOException ioe) {* * System.out.println(ioe);* *}* In the meantime, I will use the old way with walkFileTree and a FileVisitor. How am I supposed to walk() a directory tree in Java 8 without walk() ? I was looking forward to using Stream to do it but I can't. What should I do ? Thank you. Regards, Gilles From martinrb at google.com Mon May 23 19:21:06 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 23 May 2016 12:21:06 -0700 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: <57434BD1.4080009@oracle.com> References: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> <8526fa40-f9ee-2c5d-4373-e9e0ceb40577@gmail.com> <3087f133-69a8-58b2-cc57-8f9854ae91b2@oracle.com> <57434BD1.4080009@oracle.com> Message-ID: On Mon, May 23, 2016 at 11:28 AM, Xueming Shen wrote: > The proposed change switches from the finalizer to the ObjectPool to clean > up > the native resource for Inflater. It appears to be a bigger change. Which > has > a default 32/maxCacheSize and 1 secod keepAliveTime setting. It might have > a big impact to existing applications on how to use the Inflater. It would > be > fine to have the ZipFile to arrange how to use the Inflater based on its use > scenario, but I'm concerned if it's the correct approach to change the > default > behavior of Inflater, which might have nothing to do with ZipFile. This _is_ becoming a big scary change, but getting rid of the rat's nest of finalizers is definitely progress. I am still contending that zstream caching is not worth much. The best I could do with a synthetic benchmark designed to make caching win was 25% better performance. Martin's rule is if you can't even come up with a friendly benchmark that gives you a 2x win, give up on your optimization! So performance wise, there is no big impact here on any applications, except to fix excessive memory retention and OOME. (but yeah, it's barely worth maintaining a cache, because this code is so performance critical) From martinrb at google.com Mon May 23 19:49:45 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 23 May 2016 12:49:45 -0700 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: References: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> <8526fa40-f9ee-2c5d-4373-e9e0ceb40577@gmail.com> <3087f133-69a8-58b2-cc57-8f9854ae91b2@oracle.com> <57434BD1.4080009@oracle.com> Message-ID: The utterly boring parts of my changes are in http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ZipFile-tidy/ Can we get these in now? From xueming.shen at oracle.com Mon May 23 19:55:24 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 23 May 2016 12:55:24 -0700 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: References: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> <8526fa40-f9ee-2c5d-4373-e9e0ceb40577@gmail.com> <3087f133-69a8-58b2-cc57-8f9854ae91b2@oracle.com> <57434BD1.4080009@oracle.com> Message-ID: <5743602C.8000802@oracle.com> looks fine. i just pushed in a change. so you may need a sync :-) On 5/23/16, 12:49 PM, Martin Buchholz wrote: > The utterly boring parts of my changes are in > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ZipFile-tidy/ > Can we get these in now? From martinrb at google.com Mon May 23 20:16:11 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 23 May 2016 13:16:11 -0700 Subject: VarHandles on non-int-sized fields and atomic operations Message-ID: I believe C++ allows anything to be atomic using their atomic<> template. Having the atomic annotation at the declaration site: - makes it obvious to the human and the compiler that the data must be accessed atomically. - allows the compiler to lay out the data so that native cpu instructions can access the data efficiently and atomically. So it is likely that atomic will be stored in a 32-bit field, since the cpu is likely to have a 32-bit cas, but not 16-bit cas. With VarHandles, the declared fields are Ordinary Java Fields, so they are likely to be layed out as with normal fields. As a result, it looks like you can't do a cas with a VarHandle to a short field. If that's true, then the hardware is intruding into the API. What happens when a platform with only a 64-bit CAS comes along? Since atomic fields need different field layout from regular fields, it seems to make sense to require that fields which will be accessed via a VarHandle are clearly marked as being "atomic" in some way. With the Unsafe API, we sort-of got this by requiring that fields be volatile (although some users surely cheated here), and because there was no Unsafe.compareAndSwapShort (but there is with VarHandles!) My original motivation was to be able to replace an AtomicBoolean with a VarHandle to a boolean field. From martinrb at google.com Mon May 23 20:26:59 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 23 May 2016 13:26:59 -0700 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: <5743602C.8000802@oracle.com> References: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> <8526fa40-f9ee-2c5d-4373-e9e0ceb40577@gmail.com> <3087f133-69a8-58b2-cc57-8f9854ae91b2@oracle.com> <57434BD1.4080009@oracle.com> <5743602C.8000802@oracle.com> Message-ID: On Mon, May 23, 2016 at 12:55 PM, Xueming Shen wrote: > looks fine. i just pushed in a change. so you may need a sync :-) Thanks - pushed. From martinrb at google.com Mon May 23 20:32:10 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 23 May 2016 13:32:10 -0700 Subject: RFR: JDK-8153768 Miscellaneous changes imported from jsr166 CVS 2016-05 Message-ID: JSR166 CVS has some unfinished work in progress, but enough minor changes have accumulated that we should integrate into openjdk9: http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/ https://bugs.openjdk.java.net/browse/JDK-8153768 From xueming.shen at oracle.com Mon May 23 20:33:57 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 23 May 2016 13:33:57 -0700 Subject: [9] RFR: Static build of libzip is missing JNI_OnLoad_zip entry point In-Reply-To: <1529814e-b041-a3bd-29e2-a5ca80ee7ed4@oracle.com> References: <1529814e-b041-a3bd-29e2-a5ca80ee7ed4@oracle.com> Message-ID: <57436935.5030807@oracle.com> looks fine. On 05/20/2016 04:16 PM, Naoto Sato wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8150179 > > The proposed fix is located at: > > http://cr.openjdk.java.net/~naoto/8150179/webrev.00/ > > The fix is to simply bring the JNI OnLoad entry point back from ZipFile.c which was removed. > > Naoto From peter.levart at gmail.com Mon May 23 21:28:35 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 23 May 2016 23:28:35 +0200 Subject: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters In-Reply-To: <57434BD1.4080009@oracle.com> References: <7248e68b-2d4e-3994-e3b4-246563b075ac@gmail.com> <8526fa40-f9ee-2c5d-4373-e9e0ceb40577@gmail.com> <3087f133-69a8-58b2-cc57-8f9854ae91b2@oracle.com> <57434BD1.4080009@oracle.com> Message-ID: <0390ca0a-b9c6-5a9a-5707-04ef2e78c4f9@gmail.com> Hi Sherman, Martin, On 05/23/2016 08:28 PM, Xueming Shen wrote: > My apology. I meant to say "to have Inflater to be aware of the > ObjectPool...". > The proposed change switches from the finalizer to the ObjectPool to > clean up > the native resource for Inflater. It appears to be a bigger change. > Which has > a default 32/maxCacheSize and 1 secod keepAliveTime setting. It might have > a big impact to existing applications on how to use the Inflater. It > would be > fine to have the ZipFile to arrange how to use the Inflater based on > its use > scenario, but I'm concerned if it's the correct approach to change the > default > behavior of Inflater, which might have nothing to do with ZipFile. > > sherman It might have a big impact to existing applications, yes. A positive one! On 05/23/2016 09:21 PM, Martin Buchholz wrote: > .... > I am still contending that zstream caching is not worth much. The > best I could do with a synthetic benchmark designed to make caching > win was 25% better performance. Martin's rule is if you can't even > come up with a friendly benchmark that gives you a 2x win, give up on > your optimization! So performance wise, there is no big impact here > on any applications, except to fix excessive memory retention and > OOME. > > Here's the 1st test I did. The micro benchmark Martin created and is attached to the issue 8156484. Just modified a bit to issue a heap dump at the end: public class Benchmark60kMulti { private static void dumpHistogram() { // dump a heap histogram try { new ProcessBuilder( System.getProperty("java.home") + "/bin/jmap", "-histo:live", String.valueOf(ProcessHandle.current().getPid()) ).redirectOutput(ProcessBuilder.Redirect.to( new File("histo_live.txt")) ).start().waitFor(); } catch (Exception e) { e.printStackTrace(); } } public static void main(String[] args) throws Throwable { final int REPS = 20; final int THREADS = 8; final byte[] data = "123456789".getBytes("UTF-8"); final File file = new File("60k.zip"); if (!file.exists()) { try (FileOutputStream fos = new FileOutputStream(file); BufferedOutputStream bos = new BufferedOutputStream(fos); ZipOutputStream zos = new ZipOutputStream(bos)) { for (int i = 0; i < 60_000; i++) { ZipEntry ze = new ZipEntry(i + ".txt"); ze.setMethod(ZipEntry.DEFLATED); ze.setSize(0); ze.setCrc(0); zos.putNextEntry(ze); zos.write(data); } } } Path target = Paths.get("60k.zip"); for (int i = 0; i < THREADS; i++) { Path link = Paths.get("symlink-" + i + ".zip"); if (!link.toFile().exists()) Files.createSymbolicLink(link, target); } ExecutorService pool = Executors.newFixedThreadPool(THREADS); ArrayList> futures = new ArrayList<>(); for (int i = 0; i < THREADS; i++) { final Path link = Paths.get("symlink-" + i + ".zip"); final Runnable task = () -> { try (ZipFile zipFile = new ZipFile(link.toFile())) { for (int j = 0; j < REPS; j++) { byte[] buf = new byte[100]; Enumeration entries = zipFile.entries(); while (entries.hasMoreElements()) { ZipEntry zentry = entries.nextElement(); try (InputStream is = zipFile.getInputStream(zentry)) { is.read(buf); } } } } catch (Throwable t) { throw new Error(t); } }; futures.add(pool.submit(task)); } pool.shutdown(); for (Future future : futures) future.get(); dumpHistogram(); pool.awaitTermination(1, TimeUnit.DAYS); } } "time" Linux command and a top-10 heap dump of live objects: real 0m22.197s user 1m34.968s sys 0m12.577s num #instances #bytes class name (module) ------------------------------------------------------- 1: 3621046 704046712 [B (java.base at 9-internal) 2: 2410133 96405320 java.lang.ref.Finalizer (java.base at 9-internal) 3: 1572755 75492240 java.util.zip.ZipFile$ZipFileInputStream (java.base at 9-internal) 4: 1204735 67465160 java.util.zip.ZipFile$ZipFileInflaterInputStream (java.base at 9-internal) 5: 4597 147104 java.util.HashMap$Node (java.base at 9-internal) 6: 5875 141000 java.lang.String (java.base at 9-internal) 7: 1140 138656 java.lang.Class (java.base at 9-internal) 8: 2681 85792 java.util.concurrent.ConcurrentHashMap$Node (java.base at 9-internal) 9: 1938 84760 [Ljava.lang.Object; (java.base at 9-internal) 10: 636 61056 [Ljava.util.HashMap$Node; (java.base at 9-internal) With webrev.03 applied: real 0m6.734s user 0m32.937s sys 0m13.760s num #instances #bytes class name (module) ------------------------------------------------------- 1: 6903 483592 [B (java.base at 9-internal) 2: 4598 147136 java.util.HashMap$Node (java.base at 9-internal) 3: 1177 143112 java.lang.Class (java.base at 9-internal) 4: 5936 142464 java.lang.String (java.base at 9-internal) 5: 2681 85792 java.util.concurrent.ConcurrentHashMap$Node (java.base at 9-internal) 6: 1943 84608 [Ljava.lang.Object; (java.base at 9-internal) 7: 2 65568 [Ljava.util.concurrent.ForkJoinTask; (java.base at 9-internal) 8: 637 61136 [Ljava.util.HashMap$Node; (java.base at 9-internal) 9: 11 33696 [C (java.base at 9-internal) 10: 637 30576 java.util.HashMap (java.base at 9-internal) I think this is more than 2x win in speed, don't you? Not to mention memory. Regards, Peter From aleksey.shipilev at oracle.com Mon May 23 22:15:10 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 24 May 2016 01:15:10 +0300 Subject: VarHandles on non-int-sized fields and atomic operations In-Reply-To: References: Message-ID: <574380EE.7080607@oracle.com> On 05/23/2016 11:16 PM, Martin Buchholz wrote: > With VarHandles, the declared fields are Ordinary Java Fields, so they > are likely to be layed out as with normal fields. > As a result, it looks like you can't do a cas with a VarHandle to a > short field. > If that's true, then the hardware is intruding into the API. > What happens when a platform with only a 64-bit CAS comes along? Then you will get an exception trying to do the CAS. > Since atomic fields need different field layout from regular fields, > it seems to make sense to require that fields which will be accessed > via a VarHandle are clearly marked as being "atomic" in some way. Mark that as "volatile int" :) Because if marking boolean field with some "atomic" quantifier would blow up its storage to at least int, that's what you get in the end anyhow. > With the Unsafe API, we sort-of got this by requiring that fields be > volatile (although some users surely cheated here), and because there > was no Unsafe.compareAndSwapShort (but there is with VarHandles!) Notice there is still no magic: we still can do CASes only on ints, longs, references. (This is still a common denominator among all supported platforms). > My original motivation was to be able to replace an AtomicBoolean with > a VarHandle to a boolean field. No can do. AtomicBoolean, alas, should still keep "volatile int". See the relevant discussion about this here: http://mail.openjdk.java.net/pipermail/jmm-dev/2015-August/000193.html Thanks, -Aleksey From martinrb at google.com Mon May 23 22:16:55 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 23 May 2016 15:16:55 -0700 Subject: VarHandles on non-int-sized fields and atomic operations In-Reply-To: References: Message-ID: On Mon, May 23, 2016 at 1:16 PM, Martin Buchholz wrote: > So it is likely that > atomic > will be stored in a 32-bit field, since the cpu is likely to have a > 32-bit cas, but not 16-bit cas. So apparently you can still store your atomic in 16 bits, by implementing strong CAS and atomic assignment using read+mask+cas on enclosing 32 bits in a loop. But if you knew ahead of time that your short was going to be atomic, you might want to give it those extra 16 bits anyways? From aleksey.shipilev at oracle.com Mon May 23 22:29:57 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 24 May 2016 01:29:57 +0300 Subject: RFR: JDK-8153768 Miscellaneous changes imported from jsr166 CVS 2016-05 In-Reply-To: References: Message-ID: <57438465.2020403@oracle.com> On 05/23/2016 11:32 PM, Martin Buchholz wrote: > JSR166 CVS has some unfinished work in progress, but enough minor > changes have accumulated that we should integrate into openjdk9: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/ *) Removing Cloneable from submaps probably requires CCC? *) Want to be extra modern in sample code? Use method references! - * solvers.forEach((solver) -> cs.submit(solver)); + * solvers.forEach(cs::submit); Otherwise looks okay. Thanks, -Aleksey From martinrb at google.com Mon May 23 22:32:20 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 23 May 2016 15:32:20 -0700 Subject: VarHandles on non-int-sized fields and atomic operations In-Reply-To: <574380EE.7080607@oracle.com> References: <574380EE.7080607@oracle.com> Message-ID: On Mon, May 23, 2016 at 3:15 PM, Aleksey Shipilev wrote: >> Since atomic fields need different field layout from regular fields, >> it seems to make sense to require that fields which will be accessed >> via a VarHandle are clearly marked as being "atomic" in some way. > > Mark that as "volatile int" :) Because if marking boolean field with > some "atomic" quantifier would blow up its storage to at least int, > that's what you get in the end anyhow. But that's violating the abstraction boundary! You can use AtomicBoolean without being aware of whether you are actually generating 1-bit, 8-bit or 32-bit CASes. That's the JVM's job! It's going back to Evil Old C if we start having to encode our booleans using ints, just because of the instructions common on today's CPUs. It's true that users had to do this with Unsafe, but aren't VarHandles supposed to be a public high level replacement? I think we're losing something if any VarHandles to primitive types fail to have a CAS. From aleksey.shipilev at oracle.com Mon May 23 22:48:03 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 24 May 2016 01:48:03 +0300 Subject: VarHandles on non-int-sized fields and atomic operations In-Reply-To: References: <574380EE.7080607@oracle.com> Message-ID: <574388A3.90706@oracle.com> On 05/24/2016 01:32 AM, Martin Buchholz wrote: > On Mon, May 23, 2016 at 3:15 PM, Aleksey Shipilev > wrote: >>> Since atomic fields need different field layout from regular fields, >>> it seems to make sense to require that fields which will be accessed >>> via a VarHandle are clearly marked as being "atomic" in some way. >> >> Mark that as "volatile int" :) Because if marking boolean field with >> some "atomic" quantifier would blow up its storage to at least int, >> that's what you get in the end anyhow. > > But that's violating the abstraction boundary! > > You can use AtomicBoolean without being aware of whether you are > actually generating 1-bit, 8-bit or 32-bit CASes. That's the JVM's > job! Even JVM is just a program and cannot perform miracles. By the way, what exactly are you winning with 1-byte field in AtomicBoolean? java.util.concurrent.atomic.AtomicBoolean object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 4 (object header) N/A 4 4 (object header) N/A 8 4 (object header) N/A 12 4 int AtomicBoolean.value 0 Instance size: 16 bytes Making AtomicBoolean.value boolean would not decrease instance size, because it will still be rounded towards 16 bytes, with 3 bytes alignment shadow. > It's going back to Evil Old C if we start having to encode our > booleans using ints, just because of the instructions common on > today's CPUs. It's true that users had to do this with Unsafe, but > aren't VarHandles supposed to be a public high level replacement? VarHandles is hardly "high level", pretty much like MethodHandles are not high level. Those are building blocks to be used in library/runtime code. What Unsafe accesses could do, VarHandles can also do (sometimes more) -- without violating correctness and platform reliability. > I think we're losing something if any VarHandles to primitive types > fail to have a CAS. Not "any", int/long/reference VarHandles still do CASes. Note that the current API does not preclude implementing CASes for other types if you can come up with a plausible mechanics of doing so. The thing is, there does not seem to be a plausible fallback strategy when platform cannot do a subword CAS. Or at least I cannot see it. Artisanal Unsafe.compareAndSwapBoolean implementations are welcome :) Thanks, -Aleksey From martinrb at google.com Mon May 23 23:03:20 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 23 May 2016 16:03:20 -0700 Subject: RFR: JDK-8153768 Miscellaneous changes imported from jsr166 CVS 2016-05 In-Reply-To: <57438465.2020403@oracle.com> References: <57438465.2020403@oracle.com> Message-ID: On Mon, May 23, 2016 at 3:29 PM, Aleksey Shipilev wrote: > On 05/23/2016 11:32 PM, Martin Buchholz wrote: >> JSR166 CVS has some unfinished work in progress, but enough minor >> changes have accumulated that we should integrate into openjdk9: >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/ > > *) Removing Cloneable from submaps probably requires CCC? It never appears in the API. The use of Cloneable here was a mistake - the clone method was never implemented! So only users who checked for "implements Cloneable" without actually trying to call clone could be affected. And who would try to clone submaps anyways? > *) Want to be extra modern in sample code? Use method references! > - * solvers.forEach((solver) -> cs.submit(solver)); > + * solvers.forEach(cs::submit); OK - switched to using method references! From martinrb at google.com Mon May 23 23:20:46 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 23 May 2016 16:20:46 -0700 Subject: VarHandles on non-int-sized fields and atomic operations In-Reply-To: <574388A3.90706@oracle.com> References: <574380EE.7080607@oracle.com> <574388A3.90706@oracle.com> Message-ID: On Mon, May 23, 2016 at 3:48 PM, Aleksey Shipilev wrote: > By the way, what exactly are you winning with 1-byte field in AtomicBoolean? I'm not trying to replace the int field inside the AtomicBoolean with a boolean - that's an implementation detail. (Although I would take it if I could declare an atomic boolean inside AtomicBoolean and let the JVM choose the best size for the platform. It *is* a small weakness that we need to use the "int" type here in java code) I'm trying to allow regular programmers to declare their primitive fields with the natural Java type and have all the atomic operations available. > Not "any", int/long/reference VarHandles still do CASes. Note that the > current API does not preclude implementing CASes for other types if you > can come up with a plausible mechanics of doing so. > > The thing is, there does not seem to be a plausible fallback strategy > when platform cannot do a subword CAS. Or at least I cannot see it. > Artisanal Unsafe.compareAndSwapBoolean implementations are welcome :) As I said in a previous message, you can implement subword CAS using fullword CAS in a loop. cas8bit(expect, update) { for (;;) { fullword = atomicRead32() if ((fullword &0xff) != expect) return false; if (cas32(fullword, (fullword & ~0xff) | update) return true; } } but it would probably be more efficient if a fullword was allocated for the subword field. From martinrb at google.com Tue May 24 00:55:46 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 23 May 2016 17:55:46 -0700 Subject: VarHandles on non-int-sized fields and atomic operations In-Reply-To: <574388A3.90706@oracle.com> References: <574380EE.7080607@oracle.com> <574388A3.90706@oracle.com> Message-ID: Another way to look at it: We have an existing field boolean closed; which should be updated using CAS for correctness, but currently is not. I should not have to change the type of the field to int just so that I can get something that is CASable. From john.r.rose at oracle.com Tue May 24 02:43:36 2016 From: john.r.rose at oracle.com (John Rose) Date: Mon, 23 May 2016 19:43:36 -0700 Subject: VarHandles on non-int-sized fields and atomic operations In-Reply-To: References: <574380EE.7080607@oracle.com> <574388A3.90706@oracle.com> Message-ID: <0FAA8D1C-0FB5-4058-A8C5-E905306E6D84@oracle.com> On May 23, 2016, at 4:20 PM, Martin Buchholz wrote: > > As I said in a previous message, you can implement subword CAS using > fullword CAS in a loop. > > cas8bit(expect, update) { > for (;;) { > fullword = atomicRead32() > if ((fullword &0xff) != expect) return false; > if (cas32(fullword, (fullword & ~0xff) | update) return true; > } > } Yes, that's the "artisanal" version I would reach for. It doesn't scale well if there is unrelated activity on nearby bytes. But, for that matter, "nearby" can mean "within 64 bytes", which is why we have @Contended for when we really need it. ? John From amy.lu at oracle.com Tue May 24 06:10:30 2016 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 24 May 2016 14:10:30 +0800 Subject: JDK 9 RFR of JDK-8151768: Consider moving pack200 tests to tier 1 Message-ID: <5743F056.9040005@oracle.com> Currently tools/pack200 tests are defined to be part of tier 2 testing. The pack200 tests have a history of finding VM issue and they are good candidates for tier 1 testing, in which trying to cover VM-related functionality. This patch is to move tools/pack200 tests from tier2 to tier1. bug: https://bugs.openjdk.java.net/browse/JDK-8151768 webrev: http://cr.openjdk.java.net/~amlu/8151768/webrev.00/ Thanks, Amy --- old/test/TEST.groups 2016-05-24 13:44:38.000000000 +0800 +++ new/test/TEST.groups 2016-05-24 13:44:38.000000000 +0800 @@ -34,7 +34,8 @@ sun/nio/cs/ISO8859x.java \ java/nio/Buffer \ com/sun/crypto/provider/Cipher \ - :jdk_math + :jdk_math \ + tools/pack200 tier2 = \ java/lang/ProcessHandle/TreeTest.java \ @@ -50,6 +51,7 @@ -com/sun/crypto/provider/Cipher \ :jdk_text \ :core_tools \ + -tools/pack200 \ :jdk_other tier3 = \ From joe.darcy at oracle.com Tue May 24 06:32:07 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 23 May 2016 23:32:07 -0700 Subject: JDK 9 RFR of JDK-8151768: Consider moving pack200 tests to tier 1 In-Reply-To: <5743F056.9040005@oracle.com> References: <5743F056.9040005@oracle.com> Message-ID: Looks fine Amy; thanks, -Joe On 5/23/2016 11:10 PM, Amy Lu wrote: > Currently tools/pack200 tests are defined to be part of tier 2 > testing. The pack200 tests have a history of finding VM issue and they > are good candidates for tier 1 testing, in which trying to cover > VM-related functionality. > > This patch is to move tools/pack200 tests from tier2 to tier1. > > bug: https://bugs.openjdk.java.net/browse/JDK-8151768 > webrev: http://cr.openjdk.java.net/~amlu/8151768/webrev.00/ > > Thanks, > Amy > > --- old/test/TEST.groups 2016-05-24 13:44:38.000000000 +0800 > +++ new/test/TEST.groups 2016-05-24 13:44:38.000000000 +0800 > @@ -34,7 +34,8 @@ > sun/nio/cs/ISO8859x.java \ > java/nio/Buffer \ > com/sun/crypto/provider/Cipher \ > - :jdk_math > + :jdk_math \ > + tools/pack200 > > tier2 = \ > java/lang/ProcessHandle/TreeTest.java \ > @@ -50,6 +51,7 @@ > -com/sun/crypto/provider/Cipher \ > :jdk_text \ > :core_tools \ > + -tools/pack200 \ > :jdk_other > > tier3 = \ > > From shilpi.rastogi at oracle.com Tue May 24 06:40:47 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Tue, 24 May 2016 12:10:47 +0530 Subject: RFR[9]: 8156868 MethodHandles.zero(Class) doc issues In-Reply-To: <5F8C3A4C-3D8E-430B-A085-7B82E7D18D18@oracle.com> References: <5742A2D9.7020501@oracle.com> <5F8C3A4C-3D8E-430B-A085-7B82E7D18D18@oracle.com> Message-ID: <5743F76F.50905@oracle.com> Thanks Paul!! Please see http://cr.openjdk.java.net/~srastogi/8156868/webrev.02/ On 5/23/2016 9:08 PM, Paul Sandoz wrote: >> On 23 May 2016, at 08:27, shilpi.rastogi at oracle.com wrote: >> >> Hi All, >> >> Please review small doc changes- >> >> http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/ >> >> Fixed following doc issues in same patch >> >> https://bugs.openjdk.java.net/browse/JDK-8138599 >> http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/src/java.base/share/classes/java/lang/invoke/MemberName.java.sdiff.html >> > I think that?s an correct educated guess at completing the trailing sentence. > > >> https://bugs.openjdk.java.net/browse/JDK-8138597 >> http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/src/java.base/share/classes/java/lang/invoke/MethodHandle.java.sdiff.html >> >> https://bugs.openjdk.java.net/browse/JDK-8156868 >> http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/src/java.base/share/classes/java/lang/invoke/MethodHandles.java.sdiff.html >> > +1 > > >> https://bugs.openjdk.java.net/browse/JDK-8075283 >> http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/src/java.base/share/classes/jdk/internal/misc/Unsafe.java.sdiff.html >> > Can you also update the same method on sun.misc.Unsafe in the jdk.unsupported module? http://cr.openjdk.java.net/~srastogi/8156868/webrev.02/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java.sdiff.html Regards, Shilpi > > Thanks, > Paul. From david.holmes at oracle.com Tue May 24 06:50:12 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 24 May 2016 16:50:12 +1000 Subject: VarHandles on non-int-sized fields and atomic operations In-Reply-To: References: <574380EE.7080607@oracle.com> <574388A3.90706@oracle.com> Message-ID: <8aa84136-6fa6-30fd-e939-a070c90994fa@oracle.com> On 24/05/2016 9:20 AM, Martin Buchholz wrote: > On Mon, May 23, 2016 at 3:48 PM, Aleksey Shipilev > wrote: >> By the way, what exactly are you winning with 1-byte field in AtomicBoolean? > > I'm not trying to replace the int field inside the AtomicBoolean with > a boolean - that's an implementation detail. > (Although I would take it if I could declare an atomic boolean inside > AtomicBoolean and let the JVM choose the best size for the platform. > It *is* a small weakness that we need to use the "int" type here in > java code) > > I'm trying to allow regular programmers to declare their primitive > fields with the natural Java type and have all the atomic operations > available. > >> Not "any", int/long/reference VarHandles still do CASes. Note that the >> current API does not preclude implementing CASes for other types if you >> can come up with a plausible mechanics of doing so. >> >> The thing is, there does not seem to be a plausible fallback strategy >> when platform cannot do a subword CAS. Or at least I cannot see it. >> Artisanal Unsafe.compareAndSwapBoolean implementations are welcome :) > > As I said in a previous message, you can implement subword CAS using > fullword CAS in a loop. > > cas8bit(expect, update) { > for (;;) { > fullword = atomicRead32() > if ((fullword &0xff) != expect) return false; > if (cas32(fullword, (fullword & ~0xff) | update) return true; > } > } > > but it would probably be more efficient if a fullword was allocated > for the subword field. The above will only work if the subword field is suitably aligned within the word ie atomicRead32() needs to know the address of the subword of interest. I don't see the VarHandle situation as being any different from the Atomic*FieldUpdater one. The practicalities of implementation limitations shaped the API so that we don't give the illusion of delivering something we aren't. My only problem with VarHandles is that I can't see anything that defines when the various AccessModes are unsupported. ?? Cheers, David From david.holmes at oracle.com Tue May 24 07:07:27 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 24 May 2016 17:07:27 +1000 Subject: VarHandles on non-int-sized fields and atomic operations In-Reply-To: <8aa84136-6fa6-30fd-e939-a070c90994fa@oracle.com> References: <574380EE.7080607@oracle.com> <574388A3.90706@oracle.com> <8aa84136-6fa6-30fd-e939-a070c90994fa@oracle.com> Message-ID: Expansion ... On 24/05/2016 4:50 PM, David Holmes wrote: > On 24/05/2016 9:20 AM, Martin Buchholz wrote: >> On Mon, May 23, 2016 at 3:48 PM, Aleksey Shipilev >> wrote: >>> By the way, what exactly are you winning with 1-byte field in >>> AtomicBoolean? >> >> I'm not trying to replace the int field inside the AtomicBoolean with >> a boolean - that's an implementation detail. >> (Although I would take it if I could declare an atomic boolean inside >> AtomicBoolean and let the JVM choose the best size for the platform. >> It *is* a small weakness that we need to use the "int" type here in >> java code) >> >> I'm trying to allow regular programmers to declare their primitive >> fields with the natural Java type and have all the atomic operations >> available. >> >>> Not "any", int/long/reference VarHandles still do CASes. Note that the >>> current API does not preclude implementing CASes for other types if you >>> can come up with a plausible mechanics of doing so. >>> >>> The thing is, there does not seem to be a plausible fallback strategy >>> when platform cannot do a subword CAS. Or at least I cannot see it. >>> Artisanal Unsafe.compareAndSwapBoolean implementations are welcome :) >> >> As I said in a previous message, you can implement subword CAS using >> fullword CAS in a loop. >> >> cas8bit(expect, update) { >> for (;;) { >> fullword = atomicRead32() >> if ((fullword &0xff) != expect) return false; >> if (cas32(fullword, (fullword & ~0xff) | update) return true; >> } >> } >> >> but it would probably be more efficient if a fullword was allocated >> for the subword field. > > The above will only work if the subword field is suitably aligned within > the word ie atomicRead32() needs to know the address of the subword of > interest. ... and you need to know how to form the correct mask. David ----- > > I don't see the VarHandle situation as being any different from the > Atomic*FieldUpdater one. The practicalities of implementation > limitations shaped the API so that we don't give the illusion of > delivering something we aren't. My only problem with VarHandles is that > I can't see anything that defines when the various AccessModes are > unsupported. ?? > > Cheers, > David From paul.sandoz at oracle.com Tue May 24 07:57:07 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 24 May 2016 09:57:07 +0200 Subject: VarHandles on non-int-sized fields and atomic operations In-Reply-To: References: <574380EE.7080607@oracle.com> <574388A3.90706@oracle.com> Message-ID: <06724E19-63D6-414C-8A5E-B503F882FDE0@oracle.com> > On 24 May 2016, at 02:55, Martin Buchholz wrote: > > Another way to look at it: We have an existing field > > boolean closed; > > which should be updated using CAS for correctness, but currently is not. > I should not have to change the type of the field to int just so that > I can get something that is CASable. I think you would have to qualify that field in such a manner to inform the VM how best to layout the memory optimally for expected operations on that field. At the moment we don?t have such a qualifier: ?this is a boolean but i don?t care about size, please use what ever bit size and alignment is needed so i can perform hardware-based atomic operations on it? As Aleksey said VarHandle is low-level. It can replace the use of Unsafe within AtomicBoolean. If you currently want to achieve what AtomicBoolean does without the boxing you need to use an int field and operate on it directly. It seems quite possible to expose VarHandle field views covering an int for the shorter types boolean, byte. char and short. Internally those types are widened to int for basic signatures so i think it?s just a matter of rewiring to the VH int field support with adjusted method types. (The boolean case may require a little more care given the disparity between Java source and byte code.) However, i am not sure that is very helpful. I would be reluctant at this point (and we were already reluctant) to investigate sub-word atomic ops, and the implications that might have for guarantees/locking/tearing/performance etc. Paul. From aph at redhat.com Tue May 24 08:19:17 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 24 May 2016 09:19:17 +0100 Subject: Fwd: Files.walk() is unusable because of AccessDeniedException In-Reply-To: References: Message-ID: <57440E85.2040809@redhat.com> On 05/20/2016 10:38 AM, Gilles Habran wrote: > why is my message still waiting for approval after a month ? What is it you want Java to do? You can't walk the directory because you don't have permission. sudo should work. Andrew. From chris.hegarty at oracle.com Tue May 24 10:46:12 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 24 May 2016 11:46:12 +0100 Subject: RFR: JDK-8153768 Miscellaneous changes imported from jsr166 CVS 2016-05 In-Reply-To: References: Message-ID: <9192FD1A-A5C7-49F6-9551-486CFA918F62@oracle.com> > On 23 May 2016, at 21:32, Martin Buchholz wrote: > > JSR166 CVS has some unfinished work in progress, but enough minor > changes have accumulated that we should integrate into openjdk9: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/ > https://bugs.openjdk.java.net/browse/JDK-8153768 This looks fine Martin. -Chris. From paul.sandoz at oracle.com Tue May 24 11:00:10 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 24 May 2016 13:00:10 +0200 Subject: VarHandles on non-int-sized fields and atomic operations In-Reply-To: <8aa84136-6fa6-30fd-e939-a070c90994fa@oracle.com> References: <574380EE.7080607@oracle.com> <574388A3.90706@oracle.com> <8aa84136-6fa6-30fd-e939-a070c90994fa@oracle.com> Message-ID: <664D8D11-F8F1-4641-B41A-68D2D3724E02@oracle.com> > On 24 May 2016, at 08:50, David Holmes wrote: > My only problem with VarHandles is that I can't see anything that defines when the various AccessModes are unsupported. ?? > Each producer of a VarHandle (factory method) specifies the supported access modes. The documentation on VarHandle categorises the access modes and the factory method refers to those categories. The method VarHandle.isAccessModeSupported can be used at runtime to query if the access mode is supported. If we choose to support subword CAS that would bring some clarity to this situation. A concern is it might be misleading in terms of performance expectations. Paul. From paul.sandoz at oracle.com Tue May 24 11:57:58 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 24 May 2016 13:57:58 +0200 Subject: RFR: JDK-8153768 Miscellaneous changes imported from jsr166 CVS 2016-05 In-Reply-To: References: <57438465.2020403@oracle.com> Message-ID: <496B7FB5-312D-4A37-AE5C-B17238D5A05C@oracle.com> > On 24 May 2016, at 01:03, Martin Buchholz wrote: > > On Mon, May 23, 2016 at 3:29 PM, Aleksey Shipilev > wrote: >> On 05/23/2016 11:32 PM, Martin Buchholz wrote: >>> JSR166 CVS has some unfinished work in progress, but enough minor >>> changes have accumulated that we should integrate into openjdk9: >>> >>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/ >> +1 >> *) Removing Cloneable from submaps probably requires CCC? > > It never appears in the API. Yes, cannot write Java source to call clone on the returned ConcurrentNavigableMap, so i think we are ok here. Paul. > The use of Cloneable here was a mistake > - the clone method was never implemented! So only users who checked > for "implements Cloneable" without actually trying to call clone could > be affected. And who would try to clone submaps anyways? > >> *) Want to be extra modern in sample code? Use method references! >> - * solvers.forEach((solver) -> cs.submit(solver)); >> + * solvers.forEach(cs::submit); > > OK - switched to using method references! From paul.sandoz at oracle.com Tue May 24 12:23:17 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 24 May 2016 14:23:17 +0200 Subject: RFR[9]: 8156868 MethodHandles.zero(Class) doc issues In-Reply-To: <5743F76F.50905@oracle.com> References: <5742A2D9.7020501@oracle.com> <5F8C3A4C-3D8E-430B-A085-7B82E7D18D18@oracle.com> <5743F76F.50905@oracle.com> Message-ID: > On 24 May 2016, at 08:40, shilpi.rastogi at oracle.com wrote: > > Thanks Paul!! > > Please see http://cr.openjdk.java.net/~srastogi/8156868/webrev.02/ > +1 Paul. From dalibor.topic at oracle.com Tue May 24 13:42:18 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 24 May 2016 15:42:18 +0200 Subject: [PATCH] Implement a noop clear() for Collections#EMPTY_LIST In-Reply-To: References: Message-ID: Thanks, Naufal - I'll take a look and let you & Paul know when it's processed. cheers, dalibor topic On 23.05.2016 12:53, Mohamed Naufal wrote: > Hi Paul, > > I've already sent a signed copy of the OCA to oracle-ca_us at oracle.com. > > Thanks, > Naufal > > On 23 May 2016 at 16:13, Paul Sandoz wrote: > >> Hi Naufal, >> >> Thanks for looking at this. >> >> For us to accept your patch (no matter how small) you need to become a >> contributor, which requires that you agree to the Oracle Contributor >> Agreement (OCA), see: >> >> http://openjdk.java.net/contribute/ >> >> Thanks, >> Paul. >> >>> On 22 May 2016, at 12:10, Mohamed Naufal wrote: >>> >>> Hi, >>> >>> A call to clear() on Collections#EMPTY_LIST is currently redirected to >>> AbstractList#clear(), which performs a bunch of checks and creates a >>> ListItr object, all of which is unnecessary for an EmptyList. >>> >>> PFA a patch that implements a noop clear() for EmptyList. >>> >>> Thanks, >>> Naufal >>> >> >> -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From pavel.rappo at oracle.com Tue May 24 14:08:48 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 24 May 2016 15:08:48 +0100 Subject: 8157677: Subclasses of Reader do not inherit the contents in the exception tag from the parent Reader class in the latest spec In-Reply-To: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> Message-ID: Hi, Could you please review a trivial change for JDK-8157677? http://cr.openjdk.java.net/~prappo/8157677/webrev.00/ http://cr.openjdk.java.net/~prappo/8157677/specdiff.00/overview-summary.html Thanks, -Pavel -------------------------------------------------------------------------------- The problem is caused by a glitch in handling '@exception' tag by javadoc tool: https://bugs.openjdk.java.net/browse/JDK-8157682 From aleksey.shipilev at oracle.com Tue May 24 14:16:27 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 24 May 2016 17:16:27 +0300 Subject: 8157677: Subclasses of Reader do not inherit the contents in the exception tag from the parent Reader class in the latest spec In-Reply-To: References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> Message-ID: <5744623B.3090305@oracle.com> On 05/24/2016 05:08 PM, Pavel Rappo wrote: > Could you please review a trivial change for JDK-8157677? > > http://cr.openjdk.java.net/~prappo/8157677/webrev.00/ *) CharArrayReader: code changes *) It's weird to see @exception and @throws side-by-side: * @exception IOException If an I/O error occurs * @throws IndexOutOfBoundsException {@inheritDoc} Wouldn't it be better to raise the priority for the javadoc bug, and fix it there? > The problem is caused by a glitch in handling '@exception' tag by javadoc tool: > > https://bugs.openjdk.java.net/browse/JDK-8157682 Thanks, -Aleksey From pavel.rappo at oracle.com Tue May 24 14:24:50 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 24 May 2016 15:24:50 +0100 Subject: 8157677: Subclasses of Reader do not inherit the contents in the exception tag from the parent Reader class in the latest spec In-Reply-To: <5744623B.3090305@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <5744623B.3090305@oracle.com> Message-ID: <1BC37401-8F26-4DB7-8AEF-723E1614D379@oracle.com> Thanks for looking at this! > On 24 May 2016, at 15:16, Aleksey Shipilev wrote: > > *) CharArrayReader: code changes What's your concern with 'b'->'buf' rename? Access parameter's name through reflection or something else? > *) It's weird to see @exception and @throws side-by-side: > > * @exception IOException If an I/O error occurs > * @throws IndexOutOfBoundsException {@inheritDoc} > I wanted to address this issue only, i.e. to be very focused. > Wouldn't it be better to raise the priority for the javadoc bug, and fix > it there? It doesn't mean we can't raise the priority, though it's not me to decide this. Especially, given there's a trivial workaround available. From roger.riggs at oracle.com Tue May 24 14:36:28 2016 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 24 May 2016 10:36:28 -0400 Subject: 8157677: Subclasses of Reader do not inherit the contents in the exception tag from the parent Reader class in the latest spec In-Reply-To: <1BC37401-8F26-4DB7-8AEF-723E1614D379@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <5744623B.3090305@oracle.com> <1BC37401-8F26-4DB7-8AEF-723E1614D379@oracle.com> Message-ID: <87157273-7770-f25c-8b35-06b7a3ceefcd@oracle.com> Hi Pavel, To keep it simple and clean, the change from @exception to @throws is not needed and reduces the number of files changed. The change in the parameter name is a bit unusual, typically they are not changed but in this case the change is needed to make parameter name consistent with the *inherited* specification. The change of @exception to @throws can be done consistently across the file later. $.02, Roger On 5/24/16 10:24 AM, Pavel Rappo wrote: > Thanks for looking at this! > >> On 24 May 2016, at 15:16, Aleksey Shipilev wrote: >> >> *) CharArrayReader: code changes > What's your concern with 'b'->'buf' rename? Access parameter's name through > reflection or something else? > >> *) It's weird to see @exception and @throws side-by-side: >> >> * @exception IOException If an I/O error occurs >> * @throws IndexOutOfBoundsException {@inheritDoc} >> > I wanted to address this issue only, i.e. to be very focused. > >> Wouldn't it be better to raise the priority for the javadoc bug, and fix >> it there? > It doesn't mean we can't raise the priority, though it's not me to decide this. > Especially, given there's a trivial workaround available. > > From pavel.rappo at oracle.com Tue May 24 14:45:25 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 24 May 2016 15:45:25 +0100 Subject: 8157677: Subclasses of Reader do not inherit the contents in the exception tag from the parent Reader class in the latest spec In-Reply-To: <87157273-7770-f25c-8b35-06b7a3ceefcd@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <5744623B.3090305@oracle.com> <1BC37401-8F26-4DB7-8AEF-723E1614D379@oracle.com> <87157273-7770-f25c-8b35-06b7a3ceefcd@oracle.com> Message-ID: <8E1E5454-4DE0-4538-8CFE-FE91ADBDED59@oracle.com> Hi Roger, > On 24 May 2016, at 15:36, Roger Riggs wrote: > > To keep it simple and clean, the change from @exception to @throws is not needed > and reduces the number of files changed. That's what the change is all about. I was thinking about it a year ago: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fbdc1331db75 Turned out to be an incorrect assumption :-) In this particular case @throws works differently from @exception (unfortunately). That's why I've attached a specdiff. From jiangli.zhou at Oracle.COM Tue May 24 17:47:10 2016 From: jiangli.zhou at Oracle.COM (Jiangli Zhou) Date: Tue, 24 May 2016 10:47:10 -0700 Subject: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL Message-ID: <2DB03389-7ADF-4752-A507-88F0058E230E@oracle.com> Hi, Please review the following webrev that changes the jdk.internal.loader.ClassLoaders.addURLToUCP() to java.internal.loader.ClassLoaders.toFileURL(). The change is provided by Alan (thanks, Alan!). webrev: http://cr.openjdk.java.net/~jiangli/8157716/webrev.00/ but: https://bugs.openjdk.java.net/browse/JDK-8157716 Thanks, Jiangli From martinrb at google.com Tue May 24 17:57:44 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 24 May 2016 10:57:44 -0700 Subject: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL In-Reply-To: <2DB03389-7ADF-4752-A507-88F0058E230E@oracle.com> References: <2DB03389-7ADF-4752-A507-88F0058E230E@oracle.com> Message-ID: English syntax error. + * Attempts to convert to the given string to a file URL. --- There should be some motivation for why you are calling toRealPath, and e.g. not toAbsolutePath. What problem are you trying to solve? At Google we have special needs - this is the kind of change we end up locally reverting. On Tue, May 24, 2016 at 10:47 AM, Jiangli Zhou wrote: > Hi, > > Please review the following webrev that changes the jdk.internal.loader.ClassLoaders.addURLToUCP() to java.internal.loader.ClassLoaders.toFileURL(). The change is provided by Alan (thanks, Alan!). > > webrev: http://cr.openjdk.java.net/~jiangli/8157716/webrev.00/ > but: https://bugs.openjdk.java.net/browse/JDK-8157716 > > Thanks, > Jiangli > > From joe.darcy at oracle.com Tue May 24 18:28:29 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 24 May 2016 11:28:29 -0700 Subject: JDK 9 RFR of JDK-8157724: Improve javadoc tag usage in java.math Message-ID: <247bd1a9-7c32-a064-0b39-9482a4e6a2ab@oracle.com> Hello, The javadoc of the java.math package has various locations where the @jls, @apiNote, etc. javadoc tags could be used. Those tags should be used as appropriate. Please review the webrev below which makes those updates along with some typo fixes: http://cr.openjdk.java.net/~darcy/8157724.0/ Thanks, -Joe From timo.kinnunen at gmail.com Tue May 24 18:40:09 2016 From: timo.kinnunen at gmail.com (timo.kinnunen at gmail.com) Date: Tue, 24 May 2016 20:40:09 +0200 Subject: Fwd: Files.walk() is unusable because of AccessDeniedException In-Reply-To: <57440E85.2040809@redhat.com> References: <57440E85.2040809@redhat.com> Message-ID: <5744a00c.45bd1c0a.99717.ffffbc37@mx.google.com> Hi, The API documentation makes the point that if there is a security manager installed which denies access to some entries amongst the visited files and directories then those entries are silently skipped, their presence not being disclosed by the walk terminating early due to an access denied exception. This is reasonable and follows the principle that information about privileged information is also privileged information. However Files::walk doesn?t follow that principle consistently. There?s no mention of the java.nio.file.attribute package or the AclEntryPermission enum, for example. It is not clear to me if, as an extreme example, the presence of an ACL on a file which denies read access to the file?s ACL (READ_ACL) would be leaked by Files::walk. What Files::walk could do is support all access control mechanisms in the JDK in equal measure. As is it is, currently it is only those protected files that are unknown to the security manager and unknowable to Java that are being revealed to unprivileged users. This seems like the exact opposite of how it should be. -- Have a nice day, Timo Sent from Mail for Windows 10 From: Andrew Haley From lance.andersen at oracle.com Tue May 24 18:43:30 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 24 May 2016 14:43:30 -0400 Subject: JDK 9 RFR of JDK-8157724: Improve javadoc tag usage in java.math In-Reply-To: <247bd1a9-7c32-a064-0b39-9482a4e6a2ab@oracle.com> References: <247bd1a9-7c32-a064-0b39-9482a4e6a2ab@oracle.com> Message-ID: Hi Joe, The changes look reasonable Best Lance > On May 24, 2016, at 2:28 PM, joe darcy wrote: > > Hello, > > The javadoc of the java.math package has various locations where the @jls, @apiNote, etc. javadoc tags could be used. Those tags should be used as appropriate. Please review the webrev below which makes those updates along with some typo fixes: > > http://cr.openjdk.java.net/~darcy/8157724.0/ > > 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 brian.burkhalter at oracle.com Tue May 24 18:44:42 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 24 May 2016 11:44:42 -0700 Subject: JDK 9 RFR of JDK-8157724: Improve javadoc tag usage in java.math In-Reply-To: <247bd1a9-7c32-a064-0b39-9482a4e6a2ab@oracle.com> References: <247bd1a9-7c32-a064-0b39-9482a4e6a2ab@oracle.com> Message-ID: <77603606-883F-4E84-A2CE-5A57C111666C@oracle.com> Hi Joe, At new line 1902 and elsewhere, is preferable to in general? (Not a question pertaining only to this change.) +1 Brian On May 24, 2016, at 11:28 AM, joe darcy wrote: > The javadoc of the java.math package has various locations where the @jls, @apiNote, etc. javadoc tags could be used. Those tags should be used as appropriate. Please review the webrev below which makes those updates along with some typo fixes: > > http://cr.openjdk.java.net/~darcy/8157724.0/ From Alan.Bateman at oracle.com Tue May 24 18:49:32 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 May 2016 19:49:32 +0100 Subject: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL In-Reply-To: References: <2DB03389-7ADF-4752-A507-88F0058E230E@oracle.com> Message-ID: <5744A23C.4030704@oracle.com> On 24/05/2016 18:57, Martin Buchholz wrote: > English syntax error. > > + * Attempts to convert to the given string to a file URL. > > --- > > There should be some motivation for why you are calling toRealPath, > and e.g. not toAbsolutePath. > What problem are you trying to solve? > > At Google we have special needs - this is the kind of change we end up > locally reverting. > Yeah, the context isn't clear here. This is all related to the HotSpot CDS feature and so very tied to the built-in class loaders. File paths are recorded at -Xshare:dump time and checked at -Xshare:on time. Too many types of fie path and corner cases on Windows for the VM to get it right. -Alan From joe.darcy at oracle.com Tue May 24 18:59:43 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 24 May 2016 11:59:43 -0700 Subject: JDK 9 RFR of JDK-8157724: Improve javadoc tag usage in java.math In-Reply-To: <77603606-883F-4E84-A2CE-5A57C111666C@oracle.com> References: <247bd1a9-7c32-a064-0b39-9482a4e6a2ab@oracle.com> <77603606-883F-4E84-A2CE-5A57C111666C@oracle.com> Message-ID: Hi Brian, As I understand it, if one is being pedantic about HTML tags, "" is more of a semantic tag while "" is purely typographical so there are cases where "" should not be replaced by "". HTH, -Joe On 5/24/2016 11:44 AM, Brian Burkhalter wrote: > Hi Joe, > > At new line 1902 and elsewhere, is preferable to in > general? (Not a question pertaining only to this change.) > > +1 > > Brian > > On May 24, 2016, at 11:28 AM, joe darcy > wrote: > >> The javadoc of the java.math package has various locations where the >> @jls, @apiNote, etc. javadoc tags could be used. Those tags should be >> used as appropriate. Please review the webrev below which makes those >> updates along with some typo fixes: >> >> http://cr.openjdk.java.net/~darcy/8157724.0/ >> > From brian.burkhalter at oracle.com Tue May 24 19:07:37 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 24 May 2016 12:07:37 -0700 Subject: JDK 9 RFR of JDK-8157724: Improve javadoc tag usage in java.math In-Reply-To: References: <247bd1a9-7c32-a064-0b39-9482a4e6a2ab@oracle.com> <77603606-883F-4E84-A2CE-5A57C111666C@oracle.com> Message-ID: <325D3D8A-64B9-4626-877A-3222529F8E40@oracle.com> Hi Joe, Yes, that is useful. I had not recalled seeing the emphasis tag before so I was curious as to the policy. Thanks, Brian On May 24, 2016, at 11:59 AM, joe darcy wrote: > As I understand it, if one is being pedantic about HTML tags, "" is more of a semantic tag while "" is purely typographical so there are cases where "" should not be replaced by "". > > On 5/24/2016 11:44 AM, Brian Burkhalter wrote: >> >> At new line 1902 and elsewhere, is preferable to in general? (Not a question pertaining only to this change.) From joe.darcy at oracle.com Tue May 24 19:27:39 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 24 May 2016 12:27:39 -0700 Subject: JDK 9 RFR of JDK-8157724: Improve javadoc tag usage in java.math In-Reply-To: <325D3D8A-64B9-4626-877A-3222529F8E40@oracle.com> References: <247bd1a9-7c32-a064-0b39-9482a4e6a2ab@oracle.com> <77603606-883F-4E84-A2CE-5A57C111666C@oracle.com> <325D3D8A-64B9-4626-877A-3222529F8E40@oracle.com> Message-ID: <0f03ee01-fef8-77a9-98fa-3b36ab7dae74@oracle.com> Hi Brian, We don't apply a policy consistently, but I did another pass on BigDecimal and BigInteger to be more consistent: http://cr.openjdk.java.net/~darcy/8157724.1 This also includes an additional @jls tag in BigInteger to the arithmetic operations in JLS and a @see from BigDecimal's sqrt method to the BigInteger method. Thanks, -Joe On 5/24/2016 12:07 PM, Brian Burkhalter wrote: > Hi Joe, > > Yes, that is useful. I had not recalled seeing the emphasis tag before > so I was curious as to the policy. > > Thanks, > > Brian > > On May 24, 2016, at 11:59 AM, joe darcy > wrote: >> >> As I understand it, if one is being pedantic about HTML tags, "" >> is more of a semantic tag while "" is purely typographical so >> there are cases where "" should not be replaced by "". >> >> On 5/24/2016 11:44 AM, Brian Burkhalter wrote: >>> >>> At new line 1902 and elsewhere, is preferable to in >>> general? (Not a question pertaining only to this change.) > From aleksey.shipilev at oracle.com Tue May 24 19:29:03 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 24 May 2016 22:29:03 +0300 Subject: VarHandles on non-int-sized fields and atomic operations In-Reply-To: <0FAA8D1C-0FB5-4058-A8C5-E905306E6D84@oracle.com> References: <574380EE.7080607@oracle.com> <574388A3.90706@oracle.com> <0FAA8D1C-0FB5-4058-A8C5-E905306E6D84@oracle.com> Message-ID: <5744AB7F.4070202@oracle.com> On 05/24/2016 05:43 AM, John Rose wrote: > On May 23, 2016, at 4:20 PM, Martin Buchholz > wrote: >> >> As I said in a previous message, you can implement subword CAS using >> fullword CAS in a loop. >> >> cas8bit(expect, update) { >> for (;;) { >> fullword = atomicRead32() >> if ((fullword &0xff) != expect) return false; >> if (cas32(fullword, (fullword & ~0xff) | update) return true; >> } >> } Yes, stupid me! I was under impression that loops are no-no to emulate strong CAS. But we do loops already with LL/SC... > Yes, that's the "artisanal" version I would reach for. > It doesn't scale well if there is unrelated activity on nearby bytes. Okay, we are exploring it here: https://bugs.openjdk.java.net/browse/JDK-8157726 I was able to intrinsify subword accesses on x86_64, and their performance is on par with int versions. Plain Martin-style Java loops are around 2x slower than direct intrinsics in a few basic tests (I expect them to be even slower on contended cases and/or non-x86 platforms). But first, we need to hook them up to VarHandles (in progress now). Thanks, -Aleksey From ecki at zusammenkunft.net Tue May 24 19:52:03 2016 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Tue, 24 May 2016 21:52:03 +0200 Subject: Files.walk() is unusable because of AccessDeniedException In-Reply-To: <5744a00c.45bd1c0a.99717.ffffbc37@mx.google.com> References: <57440E85.2040809@redhat.com> <5744a00c.45bd1c0a.99717.ffffbc37@mx.google.com> Message-ID: The AccessDeniedExceptions are not a java security mechanism. It is a OS mechanism and i think it is good that java reveals all information also available with native access (i.e. if you have no 'x' permission on a dir you cannot enter it but you can see it (as long asmyou have read permission on the parent). The only issue is here that the walker should be able to skip or resume walking in such a scenario. (Itmsounds like this is the problem/question here?) Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: timo.kinnunen at gmail.com To: Andrew Haley , Gilles Habran , "core-libs-dev at openjdk.java.net" Sent: Di., 24 Mai 2016 21:40 Subject: RE: Fwd: Files.walk() is unusable because of AccessDeniedException Hi, The API documentation makes the point that if there is a security manager installed which denies access to some entries amongst the visited files and directories then those entries are silently skipped, their presence not being disclosed by the walk terminating early due to an access denied exception. This is reasonable and follows the principle that information about privileged information is also privileged information. However Files::walk doesn?t follow that principle consistently. There?s no mention of the java.nio.file.attribute package or the AclEntryPermission enum, for example. It is not clear to me if, as an extreme example, the presence of an ACL on a file which denies read access to the file?s ACL (READ_ACL) would be leaked by Files::walk. What Files::walk could do is support all access control mechanisms in the JDK in equal measure. As is it is, currently it is only those protected files that are unknown to the security manager and unknowable to Java that are being revealed to unprivileged users. This seems like the exact opposite of how it should be. -- Have a nice day, Timo Sent from Mail for Windows 10 From: Andrew Haley From jiangli.zhou at Oracle.COM Tue May 24 20:00:14 2016 From: jiangli.zhou at Oracle.COM (Jiangli Zhou) Date: Tue, 24 May 2016 13:00:14 -0700 Subject: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL In-Reply-To: References: <2DB03389-7ADF-4752-A507-88F0058E230E@oracle.com> Message-ID: <6F6DE1EB-2CA5-400E-9E4E-A5ACAB6DD4CD@oracle.com> Hi Martin, Thanks for the review. > On May 24, 2016, at 10:57 AM, Martin Buchholz wrote: > > English syntax error. > > + * Attempts to convert to the given string to a file URL. > Will fix. > --- > > There should be some motivation for why you are calling toRealPath, > and e.g. not toAbsolutePath. > What problem are you trying to solve? The toRealPath() method is used by the class loader code in the core library to convert each element in the class path to its real path. The VM also needs to retrieve the path information when loading CDS archived classes. The VM behavior needs be consistent with the core library when handling the class path. That?s why the new API is created for both the library and VM code to use. Thanks, Jiangli > > At Google we have special needs - this is the kind of change we end up > locally reverting. > > > On Tue, May 24, 2016 at 10:47 AM, Jiangli Zhou wrote: >> Hi, >> >> Please review the following webrev that changes the jdk.internal.loader.ClassLoaders.addURLToUCP() to java.internal.loader.ClassLoaders.toFileURL(). The change is provided by Alan (thanks, Alan!). >> >> webrev: http://cr.openjdk.java.net/~jiangli/8157716/webrev.00/ >> but: https://bugs.openjdk.java.net/browse/JDK-8157716 >> >> Thanks, >> Jiangli >> >> From paul.sandoz at oracle.com Tue May 24 20:17:46 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 24 May 2016 22:17:46 +0200 Subject: VarHandles on non-int-sized fields and atomic operations In-Reply-To: <5744AB7F.4070202@oracle.com> References: <574380EE.7080607@oracle.com> <574388A3.90706@oracle.com> <0FAA8D1C-0FB5-4058-A8C5-E905306E6D84@oracle.com> <5744AB7F.4070202@oracle.com> Message-ID: <40963353-AF70-453C-A451-E69FC32E32C7@oracle.com> > On 24 May 2016, at 21:29, Aleksey Shipilev wrote: > > On 05/24/2016 05:43 AM, John Rose wrote: >> On May 23, 2016, at 4:20 PM, Martin Buchholz > > wrote: >>> >>> As I said in a previous message, you can implement subword CAS using >>> fullword CAS in a loop. >>> >>> cas8bit(expect, update) { >>> for (;;) { >>> fullword = atomicRead32() >>> if ((fullword &0xff) != expect) return false; >>> if (cas32(fullword, (fullword & ~0xff) | update) return true; >>> } >>> } > > Yes, stupid me! I was under impression that loops are no-no to emulate > strong CAS. But we do loops already with LL/SC? Indeed, doh! Martin, many thanks for persisting with this. > >> Yes, that's the "artisanal" version I would reach for. >> It doesn't scale well if there is unrelated activity on nearby bytes. > > Okay, we are exploring it here: > https://bugs.openjdk.java.net/browse/JDK-8157726 > > I was able to intrinsify subword accesses on x86_64, and their > performance is on par with int versions. Plain Martin-style Java loops > are around 2x slower than direct intrinsics in a few basic tests (I > expect them to be even slower on contended cases and/or non-x86 > platforms). But first, we need to hook them up to VarHandles (in > progress now). > Nice work! This is looking very promising on x86. Paul. From Alan.Bateman at oracle.com Tue May 24 20:32:15 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 May 2016 21:32:15 +0100 Subject: Files.walk() is unusable because of AccessDeniedException In-Reply-To: References: <57440E85.2040809@redhat.com> <5744a00c.45bd1c0a.99717.ffffbc37@mx.google.com> Message-ID: <5744BA4F.1040606@oracle.com> On 24/05/2016 20:52, ecki at zusammenkunft.net wrote: > The AccessDeniedExceptions are not a java security mechanism. It is a OS mechanism and i think it is good that java reveals all information also available with native access (i.e. if you have no 'x' permission on a dir you cannot enter it but you can see it (as long asmyou have read permission on the parent). > > The only issue is here that the walker should be able to skip or resume walking in such a scenario. (Itmsounds like this is the problem/question here?) > That's right and I think this question is about the scenario where some of the file system is not accessible. With Files.walkFileTree then you provide a FileVisitor that can deal with exceptions and control which parts of the file tree are visited. The newer walk/find methods don't so it would require introducing a new API. It's come up before, and is easy to do, just not clear that we want to introduce yet further variations. -Alan From david.holmes at oracle.com Tue May 24 20:43:31 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 May 2016 06:43:31 +1000 Subject: VarHandles on non-int-sized fields and atomic operations In-Reply-To: <5744AB7F.4070202@oracle.com> References: <574380EE.7080607@oracle.com> <574388A3.90706@oracle.com> <0FAA8D1C-0FB5-4058-A8C5-E905306E6D84@oracle.com> <5744AB7F.4070202@oracle.com> Message-ID: On 25/05/2016 5:29 AM, Aleksey Shipilev wrote: > On 05/24/2016 05:43 AM, John Rose wrote: >> On May 23, 2016, at 4:20 PM, Martin Buchholz > > wrote: >>> >>> As I said in a previous message, you can implement subword CAS using >>> fullword CAS in a loop. >>> >>> cas8bit(expect, update) { >>> for (;;) { >>> fullword = atomicRead32() >>> if ((fullword &0xff) != expect) return false; >>> if (cas32(fullword, (fullword & ~0xff) | update) return true; >>> } >>> } > > Yes, stupid me! I was under impression that loops are no-no to emulate > strong CAS. But we do loops already with LL/SC... The VM also does it for jbyte variant. >> Yes, that's the "artisanal" version I would reach for. >> It doesn't scale well if there is unrelated activity on nearby bytes. > > Okay, we are exploring it here: > https://bugs.openjdk.java.net/browse/JDK-8157726 Don't overlook we are past FC for hotspot so this will need approval before it can be pushed. David ----- > I was able to intrinsify subword accesses on x86_64, and their > performance is on par with int versions. Plain Martin-style Java loops > are around 2x slower than direct intrinsics in a few basic tests (I > expect them to be even slower on contended cases and/or non-x86 > platforms). But first, we need to hook them up to VarHandles (in > progress now). > > Thanks, > -Aleksey > > From brian.burkhalter at oracle.com Tue May 24 20:47:30 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 24 May 2016 13:47:30 -0700 Subject: JDK 9 RFR of JDK-8157724: Improve javadoc tag usage in java.math In-Reply-To: <0f03ee01-fef8-77a9-98fa-3b36ab7dae74@oracle.com> References: <247bd1a9-7c32-a064-0b39-9482a4e6a2ab@oracle.com> <77603606-883F-4E84-A2CE-5A57C111666C@oracle.com> <325D3D8A-64B9-4626-877A-3222529F8E40@oracle.com> <0f03ee01-fef8-77a9-98fa-3b36ab7dae74@oracle.com> Message-ID: <867CEA3E-12D3-4277-BFFC-DE370E8F1179@oracle.com> Hi Joe, In the new version of BigDecimal at line 3586: ?as defined? -> ?as defined in?. Otherwise +1. Thanks, Brian On May 24, 2016, at 12:27 PM, joe darcy wrote: > We don't apply a policy consistently, but I did another pass on BigDecimal and BigInteger to be more consistent: > > http://cr.openjdk.java.net/~darcy/8157724.1 > > This also includes an additional @jls tag in BigInteger to the arithmetic operations in JLS and a @see from BigDecimal's sqrt method to the BigInteger method. From joe.darcy at oracle.com Tue May 24 20:52:00 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 24 May 2016 13:52:00 -0700 Subject: JDK 9 RFR of JDK-8157724: Improve javadoc tag usage in java.math In-Reply-To: <867CEA3E-12D3-4277-BFFC-DE370E8F1179@oracle.com> References: <247bd1a9-7c32-a064-0b39-9482a4e6a2ab@oracle.com> <77603606-883F-4E84-A2CE-5A57C111666C@oracle.com> <325D3D8A-64B9-4626-877A-3222529F8E40@oracle.com> <0f03ee01-fef8-77a9-98fa-3b36ab7dae74@oracle.com> <867CEA3E-12D3-4277-BFFC-DE370E8F1179@oracle.com> Message-ID: <2b402a13-1eba-153b-6dd5-3d60be06fbaa@oracle.com> Hi Brian, Pushed with typo corrects; thanks, -Joe On 5/24/2016 1:47 PM, Brian Burkhalter wrote: > Hi Joe, > > In the new version of BigDecimal at line 3586: ?as defined? -> ?as > defined in?. > > Otherwise +1. > > Thanks, > > Brian > > On May 24, 2016, at 12:27 PM, joe darcy > wrote: >> >> We don't apply a policy consistently, but I did another pass on >> BigDecimal and BigInteger to be more consistent: >> >> http://cr.openjdk.java.net/~darcy/8157724.1 >> >> This also includes an additional @jls tag in BigInteger to the >> arithmetic operations in JLS and a @see from BigDecimal's sqrt method >> to the BigInteger method. >> From martinrb at google.com Tue May 24 22:02:15 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 24 May 2016 15:02:15 -0700 Subject: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL In-Reply-To: <5744A23C.4030704@oracle.com> References: <2DB03389-7ADF-4752-A507-88F0058E230E@oracle.com> <5744A23C.4030704@oracle.com> Message-ID: On Tue, May 24, 2016 at 11:49 AM, Alan Bateman wrote: > Yeah, the context isn't clear here. This is all related to the HotSpot CDS > feature and so very tied to the built-in class loaders. File paths are > recorded at -Xshare:dump time and checked at -Xshare:on time. Too many types > of fie path and corner cases on Windows for the VM to get it right. Canonicalization is reasonable for checking whether two files are the same (but of course it's not reliable!). But it should be explained - it is not at all obvious how this code relates to CDS... and the resulting canonicalized paths should never be exposed to the user, e.g. in java.class.path. From david.holmes at oracle.com Tue May 24 23:14:57 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 May 2016 09:14:57 +1000 Subject: VarHandles on non-int-sized fields and atomic operations In-Reply-To: References: <574380EE.7080607@oracle.com> <574388A3.90706@oracle.com> <0FAA8D1C-0FB5-4058-A8C5-E905306E6D84@oracle.com> <5744AB7F.4070202@oracle.com> Message-ID: <87e9aec7-312a-7f14-0e22-0f6ce28410ad@oracle.com> On 25/05/2016 6:43 AM, David Holmes wrote: > On 25/05/2016 5:29 AM, Aleksey Shipilev wrote: >> On 05/24/2016 05:43 AM, John Rose wrote: >>> On May 23, 2016, at 4:20 PM, Martin Buchholz >> > wrote: >>>> >>>> As I said in a previous message, you can implement subword CAS using >>>> fullword CAS in a loop. >>>> >>>> cas8bit(expect, update) { >>>> for (;;) { >>>> fullword = atomicRead32() >>>> if ((fullword &0xff) != expect) return false; >>>> if (cas32(fullword, (fullword & ~0xff) | update) return true; >>>> } >>>> } >> >> Yes, stupid me! I was under impression that loops are no-no to emulate >> strong CAS. But we do loops already with LL/SC... > > The VM also does it for jbyte variant. > >>> Yes, that's the "artisanal" version I would reach for. >>> It doesn't scale well if there is unrelated activity on nearby bytes. >> >> Okay, we are exploring it here: >> https://bugs.openjdk.java.net/browse/JDK-8157726 > > Don't overlook we are past FC for hotspot so this will need approval > before it can be pushed. Never mind I see the JEP 193 exemption - though it is a bit odd to see an exception for a JEP that is already marked integrated. David > David > ----- > >> I was able to intrinsify subword accesses on x86_64, and their >> performance is on par with int versions. Plain Martin-style Java loops >> are around 2x slower than direct intrinsics in a few basic tests (I >> expect them to be even slower on contended cases and/or non-x86 >> platforms). But first, we need to hook them up to VarHandles (in >> progress now). >> >> Thanks, >> -Aleksey >> >> From martinrb at google.com Tue May 24 23:15:51 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 24 May 2016 16:15:51 -0700 Subject: VarHandles on non-int-sized fields and atomic operations In-Reply-To: <40963353-AF70-453C-A451-E69FC32E32C7@oracle.com> References: <574380EE.7080607@oracle.com> <574388A3.90706@oracle.com> <0FAA8D1C-0FB5-4058-A8C5-E905306E6D84@oracle.com> <5744AB7F.4070202@oracle.com> <40963353-AF70-453C-A451-E69FC32E32C7@oracle.com> Message-ID: More high-level observations on low-level operations: We already sort-of have an existing field qualifier for atomic: "volatile" ! It is already the case that e.g. volatile long is atomic while unadorned long is not. But atomics without CAS make us sad, so we're adding them. Also, by analogy, Atomic*FieldUpdaters must refer to a volatile variable. It seems not unreasonable to require that VarHandles also refer to a volatile field. If a field is declared volatile boolean; then the VM should ensure not only that it can be reasonably efficiently updated using ordinary read/write as is already the case but also that it can be reasonably efficiently CAS'ed, and that may mean giving it 32 bits instead of 8 on some platforms. But it would be a VM implementation detail. It would be even nicer if the field qualifier was literally "atomic", but I don't think that is going to happen. The best we can hope for is: "volatile" is how you spell "atomic" in Java. From martinrb at google.com Tue May 24 23:30:44 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 24 May 2016 16:30:44 -0700 Subject: VarHandles on non-int-sized fields and atomic operations In-Reply-To: <0FAA8D1C-0FB5-4058-A8C5-E905306E6D84@oracle.com> References: <574380EE.7080607@oracle.com> <574388A3.90706@oracle.com> <0FAA8D1C-0FB5-4058-A8C5-E905306E6D84@oracle.com> Message-ID: On Mon, May 23, 2016 at 7:43 PM, John Rose wrote: > It doesn't scale well if there is unrelated activity on nearby bytes. > But, for that matter, "nearby" can mean "within 64 bytes", > which is why we have @Contended for when we really need it. Because "nearby" means "within 64 bytes", I think it's a non-issue for small atomic value types. There is no significant difference between atomic and plain fields. --- As for the storage for a boolean, 1-bit, 8-bit and 32-bit are all plausible choices for VMs today. 1-bit storage is most compact of course, but is rejected as too expensive because modern machines don't have instructions to modify single bits, and because sequences of adjacent booleans are rare. But note that we implement BitSet using a long[] kludge because of the lack of a compact boolean[] with 1-bit/boolean. From mandy.chung at oracle.com Tue May 24 23:42:45 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 24 May 2016 16:42:45 -0700 Subject: JDK 9 RFR of JDK-8151904: test/java/lang/StackWalker/VerifyStackTrace.java needs to handle update releases In-Reply-To: <573EA368.2060203@oracle.com> References: <573EA368.2060203@oracle.com> Message-ID: > On May 19, 2016, at 10:40 PM, Hamlin Li wrote: > > The test currently hardcodes the version number "9". We should build a JDK with a different release number e.g. 9.1 and checks if this test handles it properly. > Test run successfully on 9-ea+118, dummybundles(9-ea+255, 9.1-ea+255, 9.0.1-ea+255, 9.0.0.1-ea+255). > > bug: https://bugs.openjdk.java.net/browse/JDK-8151904 > webrev: http://cr.openjdk.java.net/~mli/8151904/webrev.00/ Looks okay. Mandy From naoto.sato at oracle.com Tue May 24 23:47:27 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 24 May 2016 16:47:27 -0700 Subject: [9] RFR: Static build of libzip is missing JNI_OnLoad_zip entry point Message-ID: <4d46320e-739d-78cf-9110-a29815b06021@oracle.com> Hello, The previous attempt to fix this one failed in the installer build, as it does not recognize the added macro. I've updated the fix to add extra check for static build (yeah, this is redundant with the real jni_util.h, but effectively avoid the installer build failure). http://cr.openjdk.java.net/~naoto/8150179/webrev.01/ Please review. Naoto From gilleshabran at gmail.com Tue May 24 08:36:54 2016 From: gilleshabran at gmail.com (Gilles Habran) Date: Tue, 24 May 2016 10:36:54 +0200 Subject: Fwd: Files.walk() is unusable because of AccessDeniedException In-Reply-To: <57440E85.2040809@redhat.com> References: <57440E85.2040809@redhat.com> Message-ID: Good morning, well I would like to be able to manage the outcome of the processing myself and not get an exception in a part where I have no control. For example, I would expect to get an exception when I tried to read a file where I don't have the permission. I would not expect to get an exception when Java creates the Stream. Maybe I am the only one to have a problem with this ? I don't know but it feels strange to be forced to execute a software with root permissions where I don't even plan to read file I cannot read because of lack of permissions. For me, we should be able to test the attributes of a file and depending on the result, read the file or not. If we read the file without permission, we get an exception, if not, we can go to the next file without error. If that's unclear, please let me know, I'll try to give more informations or examples. Thank you. On 24 May 2016 at 10:19, Andrew Haley wrote: > On 05/20/2016 10:38 AM, Gilles Habran wrote: > > why is my message still waiting for approval after a month ? > > What is it you want Java to do? You can't walk the directory > because you don't have permission. sudo should work. > > Andrew. > > From henry.jen at oracle.com Wed May 25 06:23:51 2016 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 24 May 2016 23:23:51 -0700 Subject: Fwd: Files.walk() is unusable because of AccessDeniedException In-Reply-To: References: <57440E85.2040809@redhat.com> Message-ID: I think there is a work-around, use list() and flatMap() should get you what you needed. The API is designed to walk a tree where you suppose to have access with. If OS level cause an IOException, that need to be dealt with. Acknowledged that exception handling is not a strong suite in Stream API, developer will need to do some work. Files.find() also allows you to get entries and filter out by permission. What you can do is make sure you have permission on the top level, then call find with maxDepth 1 to only get entries on that directory. Combined with flatMap(), you should be able to get what you want. Try the following code to see if it works for you. import java.nio.file.Files; import java.nio.file.Path; import java.nio.file.Paths; import java.util.stream.Stream; import java.io.IOException; public class ListCanRead { ? ? static Stream walkReadable(Path p) { ? ? ? ? if (Files.isReadable(p)) { ? ? ? ? ? ? if (Files.isDirectory(p)) { ? ? ? ? ? ? ? ? try { ? ? ? ? ? ? ? ? ? ? return Stream.concat(Stream.of(p), Files.list(p)); ? ? ? ? ? ? ? ? } catch (IOException ioe) { ? ? ? ? ? ? ? ? ? ? return Stream.of(p); ? ? ? ? ? ? ? ? } ? ? ? ? ? ? } else { ? ? ? ? ? ? ? ? return Stream.of(p); ? ? ? ? ? ? } ? ? ? ? } ? ? ? ? return Stream.of(p); ? ? } ? ? public static void main(String[] args) throws IOException { ? ? ? ? System.out.println("List directory: " + args[0]); ? ? ? ? walkReadable(Paths.get(args[0])).flatMap(ListCanRead::walkReadable) ? ? ? ? ? ? .forEach(System.out::println); ? ? ? ? Files.walk(Paths.get(args[0])) ? ? ? ? ? ? .forEach(System.out::println); // Could throw AccessDeniedException ? ? } } Cheers, Henry On May 24, 2016 at 4:48:30 PM, Gilles Habran (gilleshabran at gmail.com) wrote: > Good morning, > > well I would like to be able to manage the outcome of the processing myself > and not get an exception in a part where I have no control. > > For example, I would expect to get an exception when I tried to read a file > where I don't have the permission. I would not expect to get an exception > when Java creates the Stream. > > Maybe I am the only one to have a problem with this ? I don't know but it > feels strange to be forced to execute a software with root permissions > where I don't even plan to read file I cannot read because of lack of > permissions. > > For me, we should be able to test the attributes of a file and depending on > the result, read the file or not. If we read the file without permission, > we get an exception, if not, we can go to the next file without error. > > If that's unclear, please let me know, I'll try to give more informations > or examples. > > Thank you. > > On 24 May 2016 at 10:19, Andrew Haley wrote: > > > On 05/20/2016 10:38 AM, Gilles Habran wrote: > > > why is my message still waiting for approval after a month ? > > > > What is it you want Java to do? You can't walk the directory > > because you don't have permission. sudo should work. > > > > Andrew. > > > > > From paul.sandoz at oracle.com Wed May 25 07:07:58 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 25 May 2016 09:07:58 +0200 Subject: VarHandles on non-int-sized fields and atomic operations In-Reply-To: <87e9aec7-312a-7f14-0e22-0f6ce28410ad@oracle.com> References: <574380EE.7080607@oracle.com> <574388A3.90706@oracle.com> <0FAA8D1C-0FB5-4058-A8C5-E905306E6D84@oracle.com> <5744AB7F.4070202@oracle.com> <87e9aec7-312a-7f14-0e22-0f6ce28410ad@oracle.com> Message-ID: <34418985-64E1-4604-ADD5-6806221360F9@oracle.com> > On 25 May 2016, at 01:14, David Holmes wrote: >>>> Yes, that's the "artisanal" version I would reach for. >>>> It doesn't scale well if there is unrelated activity on nearby bytes. >>> >>> Okay, we are exploring it here: >>> https://bugs.openjdk.java.net/browse/JDK-8157726 >> >> Don't overlook we are past FC for hotspot so this will need approval >> before it can be pushed. > > Never mind I see the JEP 193 exemption - though it is a bit odd to see an exception for a JEP that is already marked integrated. > Because the main feature was integrated into master. The exception is primarily for finishing up some of the stress testing, which can proceed beyond the integration of the feature. In the interim new API enhacements have arrived, and may arrive in the future especially given the long soak time. It is not unusual to process additional enhancements after a JEP is integrated or completes, but it certainly gets more complicated post FC! Paul. From paul.sandoz at oracle.com Wed May 25 07:53:19 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 25 May 2016 09:53:19 +0200 Subject: VarHandles on non-int-sized fields and atomic operations In-Reply-To: References: <574380EE.7080607@oracle.com> <574388A3.90706@oracle.com> <0FAA8D1C-0FB5-4058-A8C5-E905306E6D84@oracle.com> <5744AB7F.4070202@oracle.com> <40963353-AF70-453C-A451-E69FC32E32C7@oracle.com> Message-ID: > On 25 May 2016, at 01:15, Martin Buchholz wrote: > > More high-level observations on low-level operations: > > We already sort-of have an existing field qualifier for atomic: "volatile" ! > It is already the case that e.g. volatile long is atomic while > unadorned long is not. > But atomics without CAS make us sad, so we're adding them. > Also, by analogy, Atomic*FieldUpdaters must refer to a volatile variable. > It seems not unreasonable to require that VarHandles also refer to a > volatile field. > We wanted the flexibility to perform ?normal" plain access against other accesses using a VarHandle, of course that requires very careful use. Furthermore, other operations anyway override that of the volatile semantics. (Relatedly, there is no qualifier on the components of an array.) > If a field is declared > volatile boolean; > then the VM should ensure not only that it can be reasonably > efficiently updated using ordinary read/write as is already the case > but also that it can be reasonably efficiently CAS'ed, and that may > mean giving it 32 bits instead of 8 on some platforms. But it would > be a VM implementation detail. > That flexibility may be required for SPARC [*], though i don?t know how much work would be required to support such platform Object specific layouts. > It would be even nicer if the field qualifier was literally "atomic", > but I don't think that is going to happen. The best we can hope for > is: > > "volatile" is how you spell "atomic" in Java. That is a reasonable assumption under the circumstances, although i don?t like the way volatile conflates atomicity and memory ordering guarantees and arguably what you propose does adds to the conflation, since int field access is already atomic. I would still prefer the flexibility of not requiring a field covered by a VarHandle to be declared as such, even if volatile is conflated further (as mostly an implementation detail) to imply efficient CAS operations can be performed, perhaps at the expense of using more memory. Aleksey did some analysis to indicate we might be able to achieve access atomicity (not conflated with being able to perform an efficient CAS) by default without qualification for all types: http://shipilev.net/blog/2014/all-accesses-are-atomic/ and you can even use an experimental flag -XX:+AlwaysAtomicAccesses and try it out. Paul. [*] IIUC SPARC has just 32/64bit CAS operation. ARM has byte/short LL/SC instructions. From aleksey.shipilev at oracle.com Wed May 25 09:21:19 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 25 May 2016 12:21:19 +0300 Subject: 8157677: Subclasses of Reader do not inherit the contents in the exception tag from the parent Reader class in the latest spec In-Reply-To: <1BC37401-8F26-4DB7-8AEF-723E1614D379@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <5744623B.3090305@oracle.com> <1BC37401-8F26-4DB7-8AEF-723E1614D379@oracle.com> Message-ID: <57456E8F.5000900@oracle.com> On 05/24/2016 05:24 PM, Pavel Rappo wrote: > Thanks for looking at this! > >> On 24 May 2016, at 15:16, Aleksey Shipilev wrote: >> >> *) CharArrayReader: code changes > > What's your concern with 'b'->'buf' rename? Access parameter's name through > reflection or something else? This change is not covered by bug synopsis. This forces to read every damn changeset when traversing the change history for a file, looking for suspicious changes. >> *) It's weird to see @exception and @throws side-by-side: >> >> * @exception IOException If an I/O error occurs >> * @throws IndexOutOfBoundsException {@inheritDoc} >> > > I wanted to address this issue only, i.e. to be very focused. This desire contradicts with the 'b' -> 'buf' change. >> Wouldn't it be better to raise the priority for the javadoc bug, and fix >> it there? > > It doesn't mean we can't raise the priority, though it's not me to decide this. > Especially, given there's a trivial workaround available. It's your call, but I am very unhappy seeing JDK code changes to work around the bug in the JDK tool that we have the developers for. Thanks, -Aleksey From amy.lu at oracle.com Wed May 25 09:44:58 2016 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 25 May 2016 17:44:58 +0800 Subject: JDK 9 RFR of JDK-8157813: Remove sun/rmi/transport/proxy/EagerHttpFallback.java from ProblemList.txt Message-ID: <5745741A.7040002@oracle.com> sun/rmi/transport/proxy/EagerHttpFallback.java This test has been removed in JDK-8155978: JDK-8155978: Remove HTTP proxy implementation and tests from RMI https://bugs.openjdk.java.net/browse/JDK-8155978 This patch is to remove this test from ProblemList.txt as well. bug: https://bugs.openjdk.java.net/browse/JDK-8157813 webrev: http://cr.openjdk.java.net/~amlu/8157813/webrev.00/ Thanks, Amy --- old/test/ProblemList.txt 2016-05-25 17:34:27.000000000 +0800 +++ new/test/ProblemList.txt 2016-05-25 17:34:26.000000000 +0800 @@ -195,8 +195,6 @@ java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java 7191877 generic-all -sun/rmi/transport/proxy/EagerHttpFallback.java 7195095 generic-all - java/rmi/activation/Activatable/extLoadedImpl/ext.sh 8062724 generic-all sun/rmi/rmic/newrmic/equivalence/run.sh 8145980 generic-all From aleksey.shipilev at oracle.com Wed May 25 09:50:59 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 25 May 2016 12:50:59 +0300 Subject: JDK 9 RFR of JDK-8157813: Remove sun/rmi/transport/proxy/EagerHttpFallback.java from ProblemList.txt In-Reply-To: <5745741A.7040002@oracle.com> References: <5745741A.7040002@oracle.com> Message-ID: <57457583.8060405@oracle.com> On 05/25/2016 12:44 PM, Amy Lu wrote: > This patch is to remove this test from ProblemList.txt as well. > > bug: https://bugs.openjdk.java.net/browse/JDK-8157813 > webrev: http://cr.openjdk.java.net/~amlu/8157813/webrev.00/ Reviewed. Thanks, -Aleksey From chris.hegarty at oracle.com Wed May 25 10:43:14 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 25 May 2016 11:43:14 +0100 Subject: RFR [9] 8157825: Remove JDK 9 specific methods from sun.misc.Unsafe Message-ID: <557200C7-B8E4-4319-ADAB-B4D58845553F@oracle.com> sun.misc.Unsafe, in the jdk.unsupported module, should not have any new public methods that were not already part of its API in JDK 8. This issue will remove three such methods, getUncompressedObject, getJavaMirror, and getKlassPointer, that were added by JDK-8022853, in JDK 9. diff --git a/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java b/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java --- a/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java +++ b/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java @@ -296,45 +296,6 @@ theInternalUnsafe.putDouble(o, offset, x); } - - // These read VM internal data. - - /** - * Fetches an uncompressed reference value from a given native variable - * ignoring the VM's compressed references mode. - * - * @param address a memory address locating the variable - * @return the value fetched from the indicated native variable - */ - @ForceInline - public Object getUncompressedObject(long address) { - return theInternalUnsafe.getUncompressedObject(address); - } - - /** - * Fetches the {@link java.lang.Class} Java mirror for the given native - * metaspace {@code Klass} pointer. - * - * @param metaspaceKlass a native metaspace {@code Klass} pointer - * @return the {@link java.lang.Class} Java mirror - */ - @ForceInline - public Class getJavaMirror(long metaspaceKlass) { - return theInternalUnsafe.getJavaMirror(metaspaceKlass); - } - - /** - * Fetches a native metaspace {@code Klass} pointer for the given Java - * object. - * - * @param o Java heap object for which to fetch the class pointer - * @return a native metaspace {@code Klass} pointer - */ - @ForceInline - public long getKlassPointer(Object o) { - return theInternalUnsafe.getKlassPointer(o); - } - // These work on values in the C heap. /** -Chris. From aleksey.shipilev at oracle.com Wed May 25 10:52:08 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 25 May 2016 13:52:08 +0300 Subject: RFR [9] 8157825: Remove JDK 9 specific methods from sun.misc.Unsafe In-Reply-To: <557200C7-B8E4-4319-ADAB-B4D58845553F@oracle.com> References: <557200C7-B8E4-4319-ADAB-B4D58845553F@oracle.com> Message-ID: <574583D8.7070209@oracle.com> On 05/25/2016 01:43 PM, Chris Hegarty wrote: > sun.misc.Unsafe, in the jdk.unsupported module, should not have any new public > methods that were not already part of its API in JDK 8. This issue will remove three > such methods, getUncompressedObject, getJavaMirror, and getKlassPointer, that > were added by JDK-8022853, in JDK 9. Yes, +1. Thanks, -Aleksey From Alan.Bateman at oracle.com Wed May 25 10:54:47 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 May 2016 11:54:47 +0100 Subject: RFR [9] 8157825: Remove JDK 9 specific methods from sun.misc.Unsafe In-Reply-To: <557200C7-B8E4-4319-ADAB-B4D58845553F@oracle.com> References: <557200C7-B8E4-4319-ADAB-B4D58845553F@oracle.com> Message-ID: <57458477.2070008@oracle.com> On 25/05/2016 11:43, Chris Hegarty wrote: > sun.misc.Unsafe, in the jdk.unsupported module, should not have any new public > methods that were not already part of its API in JDK 8. This issue will remove three > such methods, getUncompressedObject, getJavaMirror, and getKlassPointer, that > were added by JDK-8022853, in JDK 9. > > Looks good. -Alan From uschindler at apache.org Wed May 25 11:04:45 2016 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 25 May 2016 13:04:45 +0200 Subject: RFR [9] 8157825: Remove JDK 9 specific methods from sun.misc.Unsafe In-Reply-To: <557200C7-B8E4-4319-ADAB-B4D58845553F@oracle.com> References: <557200C7-B8E4-4319-ADAB-B4D58845553F@oracle.com> Message-ID: <00ab01d1b675$4256f900$c704eb00$@apache.org> +1 Let public Unsafe die (at least partially)! :-) Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf Of Chris Hegarty > Sent: Wednesday, May 25, 2016 12:43 PM > To: core-libs-dev > Subject: RFR [9] 8157825: Remove JDK 9 specific methods from > sun.misc.Unsafe > > sun.misc.Unsafe, in the jdk.unsupported module, should not have any new > public > methods that were not already part of its API in JDK 8. This issue will remove > three > such methods, getUncompressedObject, getJavaMirror, and > getKlassPointer, that > were added by JDK-8022853, in JDK 9. > > diff --git a/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java > b/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java > --- a/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java > +++ b/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java > @@ -296,45 +296,6 @@ > theInternalUnsafe.putDouble(o, offset, x); > } > > - > - // These read VM internal data. > - > - /** > - * Fetches an uncompressed reference value from a given native variable > - * ignoring the VM's compressed references mode. > - * > - * @param address a memory address locating the variable > - * @return the value fetched from the indicated native variable > - */ > - @ForceInline > - public Object getUncompressedObject(long address) { > - return theInternalUnsafe.getUncompressedObject(address); > - } > - > - /** > - * Fetches the {@link java.lang.Class} Java mirror for the given native > - * metaspace {@code Klass} pointer. > - * > - * @param metaspaceKlass a native metaspace {@code Klass} pointer > - * @return the {@link java.lang.Class} Java mirror > - */ > - @ForceInline > - public Class getJavaMirror(long metaspaceKlass) { > - return theInternalUnsafe.getJavaMirror(metaspaceKlass); > - } > - > - /** > - * Fetches a native metaspace {@code Klass} pointer for the given Java > - * object. > - * > - * @param o Java heap object for which to fetch the class pointer > - * @return a native metaspace {@code Klass} pointer > - */ > - @ForceInline > - public long getKlassPointer(Object o) { > - return theInternalUnsafe.getKlassPointer(o); > - } > - > // These work on values in the C heap. > > /** > > -Chris.= From gary.adams at oracle.com Wed May 25 16:01:41 2016 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 25 May 2016 12:01:41 -0400 Subject: [9] RFR: Static build of libzip is missing JNI_OnLoad_zip entry point In-Reply-To: <4d46320e-739d-78cf-9110-a29815b06021@oracle.com> References: <4d46320e-739d-78cf-9110-a29815b06021@oracle.com> Message-ID: <5745CC65.5030000@oracle.com> This fix will not work for the macosx static build. e.g. configure --enable-static-build=yes When linking static libraries the entry point for JNI_OnLoad_zip is needed to inform the symbol lookups to be performed on the current executable, rather than a dynamic library. On 05/24/16 19:47, Naoto Sato wrote: > Hello, > > The previous attempt to fix this one failed in the installer build, as > it does not recognize the added macro. I've updated the fix to add > extra check for static build (yeah, this is redundant with the real > jni_util.h, but effectively avoid the installer build failure). > > http://cr.openjdk.java.net/~naoto/8150179/webrev.01/ > > Please review. > > Naoto From andrey.x.nazarov at oracle.com Wed May 25 16:07:41 2016 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Wed, 25 May 2016 19:07:41 +0300 Subject: RFR: JDK-8157850 Jar tests should pass through VM options Message-ID: <2da88f6b-b377-ac21-cc34-a0f2a1a566bf@oracle.com> Some jar tests start VMs without passing vmoptions from jtreg. This fix pass jtreg's vmoptions and javaoptions to processes(java, jar, javac) started by tests. webrev: http://cr.openjdk.java.net/~anazarov/8157850/webrev.01/ jbs: https://bugs.openjdk.java.net/browse/JDK-8157850 --Andrey From gilleshabran at gmail.com Wed May 25 07:39:43 2016 From: gilleshabran at gmail.com (Gilles Habran) Date: Wed, 25 May 2016 09:39:43 +0200 Subject: Fwd: Files.walk() is unusable because of AccessDeniedException In-Reply-To: References: <57440E85.2040809@redhat.com> Message-ID: Hi Henry, I knew there was a work around as I created something similar than yours when I needed it. :) Apparently, we have two different opinions regarding Files.walk() and how this method is supposed to handle permissions. I just sent this email because I felt that Files.walk() didn't behave like it should, maybe I am wrong. I read everything from my root directory so it makes sense that that I don't have the permissions to read everything (I'll get the same thing when I read /proc for sure) but what happens the day I walk the home directory of the user as the user. I am supposed to have access to everything in there, right ? My application will just crash if there is a dirty file in there with bad permissions and there is nothing I can do about it... not with Files.walk(). To be sure that I don't have a problem, I will need to create my own method like yours because I would take a great risk using Files.walk() if I get an exception that stops my process in case there is an unexpected file with bad permissions. Have a nice day. Best regards, Gilles On 25 May 2016 at 08:23, Henry Jen wrote: > I think there is a work-around, use list() and flatMap() should get you > what you needed. > > The API is designed to walk a tree where you suppose to have access with. > If OS level cause an IOException, that need to be dealt with. Acknowledged > that exception handling is not a strong suite in Stream API, developer will > need to do some work. > > Files.find() also allows you to get entries and filter out by permission. > What you can do is make sure you have permission on the top level, then > call find with maxDepth 1 to only get entries on that directory. > > Combined with flatMap(), you should be able to get what you want. Try the > following code to see if it works for you. > > import java.nio.file.Files; > import java.nio.file.Path; > import java.nio.file.Paths; > import java.util.stream.Stream; > import java.io.IOException; > > public class ListCanRead { > static Stream walkReadable(Path p) { > if (Files.isReadable(p)) { > if (Files.isDirectory(p)) { > try { > return Stream.concat(Stream.of(p), Files.list(p)); > } catch (IOException ioe) { > return Stream.of(p); > } > } else { > return Stream.of(p); > } > } > return Stream.of(p); > } > > public static void main(String[] args) throws IOException { > System.out.println("List directory: " + args[0]); > walkReadable(Paths.get(args[0])).flatMap(ListCanRead::walkReadable) > .forEach(System.out::println); > > Files.walk(Paths.get(args[0])) > .forEach(System.out::println); // Could throw > AccessDeniedException > } > } > > Cheers, > Henry > > On May 24, 2016 at 4:48:30 PM, Gilles Habran (gilleshabran at gmail.com) > wrote: > > Good morning, > > > > well I would like to be able to manage the outcome of the processing > myself > > and not get an exception in a part where I have no control. > > > > For example, I would expect to get an exception when I tried to read a > file > > where I don't have the permission. I would not expect to get an exception > > when Java creates the Stream. > > > > Maybe I am the only one to have a problem with this ? I don't know but it > > feels strange to be forced to execute a software with root permissions > > where I don't even plan to read file I cannot read because of lack of > > permissions. > > > > For me, we should be able to test the attributes of a file and depending > on > > the result, read the file or not. If we read the file without permission, > > we get an exception, if not, we can go to the next file without error. > > > > If that's unclear, please let me know, I'll try to give more informations > > or examples. > > > > Thank you. > > > > On 24 May 2016 at 10:19, Andrew Haley wrote: > > > > > On 05/20/2016 10:38 AM, Gilles Habran wrote: > > > > why is my message still waiting for approval after a month ? > > > > > > What is it you want Java to do? You can't walk the directory > > > because you don't have permission. sudo should work. > > > > > > Andrew. > > > > > > > > > > From xueming.shen at oracle.com Wed May 25 16:39:15 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 25 May 2016 09:39:15 -0700 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() Message-ID: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> Hi, Please help review the changes for the following zipfs related bug fixes JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() JDK-8153248: (zipfs) ZipPath#getFileName( ) returns inconsistent result JDK-8146754: (zipfs) ZipPath.relativize() returns wrong result for path ending with slash / JDK-8139956: (zipfs) ZipPath does not produce correct empty path on relativize() issue: https://bugs.openjdk.java.net/browse/JDK-8147539 https://bugs.openjdk.java.net/browse/JDK-8153248 https://bugs.openjdk.java.net/browse/JDK-8146754 https://bugs.openjdk.java.net/browse/JDK-8139956 webrev: http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev/ The changes are relative easy. (1) ZipPath.initOffsets() should deal with empty path specially, as the UnixPath impl does (2) ZipPath.normalize(byte[]) should take care of tailing "/" (it is taken care of at ZipPath.normalize(byte[], int), but is missed in the "main" method) (3) ZipPath.register() should throw PME as suggested. Thanks, Sherman From naoto.sato at oracle.com Wed May 25 16:44:54 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 25 May 2016 09:44:54 -0700 Subject: [9] RFR: Static build of libzip is missing JNI_OnLoad_zip entry point In-Reply-To: <5745CC65.5030000@oracle.com> References: <4d46320e-739d-78cf-9110-a29815b06021@oracle.com> <5745CC65.5030000@oracle.com> Message-ID: Attached is the output from "nm -g build/macosx_x64/jdk/lib/libzip.a" with the proposed fix applied. I see the symbol "_JNI_OnLoad_zip" in it. Am I missing something? Naoto On 5/25/16 9:01 AM, Gary Adams wrote: > This fix will not work for the macosx static build. > e.g. configure --enable-static-build=yes > > When linking static libraries the entry point for > JNI_OnLoad_zip is needed to inform the symbol lookups > to be performed on the current executable, > rather than a dynamic library. > > On 05/24/16 19:47, Naoto Sato wrote: >> Hello, >> >> The previous attempt to fix this one failed in the installer build, as >> it does not recognize the added macro. I've updated the fix to add >> extra check for static build (yeah, this is redundant with the real >> jni_util.h, but effectively avoid the installer build failure). >> >> http://cr.openjdk.java.net/~naoto/8150179/webrev.01/ >> >> Please review. >> >> Naoto > -------------- next part -------------- libzip.a(Adler32.o): 0000000000000000 T _Java_java_util_zip_Adler32_update 0000000000000090 T _Java_java_util_zip_Adler32_updateByteBuffer 0000000000000022 T _Java_java_util_zip_Adler32_updateBytes U _adler32 libzip.a(CRC32.o): 0000000000000000 T _Java_java_util_zip_CRC32_update 000000000000009d T _Java_java_util_zip_CRC32_updateByteBuffer0 0000000000000022 T _Java_java_util_zip_CRC32_updateBytes0 0000000000000090 T _ZIP_CRC32 U _crc32 libzip.a(Deflater.o): U _JNU_ThrowIllegalArgumentException U _JNU_ThrowInternalError U _JNU_ThrowOutOfMemoryError 00000000000002fd T _Java_java_util_zip_Deflater_deflateBytes 000000000000076b T _Java_java_util_zip_Deflater_end 0000000000000736 T _Java_java_util_zip_Deflater_getAdler 000000000000015f T _Java_java_util_zip_Deflater_init 0000000000000000 T _Java_java_util_zip_Deflater_initIDs 000000000000073f T _Java_java_util_zip_Deflater_reset 000000000000024e T _Java_java_util_zip_Deflater_setDictionary U _calloc U _deflate U _deflateEnd U _deflateInit2_ U _deflateParams U _deflateReset U _deflateSetDictionary U _free libzip.a(Inflater.o): U _JNU_ThrowByName U _JNU_ThrowIllegalArgumentException U _JNU_ThrowInternalError U _JNU_ThrowOutOfMemoryError 000000000000052d T _Java_java_util_zip_Inflater_end 00000000000004f8 T _Java_java_util_zip_Inflater_getAdler 0000000000000246 T _Java_java_util_zip_Inflater_inflateBytes 00000000000000d8 T _Java_java_util_zip_Inflater_init 0000000000000000 T _Java_java_util_zip_Inflater_initIDs 0000000000000501 T _Java_java_util_zip_Inflater_reset 0000000000000191 T _Java_java_util_zip_Inflater_setDictionary U _calloc U _free U _inflate U _inflateEnd U _inflateInit2_ U _inflateReset U _inflateSetDictionary libzip.a(zip_util.o): 0000000000001de0 T _InflateFully 0000000000000000 T _JNI_OnLoad_zip U _JVM_NativePath U _JVM_RawMonitorCreate U _JVM_RawMonitorDestroy U _JVM_RawMonitorEnter U _JVM_RawMonitorExit 0000000000001104 T _ZIP_Close 000000000000201a T _ZIP_FindEntry 0000000000001188 T _ZIP_FreeEntry 000000000000121a T _ZIP_GetEntry 0000000000001253 T _ZIP_GetEntry2 0000000000001c26 T _ZIP_GetEntryDataOffset 0000000000001bd7 T _ZIP_GetNextEntry 000000000000007f T _ZIP_Get_From_Cache 00000000000022b3 T _ZIP_InflateFully 00000000000011fe T _ZIP_Lock 00000000000010c5 T _ZIP_Open 000000000000000b T _ZIP_Open_Generic 00000000000001ce T _ZIP_Put_In_Cache 00000000000001de T _ZIP_Put_In_Cache0 0000000000001d25 T _ZIP_Read 000000000000206d T _ZIP_ReadEntry 000000000000120c T _ZIP_Unlock U ___error U ___memset_chk U ___stack_chk_fail U ___stack_chk_guard U ___stderrp U ___strcpy_chk U _calloc U _close 0000000000001422 T _equals U _free U _getErrorString U _getLastErrorString U _inflate U _inflateEnd U _inflateInit2_ U _jio_fprintf U _lseek U _malloc U _memcpy U _memset U _mmap U _munmap U _open U _read U _realloc U _strcmp U _strcpy U _strdup U _strlen U _sysconf From gary.adams at oracle.com Wed May 25 16:57:13 2016 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 25 May 2016 12:57:13 -0400 Subject: [9] RFR: Static build of libzip is missing JNI_OnLoad_zip entry point In-Reply-To: References: <4d46320e-739d-78cf-9110-a29815b06021@oracle.com> <5745CC65.5030000@oracle.com> Message-ID: <5745D969.7080501@oracle.com> Never mind. You are right. The static case is fine with your fix. There won't be a JNI_OnLoad entry for the dynamic case, but that entry point is optional. On 05/25/16 12:44, Naoto Sato wrote: > Attached is the output from "nm -g build/macosx_x64/jdk/lib/libzip.a" > with the proposed fix applied. I see the symbol "_JNI_OnLoad_zip" in > it. Am I missing something? > > Naoto > > On 5/25/16 9:01 AM, Gary Adams wrote: >> This fix will not work for the macosx static build. >> e.g. configure --enable-static-build=yes >> >> When linking static libraries the entry point for >> JNI_OnLoad_zip is needed to inform the symbol lookups >> to be performed on the current executable, >> rather than a dynamic library. >> >> On 05/24/16 19:47, Naoto Sato wrote: >>> Hello, >>> >>> The previous attempt to fix this one failed in the installer build, as >>> it does not recognize the added macro. I've updated the fix to add >>> extra check for static build (yeah, this is redundant with the real >>> jni_util.h, but effectively avoid the installer build failure). >>> >>> http://cr.openjdk.java.net/~naoto/8150179/webrev.01/ >>> >>> Please review. >>> >>> Naoto >> From alexandre.iline at oracle.com Wed May 25 17:18:15 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 25 May 2016 10:18:15 -0700 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> Message-ID: Hi. Should the tests also declare ?@modules jdk.zipfs?? Shura > On May 25, 2016, at 9:39 AM, Xueming Shen wrote: > > Hi, > > Please help review the changes for the following zipfs related bug fixes > > JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() > JDK-8153248: (zipfs) ZipPath#getFileName( ) returns inconsistent result > JDK-8146754: (zipfs) ZipPath.relativize() returns wrong result for path ending with slash / > JDK-8139956: (zipfs) ZipPath does not produce correct empty path on relativize() > > issue: > https://bugs.openjdk.java.net/browse/JDK-8147539 > https://bugs.openjdk.java.net/browse/JDK-8153248 > https://bugs.openjdk.java.net/browse/JDK-8146754 > https://bugs.openjdk.java.net/browse/JDK-8139956 > > webrev: > http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev/ > > The changes are relative easy. > (1) ZipPath.initOffsets() should deal with empty path specially, as the UnixPath impl does > (2) ZipPath.normalize(byte[]) should take care of tailing "/" (it is taken care of at > ZipPath.normalize(byte[], int), but is missed in the "main" method) > (3) ZipPath.register() should throw PME as suggested. > > Thanks, > Sherman From martinrb at google.com Wed May 25 17:48:14 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 25 May 2016 10:48:14 -0700 Subject: RFR: JDK-8157850 Jar tests should pass through VM options In-Reply-To: <2da88f6b-b377-ac21-cc34-a0f2a1a566bf@oracle.com> References: <2da88f6b-b377-ac21-cc34-a0f2a1a566bf@oracle.com> Message-ID: Hi Andrey, Looking at http://openjdk.java.net/jtreg/vmoptions.html, I see we have both test.vm.opts and test.tool.vm.opts and the latter is supposed to take care of adding "-J". + VM_OPTIONS.stream().map(opt -> "-J" + opt).forEach(commands::add); + JAVA_OPTIONS.stream().map(opt -> "-J" + opt).forEach(commands::add); --- Maybe splitting on "\\s+" would be better. --- I think we should have test library methods to return the List for java subprocesses, one that could try hard to get the option tokenization correct. --- On Wed, May 25, 2016 at 9:07 AM, Andrey Nazarov wrote: > Some jar tests start VMs without passing vmoptions from jtreg. > > This fix pass jtreg's vmoptions and javaoptions to processes(java, jar, > javac) started by tests. > > webrev: http://cr.openjdk.java.net/~anazarov/8157850/webrev.01/ > > jbs: https://bugs.openjdk.java.net/browse/JDK-8157850 > > --Andrey > From mandy.chung at oracle.com Wed May 25 17:52:38 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 May 2016 10:52:38 -0700 Subject: RFR [9] 8157825: Remove JDK 9 specific methods from sun.misc.Unsafe In-Reply-To: <557200C7-B8E4-4319-ADAB-B4D58845553F@oracle.com> References: <557200C7-B8E4-4319-ADAB-B4D58845553F@oracle.com> Message-ID: <9CA17AF2-DAAF-4B7D-B9DF-58BF58675FD0@oracle.com> +1 Mandy > On May 25, 2016, at 3:43 AM, Chris Hegarty wrote: > > sun.misc.Unsafe, in the jdk.unsupported module, should not have any new public > methods that were not already part of its API in JDK 8. This issue will remove three > such methods, getUncompressedObject, getJavaMirror, and getKlassPointer, that > were added by JDK-8022853, in JDK 9. > > diff --git a/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java b/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java > --- a/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java > +++ b/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java > @@ -296,45 +296,6 @@ > theInternalUnsafe.putDouble(o, offset, x); > } > > - > - // These read VM internal data. > - > - /** > - * Fetches an uncompressed reference value from a given native variable > - * ignoring the VM's compressed references mode. > - * > - * @param address a memory address locating the variable > - * @return the value fetched from the indicated native variable > - */ > - @ForceInline > - public Object getUncompressedObject(long address) { > - return theInternalUnsafe.getUncompressedObject(address); > - } > - > - /** > - * Fetches the {@link java.lang.Class} Java mirror for the given native > - * metaspace {@code Klass} pointer. > - * > - * @param metaspaceKlass a native metaspace {@code Klass} pointer > - * @return the {@link java.lang.Class} Java mirror > - */ > - @ForceInline > - public Class getJavaMirror(long metaspaceKlass) { > - return theInternalUnsafe.getJavaMirror(metaspaceKlass); > - } > - > - /** > - * Fetches a native metaspace {@code Klass} pointer for the given Java > - * object. > - * > - * @param o Java heap object for which to fetch the class pointer > - * @return a native metaspace {@code Klass} pointer > - */ > - @ForceInline > - public long getKlassPointer(Object o) { > - return theInternalUnsafe.getKlassPointer(o); > - } > - > // These work on values in the C heap. > > /** > > -Chris. From xueming.shen at oracle.com Wed May 25 17:49:54 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 25 May 2016 10:49:54 -0700 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> Message-ID: <5745E5C2.4090705@oracle.com> Should it? My understanding is that those tests don't use zipfs directly from zipfs module, it access it via java.base's FileSystemProvider interface. It depends on the jdk runtime to pick up the zipfs "provider" to function. So if the jdk runtime fails to pick up the zipfs module for whatever reason, that's something we want to detect as well? -Sherman On 05/25/2016 10:18 AM, Alexandre (Shura) Iline wrote: > Hi. > > Should the tests also declare ?@modules jdk.zipfs?? > > Shura > >> On May 25, 2016, at 9:39 AM, Xueming Shen wrote: >> >> Hi, >> >> Please help review the changes for the following zipfs related bug fixes >> >> JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() >> JDK-8153248: (zipfs) ZipPath#getFileName( ) returns inconsistent result >> JDK-8146754: (zipfs) ZipPath.relativize() returns wrong result for path ending with slash / >> JDK-8139956: (zipfs) ZipPath does not produce correct empty path on relativize() >> >> issue: >> https://bugs.openjdk.java.net/browse/JDK-8147539 >> https://bugs.openjdk.java.net/browse/JDK-8153248 >> https://bugs.openjdk.java.net/browse/JDK-8146754 >> https://bugs.openjdk.java.net/browse/JDK-8139956 >> >> webrev: >> http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev/ >> >> The changes are relative easy. >> (1) ZipPath.initOffsets() should deal with empty path specially, as the UnixPath impl does >> (2) ZipPath.normalize(byte[]) should take care of tailing "/" (it is taken care of at >> ZipPath.normalize(byte[], int), but is missed in the "main" method) >> (3) ZipPath.register() should throw PME as suggested. >> >> Thanks, >> Sherman From alexandre.iline at oracle.com Wed May 25 18:06:43 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 25 May 2016 11:06:43 -0700 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: <5745E5C2.4090705@oracle.com> References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> <5745E5C2.4090705@oracle.com> Message-ID: Sherman, Not declaring any module dependencies in test is equivalent to declaring that the test only depends on java.base. In such case, the test will be picked up for execution by JTReg, no matter what modules are available. One way to test such behavior would be to supply -javaoptions:?-limitmods java.base? in the JTReg command line. The tests will be selected for execution, but would they work? I have taken another look on the code now, it looks like with the absence of jdk.zipfs test/jdk/nio/zipfs/Basic.java test will fail. I think it would be good to skip this test altogether if there is no jdk.zipfs available. Shura > On May 25, 2016, at 10:49 AM, Xueming Shen wrote: > > > Should it? My understanding is that those tests don't use zipfs directly > from zipfs module, it access it via java.base's FileSystemProvider interface. > It depends on the jdk runtime to pick up the zipfs "provider" to function. So > if the jdk runtime fails to pick up the zipfs module for whatever reason, > that's something we want to detect as well? > > -Sherman > > On 05/25/2016 10:18 AM, Alexandre (Shura) Iline wrote: >> Hi. >> >> Should the tests also declare ?@modules jdk.zipfs?? >> >> Shura >> >>> On May 25, 2016, at 9:39 AM, Xueming Shen wrote: >>> >>> Hi, >>> >>> Please help review the changes for the following zipfs related bug fixes >>> >>> JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() >>> JDK-8153248: (zipfs) ZipPath#getFileName( ) returns inconsistent result >>> JDK-8146754: (zipfs) ZipPath.relativize() returns wrong result for path ending with slash / >>> JDK-8139956: (zipfs) ZipPath does not produce correct empty path on relativize() >>> >>> issue: >>> https://bugs.openjdk.java.net/browse/JDK-8147539 >>> https://bugs.openjdk.java.net/browse/JDK-8153248 >>> https://bugs.openjdk.java.net/browse/JDK-8146754 >>> https://bugs.openjdk.java.net/browse/JDK-8139956 >>> >>> webrev: >>> http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev/ >>> >>> The changes are relative easy. >>> (1) ZipPath.initOffsets() should deal with empty path specially, as the UnixPath impl does >>> (2) ZipPath.normalize(byte[]) should take care of tailing "/" (it is taken care of at >>> ZipPath.normalize(byte[], int), but is missed in the "main" method) >>> (3) ZipPath.register() should throw PME as suggested. >>> >>> Thanks, >>> Sherman > From martinrb at google.com Wed May 25 18:09:15 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 25 May 2016 11:09:15 -0700 Subject: VarHandles on non-int-sized fields and atomic operations In-Reply-To: References: <574380EE.7080607@oracle.com> <574388A3.90706@oracle.com> <0FAA8D1C-0FB5-4058-A8C5-E905306E6D84@oracle.com> <5744AB7F.4070202@oracle.com> <40963353-AF70-453C-A451-E69FC32E32C7@oracle.com> Message-ID: On Wed, May 25, 2016 at 12:53 AM, Paul Sandoz wrote: > >> On 25 May 2016, at 01:15, Martin Buchholz wrote: >> We already sort-of have an existing field qualifier for atomic: "volatile" ! >> It is already the case that e.g. volatile long is atomic while >> unadorned long is not. >> But atomics without CAS make us sad, so we're adding them. >> Also, by analogy, Atomic*FieldUpdaters must refer to a volatile variable. >> It seems not unreasonable to require that VarHandles also refer to a >> volatile field. >> > > We wanted the flexibility to perform ?normal" plain access against other accesses using a VarHandle, of course that requires very careful use. Furthermore, other operations anyway override that of the volatile semantics. A*FU also provides API to weaken the normal semantics of volatile - e.g. (the poorly named and specified) lazySet. So it is already the case that there is no global sequential consistent order in Java for all memory operations on fields marked volatile! (It's true that there is no "volatile" for array elements) The dynamic nature of VarHandle bothers me a little. Static analysis tools cannot discover fields being used with atomic operations with certainty. Even though in practice most uses of VarHandles will be to fields declared "nearby". From martinrb at google.com Wed May 25 18:20:23 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 25 May 2016 11:20:23 -0700 Subject: VarHandles on non-int-sized fields and atomic operations In-Reply-To: References: <574380EE.7080607@oracle.com> <574388A3.90706@oracle.com> <0FAA8D1C-0FB5-4058-A8C5-E905306E6D84@oracle.com> <5744AB7F.4070202@oracle.com> <40963353-AF70-453C-A451-E69FC32E32C7@oracle.com> Message-ID: On Wed, May 25, 2016 at 12:53 AM, Paul Sandoz wrote: > > Aleksey did some analysis to indicate we might be able to achieve access atomicity (not conflated with being able to perform an efficient CAS) by default without qualification for all types: > > http://shipilev.net/blog/2014/all-accesses-are-atomic/ I don't do "mobile Java", but I suspect platforms without 64-bit atomic instructions are still important. > and you can even use an experimental flag -XX:+AlwaysAtomicAccesses and try it out. We should imagine that Value Types are coming soon, and what we're developing now will need to fit into that world. We will have value types that are too small and too big for machine CAS instructions. The ones that are too big will be a bigger problem (need to use a lock!) than the ones that are too small (need to use over-sized CAS in a loop, or reserve more space) From Alan.Bateman at oracle.com Wed May 25 18:20:25 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 May 2016 19:20:25 +0100 Subject: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL In-Reply-To: References: <2DB03389-7ADF-4752-A507-88F0058E230E@oracle.com> <5744A23C.4030704@oracle.com> Message-ID: <5745ECE9.8020401@oracle.com> On 24/05/2016 23:02, Martin Buchholz wrote: > On Tue, May 24, 2016 at 11:49 AM, Alan Bateman wrote: > >> Yeah, the context isn't clear here. This is all related to the HotSpot CDS >> feature and so very tied to the built-in class loaders. File paths are >> recorded at -Xshare:dump time and checked at -Xshare:on time. Too many types >> of fie path and corner cases on Windows for the VM to get it right. > Canonicalization is reasonable for checking whether two files are the > same (but of course it's not reliable!). But it should be explained - > it is not at all obvious how this code relates to CDS... and the > resulting canonicalized paths should never be exposed to the user, > e.g. in java.class.path. It's not exposed in the value of java.class.path but URLs to resources on the class path are based on the canonical file path. It would be nice to not need that but this behavior has been there for a long time (we still JDK 1.2) so we have to be cautious about changing it. -Alan From jiangli.zhou at oracle.com Wed May 25 18:28:49 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 25 May 2016 11:28:49 -0700 Subject: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL In-Reply-To: <6F6DE1EB-2CA5-400E-9E4E-A5ACAB6DD4CD@oracle.com> References: <2DB03389-7ADF-4752-A507-88F0058E230E@oracle.com> <6F6DE1EB-2CA5-400E-9E4E-A5ACAB6DD4CD@oracle.com> Message-ID: Here is the updated webrev: http://cr.openjdk.java.net/~jiangli/8157716/webrev.01/ Thanks, Jiangli > On May 24, 2016, at 1:00 PM, Jiangli Zhou wrote: > > Hi Martin, > > Thanks for the review. > >> On May 24, 2016, at 10:57 AM, Martin Buchholz wrote: >> >> English syntax error. >> >> + * Attempts to convert to the given string to a file URL. >> > > Will fix. > >> --- >> >> There should be some motivation for why you are calling toRealPath, >> and e.g. not toAbsolutePath. >> What problem are you trying to solve? > > The toRealPath() method is used by the class loader code in the core library to convert each element in the class path to its real path. The VM also needs to retrieve the path information when loading CDS archived classes. The VM behavior needs be consistent with the core library when handling the class path. That?s why the new API is created for both the library and VM code to use. > > Thanks, > Jiangli > >> >> At Google we have special needs - this is the kind of change we end up >> locally reverting. >> >> >> On Tue, May 24, 2016 at 10:47 AM, Jiangli Zhou wrote: >>> Hi, >>> >>> Please review the following webrev that changes the jdk.internal.loader.ClassLoaders.addURLToUCP() to java.internal.loader.ClassLoaders.toFileURL(). The change is provided by Alan (thanks, Alan!). >>> >>> webrev: http://cr.openjdk.java.net/~jiangli/8157716/webrev.00/ >>> but: https://bugs.openjdk.java.net/browse/JDK-8157716 >>> >>> Thanks, >>> Jiangli >>> >>> > From mandy.chung at oracle.com Wed May 25 18:31:03 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 May 2016 11:31:03 -0700 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> <5745E5C2.4090705@oracle.com> Message-ID: <7EEDA61B-69FF-4A13-99A3-990EC1A05E66@oracle.com> The tests under test/jdk/nio/zipfs are intended to test the zipfs implementation and hence they fail if the zipfs provider does not exist. So I agree with Shura that they should have @modules jdk.zipfs that enables test selection per the @modules declaration. Mandy > On May 25, 2016, at 11:06 AM, Alexandre (Shura) Iline wrote: > > Sherman, > > Not declaring any module dependencies in test is equivalent to declaring that the test only depends on java.base. In such case, the test will be picked up for execution by JTReg, no matter what modules are available. One way to test such behavior would be to supply -javaoptions:?-limitmods java.base? in the JTReg command line. The tests will be selected for execution, but would they work? > > I have taken another look on the code now, it looks like with the absence of jdk.zipfs test/jdk/nio/zipfs/Basic.java test will fail. I think it would be good to skip this test altogether if there is no jdk.zipfs available. > > Shura > >> On May 25, 2016, at 10:49 AM, Xueming Shen wrote: >> >> >> Should it? My understanding is that those tests don't use zipfs directly >> from zipfs module, it access it via java.base's FileSystemProvider interface. >> It depends on the jdk runtime to pick up the zipfs "provider" to function. So >> if the jdk runtime fails to pick up the zipfs module for whatever reason, >> that's something we want to detect as well? >> >> -Sherman >> >> On 05/25/2016 10:18 AM, Alexandre (Shura) Iline wrote: >>> Hi. >>> >>> Should the tests also declare ?@modules jdk.zipfs?? >>> >>> Shura >>> >>>> On May 25, 2016, at 9:39 AM, Xueming Shen wrote: >>>> >>>> Hi, >>>> >>>> Please help review the changes for the following zipfs related bug fixes >>>> >>>> JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() >>>> JDK-8153248: (zipfs) ZipPath#getFileName( ) returns inconsistent result >>>> JDK-8146754: (zipfs) ZipPath.relativize() returns wrong result for path ending with slash / >>>> JDK-8139956: (zipfs) ZipPath does not produce correct empty path on relativize() >>>> >>>> issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8147539 >>>> https://bugs.openjdk.java.net/browse/JDK-8153248 >>>> https://bugs.openjdk.java.net/browse/JDK-8146754 >>>> https://bugs.openjdk.java.net/browse/JDK-8139956 >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev/ >>>> >>>> The changes are relative easy. >>>> (1) ZipPath.initOffsets() should deal with empty path specially, as the UnixPath impl does >>>> (2) ZipPath.normalize(byte[]) should take care of tailing "/" (it is taken care of at >>>> ZipPath.normalize(byte[], int), but is missed in the "main" method) >>>> (3) ZipPath.register() should throw PME as suggested. >>>> >>>> Thanks, >>>> Sherman >> > From xueming.shen at oracle.com Wed May 25 18:31:52 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 25 May 2016 11:31:52 -0700 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> <5745E5C2.4090705@oracle.com> Message-ID: <5745EF98.9040002@oracle.com> On 5/25/16, 11:06 AM, Alexandre (Shura) Iline wrote: > Sherman, > > Not declaring any module dependencies in test is equivalent to declaring that the test only depends on java.base. In such case, the test will be picked up for execution by JTReg, no matter what modules are available. One way to test such behavior would be to supply -javaoptions:?-limitmods java.base? in the JTReg command line. The tests will be selected for execution, but would they work? > > I have taken another look on the code now, it looks like with the absence of jdk.zipfs test/jdk/nio/zipfs/Basic.java test will fail. I think it would be good to skip this test altogether if there is no jdk.zipfs available. Hi Shura, Yes, the test will fail if the jdk.zipfs is absence. With the assumption that zipfs module should be available to the jdk images/runtime by default. If it's not there/available, something is wrong and we would want to know why. So the intention here is not to skip the zipfs test silently, if the zipfs is missing from the jdk image. That said, arguably these existing tests are the unit tests for the zipfs functionality, it might be desired to have separate test(s) for testing the availability of the zipfs... sherman > > Shura > >> On May 25, 2016, at 10:49 AM, Xueming Shen wrote: >> >> >> Should it? My understanding is that those tests don't use zipfs directly >> from zipfs module, it access it via java.base's FileSystemProvider interface. >> It depends on the jdk runtime to pick up the zipfs "provider" to function. So >> if the jdk runtime fails to pick up the zipfs module for whatever reason, >> that's something we want to detect as well? >> >> -Sherman >> >> On 05/25/2016 10:18 AM, Alexandre (Shura) Iline wrote: >>> Hi. >>> >>> Should the tests also declare ?@modules jdk.zipfs?? >>> >>> Shura >>> >>>> On May 25, 2016, at 9:39 AM, Xueming Shen wrote: >>>> >>>> Hi, >>>> >>>> Please help review the changes for the following zipfs related bug fixes >>>> >>>> JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() >>>> JDK-8153248: (zipfs) ZipPath#getFileName( ) returns inconsistent result >>>> JDK-8146754: (zipfs) ZipPath.relativize() returns wrong result for path ending with slash / >>>> JDK-8139956: (zipfs) ZipPath does not produce correct empty path on relativize() >>>> >>>> issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8147539 >>>> https://bugs.openjdk.java.net/browse/JDK-8153248 >>>> https://bugs.openjdk.java.net/browse/JDK-8146754 >>>> https://bugs.openjdk.java.net/browse/JDK-8139956 >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev/ >>>> >>>> The changes are relative easy. >>>> (1) ZipPath.initOffsets() should deal with empty path specially, as the UnixPath impl does >>>> (2) ZipPath.normalize(byte[]) should take care of tailing "/" (it is taken care of at >>>> ZipPath.normalize(byte[], int), but is missed in the "main" method) >>>> (3) ZipPath.register() should throw PME as suggested. >>>> >>>> Thanks, >>>> Sherman From Alan.Bateman at oracle.com Wed May 25 18:43:18 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 May 2016 19:43:18 +0100 Subject: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL In-Reply-To: References: <2DB03389-7ADF-4752-A507-88F0058E230E@oracle.com> <6F6DE1EB-2CA5-400E-9E4E-A5ACAB6DD4CD@oracle.com> Message-ID: <5745F246.2040401@oracle.com> On 25/05/2016 19:28, Jiangli Zhou wrote: > Here is the updated webrev: > > http://cr.openjdk.java.net/~jiangli/8157716/webrev.01/ This patch changes long standing behavior in URLs to resources on the class path will no longer be URLs to the canonical file path. It's might be okay but it's impossible to know. I thought the first patch was okay, except for the typo that Martin pointed out. -Alan From alexandre.iline at oracle.com Wed May 25 18:46:14 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 25 May 2016 11:46:14 -0700 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: <5745EF98.9040002@oracle.com> References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> <5745E5C2.4090705@oracle.com> <5745EF98.9040002@oracle.com> Message-ID: > On May 25, 2016, at 11:31 AM, Xueming Shen wrote: > > On 5/25/16, 11:06 AM, Alexandre (Shura) Iline wrote: >> Sherman, >> >> Not declaring any module dependencies in test is equivalent to declaring that the test only depends on java.base. In such case, the test will be picked up for execution by JTReg, no matter what modules are available. One way to test such behavior would be to supply -javaoptions:?-limitmods java.base? in the JTReg command line. The tests will be selected for execution, but would they work? >> >> I have taken another look on the code now, it looks like with the absence of jdk.zipfs test/jdk/nio/zipfs/Basic.java test will fail. I think it would be good to skip this test altogether if there is no jdk.zipfs available. > > Hi Shura, > > Yes, the test will fail if the jdk.zipfs is absence. With the assumption that zipfs module should > be available to the jdk images/runtime by default. If it's not there/available, something is wrong Well, not necessarily. Since JTReg is taking on the burden to select tests for execution based on the available modules, be it -limitmods option or a custom built limited JDK image, the test suite will be used to execute tests for compact profiles, for example. We will be relying on JTReg to select proper tests. The plan is to get rid of the test groups for compact profiles when the test markup is complete. Shura > and we would want to know why. So the intention here is not to skip the zipfs test silently, if > the zipfs is missing from the jdk image. That said, arguably these existing tests are the unit tests > for the zipfs functionality, it might be desired to have separate test(s) for testing the availability > of the zipfs... > > sherman > >> >> Shura >> >>> On May 25, 2016, at 10:49 AM, Xueming Shen wrote: >>> >>> >>> Should it? My understanding is that those tests don't use zipfs directly >>> from zipfs module, it access it via java.base's FileSystemProvider interface. >>> It depends on the jdk runtime to pick up the zipfs "provider" to function. So >>> if the jdk runtime fails to pick up the zipfs module for whatever reason, >>> that's something we want to detect as well? >>> >>> -Sherman >>> >>> On 05/25/2016 10:18 AM, Alexandre (Shura) Iline wrote: >>>> Hi. >>>> >>>> Should the tests also declare ?@modules jdk.zipfs?? >>>> >>>> Shura >>>> >>>>> On May 25, 2016, at 9:39 AM, Xueming Shen wrote: >>>>> >>>>> Hi, >>>>> >>>>> Please help review the changes for the following zipfs related bug fixes >>>>> >>>>> JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() >>>>> JDK-8153248: (zipfs) ZipPath#getFileName( ) returns inconsistent result >>>>> JDK-8146754: (zipfs) ZipPath.relativize() returns wrong result for path ending with slash / >>>>> JDK-8139956: (zipfs) ZipPath does not produce correct empty path on relativize() >>>>> >>>>> issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8147539 >>>>> https://bugs.openjdk.java.net/browse/JDK-8153248 >>>>> https://bugs.openjdk.java.net/browse/JDK-8146754 >>>>> https://bugs.openjdk.java.net/browse/JDK-8139956 >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev/ >>>>> >>>>> The changes are relative easy. >>>>> (1) ZipPath.initOffsets() should deal with empty path specially, as the UnixPath impl does >>>>> (2) ZipPath.normalize(byte[]) should take care of tailing "/" (it is taken care of at >>>>> ZipPath.normalize(byte[], int), but is missed in the "main" method) >>>>> (3) ZipPath.register() should throw PME as suggested. >>>>> >>>>> Thanks, >>>>> Sherman > From martinrb at google.com Wed May 25 18:50:10 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 25 May 2016 11:50:10 -0700 Subject: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL In-Reply-To: <5745F246.2040401@oracle.com> References: <2DB03389-7ADF-4752-A507-88F0058E230E@oracle.com> <6F6DE1EB-2CA5-400E-9E4E-A5ACAB6DD4CD@oracle.com> <5745F246.2040401@oracle.com> Message-ID: Ohh, I missed that calling toRealPath was existing behavior, not changed by webrev.00 I agree changing that sort of thing is risky. Will toFileURL really be called by the VM? It's not now. I'm surprised the VM would want an actual URL instead of a canonicalized native file name. On Wed, May 25, 2016 at 11:43 AM, Alan Bateman wrote: > > > On 25/05/2016 19:28, Jiangli Zhou wrote: >> >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~jiangli/8157716/webrev.01/ > > This patch changes long standing behavior in URLs to resources on the class > path will no longer be URLs to the canonical file path. It's might be okay > but it's impossible to know. I thought the first patch was okay, except for > the typo that Martin pointed out. > > -Alan From Alan.Bateman at oracle.com Wed May 25 18:55:33 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 May 2016 19:55:33 +0100 Subject: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL In-Reply-To: References: <2DB03389-7ADF-4752-A507-88F0058E230E@oracle.com> <6F6DE1EB-2CA5-400E-9E4E-A5ACAB6DD4CD@oracle.com> <5745F246.2040401@oracle.com> Message-ID: <5745F525.5030702@oracle.com> On 25/05/2016 19:50, Martin Buchholz wrote: > Ohh, I missed that calling toRealPath was existing behavior, not > changed by webrev.00 > I agree changing that sort of thing is risky. I think so too as the existing behavior go way back (I think JDK 1.2). > > Will toFileURL really be called by the VM? It's not now. I'm > surprised the VM would want an actual URL instead of a canonicalized > native file name. It's related to protection domain checking so that is why it's a URL. -Alan From jiangli.zhou at oracle.com Wed May 25 18:55:44 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 25 May 2016 11:55:44 -0700 Subject: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL In-Reply-To: <5745F246.2040401@oracle.com> References: <2DB03389-7ADF-4752-A507-88F0058E230E@oracle.com> <6F6DE1EB-2CA5-400E-9E4E-A5ACAB6DD4CD@oracle.com> <5745F246.2040401@oracle.com> Message-ID: > On May 25, 2016, at 11:43 AM, Alan Bateman wrote: > > > > On 25/05/2016 19:28, Jiangli Zhou wrote: >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~jiangli/8157716/webrev.01/ > This patch changes long standing behavior in URLs to resources on the class path will no longer be URLs to the canonical file path. It's might be okay but it's impossible to know. I thought the first patch was okay, except for the typo that Martin pointed out. My mistake. I?ve re-updated the above webrev. Please refresh the link. Thanks, Jiangli > > -Alan From andrey.x.nazarov at oracle.com Wed May 25 18:57:39 2016 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Wed, 25 May 2016 21:57:39 +0300 Subject: RFR: JDK-8157850 Jar tests should pass through VM options In-Reply-To: References: <2da88f6b-b377-ac21-cc34-a0f2a1a566bf@oracle.com> Message-ID: Hi Martin, See my comments inline. > On 25 May 2016, at 20:48, Martin Buchholz wrote: > > Hi Andrey, > > Looking at http://openjdk.java.net/jtreg/vmoptions.html, > I see we have both test.vm.opts and test.tool.vm.opts > and the latter is supposed to take care of adding "-J". > > + VM_OPTIONS.stream().map(opt -> "-J" + opt).forEach(commands::add); > + JAVA_OPTIONS.stream().map(opt -> "-J" + opt).forEach(commands::add); I considered this option for Basic.java test. But it doesn?t make code clearer.The test requires both test.tool.vm.opts and test.vm.opts for jar tool and java invocation. For CLICompatibility.java test.tool.vm.opts is enough since test invokes only jar tool. > > --- > > Maybe splitting on "\\s+" would be better. In theory yes. I?ll update. > > --- > > I think we should have test library methods to return the List > for java subprocesses, one that could try hard to get the option > tokenization correct. Agree. But I think it should be separate patch with changes in tests that use process builder with such option. Better we need some framework which will pass options for us. It?s common problem not passing through VM options. > > --- > > > On Wed, May 25, 2016 at 9:07 AM, Andrey Nazarov > wrote: >> Some jar tests start VMs without passing vmoptions from jtreg. >> >> This fix pass jtreg's vmoptions and javaoptions to processes(java, jar, >> javac) started by tests. >> >> webrev: http://cr.openjdk.java.net/~anazarov/8157850/webrev.01/ >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8157850 >> >> --Andrey >> From martinrb at google.com Wed May 25 19:04:19 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 25 May 2016 12:04:19 -0700 Subject: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL In-Reply-To: References: <2DB03389-7ADF-4752-A507-88F0058E230E@oracle.com> <6F6DE1EB-2CA5-400E-9E4E-A5ACAB6DD4CD@oracle.com> <5745F246.2040401@oracle.com> Message-ID: Since canonicalization is an important part of this API, I suggest renaming toFileURL to toCanonicalFileURL by analogy with getCanonicalFile. Also, I'm sure your security experts have already considered the implications of following or not following symlinks when matching user-provided paths ... On Wed, May 25, 2016 at 11:55 AM, Jiangli Zhou wrote: > >> On May 25, 2016, at 11:43 AM, Alan Bateman wrote: >> >> >> >> On 25/05/2016 19:28, Jiangli Zhou wrote: >>> Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~jiangli/8157716/webrev.01/ >> This patch changes long standing behavior in URLs to resources on the class path will no longer be URLs to the canonical file path. It's might be okay but it's impossible to know. I thought the first patch was okay, except for the typo that Martin pointed out. > > My mistake. I?ve re-updated the above webrev. Please refresh the link. > > Thanks, > Jiangli > >> >> -Alan > From xueming.shen at oracle.com Wed May 25 19:01:34 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 25 May 2016 12:01:34 -0700 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> <5745E5C2.4090705@oracle.com> <5745EF98.9040002@oracle.com> Message-ID: <5745F68E.6020001@oracle.com> On 05/25/2016 11:46 AM, Alexandre (Shura) Iline wrote: >> On May 25, 2016, at 11:31 AM, Xueming Shen wrote: >> >> On 5/25/16, 11:06 AM, Alexandre (Shura) Iline wrote: >>> Sherman, >>> >>> Not declaring any module dependencies in test is equivalent to declaring that the test only depends on java.base. In such case, the test will be picked up for execution by JTReg, no matter what modules are available. One way to test such behavior would be to supply -javaoptions:?-limitmods java.base? in the JTReg command line. The tests will be selected for execution, but would they work? >>> >>> I have taken another look on the code now, it looks like with the absence of jdk.zipfs test/jdk/nio/zipfs/Basic.java test will fail. I think it would be good to skip this test altogether if there is no jdk.zipfs available. >> Hi Shura, >> >> Yes, the test will fail if the jdk.zipfs is absence. With the assumption that zipfs module should >> be available to the jdk images/runtime by default. If it's not there/available, something is wrong > Well, not necessarily. > > Since JTReg is taking on the burden to select tests for execution based on the available modules, be it -limitmods option or a custom built limited JDK image, the test suite will be used to execute tests for compact profiles, for example. We will be relying on JTReg to select proper tests. The plan is to get rid of the test groups for compact profiles when the test markup is complete. > > Shura > Sure, if there is such "plan". http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev Here is the updated webrev with the @module tag. thanks! Sherman From Alan.Bateman at oracle.com Wed May 25 19:14:12 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 May 2016 20:14:12 +0100 Subject: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL In-Reply-To: References: <2DB03389-7ADF-4752-A507-88F0058E230E@oracle.com> <6F6DE1EB-2CA5-400E-9E4E-A5ACAB6DD4CD@oracle.com> <5745F246.2040401@oracle.com> Message-ID: <5745F984.3020806@oracle.com> On 25/05/2016 20:04, Martin Buchholz wrote: > : > > Also, I'm sure your security experts have already considered the > implications of following or not following symlinks when matching > user-provided paths ... > Nothing has changed here and there is always a permission check before returning a URL to a resource on the class path. -Alan From mandy.chung at oracle.com Wed May 25 19:17:58 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 May 2016 12:17:58 -0700 Subject: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL In-Reply-To: References: <2DB03389-7ADF-4752-A507-88F0058E230E@oracle.com> <6F6DE1EB-2CA5-400E-9E4E-A5ACAB6DD4CD@oracle.com> Message-ID: <60117D7C-517A-493C-B5C5-682D3EDE5FAD@oracle.com> > On May 25, 2016, at 11:28 AM, Jiangli Zhou wrote: > > Here is the updated webrev: > > http://cr.openjdk.java.net/~jiangli/8157716/webrev.01/ The version restoring toRealPath looks okay. I think the proposed toFileURL method name is fine and perhaps the javadoc of toFileURL method could make it clearer. If we had to rename it, maybe toRealPathFileURL (mouthful but it clearly shows it?s ?real path? as specified in java.nio.file.Path). Mandy From martinrb at google.com Wed May 25 19:21:17 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 25 May 2016 12:21:17 -0700 Subject: RFR: JDK-8157850 Jar tests should pass through VM options In-Reply-To: References: <2da88f6b-b377-ac21-cc34-a0f2a1a566bf@oracle.com> Message-ID: Agreed and Reviewed! On Wed, May 25, 2016 at 11:57 AM, Andrey Nazarov wrote: > Hi Martin, > > See my comments inline. >> On 25 May 2016, at 20:48, Martin Buchholz wrote: >> >> Hi Andrey, >> >> Looking at http://openjdk.java.net/jtreg/vmoptions.html, >> I see we have both test.vm.opts and test.tool.vm.opts >> and the latter is supposed to take care of adding "-J". >> >> + VM_OPTIONS.stream().map(opt -> "-J" + opt).forEach(commands::add); >> + JAVA_OPTIONS.stream().map(opt -> "-J" + opt).forEach(commands::add); > I considered this option for Basic.java test. But it doesn?t make code clearer.The test requires both test.tool.vm.opts and test.vm.opts for jar tool and java invocation. > For CLICompatibility.java test.tool.vm.opts is enough since test invokes only jar tool. >> >> --- >> >> Maybe splitting on "\\s+" would be better. > In theory yes. I?ll update. >> >> --- >> >> I think we should have test library methods to return the List >> for java subprocesses, one that could try hard to get the option >> tokenization correct. > Agree. But I think it should be separate patch with changes in tests that use process builder with such option. Better we need some framework which will pass options for us. It?s common problem not passing through VM options. >> >> --- >> >> >> On Wed, May 25, 2016 at 9:07 AM, Andrey Nazarov >> wrote: >>> Some jar tests start VMs without passing vmoptions from jtreg. >>> >>> This fix pass jtreg's vmoptions and javaoptions to processes(java, jar, >>> javac) started by tests. >>> >>> webrev: http://cr.openjdk.java.net/~anazarov/8157850/webrev.01/ >>> >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8157850 >>> >>> --Andrey >>> > From jiangli.zhou at oracle.com Wed May 25 19:24:31 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 25 May 2016 12:24:31 -0700 Subject: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL In-Reply-To: <60117D7C-517A-493C-B5C5-682D3EDE5FAD@oracle.com> References: <2DB03389-7ADF-4752-A507-88F0058E230E@oracle.com> <6F6DE1EB-2CA5-400E-9E4E-A5ACAB6DD4CD@oracle.com> <60117D7C-517A-493C-B5C5-682D3EDE5FAD@oracle.com> Message-ID: <96047593-E526-44BB-A21F-E863A184762B@oracle.com> Hi Mandy, > On May 25, 2016, at 12:17 PM, Mandy Chung wrote: > > >> On May 25, 2016, at 11:28 AM, Jiangli Zhou wrote: >> >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~jiangli/8157716/webrev.01/ > > The version restoring toRealPath looks okay. Thanks for the review. > > I think the proposed toFileURL method name is fine and perhaps the javadoc of toFileURL method could make it clearer. If we had to rename it, maybe toRealPathFileURL (mouthful but it clearly shows it?s ?real path? as specified in java.nio.file.Path). I discussed with Alan. We will keep the proposed toFileURL method name for now. Thanks, Jiangli > > Mandy > From mandy.chung at oracle.com Wed May 25 19:29:48 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 May 2016 12:29:48 -0700 Subject: Review request JDK-8153944: wsimport and wsgen usage messages not printed Message-ID: <0E40526D-17C1-4E8E-B2D7-6099800A6965@oracle.com> wsgen and wsimport tools use the utility classes in java.xml.bind module to localize messages. Resource bundles are encapsulated in named modules and hence utility like com.sun.istack.internal.localization.LocalizableMessageFactory. The owner of the resource bundle should be the one loading ResourceBundle. The solution to this type of issue is to update the utility classes to accept a function to return ResourceBundle rather than by base name. Another alternative could do the localization locally within the module and this may not be applicable to JAX-WS since jdk.xml.ws is tightly coupled with java.xml.ws. Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153944/webrev.00 This patch touches quites a few files, one per supporting class to get messages from one resource bundle. The change is straight-forward and same pattern applies to each message file. Mandy From mandy.chung at oracle.com Wed May 25 19:39:32 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 May 2016 12:39:32 -0700 Subject: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL In-Reply-To: <96047593-E526-44BB-A21F-E863A184762B@oracle.com> References: <2DB03389-7ADF-4752-A507-88F0058E230E@oracle.com> <6F6DE1EB-2CA5-400E-9E4E-A5ACAB6DD4CD@oracle.com> <60117D7C-517A-493C-B5C5-682D3EDE5FAD@oracle.com> <96047593-E526-44BB-A21F-E863A184762B@oracle.com> Message-ID: <6EB1DBB1-10E2-495E-8805-8A11F711EC10@oracle.com> > On May 25, 2016, at 12:24 PM, Jiangli Zhou wrote: > > Hi Mandy, > >> On May 25, 2016, at 12:17 PM, Mandy Chung wrote: >> >> >>> On May 25, 2016, at 11:28 AM, Jiangli Zhou wrote: >>> >>> Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~jiangli/8157716/webrev.01/ >> >> The version restoring toRealPath looks okay. > > Thanks for the review. > >> >> I think the proposed toFileURL method name is fine and perhaps the javadoc of toFileURL method could make it clearer. If we had to rename it, maybe toRealPathFileURL (mouthful but it clearly shows it?s ?real path? as specified in java.nio.file.Path). > > I discussed with Alan. We will keep the proposed toFileURL method name for now. That?s fine with me. Mandy From Alan.Bateman at oracle.com Wed May 25 19:42:57 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 May 2016 20:42:57 +0100 Subject: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL In-Reply-To: <96047593-E526-44BB-A21F-E863A184762B@oracle.com> References: <2DB03389-7ADF-4752-A507-88F0058E230E@oracle.com> <6F6DE1EB-2CA5-400E-9E4E-A5ACAB6DD4CD@oracle.com> <60117D7C-517A-493C-B5C5-682D3EDE5FAD@oracle.com> <96047593-E526-44BB-A21F-E863A184762B@oracle.com> Message-ID: <57460041.5040203@oracle.com> On 25/05/2016 20:24, Jiangli Zhou wrote: > >> I think the proposed toFileURL method name is fine and perhaps the javadoc of toFileURL method could make it clearer. If we had to rename it, maybe toRealPathFileURL (mouthful but it clearly shows it?s ?real path? as specified in java.nio.file.Path). > I discussed with Alan. We will keep the proposed toFileURL method name for now. > That should be fine. This is internal to the JDK and the VM doesn't care whether how the URL is constructed, it just has to be consistent with the library code I think. -Alan From Alan.Bateman at oracle.com Wed May 25 19:45:25 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 May 2016 20:45:25 +0100 Subject: Review request JDK-8153944: wsimport and wsgen usage messages not printed In-Reply-To: <0E40526D-17C1-4E8E-B2D7-6099800A6965@oracle.com> References: <0E40526D-17C1-4E8E-B2D7-6099800A6965@oracle.com> Message-ID: <574600D5.5060306@oracle.com> On 25/05/2016 20:29, Mandy Chung wrote: > wsgen and wsimport tools use the utility classes in java.xml.bind module to localize messages. Resource bundles are encapsulated in named modules and hence utility like com.sun.istack.internal.localization.LocalizableMessageFactory. > > The owner of the resource bundle should be the one loading ResourceBundle. The solution to this type of issue is to update the utility classes to accept a function to return ResourceBundle rather than by base name. Another alternative could do the localization locally within the module and this may not be applicable to JAX-WS since jdk.xml.ws is tightly coupled with java.xml.ws. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153944/webrev.00 > > This patch touches quites a few files, one per supporting class to get messages from one resource bundle. The change is straight-forward and same pattern applies to each message file. > I don't know area but I looked at the changes and I get the gist of this. It would be good if Aleksej could review as he's the current connection to the upstream project that owns this code. -Alan From mandy.chung at oracle.com Wed May 25 19:46:47 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 May 2016 12:46:47 -0700 Subject: Review request JDK-8157877: Clean up StackWalker permission checks Message-ID: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157877/webrev.00/ Trivial cleanup to do the check after the options are cloned. Mandy From lance.andersen at oracle.com Wed May 25 19:48:07 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 25 May 2016 15:48:07 -0400 Subject: Review request JDK-8157877: Clean up StackWalker permission checks In-Reply-To: References: Message-ID: +1 > On May 25, 2016, at 3:46 PM, Mandy Chung wrote: > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157877/webrev.00/ > > Trivial cleanup to do the check after the options are cloned. > 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 mandy.chung at oracle.com Wed May 25 19:48:36 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 May 2016 12:48:36 -0700 Subject: Review request JDK-8153944: wsimport and wsgen usage messages not printed In-Reply-To: <574600D5.5060306@oracle.com> References: <0E40526D-17C1-4E8E-B2D7-6099800A6965@oracle.com> <574600D5.5060306@oracle.com> Message-ID: > On May 25, 2016, at 12:45 PM, Alan Bateman wrote: > > On 25/05/2016 20:29, Mandy Chung wrote: >> wsgen and wsimport tools use the utility classes in java.xml.bind module to localize messages. Resource bundles are encapsulated in named modules and hence utility like com.sun.istack.internal.localization.LocalizableMessageFactory. >> >> The owner of the resource bundle should be the one loading ResourceBundle. The solution to this type of issue is to update the utility classes to accept a function to return ResourceBundle rather than by base name. Another alternative could do the localization locally within the module and this may not be applicable to JAX-WS since jdk.xml.ws is tightly coupled with java.xml.ws. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153944/webrev.00 >> >> This patch touches quites a few files, one per supporting class to get messages from one resource bundle. The change is straight-forward and same pattern applies to each message file. >> > I don't know area but I looked at the changes and I get the gist of this. It would be good if Aleksej could review as he's the current connection to the upstream project that owns this code. > I mentioned this patch to Aleksej earlier. Aleksej - can you review this too? Mandy From lance.andersen at oracle.com Wed May 25 19:49:09 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 25 May 2016 15:49:09 -0400 Subject: Review request JDK-8153944: wsimport and wsgen usage messages not printed In-Reply-To: <574600D5.5060306@oracle.com> References: <0E40526D-17C1-4E8E-B2D7-6099800A6965@oracle.com> <574600D5.5060306@oracle.com> Message-ID: <7482617A-1A45-4CC0-9E7F-694A511332A7@oracle.com> I looked at this also and do not see anything glaring. > On May 25, 2016, at 3:45 PM, Alan Bateman wrote: > > On 25/05/2016 20:29, Mandy Chung wrote: >> wsgen and wsimport tools use the utility classes in java.xml.bind module to localize messages. Resource bundles are encapsulated in named modules and hence utility like com.sun.istack.internal.localization.LocalizableMessageFactory. >> >> The owner of the resource bundle should be the one loading ResourceBundle. The solution to this type of issue is to update the utility classes to accept a function to return ResourceBundle rather than by base name. Another alternative could do the localization locally within the module and this may not be applicable to JAX-WS since jdk.xml.ws is tightly coupled with java.xml.ws. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153944/webrev.00 >> >> This patch touches quites a few files, one per supporting class to get messages from one resource bundle. The change is straight-forward and same pattern applies to each message file. >> > I don't know area but I looked at the changes and I get the gist of this. It would be good if Aleksej could review as he's the current connection to the upstream project that owns this code. > > -Alan 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 Alan.Bateman at oracle.com Wed May 25 19:49:13 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 May 2016 20:49:13 +0100 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: <5745F68E.6020001@oracle.com> References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> <5745E5C2.4090705@oracle.com> <5745EF98.9040002@oracle.com> <5745F68E.6020001@oracle.com> Message-ID: <574601B9.3040704@oracle.com> On 25/05/2016 20:01, Xueming Shen wrote: > : > > Sure, if there is such "plan". > > http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev > > > Here is the updated webrev with the @module tag. > In ZipPath.register then it would be good to include a comment to say something "watcher must be associated with a different provider" as it might not be immediately clear why ProviderMismatchException is thrown. The rest looks good to me. -Alan From xueming.shen at oracle.com Wed May 25 19:47:49 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 25 May 2016 12:47:49 -0700 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: <574601B9.3040704@oracle.com> References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> <5745E5C2.4090705@oracle.com> <5745EF98.9040002@oracle.com> <5745F68E.6020001@oracle.com> <574601B9.3040704@oracle.com> Message-ID: <57460165.3030903@oracle.com> On 05/25/2016 12:49 PM, Alan Bateman wrote: > > > On 25/05/2016 20:01, Xueming Shen wrote: >> : >> >> Sure, if there is such "plan". >> >> http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev >> >> Here is the updated webrev with the @module tag. >> > In ZipPath.register then it would be good to include a comment to say something "watcher must be associated with a different provider" as it might not be immediately clear why ProviderMismatchException is thrown. > > The rest looks good to me. > > -Alan thanks! updated accordingly. http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev -sherman From Alan.Bateman at oracle.com Wed May 25 19:56:05 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 May 2016 20:56:05 +0100 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: <57460165.3030903@oracle.com> References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> <5745E5C2.4090705@oracle.com> <5745EF98.9040002@oracle.com> <5745F68E.6020001@oracle.com> <574601B9.3040704@oracle.com> <57460165.3030903@oracle.com> Message-ID: <57460355.80208@oracle.com> On 25/05/2016 20:47, Xueming Shen wrote: > thanks! updated accordingly. > > http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev > Looks good. From chris.hegarty at oracle.com Wed May 25 20:01:36 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 25 May 2016 21:01:36 +0100 Subject: RFR: JDK-8157850 Jar tests should pass through VM options In-Reply-To: References: <2da88f6b-b377-ac21-cc34-a0f2a1a566bf@oracle.com> Message-ID: > On 25 May 2016, at 20:21, Martin Buchholz wrote: > > Agreed and Reviewed! +1. This looks fine. Hopefully it can be simplified, somewhat, in the future. -Chris. > > On Wed, May 25, 2016 at 11:57 AM, Andrey Nazarov > wrote: >> Hi Martin, >> >> See my comments inline. >>> On 25 May 2016, at 20:48, Martin Buchholz wrote: >>> >>> Hi Andrey, >>> >>> Looking at http://openjdk.java.net/jtreg/vmoptions.html, >>> I see we have both test.vm.opts and test.tool.vm.opts >>> and the latter is supposed to take care of adding "-J". >>> >>> + VM_OPTIONS.stream().map(opt -> "-J" + opt).forEach(commands::add); >>> + JAVA_OPTIONS.stream().map(opt -> "-J" + opt).forEach(commands::add); >> I considered this option for Basic.java test. But it doesn?t make code clearer.The test requires both test.tool.vm.opts and test.vm.opts for jar tool and java invocation. >> For CLICompatibility.java test.tool.vm.opts is enough since test invokes only jar tool. >>> >>> --- >>> >>> Maybe splitting on "\\s+" would be better. >> In theory yes. I?ll update. >>> >>> --- >>> >>> I think we should have test library methods to return the List >>> for java subprocesses, one that could try hard to get the option >>> tokenization correct. >> Agree. But I think it should be separate patch with changes in tests that use process builder with such option. Better we need some framework which will pass options for us. It?s common problem not passing through VM options. >>> >>> --- >>> >>> >>> On Wed, May 25, 2016 at 9:07 AM, Andrey Nazarov >>> wrote: >>>> Some jar tests start VMs without passing vmoptions from jtreg. >>>> >>>> This fix pass jtreg's vmoptions and javaoptions to processes(java, jar, >>>> javac) started by tests. >>>> >>>> webrev: http://cr.openjdk.java.net/~anazarov/8157850/webrev.01/ >>>> >>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8157850 >>>> >>>> --Andrey >>>> >> From jonathan.gibbons at oracle.com Wed May 25 20:04:36 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 25 May 2016 13:04:36 -0700 Subject: RFR: JDK-8157850 Jar tests should pass through VM options In-Reply-To: References: <2da88f6b-b377-ac21-cc34-a0f2a1a566bf@oracle.com> Message-ID: <57460554.7080306@oracle.com> Using JAVA_OPTIONS for tools is conceptually wrong. JAVA_OPTIONS is specifically intended to pass options to VM instances, as created by a "java" command. It is not intended that you should prefix the options with -J and use them for arbitrary tools. The code in the webrev is also perverse for taking the trouble to split the string to a stream, collect the results into a list, convert the list back into a stream again and use .forEach. You could do better, and much simpler, with something like if (!option.isEmpty()) { commands.addAll(Arrays.asList(option.split("\\s+",-1))); } -- Jon On 05/25/2016 10:48 AM, Martin Buchholz wrote: > Hi Andrey, > > Looking at http://openjdk.java.net/jtreg/vmoptions.html, > I see we have both test.vm.opts and test.tool.vm.opts > and the latter is supposed to take care of adding "-J". > > + VM_OPTIONS.stream().map(opt -> "-J" + opt).forEach(commands::add); > + JAVA_OPTIONS.stream().map(opt -> "-J" + opt).forEach(commands::add); > > --- > > Maybe splitting on "\\s+" would be better. > > --- > > I think we should have test library methods to return the List > for java subprocesses, one that could try hard to get the option > tokenization correct. > > --- > > > On Wed, May 25, 2016 at 9:07 AM, Andrey Nazarov > wrote: >> Some jar tests start VMs without passing vmoptions from jtreg. >> >> This fix pass jtreg's vmoptions and javaoptions to processes(java, jar, >> javac) started by tests. >> >> webrev: http://cr.openjdk.java.net/~anazarov/8157850/webrev.01/ >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8157850 >> >> --Andrey >> From david.holmes at oracle.com Wed May 25 20:33:25 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 May 2016 06:33:25 +1000 Subject: RFR: JDK-8157850 Jar tests should pass through VM options In-Reply-To: <57460554.7080306@oracle.com> References: <2da88f6b-b377-ac21-cc34-a0f2a1a566bf@oracle.com> <57460554.7080306@oracle.com> Message-ID: On 26/05/2016 6:04 AM, Jonathan Gibbons wrote: > Using JAVA_OPTIONS for tools is conceptually wrong. > > JAVA_OPTIONS is specifically intended to pass options to VM instances, > as created by a "java" command. It is not intended that you should > prefix the options with -J and use them for arbitrary tools. I have to agree. There is no guarantee the options being passed for the VM under test make any sense for the running of the jar tool in the jar tests. I think a number of hotspot related test options could cause problems here. Are there specific VM options that people think should be passed through? The bug report has no detail at all. David > The code in the webrev is also perverse for taking the trouble to split > the string to a stream, collect the results into a list, convert the > list back into a stream again and use .forEach. > > You could do better, and much simpler, with something like > > if (!option.isEmpty()) { > commands.addAll(Arrays.asList(option.split("\\s+",-1))); > } > > -- Jon > > > On 05/25/2016 10:48 AM, Martin Buchholz wrote: >> Hi Andrey, >> >> Looking at http://openjdk.java.net/jtreg/vmoptions.html, >> I see we have both test.vm.opts and test.tool.vm.opts >> and the latter is supposed to take care of adding "-J". >> >> + VM_OPTIONS.stream().map(opt -> "-J" + >> opt).forEach(commands::add); >> + JAVA_OPTIONS.stream().map(opt -> "-J" + >> opt).forEach(commands::add); >> >> --- >> >> Maybe splitting on "\\s+" would be better. >> >> --- >> >> I think we should have test library methods to return the List >> for java subprocesses, one that could try hard to get the option >> tokenization correct. >> >> --- >> >> >> On Wed, May 25, 2016 at 9:07 AM, Andrey Nazarov >> wrote: >>> Some jar tests start VMs without passing vmoptions from jtreg. >>> >>> This fix pass jtreg's vmoptions and javaoptions to processes(java, jar, >>> javac) started by tests. >>> >>> webrev: http://cr.openjdk.java.net/~anazarov/8157850/webrev.01/ >>> >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8157850 >>> >>> --Andrey >>> > From jonathan.gibbons at oracle.com Wed May 25 20:42:10 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 25 May 2016 13:42:10 -0700 Subject: RFR: JDK-8157850 Jar tests should pass through VM options In-Reply-To: References: <2da88f6b-b377-ac21-cc34-a0f2a1a566bf@oracle.com> <57460554.7080306@oracle.com> Message-ID: <57460E22.4060307@oracle.com> On 05/25/2016 01:33 PM, David Holmes wrote: > On 26/05/2016 6:04 AM, Jonathan Gibbons wrote: >> Using JAVA_OPTIONS for tools is conceptually wrong. >> >> JAVA_OPTIONS is specifically intended to pass options to VM instances, >> as created by a "java" command. It is not intended that you should >> prefix the options with -J and use them for arbitrary tools. > > I have to agree. There is no guarantee the options being passed for > the VM under test make any sense for the running of the jar tool in > the jar tests. I think a number of hotspot related test options could > cause problems here. > > Are there specific VM options that people think should be passed > through? The bug report has no detail at all. > > David Generally, I think that blindly passing through all the options regardless is as bad a programming practice as never passing them though. There are some that make sense to all VMs, like -ea, -esa etc, and maybe system properties, but for those, the VM options mechanism is generally good enough. (i.e. system properties test.vm.opts, test.tool.vm.opts) From a jtreg point of view, I'd be interested to know uses cases for passing additional more specific options to the VMs used to run tools like jar, jlink, javac, etc -- Jon. > >> The code in the webrev is also perverse for taking the trouble to split >> the string to a stream, collect the results into a list, convert the >> list back into a stream again and use .forEach. >> >> You could do better, and much simpler, with something like >> >> if (!option.isEmpty()) { >> commands.addAll(Arrays.asList(option.split("\\s+",-1))); >> } >> >> -- Jon >> >> >> On 05/25/2016 10:48 AM, Martin Buchholz wrote: >>> Hi Andrey, >>> >>> Looking at http://openjdk.java.net/jtreg/vmoptions.html, >>> I see we have both test.vm.opts and test.tool.vm.opts >>> and the latter is supposed to take care of adding "-J". >>> >>> + VM_OPTIONS.stream().map(opt -> "-J" + >>> opt).forEach(commands::add); >>> + JAVA_OPTIONS.stream().map(opt -> "-J" + >>> opt).forEach(commands::add); >>> >>> --- >>> >>> Maybe splitting on "\\s+" would be better. >>> >>> --- >>> >>> I think we should have test library methods to return the List >>> for java subprocesses, one that could try hard to get the option >>> tokenization correct. >>> >>> --- >>> >>> >>> On Wed, May 25, 2016 at 9:07 AM, Andrey Nazarov >>> wrote: >>>> Some jar tests start VMs without passing vmoptions from jtreg. >>>> >>>> This fix pass jtreg's vmoptions and javaoptions to processes(java, >>>> jar, >>>> javac) started by tests. >>>> >>>> webrev: http://cr.openjdk.java.net/~anazarov/8157850/webrev.01/ >>>> >>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8157850 >>>> >>>> --Andrey >>>> >> From jiangli.zhou at oracle.com Wed May 25 21:07:14 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 25 May 2016 14:07:14 -0700 Subject: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL In-Reply-To: <6EB1DBB1-10E2-495E-8805-8A11F711EC10@oracle.com> References: <2DB03389-7ADF-4752-A507-88F0058E230E@oracle.com> <6F6DE1EB-2CA5-400E-9E4E-A5ACAB6DD4CD@oracle.com> <60117D7C-517A-493C-B5C5-682D3EDE5FAD@oracle.com> <96047593-E526-44BB-A21F-E863A184762B@oracle.com> <6EB1DBB1-10E2-495E-8805-8A11F711EC10@oracle.com> Message-ID: <168F362F-F0A3-4ACA-B97B-9296610291F1@oracle.com> Hi Alan and Mandy, Thanks for confirming that. Thanks, Jiangli > On May 25, 2016, at 12:39 PM, Mandy Chung wrote: > > >> On May 25, 2016, at 12:24 PM, Jiangli Zhou wrote: >> >> Hi Mandy, >> >>> On May 25, 2016, at 12:17 PM, Mandy Chung wrote: >>> >>> >>>> On May 25, 2016, at 11:28 AM, Jiangli Zhou wrote: >>>> >>>> Here is the updated webrev: >>>> >>>> http://cr.openjdk.java.net/~jiangli/8157716/webrev.01/ >>> >>> The version restoring toRealPath looks okay. >> >> Thanks for the review. >> >>> >>> I think the proposed toFileURL method name is fine and perhaps the javadoc of toFileURL method could make it clearer. If we had to rename it, maybe toRealPathFileURL (mouthful but it clearly shows it?s ?real path? as specified in java.nio.file.Path). >> >> I discussed with Alan. We will keep the proposed toFileURL method name for now. > > That?s fine with me. > > Mandy > From stuart.marks at oracle.com Wed May 25 23:11:33 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 25 May 2016 16:11:33 -0700 Subject: RFR(xs): 8059361: Properties.stringPropertyNames() returns a set inconsistent with the assertions from the spec Message-ID: <7abd48ab-aa42-dc2a-f0f0-ad4e09b465f4@oracle.com> Hi all, Please review this small spec change. Properties.stringPropertyNames() seems to imply that the Set it returns is modifiable. It is, but only partially. Since it's a keySet() from a Hashtable, it supports removal but not addition. This change removes the implication that the returned set is fully modifiable. Bug report: https://bugs.openjdk.java.net/browse/JDK-8059361 Diffs below. Thanks, s'marks diff -r 4d9388b1ae27 src/java.base/share/classes/java/util/Properties.java --- a/src/java.base/share/classes/java/util/Properties.java Wed May 25 13:38:35 2016 -0700 +++ b/src/java.base/share/classes/java/util/Properties.java Wed May 25 16:09:22 2016 -0700 @@ -1044,9 +1044,10 @@ * properties list. Properties whose key or value is not * of type {@code String} are omitted. *

    - * The returned set is not backed by the {@code Properties} object. - * Changes to this {@code Properties} are not reflected in the set, - * or vice versa. + * The returned set is not backed by this {@code Properties} object. + * Changes to this {@code Properties} object are not reflected in the + * returned set. Any modifications that might be allowed on the + * returned set are not reflected in this Properties object. * * @return a set of keys in this property list where * the key and its corresponding value are strings, From joe.darcy at oracle.com Wed May 25 23:13:03 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 25 May 2016 16:13:03 -0700 Subject: RFR(xs): 8059361: Properties.stringPropertyNames() returns a set inconsistent with the assertions from the spec In-Reply-To: <7abd48ab-aa42-dc2a-f0f0-ad4e09b465f4@oracle.com> References: <7abd48ab-aa42-dc2a-f0f0-ad4e09b465f4@oracle.com> Message-ID: <5746317F.7020001@oracle.com> Looks fine Stuart; thanks, -Joe On 5/25/2016 4:11 PM, Stuart Marks wrote: > Hi all, > > Please review this small spec change. Properties.stringPropertyNames() > seems to imply that the Set it returns is modifiable. It is, but only > partially. Since it's a keySet() from a Hashtable, it supports removal > but not addition. This change removes the implication that the > returned set is fully modifiable. > > Bug report: > > https://bugs.openjdk.java.net/browse/JDK-8059361 > > Diffs below. > > Thanks, > > s'marks > > > > diff -r 4d9388b1ae27 > src/java.base/share/classes/java/util/Properties.java > --- a/src/java.base/share/classes/java/util/Properties.java Wed May > 25 13:38:35 2016 -0700 > +++ b/src/java.base/share/classes/java/util/Properties.java Wed May > 25 16:09:22 2016 -0700 > @@ -1044,9 +1044,10 @@ > * properties list. Properties whose key or value is not > * of type {@code String} are omitted. > *

    > - * The returned set is not backed by the {@code Properties} object. > - * Changes to this {@code Properties} are not reflected in the set, > - * or vice versa. > + * The returned set is not backed by this {@code Properties} object. > + * Changes to this {@code Properties} object are not reflected in > the > + * returned set. Any modifications that might be allowed on the > + * returned set are not reflected in this Properties object. > * > * @return a set of keys in this property list where > * the key and its corresponding value are strings, From mandy.chung at oracle.com Wed May 25 23:58:37 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 May 2016 16:58:37 -0700 Subject: RFR(xs): 8059361: Properties.stringPropertyNames() returns a set inconsistent with the assertions from the spec In-Reply-To: <7abd48ab-aa42-dc2a-f0f0-ad4e09b465f4@oracle.com> References: <7abd48ab-aa42-dc2a-f0f0-ad4e09b465f4@oracle.com> Message-ID: <42F05421-96E2-49D1-A4F7-547DC395D0EB@oracle.com> Hi Stuart, Have you considered fixing this method to return a unmodifiable set and make this spec in JDK 9? It?s a small change. Mandy > On May 25, 2016, at 4:11 PM, Stuart Marks wrote: > > Hi all, > > Please review this small spec change. Properties.stringPropertyNames() seems to imply that the Set it returns is modifiable. It is, but only partially. Since it's a keySet() from a Hashtable, it supports removal but not addition. This change removes the implication that the returned set is fully modifiable. > > Bug report: > > https://bugs.openjdk.java.net/browse/JDK-8059361 > > Diffs below. > > Thanks, > > s'marks > > > > diff -r 4d9388b1ae27 src/java.base/share/classes/java/util/Properties.java > --- a/src/java.base/share/classes/java/util/Properties.java Wed May 25 13:38:35 2016 -0700 > +++ b/src/java.base/share/classes/java/util/Properties.java Wed May 25 16:09:22 2016 -0700 > @@ -1044,9 +1044,10 @@ > * properties list. Properties whose key or value is not > * of type {@code String} are omitted. > *

    > - * The returned set is not backed by the {@code Properties} object. > - * Changes to this {@code Properties} are not reflected in the set, > - * or vice versa. > + * The returned set is not backed by this {@code Properties} object. > + * Changes to this {@code Properties} object are not reflected in the > + * returned set. Any modifications that might be allowed on the > + * returned set are not reflected in this Properties object. > * > * @return a set of keys in this property list where > * the key and its corresponding value are strings, From stuart.marks at oracle.com Thu May 26 00:11:11 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 25 May 2016 17:11:11 -0700 Subject: RFR(xs): 8059361: Properties.stringPropertyNames() returns a set inconsistent with the assertions from the spec In-Reply-To: <42F05421-96E2-49D1-A4F7-547DC395D0EB@oracle.com> References: <7abd48ab-aa42-dc2a-f0f0-ad4e09b465f4@oracle.com> <42F05421-96E2-49D1-A4F7-547DC395D0EB@oracle.com> Message-ID: <6905b320-1fff-f6c2-1bab-ad1456c89fe1@oracle.com> On 5/25/16 4:58 PM, Mandy Chung wrote: > Have you considered fixing this method to return a unmodifiable set and make this spec in JDK 9? It?s a small change. I did think about changing the behavior here but I decided against it because of the small compatibility risk. The main issue here is that there is a JCK test (new in JCK 9) that attempts to add to the set and fails because it receives UnsupportedOperationException. I want to change the spec so that the test will allow UOE. s'marks From mandy.chung at oracle.com Thu May 26 00:27:53 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 May 2016 17:27:53 -0700 Subject: RFR(xs): 8059361: Properties.stringPropertyNames() returns a set inconsistent with the assertions from the spec In-Reply-To: <6905b320-1fff-f6c2-1bab-ad1456c89fe1@oracle.com> References: <7abd48ab-aa42-dc2a-f0f0-ad4e09b465f4@oracle.com> <42F05421-96E2-49D1-A4F7-547DC395D0EB@oracle.com> <6905b320-1fff-f6c2-1bab-ad1456c89fe1@oracle.com> Message-ID: > On May 25, 2016, at 5:11 PM, Stuart Marks wrote: > > On 5/25/16 4:58 PM, Mandy Chung wrote: >> Have you considered fixing this method to return a unmodifiable set and make this spec in JDK 9? It?s a small change. > > I did think about changing the behavior here but I decided against it because of the small compatibility risk. I would suggest to make this small incompatible spec change in JDK 9 since it?s a major release. This method was intended to filter out non-String keys in this Properties for iteration and it?s an oversight not to return an unmodifiable set. Mandy > The main issue here is that there is a JCK test (new in JCK 9) that attempts to add to the set and fails because it receives UnsupportedOperationException. I want to change the spec so that the test will allow UOE. > > s'marks From amy.lu at oracle.com Thu May 26 05:10:19 2016 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 26 May 2016 13:10:19 +0800 Subject: JDK 9 RFR of JDK-8157663: Remove tools/jimage/JImageTest.java from ProblemList.txt Message-ID: <5746853B.8010203@oracle.com> tools/jimage/JImageTest.java This test is in ProblemList.txt with related bugid JDK-8150975. JDK-8150975 has been closed since previously reported image recreate issue now is not an issue anymore because the support for jimage recreate has been removed in JDK-8154090, in which test also updated. This patch is to remove mentioned test from ProblemList.txt. bug: https://bugs.openjdk.java.net/browse/JDK-8157663 webrev: http://cr.openjdk.java.net/~amlu/8157663/webrev.00/ Thanks, Amy --- old/test/ProblemList.txt 2016-05-26 12:45:36.000000000 +0800 +++ new/test/ProblemList.txt 2016-05-26 12:45:36.000000000 +0800 @@ -390,7 +390,5 @@ # core_tools -tools/jimage/JImageTest.java 8150975 linux-i586,windows-i586 - ############################################################################ From joe.darcy at oracle.com Thu May 26 05:13:36 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 25 May 2016 22:13:36 -0700 Subject: JDK 9 RFR of JDK-8157663: Remove tools/jimage/JImageTest.java from ProblemList.txt In-Reply-To: <5746853B.8010203@oracle.com> References: <5746853B.8010203@oracle.com> Message-ID: <721a07e5-e236-2d30-eed0-71b2b46d0d6b@oracle.com> Looks fine Amy; thanks, -Joe On 5/25/2016 10:10 PM, Amy Lu wrote: > tools/jimage/JImageTest.java > > This test is in ProblemList.txt with related bugid JDK-8150975. > JDK-8150975 has been closed since previously reported image recreate > issue now is not an issue anymore because the support for jimage > recreate has been removed in JDK-8154090, in which test also updated. > > This patch is to remove mentioned test from ProblemList.txt. > > bug: https://bugs.openjdk.java.net/browse/JDK-8157663 > webrev: http://cr.openjdk.java.net/~amlu/8157663/webrev.00/ > > > Thanks, > Amy > > --- old/test/ProblemList.txt 2016-05-26 12:45:36.000000000 +0800 > +++ new/test/ProblemList.txt 2016-05-26 12:45:36.000000000 +0800 > @@ -390,7 +390,5 @@ > > # core_tools > > -tools/jimage/JImageTest.java 8150975 linux-i586,windows-i586 > - > ############################################################################ > > > > From nadeesh.tv at oracle.com Thu May 26 07:49:27 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Thu, 26 May 2016 13:19:27 +0530 Subject: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour Message-ID: <5746AA87.3040501@oracle.com> Hi all, Please review BugId : https://bugs.openjdk.java.net/browse/JDK-8066806 Issue: java.time.format.DateTimeFormatter cannot parse an offset with single digit hour webrev: http://cr.openjdk.java.net/~ntv/8066806/webrev.03/ Solution: Added the suggested patterns but the parsing logic became too complex. Appreciate any suggestion to make the parsing less complicated -- Thanks and Regards, Nadeesh TV From sean.coffey at oracle.com Thu May 26 09:52:42 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 26 May 2016 10:52:42 +0100 Subject: (@modules documentation)Re: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> <5745E5C2.4090705@oracle.com> <5745EF98.9040002@oracle.com> Message-ID: <97af1957-c3ec-8f92-9698-4d8bb9a471cd@oracle.com> Was our OpenJDK documentation ever updated to highlight the @modules change for JDK 9 ? Could we edit the developer's guide[1] to highlight the @modules tag [2]. The current doc states that an @bug tag should be supplied. It would help to document why/when an @modules tag would be required also. [1] http://openjdk.java.net/guide/changePlanning.html [2] http://openjdk.java.net/jtreg/tag-spec.html Regards, Sean. On 25/05/2016 19:46, Alexandre (Shura) Iline wrote: >> On May 25, 2016, at 11:31 AM, Xueming Shen wrote: >> >> On 5/25/16, 11:06 AM, Alexandre (Shura) Iline wrote: >>> Sherman, >>> >>> Not declaring any module dependencies in test is equivalent to declaring that the test only depends on java.base. In such case, the test will be picked up for execution by JTReg, no matter what modules are available. One way to test such behavior would be to supply -javaoptions:?-limitmods java.base? in the JTReg command line. The tests will be selected for execution, but would they work? >>> >>> I have taken another look on the code now, it looks like with the absence of jdk.zipfs test/jdk/nio/zipfs/Basic.java test will fail. I think it would be good to skip this test altogether if there is no jdk.zipfs available. >> Hi Shura, >> >> Yes, the test will fail if the jdk.zipfs is absence. With the assumption that zipfs module should >> be available to the jdk images/runtime by default. If it's not there/available, something is wrong > Well, not necessarily. > > Since JTReg is taking on the burden to select tests for execution based on the available modules, be it -limitmods option or a custom built limited JDK image, the test suite will be used to execute tests for compact profiles, for example. We will be relying on JTReg to select proper tests. The plan is to get rid of the test groups for compact profiles when the test markup is complete. > > Shura > >> and we would want to know why. So the intention here is not to skip the zipfs test silently, if >> the zipfs is missing from the jdk image. That said, arguably these existing tests are the unit tests >> for the zipfs functionality, it might be desired to have separate test(s) for testing the availability >> of the zipfs... >> >> sherman >> >>> Shura >>> >>>> On May 25, 2016, at 10:49 AM, Xueming Shen wrote: >>>> >>>> >>>> Should it? My understanding is that those tests don't use zipfs directly >>>> from zipfs module, it access it via java.base's FileSystemProvider interface. >>>> It depends on the jdk runtime to pick up the zipfs "provider" to function. So >>>> if the jdk runtime fails to pick up the zipfs module for whatever reason, >>>> that's something we want to detect as well? >>>> >>>> -Sherman >>>> >>>> On 05/25/2016 10:18 AM, Alexandre (Shura) Iline wrote: >>>>> Hi. >>>>> >>>>> Should the tests also declare ?@modules jdk.zipfs?? >>>>> >>>>> Shura >>>>> >>>>>> On May 25, 2016, at 9:39 AM, Xueming Shen wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Please help review the changes for the following zipfs related bug fixes >>>>>> >>>>>> JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() >>>>>> JDK-8153248: (zipfs) ZipPath#getFileName( ) returns inconsistent result >>>>>> JDK-8146754: (zipfs) ZipPath.relativize() returns wrong result for path ending with slash / >>>>>> JDK-8139956: (zipfs) ZipPath does not produce correct empty path on relativize() >>>>>> >>>>>> issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8147539 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8153248 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8146754 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8139956 >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev/ >>>>>> >>>>>> The changes are relative easy. >>>>>> (1) ZipPath.initOffsets() should deal with empty path specially, as the UnixPath impl does >>>>>> (2) ZipPath.normalize(byte[]) should take care of tailing "/" (it is taken care of at >>>>>> ZipPath.normalize(byte[], int), but is missed in the "main" method) >>>>>> (3) ZipPath.register() should throw PME as suggested. >>>>>> >>>>>> Thanks, >>>>>> Sherman From paul.sandoz at oracle.com Thu May 26 10:04:58 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 26 May 2016 12:04:58 +0200 Subject: Files.walk() is unusable because of AccessDeniedException In-Reply-To: References: <57440E85.2040809@redhat.com> Message-ID: <0EB8ED56-DE83-480B-AE3D-BDF6741BEF0B@oracle.com> Hi, Jumping in a bit late to this thread? To achieve this with parity to the non-Stream walk method we would need to implement a FileTreeSpliterator that accepts a FileVistor for the purposes of specialised filtering. You can do this with an Iterator-based implementation from which a Spliterator can be created from, but you could just as easily inherit from AbstractSpliterator. Then we could surface a new method accepting a FileVistor. You could implement your own Spliterator along such lines then create a Stream from it. If you go that route and wanna contribute back to OpenJDK I would be happy to help in the acceptance and processing of such a contribution. Paul. > On 25 May 2016, at 09:39, Gilles Habran wrote: > > Hi Henry, > > I knew there was a work around as I created something similar than yours > when I needed it. :) > > Apparently, we have two different opinions regarding Files.walk() and how > this method is supposed to handle permissions. I just sent this email > because I felt that Files.walk() didn't behave like it should, maybe I am > wrong. > > I read everything from my root directory so it makes sense that that I > don't have the permissions to read everything (I'll get the same thing when > I read /proc for sure) but what happens the day I walk the home directory > of the user as the user. I am supposed to have access to everything in > there, right ? My application will just crash if there is a dirty file in > there with bad permissions and there is nothing I can do about it... not > with Files.walk(). > > To be sure that I don't have a problem, I will need to create my own method > like yours because I would take a great risk using Files.walk() if I get an > exception that stops my process in case there is an unexpected file with > bad permissions. > > Have a nice day. > > Best regards, > > Gilles > > On 25 May 2016 at 08:23, Henry Jen wrote: > >> I think there is a work-around, use list() and flatMap() should get you >> what you needed. >> >> The API is designed to walk a tree where you suppose to have access with. >> If OS level cause an IOException, that need to be dealt with. Acknowledged >> that exception handling is not a strong suite in Stream API, developer will >> need to do some work. >> >> Files.find() also allows you to get entries and filter out by permission. >> What you can do is make sure you have permission on the top level, then >> call find with maxDepth 1 to only get entries on that directory. >> >> Combined with flatMap(), you should be able to get what you want. Try the >> following code to see if it works for you. >> >> import java.nio.file.Files; >> import java.nio.file.Path; >> import java.nio.file.Paths; >> import java.util.stream.Stream; >> import java.io.IOException; >> >> public class ListCanRead { >> static Stream walkReadable(Path p) { >> if (Files.isReadable(p)) { >> if (Files.isDirectory(p)) { >> try { >> return Stream.concat(Stream.of(p), Files.list(p)); >> } catch (IOException ioe) { >> return Stream.of(p); >> } >> } else { >> return Stream.of(p); >> } >> } >> return Stream.of(p); >> } >> >> public static void main(String[] args) throws IOException { >> System.out.println("List directory: " + args[0]); >> walkReadable(Paths.get(args[0])).flatMap(ListCanRead::walkReadable) >> .forEach(System.out::println); >> >> Files.walk(Paths.get(args[0])) >> .forEach(System.out::println); // Could throw >> AccessDeniedException >> } >> } >> >> Cheers, >> Henry >> >> On May 24, 2016 at 4:48:30 PM, Gilles Habran (gilleshabran at gmail.com) >> wrote: >>> Good morning, >>> >>> well I would like to be able to manage the outcome of the processing >> myself >>> and not get an exception in a part where I have no control. >>> >>> For example, I would expect to get an exception when I tried to read a >> file >>> where I don't have the permission. I would not expect to get an exception >>> when Java creates the Stream. >>> >>> Maybe I am the only one to have a problem with this ? I don't know but it >>> feels strange to be forced to execute a software with root permissions >>> where I don't even plan to read file I cannot read because of lack of >>> permissions. >>> >>> For me, we should be able to test the attributes of a file and depending >> on >>> the result, read the file or not. If we read the file without permission, >>> we get an exception, if not, we can go to the next file without error. >>> >>> If that's unclear, please let me know, I'll try to give more informations >>> or examples. >>> >>> Thank you. >>> >>> On 24 May 2016 at 10:19, Andrew Haley wrote: >>> >>>> On 05/20/2016 10:38 AM, Gilles Habran wrote: >>>>> why is my message still waiting for approval after a month ? >>>> >>>> What is it you want Java to do? You can't walk the directory >>>> because you don't have permission. sudo should work. >>>> >>>> Andrew. >>>> >>>> >>> >> >> From Alan.Bateman at oracle.com Thu May 26 10:16:43 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 26 May 2016 11:16:43 +0100 Subject: (@modules documentation) In-Reply-To: <97af1957-c3ec-8f92-9698-4d8bb9a471cd@oracle.com> References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> <5745E5C2.4090705@oracle.com> <5745EF98.9040002@oracle.com> <97af1957-c3ec-8f92-9698-4d8bb9a471cd@oracle.com> Message-ID: <5746CD0B.6040901@oracle.com> On 26/05/2016 10:52, Se?n Coffey wrote: > Was our OpenJDK documentation ever updated to highlight the @modules > change for JDK 9 ? Could we edit the developer's guide[1] to highlight > the @modules tag [2]. The current doc states that an @bug tag should > be supplied. It would help to document why/when an @modules tag would > be required also. > > [1] http://openjdk.java.net/guide/changePlanning.html > [2] http://openjdk.java.net/jtreg/tag-spec.html The tag-spec was updated but I don't think the implications for test selection have been documented elsewhere. The main thing is that we want to get to the point where you can create a runtime image with jlink and then invoke jtreg to execute the tests that are appropriate for that runtime. The jtreg command may of course need a -compilejdk as the runtime under test may not have the jdk.compiler module. If we get there then it means that the unmaintainable test groups in TEST.groups can be removed. -Alan From ramanand.patil at oracle.com Thu May 26 13:22:54 2016 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Thu, 26 May 2016 06:22:54 -0700 (PDT) Subject: RFR: 8151876: (tz) Support tzdata2016d Message-ID: <9b76a353-e477-4f59-b630-5185e9ce6c37@default> HI all, Please review the latest TZDATA integration (tzdata2016d) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8151876 Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/ Patch Contains: 1. IANA tzdata2016d integration into JDK. [It also includes tzdata2016b and tzdata2016c which was not integrated]. 2. "GMT[+ -]hh:mm" is used for formatting of the modified or newly added TimeZones in tzdata2016d. [This is done to accommodate the IANA's new system where the zones use numeric time zone abbreviations like "+04" instead of invented abbreviations like "ASTT".] 3. Test case: java/time/test/java/time/format/TestZoneTextPrinterParser.java is updated to include the failures because of GMT[+ -]hh:mm format names. 4. Few other failing tests: For few other failing tests, new linked bugs are created and will be addressed in a separate patch. Regards, Ramanand. From xueming.shen at oracle.com Thu May 26 15:27:28 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 26 May 2016 08:27:28 -0700 Subject: [9] RFR: Static build of libzip is missing JNI_OnLoad_zip entry point In-Reply-To: <4d46320e-739d-78cf-9110-a29815b06021@oracle.com> References: <4d46320e-739d-78cf-9110-a29815b06021@oracle.com> Message-ID: <8a72629c-4c07-75e3-da39-ac4acbd42692@oracle.com> +1 On 5/24/16 4:47 PM, Naoto Sato wrote: > Hello, > > The previous attempt to fix this one failed in the installer build, as > it does not recognize the added macro. I've updated the fix to add > extra check for static build (yeah, this is redundant with the real > jni_util.h, but effectively avoid the installer build failure). > > http://cr.openjdk.java.net/~naoto/8150179/webrev.01/ > > Please review. > > Naoto From andrey.x.nazarov at oracle.com Thu May 26 16:20:42 2016 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Thu, 26 May 2016 19:20:42 +0300 Subject: RFR: JDK-8157850 Jar tests should pass through VM options In-Reply-To: <57460E22.4060307@oracle.com> References: <2da88f6b-b377-ac21-cc34-a0f2a1a566bf@oracle.com> <57460554.7080306@oracle.com> <57460E22.4060307@oracle.com> Message-ID: <758a2c4c-df6d-04dd-e581-4d267abc1c5d@oracle.com> Thanks for feedback guys. I've updated review http://cr.openjdk.java.net/~anazarov/8157850/webrev.02/ Please sponsor this patch if you are OK. My use case is to run tests with different -Xms and -Xmx options. Mostly due to I need to increase heap size to gather code coverage by jcov. --Andrey On 25.05.2016 23:42, Jonathan Gibbons wrote: > > > On 05/25/2016 01:33 PM, David Holmes wrote: >> On 26/05/2016 6:04 AM, Jonathan Gibbons wrote: >>> Using JAVA_OPTIONS for tools is conceptually wrong. >>> >>> JAVA_OPTIONS is specifically intended to pass options to VM instances, >>> as created by a "java" command. It is not intended that you should >>> prefix the options with -J and use them for arbitrary tools. >> >> I have to agree. There is no guarantee the options being passed for >> the VM under test make any sense for the running of the jar tool in >> the jar tests. I think a number of hotspot related test options could >> cause problems here. >> >> Are there specific VM options that people think should be passed >> through? The bug report has no detail at all. >> >> David > > Generally, I think that blindly passing through all the options > regardless is as bad a programming practice as never passing them > though. There are some that make sense to all VMs, like -ea, -esa > etc, and maybe system properties, but for those, the VM options > mechanism is generally good enough. (i.e. system properties > test.vm.opts, test.tool.vm.opts) > > From a jtreg point of view, I'd be interested to know uses cases for > passing additional more specific options to the VMs used to run tools > like jar, jlink, javac, etc > > -- Jon. > > > >> >>> The code in the webrev is also perverse for taking the trouble to split >>> the string to a stream, collect the results into a list, convert the >>> list back into a stream again and use .forEach. >>> >>> You could do better, and much simpler, with something like >>> >>> if (!option.isEmpty()) { >>> commands.addAll(Arrays.asList(option.split("\\s+",-1))); >>> } >>> >>> -- Jon >>> >>> >>> On 05/25/2016 10:48 AM, Martin Buchholz wrote: >>>> Hi Andrey, >>>> >>>> Looking at http://openjdk.java.net/jtreg/vmoptions.html, >>>> I see we have both test.vm.opts and test.tool.vm.opts >>>> and the latter is supposed to take care of adding "-J". >>>> >>>> + VM_OPTIONS.stream().map(opt -> "-J" + >>>> opt).forEach(commands::add); >>>> + JAVA_OPTIONS.stream().map(opt -> "-J" + >>>> opt).forEach(commands::add); >>>> >>>> --- >>>> >>>> Maybe splitting on "\\s+" would be better. >>>> >>>> --- >>>> >>>> I think we should have test library methods to return the List >>>> for java subprocesses, one that could try hard to get the option >>>> tokenization correct. >>>> >>>> --- >>>> >>>> >>>> On Wed, May 25, 2016 at 9:07 AM, Andrey Nazarov >>>> wrote: >>>>> Some jar tests start VMs without passing vmoptions from jtreg. >>>>> >>>>> This fix pass jtreg's vmoptions and javaoptions to processes(java, >>>>> jar, >>>>> javac) started by tests. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~anazarov/8157850/webrev.01/ >>>>> >>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8157850 >>>>> >>>>> --Andrey >>>>> >>> > From timo.kinnunen at gmail.com Thu May 26 17:55:06 2016 From: timo.kinnunen at gmail.com (timo.kinnunen at gmail.com) Date: Thu, 26 May 2016 19:55:06 +0200 Subject: Fwd: Files.walk() is unusable because of AccessDeniedException In-Reply-To: References: <57440E85.2040809@redhat.com> Message-ID: <5747387a.4275c20a.5f924.3467@mx.google.com> Let?s not forget that in the use case where there is an installed security manager, the API clearly states how those access checks are supported. The results of access checks are communicated by the security manager using unchecked exceptions. As a result the Files::walk implementation has to carefully catch just the right unchecked exceptions in the right places so that a failed access check doesn?t escape and terminate the walk with an exception. That it does so is no accident or a random coincidence. But that gives me an idea. If the Files::walk implementation categorically refuses to support any other access checks than security manager?s, then a workaround for this could come as a custom security manager. The security manager would deny any attempts to access a file that isn?t accessible and grant the rest. This prototype implementation seems to work in some quick tests: package utils.security; import java.io.IOException; import java.nio.charset.StandardCharsets; import java.nio.file.AccessMode; import java.nio.file.FileSystems; import java.nio.file.Files; import java.nio.file.Path; import java.nio.file.Paths; public class DenyAccessWhereNoAccessGrantedSecurityManager extends SecurityManager { public static void install() { try { Path path = Files.createTempFile("all", ".policy"); Files.write(path, "grant {\n permission java.security.AllPermission;\n};".getBytes(StandardCharsets.UTF_8)); path.toFile().deleteOnExit(); System.setProperty("java.security.policy", path.toString()); System.setSecurityManager(new DenyAccessWhereNoAccessGrantedSecurityManager()); } catch(IOException e) { throw new AssertionError("Cannot install security manager, aborting", e); } } private final ThreadLocal readChecker = new Checker(AccessMode.READ); private final ThreadLocal writeChecker = new Checker(AccessMode.WRITE); private class Checker extends ThreadLocal { private final AccessMode mode; private boolean used; public Checker(AccessMode mode) { this.mode = mode; } protected @Override Checker initialValue() { return new Checker(mode); } public boolean check(String file) { if(!used && (used = true)) { try { FileSystems.getDefault().provider().checkAccess(Paths.get(file), mode); } catch(IOException e) { throw new SecurityException(e); } finally { ((used = false) || mode == AccessMode.READ ? readChecker : writeChecker).remove(); } } return !used; } } public @Override void checkRead(String file) { if(readChecker.get().check(file)) super.checkRead(file); } public @Override void checkRead(String file, Object context) { if(readChecker.get().check(file)) super.checkRead(file, context); } public @Override void checkWrite(String file) { if(writeChecker.get().check(file)) super.checkWrite(file); } } All that code boils down to a function doing binary classification with the response vocabulary consisting of either 1. throwing an exception, or 2. doing nothing. With the workaround in place this stream lists my files and public folders successfully, skipping the rest. Without, it attempts to walk into some other user?s home folder and falls over when that doesn?t work: package utils.security.test; import java.io.IOException; import java.nio.file.Files; import java.nio.file.Path; import java.nio.file.Paths; import utils.security.DenyAccessWhereNoAccessGrantedSecurityManager; public class FileAccessMain { public static void main(String[] args) throws IOException { DenyAccessWhereNoAccessGrantedSecurityManager.install(); Path path = Paths.get(System.getProperty("user.home")).getParent().toAbsolutePath(); Files.walk(path, 2).sorted().forEach(System.out::println); } } As the security manager is totally dumb itself, it must be that this big change in behavior is all coming from the logic contained in the Files::walk implementation. A binary classifier like the one above should be easy enough to add to the code in Files::walk. This would then make it unnecessary to have a custom security manager. Which I probably implemented incorrectly anyways. -- Have a nice day, Timo Sent from Mail for Windows 10 From: Henry Jen Sent: Wednesday, May 25, 2016 08:24 To: Andrew Haley; Gilles Habran Cc: core-libs-dev at openjdk.java.net Subject: Re: Fwd: Files.walk() is unusable because of AccessDeniedException I think there is a work-around, use list() and flatMap() should get you what you needed. The API is designed to walk a tree where you suppose to have access with. If OS level cause an IOException, that need to be dealt with. Acknowledged that exception handling is not a strong suite in Stream API, developer will need to do some work. Files.find() also allows you to get entries and filter out by permission. What you can do is make sure you have permission on the top level, then call find with maxDepth 1 to only get entries on that directory. Combined with flatMap(), you should be able to get what you want. Try the following code to see if it works for you. import java.nio.file.Files; import java.nio.file.Path; import java.nio.file.Paths; import java.util.stream.Stream; import java.io.IOException; public class ListCanRead { ? ? static Stream walkReadable(Path p) { ? ? ? ? if (Files.isReadable(p)) { ? ? ? ? ? ? if (Files.isDirectory(p)) { ? ? ? ? ? ? ? ? try { ? ? ? ? ? ? ? ? ? ? return Stream.concat(Stream.of(p), Files.list(p)); ? ? ? ? ? ? ? ? } catch (IOException ioe) { ? ? ? ? ? ? ? ? ? ? return Stream.of(p); ? ? ? ? ? ? ? ? } ? ? ? ? ? ? } else { ? ? ? ? ? ? ? ? return Stream.of(p); ? ? ? ? ? ? } ? ? ? ? } ? ? ? ? return Stream.of(p); ? ? } ? ? public static void main(String[] args) throws IOException { ? ? ? ? System.out.println("List directory: " + args[0]); ? ? ? ? walkReadable(Paths.get(args[0])).flatMap(ListCanRead::walkReadable) ? ? ? ? ? ? .forEach(System.out::println); ? ? ? ? Files.walk(Paths.get(args[0])) ? ? ? ? ? ? .forEach(System.out::println); // Could throw AccessDeniedException ? ? } } Cheers, Henry On May 24, 2016 at 4:48:30 PM, Gilles Habran (gilleshabran at gmail.com) wrote: > Good morning, > > well I would like to be able to manage the outcome of the processing myself > and not get an exception in a part where I have no control. > > For example, I would expect to get an exception when I tried to read a file > where I don't have the permission. I would not expect to get an exception > when Java creates the Stream. > > Maybe I am the only one to have a problem with this ? I don't know but it > feels strange to be forced to execute a software with root permissions > where I don't even plan to read file I cannot read because of lack of > permissions. > > For me, we should be able to test the attributes of a file and depending on > the result, read the file or not. If we read the file without permission, > we get an exception, if not, we can go to the next file without error. > > If that's unclear, please let me know, I'll try to give more informations > or examples. > > Thank you. > > On 24 May 2016 at 10:19, Andrew Haley wrote: > > > On 05/20/2016 10:38 AM, Gilles Habran wrote: > > > why is my message still waiting for approval after a month ? > > > > What is it you want Java to do? You can't walk the directory > > because you don't have permission. sudo should work. > > > > Andrew. > > > > > From joe.darcy at oracle.com Thu May 26 19:02:20 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 26 May 2016 12:02:20 -0700 Subject: JDK 9 RFR of JDK-6961865: javadoc for Boolean.valueOf(String) with null argument not clearly specified Message-ID: Hello, Please review these spec clarifications for java.lang.Boolean: JDK-6961865: javadoc for Boolean.valueOf(String) with null argument not clearly specified http://cr.openjdk.java.net/~darcy/6961865.0/ Thanks, -Joe From aleksey.shipilev at oracle.com Thu May 26 19:15:50 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 26 May 2016 22:15:50 +0300 Subject: JDK 9 RFR of JDK-6961865: javadoc for Boolean.valueOf(String) with null argument not clearly specified In-Reply-To: References: Message-ID: <57474B66.2040000@oracle.com> On 05/26/2016 10:02 PM, joe darcy wrote: > JDK-6961865: javadoc for Boolean.valueOf(String) with null argument > not clearly specified > > http://cr.openjdk.java.net/~darcy/6961865.0/ +1 Thanks, -Aleksey From mandy.chung at oracle.com Thu May 26 19:40:24 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 26 May 2016 12:40:24 -0700 Subject: Review Request: JDK-8157986: Runtime support for javac to determine arguments to the runtime environment Message-ID: <723D8D12-23B7-4379-B1DD-FF9082517B81@oracle.com> This patch allows jdk.compiler to get the runtime arguments without pulling in java.management (that requires java.rmi). We should look into use cases further in the future and determine whether a public API should be provided. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157986/webrev.00/index.html Mandy From stuart.marks at oracle.com Thu May 26 20:57:23 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 26 May 2016 13:57:23 -0700 Subject: RFR(xs): 8059361: Properties.stringPropertyNames() returns a set inconsistent with the assertions from the spec In-Reply-To: References: <7abd48ab-aa42-dc2a-f0f0-ad4e09b465f4@oracle.com> <42F05421-96E2-49D1-A4F7-547DC395D0EB@oracle.com> <6905b320-1fff-f6c2-1bab-ad1456c89fe1@oracle.com> Message-ID: On 5/25/16 5:27 PM, Mandy Chung wrote: >> On May 25, 2016, at 5:11 PM, Stuart Marks wrote: >> On 5/25/16 4:58 PM, Mandy Chung wrote: >>> Have you considered fixing this method to return a unmodifiable set and make this spec in JDK 9? It?s a small change. >> >> I did think about changing the behavior here but I decided against it because of the small compatibility risk. > > I would suggest to make this small incompatible spec change in JDK 9 since it?s a major release. This method was intended to filter out non-String keys in this Properties for iteration and it?s an oversight not to return an unmodifiable set. OK. I did a survey at grepcode.com and there are a lot of uses of stringPropertynames(). The vast majority are either iterating over the returned set or copying the values into a new or existing set. These wouldn't be affected by making the returned set unmodifiable. There are a handful of uses that simply return the set to the caller. From those it's really hard to tell how the set is used. However, the existing implementation permits removal only; it already prohibits addition. Making the returned set unmodifiable would break clients that only remove elements from the returned set. I can imagine use cases that would do this, but it seems like they'd be quite rare. In any case, the revised diff is appended below. I considered modifying enumerateStringProperties() to use a Set instead of a Map, but it doesn't really help, since a HashSet contains a HashMap anyway. s'marks diff -r 4d9388b1ae27 src/java.base/share/classes/java/util/Properties.java --- a/src/java.base/share/classes/java/util/Properties.java Wed May 25 13:38:35 2016 -0700 +++ b/src/java.base/share/classes/java/util/Properties.java Thu May 26 13:55:35 2016 -0700 @@ -1037,18 +1037,18 @@ } /** - * Returns a set of keys in this property list where - * the key and its corresponding value are strings, + * Returns an unmodifiable set of keys from this property list + * where the key and its corresponding value are strings, * including distinct keys in the default property list if a key * of the same name has not already been found from the main * properties list. Properties whose key or value is not * of type {@code String} are omitted. *

    - * The returned set is not backed by the {@code Properties} object. - * Changes to this {@code Properties} are not reflected in the set, - * or vice versa. + * The returned set is not backed by this {@code Properties} object. + * Changes to this {@code Properties} object are not reflected in the + * returned set. * - * @return a set of keys in this property list where + * @return an unmodifiable set of keys in this property list where * the key and its corresponding value are strings, * including the keys in the default property list. * @see java.util.Properties#defaults @@ -1057,7 +1057,7 @@ public Set stringPropertyNames() { Map h = new HashMap<>(); enumerateStringProperties(h); - return h.keySet(); + return Set.of(h.keySet().toArray(new String[0])); } /** From mandy.chung at oracle.com Thu May 26 21:28:41 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 26 May 2016 14:28:41 -0700 Subject: RFR(xs): 8059361: Properties.stringPropertyNames() returns a set inconsistent with the assertions from the spec In-Reply-To: References: <7abd48ab-aa42-dc2a-f0f0-ad4e09b465f4@oracle.com> <42F05421-96E2-49D1-A4F7-547DC395D0EB@oracle.com> <6905b320-1fff-f6c2-1bab-ad1456c89fe1@oracle.com> Message-ID: <3D856112-EB48-4C8A-9220-EA4265C163C0@oracle.com> > On May 26, 2016, at 1:57 PM, Stuart Marks wrote: > : > > However, the existing implementation permits removal only; it already prohibits addition. Making the returned set unmodifiable would break clients that only remove elements from the returned set. I can imagine use cases that would do this, but it seems like they'd be quite rare. > Thanks for looking at existing usages and fixing this issue. Yup since the existing impl throws UOE at addition, I agree that the compatibility risk of changing the returned set to unmodifiable is not high. > > - return h.keySet(); > + return Set.of(h.keySet().toArray(new String[0])); > } The patch looks fine. It?d be good to add a test case. If you use Collections.unmodifiableSet, you would not need to convert the key sets to an array. Any benefit of using Set::of instead of Collections.unmodifiableSet? Mandy From alexandre.iline at oracle.com Thu May 26 21:30:59 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Thu, 26 May 2016 14:30:59 -0700 Subject: RFR 8157996: Unneeded import in lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java Message-ID: <581899F8-DF22-4C89-B375-D96ED8EA1D39@oracle.com> Hi. Please take a look on an obvious fix: http://cr.openjdk.java.net/~shurailine/8157996/webrev.00/ There was an unneeded import statement which was getting in the way when running tests with limited module availability. Also in a couple of places I have added try with resources. Shura From mandy.chung at oracle.com Thu May 26 22:16:43 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 26 May 2016 15:16:43 -0700 Subject: RFR 8157996: Unneeded import in lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java In-Reply-To: <581899F8-DF22-4C89-B375-D96ED8EA1D39@oracle.com> References: <581899F8-DF22-4C89-B375-D96ED8EA1D39@oracle.com> Message-ID: <92A19553-F317-4B73-B873-A8AA5BD1054D@oracle.com> > On May 26, 2016, at 2:30 PM, Alexandre (Shura) Iline wrote: > > Hi. > > Please take a look on an obvious fix: > http://cr.openjdk.java.net/~shurailine/8157996/webrev.00/ > > There was an unneeded import statement which was getting in the way when running tests with limited module availability. > > Also in a couple of places I have added try with resources. Looks okay. Can you take out the extra space between ?init? and ?(? while you are on this file? 65 init (fis); I can sponsor for you. Mandy From alexandre.iline at oracle.com Thu May 26 22:29:24 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Thu, 26 May 2016 15:29:24 -0700 Subject: RFR 8157996: Unneeded import in lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java In-Reply-To: <92A19553-F317-4B73-B873-A8AA5BD1054D@oracle.com> References: <581899F8-DF22-4C89-B375-D96ED8EA1D39@oracle.com> <92A19553-F317-4B73-B873-A8AA5BD1054D@oracle.com> Message-ID: <8FCE42EF-ABDE-4CF8-B1A9-65033F454CFA@oracle.com> > On May 26, 2016, at 3:16 PM, Mandy Chung wrote: > > >> On May 26, 2016, at 2:30 PM, Alexandre (Shura) Iline wrote: >> >> Hi. >> >> Please take a look on an obvious fix: >> http://cr.openjdk.java.net/~shurailine/8157996/webrev.00/ >> >> There was an unneeded import statement which was getting in the way when running tests with limited module availability. >> >> Also in a couple of places I have added try with resources. > > Looks okay. Can you take out the extra space between ?init? and ?(? while you are on this file? > 65 init (fis); Then I am taking out all extra spaces in this code. Per the examples in http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html. :) I was thinking whether to do it to not. Shura. > > I can sponsor for you. > Mandy From stuart.marks at oracle.com Thu May 26 22:49:08 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 26 May 2016 15:49:08 -0700 Subject: RFR(xs): 8059361: Properties.stringPropertyNames() returns a set inconsistent with the assertions from the spec In-Reply-To: <3D856112-EB48-4C8A-9220-EA4265C163C0@oracle.com> References: <7abd48ab-aa42-dc2a-f0f0-ad4e09b465f4@oracle.com> <42F05421-96E2-49D1-A4F7-547DC395D0EB@oracle.com> <6905b320-1fff-f6c2-1bab-ad1456c89fe1@oracle.com> <3D856112-EB48-4C8A-9220-EA4265C163C0@oracle.com> Message-ID: <42636339-3850-ba12-af7c-1fa6b13b6e9e@oracle.com> On 5/26/16 2:28 PM, Mandy Chung wrote: >> - return h.keySet(); >> + return Set.of(h.keySet().toArray(new String[0])); >> } > > The patch looks fine. It?d be good to add a test case. > > If you use Collections.unmodifiableSet, you would not need to convert the key sets to an array. Any benefit of using Set::of instead of Collections.unmodifiableSet? There are several minor tradeoffs. Collections.unmodifiableSet() simply creates and returns a wrapper object. It contains the keySet, which is backed by the HashMap created within the stringPropertyNames() method. This keeps references to all the string keys and values around, even though the values aren't used. But the strings themselves are also referenced from the original Properties object and its default chain. The toArray() call copies the key string refs to an array, then Set.of() hashes them into its internal array. But the resulting data structure holds only references to the keys, so it's more compact. Given that most uses seem to iterate the set's elements and then throw it away, it's probably not worth the creation overhead of for an immutable Set. Drat. I guess I was too eager to use the new API. :-) I've changed this to use Collections.unmodifiableSet(); see below. I'll also add test cases to the (internal) test suite for this class. s'marks diff -r 4d9388b1ae27 src/java.base/share/classes/java/util/Properties.java --- a/src/java.base/share/classes/java/util/Properties.java Wed May 25 13:38:35 2016 -0700 +++ b/src/java.base/share/classes/java/util/Properties.java Thu May 26 15:48:20 2016 -0700 @@ -1037,18 +1037,18 @@ } /** - * Returns a set of keys in this property list where - * the key and its corresponding value are strings, + * Returns an unmodifiable set of keys from this property list + * where the key and its corresponding value are strings, * including distinct keys in the default property list if a key * of the same name has not already been found from the main * properties list. Properties whose key or value is not * of type {@code String} are omitted. *

    - * The returned set is not backed by the {@code Properties} object. - * Changes to this {@code Properties} are not reflected in the set, - * or vice versa. + * The returned set is not backed by this {@code Properties} object. + * Changes to this {@code Properties} object are not reflected in the + * returned set. * - * @return a set of keys in this property list where + * @return an unmodifiable set of keys in this property list where * the key and its corresponding value are strings, * including the keys in the default property list. * @see java.util.Properties#defaults @@ -1057,7 +1057,7 @@ public Set stringPropertyNames() { Map h = new HashMap<>(); enumerateStringProperties(h); - return h.keySet(); + return Collections.unmodifiableSet(h.keySet()); } /** From alexandre.iline at oracle.com Thu May 26 22:51:38 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Thu, 26 May 2016 15:51:38 -0700 Subject: RFR 8157996: Unneeded import in lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java In-Reply-To: <8FCE42EF-ABDE-4CF8-B1A9-65033F454CFA@oracle.com> References: <581899F8-DF22-4C89-B375-D96ED8EA1D39@oracle.com> <92A19553-F317-4B73-B873-A8AA5BD1054D@oracle.com> <8FCE42EF-ABDE-4CF8-B1A9-65033F454CFA@oracle.com> Message-ID: <5A63927B-F30F-4A0F-BBF5-7097C20C657E@oracle.com> http://cr.openjdk.java.net/~shurailine/8157996/webrev.01/ Thank you. Shura > On May 26, 2016, at 3:29 PM, Alexandre (Shura) Iline wrote: > > >> On May 26, 2016, at 3:16 PM, Mandy Chung wrote: >> >> >>> On May 26, 2016, at 2:30 PM, Alexandre (Shura) Iline wrote: >>> >>> Hi. >>> >>> Please take a look on an obvious fix: >>> http://cr.openjdk.java.net/~shurailine/8157996/webrev.00/ >>> >>> There was an unneeded import statement which was getting in the way when running tests with limited module availability. >>> >>> Also in a couple of places I have added try with resources. >> >> Looks okay. Can you take out the extra space between ?init? and ?(? while you are on this file? >> 65 init (fis); > > Then I am taking out all extra spaces in this code. Per the examples in http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html. :) > > I was thinking whether to do it to not. > > Shura. > >> >> I can sponsor for you. >> Mandy > From mandy.chung at oracle.com Thu May 26 22:56:41 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 26 May 2016 15:56:41 -0700 Subject: RFR(xs): 8059361: Properties.stringPropertyNames() returns a set inconsistent with the assertions from the spec In-Reply-To: <42636339-3850-ba12-af7c-1fa6b13b6e9e@oracle.com> References: <7abd48ab-aa42-dc2a-f0f0-ad4e09b465f4@oracle.com> <42F05421-96E2-49D1-A4F7-547DC395D0EB@oracle.com> <6905b320-1fff-f6c2-1bab-ad1456c89fe1@oracle.com> <3D856112-EB48-4C8A-9220-EA4265C163C0@oracle.com> <42636339-3850-ba12-af7c-1fa6b13b6e9e@oracle.com> Message-ID: <5FE0EF4F-EEE9-4601-8BF2-DE9019DA5CED@oracle.com> On May 26, 2016, at 3:49 PM, Stuart Marks wrote: > > > > On 5/26/16 2:28 PM, Mandy Chung wrote: >>> - return h.keySet(); >>> + return Set.of(h.keySet().toArray(new String[0])); >>> } >> >> The patch looks fine. It?d be good to add a test case. >> >> If you use Collections.unmodifiableSet, you would not need to convert the key sets to an array. Any benefit of using Set::of instead of Collections.unmodifiableSet? > > There are several minor tradeoffs. > > Collections.unmodifiableSet() simply creates and returns a wrapper object. It contains the keySet, which is backed by the HashMap created within the stringPropertyNames() method. This keeps references to all the string keys and values around, even though the values aren't used. But the strings themselves are also referenced from the original Properties object and its default chain. > > The toArray() call copies the key string refs to an array, then Set.of() hashes them into its internal array. But the resulting data structure holds only references to the keys, so it's more compact. > > Given that most uses seem to iterate the set's elements and then throw it away, it's probably not worth the creation overhead of for an immutable Set. Drat. I guess I was too eager to use the new API. :-) > > I've changed this to use Collections.unmodifiableSet(); see below. > Looks fine. I don?t have any objection in using Set::of vs Collections.unmodifiableSet() in this case (Sorry. I should have made it clear). No need for new patch if you decide to use Set.of (a comment might help). Mandy From chris.hegarty at oracle.com Fri May 27 08:17:40 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 27 May 2016 09:17:40 +0100 Subject: RFR 8157996: Unneeded import in lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java In-Reply-To: <5A63927B-F30F-4A0F-BBF5-7097C20C657E@oracle.com> References: <581899F8-DF22-4C89-B375-D96ED8EA1D39@oracle.com> <92A19553-F317-4B73-B873-A8AA5BD1054D@oracle.com> <8FCE42EF-ABDE-4CF8-B1A9-65033F454CFA@oracle.com> <5A63927B-F30F-4A0F-BBF5-7097C20C657E@oracle.com> Message-ID: > On 26 May 2016, at 23:51, Alexandre (Shura) Iline wrote: > > http://cr.openjdk.java.net/~shurailine/8157996/webrev.01/ Looks good Shura. > Thank you. > > Shura > >> On May 26, 2016, at 3:29 PM, Alexandre (Shura) Iline wrote: >> >> >>> On May 26, 2016, at 3:16 PM, Mandy Chung wrote: >>> >>> >>>> On May 26, 2016, at 2:30 PM, Alexandre (Shura) Iline wrote: >>>> >>>> Hi. >>>> >>>> Please take a look on an obvious fix: >>>> http://cr.openjdk.java.net/~shurailine/8157996/webrev.00/ >>>> >>>> There was an unneeded import statement which was getting in the way when running tests with limited module availability. >>>> >>>> Also in a couple of places I have added try with resources. >>> >>> Looks okay. Can you take out the extra space between ?init? and ?(? while you are on this file? >>> 65 init (fis); >> >> Then I am taking out all extra spaces in this code. Per the examples in http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html. :) >> >> I was thinking whether to do it to not. I have removed the extra spaces in other areas too. It is a particular, IMHO bad, style that some engineers follow. -Chris. From christoph.langer at sap.com Fri May 27 08:29:34 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 27 May 2016 08:29:34 +0000 Subject: RFR 8158023: SocketExceptions contain too little information sometimes Message-ID: Hi all, please review the following change: Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8158023.1/ Bug: https://bugs.openjdk.java.net/browse/JDK-8158023 During error analysis I stumbled over a place where I encountered a SocketException which was thrown along with some strerror information as message. I found it hard to find the originating code spot with that information. So I looked at the places where we throw exceptions, namely JNU_Throw... and NET_Throw... functions and came up with the following enhancement: - NET_ThrowByNameWithLastError can go completely as it does not provide any benefit over JNU_ThrowByNameWithLastError. - JNU_ThrowByNameWithLastError can be cleaned up. - I added JNU_ThrowByNameWithMessageAndLastError to print out a string like message + ": " + last error. - I went over all places where NET_ThrowByNameWithLastError is used and replaced it appropriately. Do you think this change is desirable/possible? Though it's mainly a net topic, I'm posting it to nio-dev and core-libs-dev as well as JNU_Throw... code affects all. Best regards Christoph From Alan.Bateman at oracle.com Fri May 27 09:24:19 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 27 May 2016 10:24:19 +0100 Subject: Review Request: JDK-8157986: Runtime support for javac to determine arguments to the runtime environment In-Reply-To: <723D8D12-23B7-4379-B1DD-FF9082517B81@oracle.com> References: <723D8D12-23B7-4379-B1DD-FF9082517B81@oracle.com> Message-ID: <57481243.6060909@oracle.com> On 26/05/2016 20:40, Mandy Chung wrote: > This patch allows jdk.compiler to get the runtime arguments without pulling in java.management (that requires java.rmi). We should look into use cases further in the future and determine whether a public API should be provided. > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157986/webrev.00/index.html > This looks okay to except that it might be better to drop the reference to JDK-8157979 from the @implNote. -Alan From sean.coffey at oracle.com Fri May 27 13:19:11 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 27 May 2016 14:19:11 +0100 Subject: RFR: 8151876: (tz) Support tzdata2016d In-Reply-To: <9b76a353-e477-4f59-b630-5185e9ce6c37@default> References: <9b76a353-e477-4f59-b630-5185e9ce6c37@default> Message-ID: <5748494F.6060404@oracle.com> Looks fine to me Ramanand. the recent 2016d changes have introduced some boundary issues for JDK rule parsing and those issues can be followed up in separate issues like you say. Regards, Sean. On 26/05/16 14:22, Ramanand Patil wrote: > HI all, > > Please review the latest TZDATA integration (tzdata2016d) to JDK9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151876 > > Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/ > > Patch Contains: > > 1. IANA tzdata2016d integration into JDK. [It also includes tzdata2016b and tzdata2016c which was not integrated]. > > 2. "GMT[+ -]hh:mm" is used for formatting of the modified or newly added TimeZones in tzdata2016d. > > [This is done to accommodate the IANA's new system where the zones use numeric time zone abbreviations like "+04" instead of invented abbreviations like "ASTT".] > > 3. Test case: java/time/test/java/time/format/TestZoneTextPrinterParser.java is updated to include the failures because of GMT[+ -]hh:mm format names. > > 4. Few other failing tests: For few other failing tests, new linked bugs are created and will be addressed in a separate patch. > > > > Regards, > > Ramanand. > > From Roger.Riggs at Oracle.com Fri May 27 13:47:09 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 27 May 2016 09:47:09 -0400 Subject: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour In-Reply-To: <5746AA87.3040501@oracle.com> References: <5746AA87.3040501@oracle.com> Message-ID: Hi Nadeesh, Seeing the complexity of this code expand, I can't help wonder if there is a better algorithm. Perhaps by trying to parse a 1 to 3 numbers(of 1 or two digits) with optional ":"s. And then match that to the valid patterns. The use of numeric indices obscures what is going on. Also, there are a number of conditions that depend on the length of the remaining input. I suspect that when appendOffset is used to parse a sequence of fields, characters belonging to the following fields will throw off the checks. I didn't see any tests that would confirm that appendOffset with input for additional fields (and input) works as intended. Thanks, Roger On 5/26/2016 3:49 AM, nadeesh tv wrote: > Hi all, > > Please review > > BugId : https://bugs.openjdk.java.net/browse/JDK-8066806 > > Issue: java.time.format.DateTimeFormatter cannot parse an offset with > single digit hour > > webrev: http://cr.openjdk.java.net/~ntv/8066806/webrev.03/ > > Solution: Added the suggested patterns but the parsing logic became > too complex. > Appreciate any suggestion to make the parsing less complicated > From daniel.fuchs at oracle.com Fri May 27 14:04:51 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 27 May 2016 16:04:51 +0200 Subject: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour In-Reply-To: References: <5746AA87.3040501@oracle.com> Message-ID: <67355320-e930-2989-96fe-a53098873e00@oracle.com> On 27/05/16 15:47, Roger Riggs wrote: > Hi Nadeesh, > > Seeing the complexity of this code expand, I can't help wonder if there > is a > better algorithm. Perhaps by trying to parse a 1 to 3 numbers(of 1 or > two digits) with optional ":"s. > And then match that to the valid patterns. > The use of numeric indices obscures what is going on. > > Also, there are a number of conditions that depend on the length of the > remaining input. > I suspect that when appendOffset is used to parse a sequence of fields, > characters belonging > to the following fields will throw off the checks. I didn't see any > tests that would confirm that > appendOffset with input for additional fields (and input) works as > intended. > > Thanks, Roger Hi, Stephen is the expert here. However, I can't help feeling that the patterns that allow you to parse/format a single digit hour without the ':' separator ("+H" excepted) are confusing. If we removed those (only adding +H, +H:mm, +H:MM, +H:MM:ss, +H:MM:SS, +H:mm:ss) would the parsing be simplified? Would that be an acceptable compromise? best regards, -- daniel > > > On 5/26/2016 3:49 AM, nadeesh tv wrote: >> Hi all, >> >> Please review >> >> BugId : https://bugs.openjdk.java.net/browse/JDK-8066806 >> >> Issue: java.time.format.DateTimeFormatter cannot parse an offset with >> single digit hour >> >> webrev: http://cr.openjdk.java.net/~ntv/8066806/webrev.03/ >> >> Solution: Added the suggested patterns but the parsing logic became >> too complex. >> Appreciate any suggestion to make the parsing less complicated >> > From masayoshi.okutsu at oracle.com Fri May 27 14:24:49 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 27 May 2016 23:24:49 +0900 Subject: RFR: 8151876: (tz) Support tzdata2016d In-Reply-To: <5748494F.6060404@oracle.com> References: <9b76a353-e477-4f59-b630-5185e9ce6c37@default> <5748494F.6060404@oracle.com> Message-ID: <12123364-e177-a744-7f24-68e4a8f87532@oracle.com> This change seems to beyond my proposal that the "GMT?hh:mm" format is used for *new* zones with the "?hh" format. But this change removes *existing* zones which have changed to use the "?hh" format in tzdata. Can this cause any compatibility issues? And have we agreed to use the "GMT?hh:mm" format? Thanks, Masayoshi On 5/27/2016 10:19 PM, Se?n Coffey wrote: > Looks fine to me Ramanand. the recent 2016d changes have introduced > some boundary issues for JDK rule parsing and those issues can be > followed up in separate issues like you say. > > Regards, > Sean. > > On 26/05/16 14:22, Ramanand Patil wrote: >> HI all, >> >> Please review the latest TZDATA integration (tzdata2016d) to JDK9. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8151876 >> >> Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/ >> >> Patch Contains: >> >> 1. IANA tzdata2016d integration into JDK. [It also includes >> tzdata2016b and tzdata2016c which was not integrated]. >> >> 2. "GMT[+ -]hh:mm" is used for formatting of the modified or >> newly added TimeZones in tzdata2016d. >> >> [This is done to accommodate the IANA's new system where the zones >> use numeric time zone abbreviations like "+04" instead of invented >> abbreviations like "ASTT".] >> >> 3. Test case: >> java/time/test/java/time/format/TestZoneTextPrinterParser.java is >> updated to include the failures because of GMT[+ -]hh:mm format names. >> >> 4. Few other failing tests: For few other failing tests, new >> linked bugs are created and will be addressed in a separate patch. >> >> >> Regards, >> >> Ramanand. >> > From nadeesh.tv at oracle.com Fri May 27 14:32:13 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Fri, 27 May 2016 20:02:13 +0530 Subject: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour In-Reply-To: <67355320-e930-2989-96fe-a53098873e00@oracle.com> References: <5746AA87.3040501@oracle.com> <67355320-e930-2989-96fe-a53098873e00@oracle.com> Message-ID: <57485A6D.4080706@oracle.com> Hi , On 5/27/2016 7:34 PM, Daniel Fuchs wrote: > On 27/05/16 15:47, Roger Riggs wrote: >> Hi Nadeesh, >> >> Seeing the complexity of this code expand, I can't help wonder if there >> is a >> better algorithm. Perhaps by trying to parse a 1 to 3 numbers(of 1 or >> two digits) with optional ":"s. >> And then match that to the valid patterns. >> The use of numeric indices obscures what is going on. I will try in this direction. >> >> Also, there are a number of conditions that depend on the length of the >> remaining input. >> I suspect that when appendOffset is used to parse a sequence of fields, >> characters belonging >> to the following fields will throw off the checks. I didn't see any >> tests that would confirm that >> appendOffset with input for additional fields (and input) works as >> intended. >> >> Thanks, Roger > > Hi, > > Stephen is the expert here. However, I can't help feeling > that the patterns that allow you to parse/format a single > digit hour without the ':' separator ("+H" excepted) are > confusing. If we removed those (only adding +H, +H:mm, +H:MM, > +H:MM:ss, +H:MM:SS, +H:mm:ss) would the parsing be simplified? > > Would that be an acceptable compromise? I feel if we remove those patterns for Single Digit hour ( without colons), it may cause confusion. Thanks and Regards, Nadeesh > > best regards, > > -- daniel > >> >> >> On 5/26/2016 3:49 AM, nadeesh tv wrote: >>> Hi all, >>> >>> Please review >>> >>> BugId : https://bugs.openjdk.java.net/browse/JDK-8066806 >>> >>> Issue: java.time.format.DateTimeFormatter cannot parse an offset with >>> single digit hour >>> >>> webrev: http://cr.openjdk.java.net/~ntv/8066806/webrev.03/ >>> >>> Solution: Added the suggested patterns but the parsing logic became >>> too complex. >>> Appreciate any suggestion to make the parsing less complicated >>> >> > -- Thanks and Regards, Nadeesh TV From mandy.chung at oracle.com Fri May 27 14:33:34 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 27 May 2016 07:33:34 -0700 Subject: Review Request: JDK-8157986: Runtime support for javac to determine arguments to the runtime environment In-Reply-To: <57481243.6060909@oracle.com> References: <723D8D12-23B7-4379-B1DD-FF9082517B81@oracle.com> <57481243.6060909@oracle.com> Message-ID: <0580A88A-93D2-4C79-9307-82C0839257E4@oracle.com> > On May 27, 2016, at 2:24 AM, Alan Bateman wrote: > > On 26/05/2016 20:40, Mandy Chung wrote: >> This patch allows jdk.compiler to get the runtime arguments without pulling in java.management (that requires java.rmi). We should look into use cases further in the future and determine whether a public API should be provided. >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157986/webrev.00/index.html >> > This looks okay to except that it might be better to drop the reference to JDK-8157979 from the @implNote. Yes I plan to drop it. thanks Mandy From sean.coffey at oracle.com Fri May 27 15:04:48 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 27 May 2016 16:04:48 +0100 Subject: RFR: 8151876: (tz) Support tzdata2016d In-Reply-To: <12123364-e177-a744-7f24-68e4a8f87532@oracle.com> References: <9b76a353-e477-4f59-b630-5185e9ce6c37@default> <5748494F.6060404@oracle.com> <12123364-e177-a744-7f24-68e4a8f87532@oracle.com> Message-ID: <57486210.7090205@oracle.com> I guess there's a low risk of timezone not being identified if being parsed in through a formatter. Isn't such an approach discouraged though ? short IDs were already subject to change in tzdata releases. Ramanand found one issue by removal of these resource strings (so far) and that's captured in JDK-8157814 There's a decision to be made about how to use the GMT?hh:mm format for new releases given IANA's new short ID identifier mechanism. I think that could be discussed as a separate issue. I'd like to see us follow a similar approach to IANA and use GMT identifiers on new timezones and perhaps even consider using the IANA long name format also for the getDisplayName(..) calls that can be made. e.g. "Asia/Almaty" instead of "Alma-Ata Time" Regards, Sean. On 27/05/16 15:24, Masayoshi Okutsu wrote: > This change seems to beyond my proposal that the "GMT?hh:mm" format is > used for *new* zones with the "?hh" format. But this change removes > *existing* zones which have changed to use the "?hh" format in tzdata. > Can this cause any compatibility issues? > > And have we agreed to use the "GMT?hh:mm" format? > > Thanks, > Masayoshi > > > On 5/27/2016 10:19 PM, Se?n Coffey wrote: >> Looks fine to me Ramanand. the recent 2016d changes have introduced >> some boundary issues for JDK rule parsing and those issues can be >> followed up in separate issues like you say. >> >> Regards, >> Sean. >> >> On 26/05/16 14:22, Ramanand Patil wrote: >>> HI all, >>> >>> Please review the latest TZDATA integration (tzdata2016d) to JDK9. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151876 >>> >>> Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/ >>> >>> Patch Contains: >>> >>> 1. IANA tzdata2016d integration into JDK. [It also includes >>> tzdata2016b and tzdata2016c which was not integrated]. >>> >>> 2. "GMT[+ -]hh:mm" is used for formatting of the modified or >>> newly added TimeZones in tzdata2016d. >>> >>> [This is done to accommodate the IANA's new system where the zones >>> use numeric time zone abbreviations like "+04" instead of invented >>> abbreviations like "ASTT".] >>> >>> 3. Test case: >>> java/time/test/java/time/format/TestZoneTextPrinterParser.java is >>> updated to include the failures because of GMT[+ -]hh:mm format names. >>> >>> 4. Few other failing tests: For few other failing tests, new >>> linked bugs are created and will be addressed in a separate patch. >>> >>> >>> Regards, >>> >>> Ramanand. >>> >> > From lance.andersen at oracle.com Fri May 27 17:28:40 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 27 May 2016 13:28:40 -0400 Subject: RFR 8154189: Deprivilege java.sql and java.sql.rowset module Message-ID: Hi all, This is a request to review the changes below to Deprivilege java.sql and java.sql.rowset modules changes to: make/common/Modules.gmk ???????? ljanders-mac:make ljanders$ hg diff diff -r cae471d3b877 make/common/Modules.gmk --- a/make/common/Modules.gmk Thu May 26 17:17:51 2016 +0000 +++ b/make/common/Modules.gmk Fri May 27 13:21:22 2016 -0400 @@ -57,7 +57,6 @@ java.rmi \ java.security.jgss \ java.security.sasl \ - java.sql \ java.xml \ java.xml.crypto \ jdk.httpserver \ @@ -72,7 +71,6 @@ # to be deprivileged BOOT_MODULES += \ - java.sql.rowset \ java.smartcardio \ jdk.naming.rmi \ # @@ -105,6 +103,8 @@ PLATFORM_MODULES += \ java.compiler \ + java.sql \ + java.sql.rowset \ java.scripting \ jdk.accessibility \ jdk.charsets \ ljanders-mac:make ljanders$ ???????? Changes to: src/java.base/share/conf/security/java.policy ???????? ljanders-mac:jdk ljanders$ hg diff diff -r df35a805b405 src/java.base/share/conf/security/java.policy --- a/src/java.base/share/conf/security/java.policy Fri May 27 08:52:22 2016 -0700 +++ b/src/java.base/share/conf/security/java.policy Fri May 27 13:24:22 2016 -0400 @@ -33,6 +33,14 @@ permission java.io.FilePermission "${java.home}/conf/security/ucrypto-solaris.cfg", "read"; }; +grant codeBase "jrt:/java.sql" { + permission java.security.AllPermission; +}; + +grant codeBase "jrt:/java.sql.rowset" { + permission java.security.AllPermission; +}; + grant codeBase "jrt:/jdk.crypto.ec" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.*"; permission java.lang.RuntimePermission "loadLibrary.sunec"; ljanders-mac:jdk ljanders$ ???????????? As part of the testing, we have run - CTS JDBC tests - against Derby embedded and client driver - All of the Derby test suites - JTREG tests - JCK JDBC and RowSet tests The Derby tests suites uncovered 2 Derby specific issues which have been addressed in the derby trunk, all other tests passed thank you and have a nice weekend Best Lance 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 Fri May 27 17:56:23 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 27 May 2016 10:56:23 -0700 Subject: RFR 8154189: Deprivilege java.sql and java.sql.rowset module In-Reply-To: References: Message-ID: <9EC5BB9E-DDBC-4361-B71C-1F983F1C1C5F@oracle.com> > On May 27, 2016, at 10:28 AM, Lance Andersen wrote: > > Hi all, > > This is a request to review the changes below to Deprivilege java.sql and java.sql.rowset modules > : The change looks fine. It?s okay to grants AllPermission to get started. It?d be nice if we could grant fine-grained permissions in the future. Mandy From lance.andersen at oracle.com Fri May 27 18:10:14 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 27 May 2016 14:10:14 -0400 Subject: RFR 8154189: Deprivilege java.sql and java.sql.rowset module In-Reply-To: <9EC5BB9E-DDBC-4361-B71C-1F983F1C1C5F@oracle.com> References: <9EC5BB9E-DDBC-4361-B71C-1F983F1C1C5F@oracle.com> Message-ID: Hi Mandy, > On May 27, 2016, at 1:56 PM, Mandy Chung wrote: > > >> On May 27, 2016, at 10:28 AM, Lance Andersen wrote: >> >> Hi all, >> >> This is a request to review the changes below to Deprivilege java.sql and java.sql.rowset modules >> : > > The change looks fine. Thank you > > It?s okay to grants AllPermission to get started. It?d be nice if we could grant fine-grained permissions in the future. Agree, it is something to try and work towards. Best Lance > > 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 Alan.Bateman at oracle.com Fri May 27 19:20:03 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 27 May 2016 20:20:03 +0100 Subject: RFR 8154189: Deprivilege java.sql and java.sql.rowset module In-Reply-To: References: Message-ID: <57489DE3.7000208@oracle.com> On 27/05/2016 18:28, Lance Andersen wrote: > Hi all, > > This is a request to review the changes below to Deprivilege java.sql and java.sql.rowset modules > > This looks okay to me too. A minor point is that it would be good to keep PLATFORM_MODULES sorted. -Alan. From xueming.shen at oracle.com Fri May 27 20:38:46 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 27 May 2016 13:38:46 -0700 Subject: RFR: JDK-8061777, , (zipfs) IllegalArgumentException in ZipCoder.toString when using Shitft_JIS Message-ID: <5748B056.3090903@oracle.com> Hi, Please help review the change for JDK-8061777. issue: https://bugs.openjdk.java.net/browse/JDK-8061777 webrev: http://cr.openjdk.java.net/~sherman/8061777 Cause: ZipPath/ZipFileSystem uses byte[] as the internal underlying storage for entry names (for better performance, as the "name" is stored as bytes inside the zip/jar file, it is desirable to avoid the redundant String<->byte[] conversion, if possible). With this design, it is natural to also work on byte[] directly for those "path" operations, including the "normalization", which mainly is to remove the redundant "/" and switch the "\" to "/". This appears to be a problem for non-utf8 encoded zip file (utf8 is the default encoding used to de/encode the entry name for the Java jar/zip APIs), especially those double-byte encodings that have 0x5c ('\') as one of the double-byte bytes. The 0x5c byte will be mistakenly normalized to '\' if we normalize on the byte[] directly. The proposed change here is to normalize on the "String" to avoid this problem. Given the fact that Java jar/zip is specified to use utf-8 by default, to avoid the potential performance risk/cost for most of the zip/jar files (if we switch completely to the String based operation) the utf-8/byte[] path is still being used (as the default) when the encoding is utf-8. The implementation only switches to "String based" code path when the encoding is specifically specified as "non-utf8", which should be rare. Thanks, Sherman From mandy.chung at oracle.com Sat May 28 04:29:54 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 27 May 2016 21:29:54 -0700 Subject: Review Request JDK-8152721: Java Web Start splash mechanism is not working in JDK9 Message-ID: <73F0BDF7-51DB-486D-B9C3-EA89A0858B07@oracle.com> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152721/webrev.00/ The launcher does not handle the new options with whitespace separated arguments properly. This patch applies that consistently in java.c I leave arg.c as is that Kumar/Henry can consider cleanup in the future. Mandy From Alan.Bateman at oracle.com Sat May 28 04:54:16 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 28 May 2016 05:54:16 +0100 Subject: Review Request JDK-8152721: Java Web Start splash mechanism is not working in JDK9 In-Reply-To: <73F0BDF7-51DB-486D-B9C3-EA89A0858B07@oracle.com> References: <73F0BDF7-51DB-486D-B9C3-EA89A0858B07@oracle.com> Message-ID: <57492478.4030200@oracle.com> On 28/05/2016 05:29, Mandy Chung wrote: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152721/webrev.00/ > > The launcher does not handle the new options with whitespace separated arguments properly. This patch applies that consistently in java.c I leave arg.c as is that Kumar/Henry can consider cleanup in the future. > The new options are handled correctly on the command, I think it's just the JDK internal JLI_Launch entry point where this was missed. The patch looks okay, I just wonder if there is there are any tests that could use this entry point. -Alan From masayoshi.okutsu at oracle.com Sat May 28 05:27:39 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Sat, 28 May 2016 14:27:39 +0900 Subject: RFR: 8151876: (tz) Support tzdata2016d In-Reply-To: <57486210.7090205@oracle.com> References: <9b76a353-e477-4f59-b630-5185e9ce6c37@default> <5748494F.6060404@oracle.com> <12123364-e177-a744-7f24-68e4a8f87532@oracle.com> <57486210.7090205@oracle.com> Message-ID: CLDR locale data defines time zone names, like this (in en.xml): Almaty Time Almaty Standard Time Almaty Summer Time The CLDR converter tool tries to fill in the missing short names from the legacy TimeZoneNames data. Removing existing names causes some unexpected behavior. I think JDK-8157814 is an example of the unexpected behavior. And the suggested fix in JDK-8157814 looks to me like a workaround. I still think the existing names should be kept unchanged for this fix. Thanks, Masayoshi On 5/28/2016 12:04 AM, Se?n Coffey wrote: > I guess there's a low risk of timezone not being identified if being > parsed in through a formatter. Isn't such an approach discouraged > though ? short IDs were already subject to change in tzdata releases. > Ramanand found one issue by removal of these resource strings (so far) > and that's captured in JDK-8157814 > > There's a decision to be made about how to use the GMT?hh:mm format > for new releases given IANA's new short ID identifier mechanism. I > think that could be discussed as a separate issue. I'd like to see us > follow a similar approach to IANA and use GMT identifiers on new > timezones and perhaps even consider using the IANA long name format > also for the getDisplayName(..) calls that can be made. e.g. > "Asia/Almaty" instead of "Alma-Ata Time" > Regards, > Sean. > On 27/05/16 15:24, Masayoshi Okutsu wrote: >> This change seems to beyond my proposal that the "GMT?hh:mm" format >> is used for *new* zones with the "?hh" format. But this change >> removes *existing* zones which have changed to use the "?hh" format >> in tzdata. Can this cause any compatibility issues? >> >> And have we agreed to use the "GMT?hh:mm" format? >> >> Thanks, >> Masayoshi >> >> >> On 5/27/2016 10:19 PM, Se?n Coffey wrote: >>> Looks fine to me Ramanand. the recent 2016d changes have introduced >>> some boundary issues for JDK rule parsing and those issues can be >>> followed up in separate issues like you say. >>> >>> Regards, >>> Sean. >>> >>> On 26/05/16 14:22, Ramanand Patil wrote: >>>> HI all, >>>> >>>> Please review the latest TZDATA integration (tzdata2016d) to JDK9. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151876 >>>> >>>> Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/ >>>> >>>> Patch Contains: >>>> >>>> 1. IANA tzdata2016d integration into JDK. [It also includes >>>> tzdata2016b and tzdata2016c which was not integrated]. >>>> >>>> 2. "GMT[+ -]hh:mm" is used for formatting of the modified or >>>> newly added TimeZones in tzdata2016d. >>>> >>>> [This is done to accommodate the IANA's new system where the zones >>>> use numeric time zone abbreviations like "+04" instead of invented >>>> abbreviations like "ASTT".] >>>> >>>> 3. Test case: >>>> java/time/test/java/time/format/TestZoneTextPrinterParser.java is >>>> updated to include the failures because of GMT[+ -]hh:mm format names. >>>> >>>> 4. Few other failing tests: For few other failing tests, new >>>> linked bugs are created and will be addressed in a separate patch. >>>> >>>> >>>> Regards, >>>> >>>> Ramanand. >>>> >>> >> > From naufal11 at gmail.com Sat May 28 09:05:13 2016 From: naufal11 at gmail.com (Mohamed Naufal) Date: Sat, 28 May 2016 14:35:13 +0530 Subject: [PATCH] Implement a noop clear() for Collections#EMPTY_LIST In-Reply-To: References: Message-ID: Hi, I see that this is applicable to EmptyMap and EmptySet as well, here's an updated patch with clear() overridden for all 3 classes. Thanks, Naufal On 23 May 2016 at 16:13, Paul Sandoz wrote: > Hi Naufal, > > Thanks for looking at this. > > For us to accept your patch (no matter how small) you need to become a > contributor, which requires that you agree to the Oracle Contributor > Agreement (OCA), see: > > http://openjdk.java.net/contribute/ > > Thanks, > Paul. > > > On 22 May 2016, at 12:10, Mohamed Naufal wrote: > > > > Hi, > > > > A call to clear() on Collections#EMPTY_LIST is currently redirected to > > AbstractList#clear(), which performs a bunch of checks and creates a > > ListItr object, all of which is unnecessary for an EmptyList. > > > > PFA a patch that implements a noop clear() for EmptyList. > > > > Thanks, > > Naufal > > > > -------------- next part -------------- # HG changeset patch # User Mohamed Naufal # Date 1464424050 -19800 # Sat May 28 13:57:30 2016 +0530 # Node ID 78c139550bfce1c1795dc5d7820766b95de19d2c # Parent bbc19b6de175e355d008d6b968183bd3c4edce55 Collections: Implement a noop clear() for EmptyList, EmptyMap and EmptySet diff -r bbc19b6de175 -r 78c139550bfc src/java.base/share/classes/java/util/Collections.java --- a/src/java.base/share/classes/java/util/Collections.java Thu May 26 16:02:16 2016 +0000 +++ b/src/java.base/share/classes/java/util/Collections.java Sat May 28 13:57:30 2016 +0530 @@ -4324,6 +4324,7 @@ public int size() {return 0;} public boolean isEmpty() {return true;} + public void clear() {} public boolean contains(Object obj) {return false;} public boolean containsAll(Collection c) { return c.isEmpty(); } @@ -4447,6 +4448,7 @@ public int size() {return 0;} public boolean isEmpty() {return true;} + public void clear() {} public boolean contains(Object obj) {return false;} public boolean containsAll(Collection c) { return c.isEmpty(); } @@ -4582,6 +4584,7 @@ public int size() {return 0;} public boolean isEmpty() {return true;} + public void clear() {} public boolean containsKey(Object key) {return false;} public boolean containsValue(Object value) {return false;} public V get(Object key) {return null;} From lowasser at google.com Sat May 28 17:02:07 2016 From: lowasser at google.com (Louis Wasserman) Date: Sat, 28 May 2016 17:02:07 +0000 Subject: [PATCH] Implement a noop clear() for Collections#EMPTY_LIST In-Reply-To: References: Message-ID: Is it? IIRC EmptyMap and EmptySet will use a singleton unmodifiable empty Iterator, so they won't incur any allocation, and the clear() will finish immediately with no work anyway. On Sat, May 28, 2016, 2:05 AM Mohamed Naufal wrote: > Hi, > > I see that this is applicable to EmptyMap and EmptySet as well, here's an > updated patch with clear() overridden for all 3 classes. > > Thanks, > Naufal > > On 23 May 2016 at 16:13, Paul Sandoz wrote: > > > Hi Naufal, > > > > Thanks for looking at this. > > > > For us to accept your patch (no matter how small) you need to become a > > contributor, which requires that you agree to the Oracle Contributor > > Agreement (OCA), see: > > > > http://openjdk.java.net/contribute/ > > > > Thanks, > > Paul. > > > > > On 22 May 2016, at 12:10, Mohamed Naufal wrote: > > > > > > Hi, > > > > > > A call to clear() on Collections#EMPTY_LIST is currently redirected to > > > AbstractList#clear(), which performs a bunch of checks and creates a > > > ListItr object, all of which is unnecessary for an EmptyList. > > > > > > PFA a patch that implements a noop clear() for EmptyList. > > > > > > Thanks, > > > Naufal > > > > > > > > From naufal11 at gmail.com Sat May 28 18:26:46 2016 From: naufal11 at gmail.com (Mohamed Naufal) Date: Sat, 28 May 2016 23:56:46 +0530 Subject: [PATCH] Implement a noop clear() for Collections#EMPTY_LIST In-Reply-To: References: Message-ID: Hi, You're right of course, I should have been clearer, no allocation happens for clear() on EmptyMap or EmptySet, but a lot of unnecessary calls are made. The call stack for clear() on EmptySet looks something like this: AbstractCollection#clear() ->EmptySet#iterator() -> Collections#emptyIterator() -> returns the singleton EmptyIterator#EMPTY_ITERATOR on which hasNext() is called. And for EmptyMap: AbstractMap#clear() -> EmptyMap#entrySet() -> Collections#emptySet(), from which point onwards, it's similar to that of EmptySet. This could be avoided with the direct override. Thanks, Naufal On 28 May 2016 at 22:32, Louis Wasserman wrote: > Is it? IIRC EmptyMap and EmptySet will use a singleton unmodifiable empty > Iterator, so they won't incur any allocation, and the clear() will finish > immediately with no work anyway. > > On Sat, May 28, 2016, 2:05 AM Mohamed Naufal wrote: > >> Hi, >> >> I see that this is applicable to EmptyMap and EmptySet as well, here's an >> updated patch with clear() overridden for all 3 classes. >> >> Thanks, >> Naufal >> >> On 23 May 2016 at 16:13, Paul Sandoz wrote: >> >> > Hi Naufal, >> > >> > Thanks for looking at this. >> > >> > For us to accept your patch (no matter how small) you need to become a >> > contributor, which requires that you agree to the Oracle Contributor >> > Agreement (OCA), see: >> > >> > http://openjdk.java.net/contribute/ >> > >> > Thanks, >> > Paul. >> > >> > > On 22 May 2016, at 12:10, Mohamed Naufal wrote: >> > > >> > > Hi, >> > > >> > > A call to clear() on Collections#EMPTY_LIST is currently redirected to >> > > AbstractList#clear(), which performs a bunch of checks and creates a >> > > ListItr object, all of which is unnecessary for an EmptyList. >> > > >> > > PFA a patch that implements a noop clear() for EmptyList. >> > > >> > > Thanks, >> > > Naufal >> > > >> > >> > >> > From lowasser at google.com Sat May 28 18:27:50 2016 From: lowasser at google.com (Louis Wasserman) Date: Sat, 28 May 2016 18:27:50 +0000 Subject: [PATCH] Implement a noop clear() for Collections#EMPTY_LIST In-Reply-To: References: Message-ID: Do you actually expect that to represent a significant performance difference? All those calls sound like things easy to JIT. On Sat, May 28, 2016, 11:26 AM Mohamed Naufal wrote: > Hi, > > You're right of course, I should have been clearer, no allocation happens > for clear() on EmptyMap or EmptySet, but a lot of unnecessary calls are > made. > > The call stack for clear() on EmptySet looks something like this: > AbstractCollection#clear() ->EmptySet#iterator() -> > Collections#emptyIterator() -> returns the singleton > EmptyIterator#EMPTY_ITERATOR on which hasNext() is called. > > And for EmptyMap: > AbstractMap#clear() -> EmptyMap#entrySet() -> Collections#emptySet(), from > which point onwards, it's similar to that of EmptySet. > > This could be avoided with the direct override. > > Thanks, > Naufal > > On 28 May 2016 at 22:32, Louis Wasserman wrote: > >> Is it? IIRC EmptyMap and EmptySet will use a singleton unmodifiable >> empty Iterator, so they won't incur any allocation, and the clear() will >> finish immediately with no work anyway. >> >> On Sat, May 28, 2016, 2:05 AM Mohamed Naufal wrote: >> >>> Hi, >>> >>> I see that this is applicable to EmptyMap and EmptySet as well, here's an >>> updated patch with clear() overridden for all 3 classes. >>> >>> Thanks, >>> Naufal >>> >>> On 23 May 2016 at 16:13, Paul Sandoz wrote: >>> >>> > Hi Naufal, >>> > >>> > Thanks for looking at this. >>> > >>> > For us to accept your patch (no matter how small) you need to become a >>> > contributor, which requires that you agree to the Oracle Contributor >>> > Agreement (OCA), see: >>> > >>> > http://openjdk.java.net/contribute/ >>> > >>> > Thanks, >>> > Paul. >>> > >>> > > On 22 May 2016, at 12:10, Mohamed Naufal wrote: >>> > > >>> > > Hi, >>> > > >>> > > A call to clear() on Collections#EMPTY_LIST is currently redirected >>> to >>> > > AbstractList#clear(), which performs a bunch of checks and creates a >>> > > ListItr object, all of which is unnecessary for an EmptyList. >>> > > >>> > > PFA a patch that implements a noop clear() for EmptyList. >>> > > >>> > > Thanks, >>> > > Naufal >>> > > >>> > >>> > >>> >> > From naufal11 at gmail.com Sat May 28 18:38:35 2016 From: naufal11 at gmail.com (Mohamed Naufal) Date: Sun, 29 May 2016 00:08:35 +0530 Subject: [PATCH] Implement a noop clear() for Collections#EMPTY_LIST In-Reply-To: References: Message-ID: Hi, Compared to avoiding an allocation, not really. In addition to avoiding the calls, this was more for the sake of consistency with the change for EmptyList. Thanks, Naufal On 28 May 2016 at 23:57, Louis Wasserman wrote: > Do you actually expect that to represent a significant performance > difference? All those calls sound like things easy to JIT. > > On Sat, May 28, 2016, 11:26 AM Mohamed Naufal wrote: > >> Hi, >> >> You're right of course, I should have been clearer, no allocation happens >> for clear() on EmptyMap or EmptySet, but a lot of unnecessary calls are >> made. >> >> The call stack for clear() on EmptySet looks something like this: >> AbstractCollection#clear() ->EmptySet#iterator() -> >> Collections#emptyIterator() -> returns the singleton >> EmptyIterator#EMPTY_ITERATOR on which hasNext() is called. >> >> And for EmptyMap: >> AbstractMap#clear() -> EmptyMap#entrySet() -> Collections#emptySet(), >> from which point onwards, it's similar to that of EmptySet. >> >> This could be avoided with the direct override. >> >> Thanks, >> Naufal >> >> On 28 May 2016 at 22:32, Louis Wasserman wrote: >> >>> Is it? IIRC EmptyMap and EmptySet will use a singleton unmodifiable >>> empty Iterator, so they won't incur any allocation, and the clear() will >>> finish immediately with no work anyway. >>> >>> On Sat, May 28, 2016, 2:05 AM Mohamed Naufal wrote: >>> >>>> Hi, >>>> >>>> I see that this is applicable to EmptyMap and EmptySet as well, here's >>>> an >>>> updated patch with clear() overridden for all 3 classes. >>>> >>>> Thanks, >>>> Naufal >>>> >>>> On 23 May 2016 at 16:13, Paul Sandoz wrote: >>>> >>>> > Hi Naufal, >>>> > >>>> > Thanks for looking at this. >>>> > >>>> > For us to accept your patch (no matter how small) you need to become a >>>> > contributor, which requires that you agree to the Oracle Contributor >>>> > Agreement (OCA), see: >>>> > >>>> > http://openjdk.java.net/contribute/ >>>> > >>>> > Thanks, >>>> > Paul. >>>> > >>>> > > On 22 May 2016, at 12:10, Mohamed Naufal >>>> wrote: >>>> > > >>>> > > Hi, >>>> > > >>>> > > A call to clear() on Collections#EMPTY_LIST is currently redirected >>>> to >>>> > > AbstractList#clear(), which performs a bunch of checks and creates a >>>> > > ListItr object, all of which is unnecessary for an EmptyList. >>>> > > >>>> > > PFA a patch that implements a noop clear() for EmptyList. >>>> > > >>>> > > Thanks, >>>> > > Naufal >>>> > > >>>> > >>>> > >>>> >>> >> From shilpi.rastogi at oracle.com Mon May 30 06:00:13 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Mon, 30 May 2016 11:30:13 +0530 Subject: RFR[9]: 8147585: Annotations with lambda expressions has parameters result in wrong behavior. Message-ID: <574BD6ED.70804@oracle.com> Hi All, Please review fix for https://bugs.openjdk.java.net/browse/JDK-8147585 http://cr.openjdk.java.net/~srastogi/8147585/webrev.00/ Problem: Annotation with Lamda has parameters results into wrong behavior ( not considered as valid annotation) because According to JLS "By virtue of the AnnotationTypeElementDeclaration production, a method declaration in an annotation type declaration cannot have formal parameters, type parameters, or a throws clause. The following production from ?4.3 is shown here for convenience:" (Ref: https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.6.1) Solution: We should skip synthetic methods during Annotation parsing. According to JLS "An annotation type has no elements other than those defined by the methods it explicitly declares." (Ref https://docs.oracle.com/javase/specs/jls/se8/html/.html#jls-9jls-9.6.1) Thanks, Shilpi From felix.yang at oracle.com Mon May 30 07:18:24 2016 From: felix.yang at oracle.com (Felix Yang) Date: Mon, 30 May 2016 15:18:24 +0800 Subject: RFR 8157816, Mark 4 httpclient tests as intermittently failing Message-ID: Hi all, please review the change to mark following tests with keyword 'intermittent'. These tests have been observed to fail intermittently for a while. test/java/net/httpclient/SplitResponse.java test/java/net/httpclient/http2/BasicTest.java test/java/net/httpclient/http2/ErrorTest.java test/java/net/httpclient/http2/TLSConnection.java Bug: https://bugs.openjdk.java.net/browse/JDK-8157816 Webrev: http://cr.openjdk.java.net/~xiaofeya/8157816/webrev.00/ Thanks, Felix Also attached the diff: diff -r ee29aaab5889 test/java/net/httpclient/SplitResponse.java --- a/test/java/net/httpclient/SplitResponse.java Mon May 30 14:58:59 2016 +0900 +++ b/test/java/net/httpclient/SplitResponse.java Sun May 29 23:49:16 2016 -0700 @@ -33,6 +33,7 @@ /** * @test * @bug 8087112 + * @key intermittent * @build Server * @run main/othervm -Djava.net.HttpClient.log=all SplitResponse */ diff -r ee29aaab5889 test/java/net/httpclient/http2/BasicTest.java --- a/test/java/net/httpclient/http2/BasicTest.java Mon May 30 14:58:59 2016 +0900 +++ b/test/java/net/httpclient/http2/BasicTest.java Sun May 29 23:49:16 2016 -0700 @@ -24,6 +24,7 @@ /* * @test * @bug 8087112 + * @key intermittent * @library /lib/testlibrary * @build jdk.testlibrary.SimpleSSLContext * @modules java.httpclient diff -r ee29aaab5889 test/java/net/httpclient/http2/ErrorTest.java --- a/test/java/net/httpclient/http2/ErrorTest.java Mon May 30 14:58:59 2016 +0900 +++ b/test/java/net/httpclient/http2/ErrorTest.java Sun May 29 23:49:16 2016 -0700 @@ -24,6 +24,7 @@ /* * @test * @bug 8157105 + * @key intermittent * @library /lib/testlibrary * @build jdk.testlibrary.SimpleSSLContext * @modules java.httpclient diff -r ee29aaab5889 test/java/net/httpclient/http2/TLSConnection.java --- a/test/java/net/httpclient/http2/TLSConnection.java Mon May 30 14:58:59 2016 +0900 +++ b/test/java/net/httpclient/http2/TLSConnection.java Sun May 29 23:49:16 2016 -0700 @@ -39,6 +39,7 @@ /* * @test * @bug 8150769 8157107 + * @key intermittent * @summary Checks that SSL parameters can be set for HTTP/2 connection * @modules java.httpclient * @compile/module=java.httpclient java/net/http/Http2Handler.java From amy.lu at oracle.com Mon May 30 07:33:08 2016 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 30 May 2016 15:33:08 +0800 Subject: JDK 9 RFR of JDK-8154980: Remove intermittent key from test BandIntegrity.java Message-ID: <574BECB4.5030606@oracle.com> tools/pack200/BandIntegrity.java This test was failing intermittently (JDK-8154049). Mentioned issues have been resolved and no open bug (no failure reported) till now. This patch is to remove @key intermittent from the test. bug: https://bugs.openjdk.java.net/browse/JDK-8154980 webrev: http://cr.openjdk.java.net/~amlu/8154980/webrev.00/ Thanks, Amy --- old/test/tools/pack200/BandIntegrity.java 2016-05-30 15:28:53.000000000 +0800 +++ new/test/tools/pack200/BandIntegrity.java 2016-05-30 15:28:53.000000000 +0800 @@ -26,7 +26,6 @@ * @summary test ensures the proper sequencing of bands, dump bands as well. * @compile -XDignore.symbol.file Utils.java BandIntegrity.java * @run main BandIntegrity - * @key intermittent * @author ksrini */ import java.io.File; From amy.lu at oracle.com Mon May 30 07:49:52 2016 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 30 May 2016 15:49:52 +0800 Subject: RFR: 8151901: test/tools/pack200/Pack200Test fails on verifying native unpacked JAR In-Reply-To: <56F0504A.4030204@oracle.com> References: <56F0504A.4030204@oracle.com> Message-ID: <574BF0A0.1080307@oracle.com> Hi, Kumar So far this test is in ProblemList.txt: tools/pack200/Pack200Test.java 8059906,8151901 generic-all Will it be removed from ProblemList.txt in this fix? Thanks, Amy On 3/22/16 3:49 AM, Kumar Srinivasan wrote: > Hi John, > > This patch contains fixes for two bugs: > 8151901: test/tools/pack200/Pack200Test fails on verifying native > unpacked JAR > 8062335: Pack200 Java implementation differs from C version, outputs > unused UTF8 for BootstrapMethods Note: The test case exhibits both of > the above. > > With this the classes produced by java and the native implementation > are congruent, > though the JDK image's classes exhibit these issues, as a precaution I > have extracted the > minimal set of classes to reproduce the issues, into the golden jar. > > The webrev is at: > http://cr.openjdk.java.net/~ksrini/8151901/webrev.00/ > > Thanks > Kumar > From aleksey.shipilev at oracle.com Mon May 30 08:42:43 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 30 May 2016 11:42:43 +0300 Subject: JDK 9 RFR of JDK-8154980: Remove intermittent key from test BandIntegrity.java In-Reply-To: <574BECB4.5030606@oracle.com> References: <574BECB4.5030606@oracle.com> Message-ID: <574BFD03.2020707@oracle.com> On 05/30/2016 10:33 AM, Amy Lu wrote: > tools/pack200/BandIntegrity.java > > This test was failing intermittently (JDK-8154049). Mentioned issues > have been resolved and no open bug (no failure reported) till now. > > This patch is to remove @key intermittent from the test. > > bug: https://bugs.openjdk.java.net/browse/JDK-8154980 > webrev: http://cr.openjdk.java.net/~amlu/8154980/webrev.00/ Reviewed. Thanks, -Aleksey From chris.hegarty at oracle.com Mon May 30 09:13:48 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 30 May 2016 10:13:48 +0100 Subject: RFR 8157816, Mark 4 httpclient tests as intermittently failing In-Reply-To: References: Message-ID: <574C044C.8030807@oracle.com> This is sad, but I agree. Reviewed. -Chris. On 30/05/16 08:18, Felix Yang wrote: > Hi all, > please review the change to mark following tests with keyword > 'intermittent'. These tests have been observed to fail intermittently > for a while. > test/java/net/httpclient/SplitResponse.java > test/java/net/httpclient/http2/BasicTest.java > test/java/net/httpclient/http2/ErrorTest.java > test/java/net/httpclient/http2/TLSConnection.java > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157816 > Webrev: http://cr.openjdk.java.net/~xiaofeya/8157816/webrev.00/ > > Thanks, > Felix > > Also attached the diff: > > diff -r ee29aaab5889 test/java/net/httpclient/SplitResponse.java > --- a/test/java/net/httpclient/SplitResponse.java Mon May 30 > 14:58:59 2016 +0900 > +++ b/test/java/net/httpclient/SplitResponse.java Sun May 29 > 23:49:16 2016 -0700 > @@ -33,6 +33,7 @@ > /** > * @test > * @bug 8087112 > + * @key intermittent > * @build Server > * @run main/othervm -Djava.net.HttpClient.log=all SplitResponse > */ > diff -r ee29aaab5889 test/java/net/httpclient/http2/BasicTest.java > --- a/test/java/net/httpclient/http2/BasicTest.java Mon May 30 > 14:58:59 2016 +0900 > +++ b/test/java/net/httpclient/http2/BasicTest.java Sun May 29 > 23:49:16 2016 -0700 > @@ -24,6 +24,7 @@ > /* > * @test > * @bug 8087112 > + * @key intermittent > * @library /lib/testlibrary > * @build jdk.testlibrary.SimpleSSLContext > * @modules java.httpclient > diff -r ee29aaab5889 test/java/net/httpclient/http2/ErrorTest.java > --- a/test/java/net/httpclient/http2/ErrorTest.java Mon May 30 > 14:58:59 2016 +0900 > +++ b/test/java/net/httpclient/http2/ErrorTest.java Sun May 29 > 23:49:16 2016 -0700 > @@ -24,6 +24,7 @@ > /* > * @test > * @bug 8157105 > + * @key intermittent > * @library /lib/testlibrary > * @build jdk.testlibrary.SimpleSSLContext > * @modules java.httpclient > diff -r ee29aaab5889 test/java/net/httpclient/http2/TLSConnection.java > --- a/test/java/net/httpclient/http2/TLSConnection.java Mon May 30 > 14:58:59 2016 +0900 > +++ b/test/java/net/httpclient/http2/TLSConnection.java Sun May 29 > 23:49:16 2016 -0700 > @@ -39,6 +39,7 @@ > /* > * @test > * @bug 8150769 8157107 > + * @key intermittent > * @summary Checks that SSL parameters can be set for HTTP/2 connection > * @modules java.httpclient > * @compile/module=java.httpclient java/net/http/Http2Handler.java > From paul.sandoz at oracle.com Mon May 30 09:31:42 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 30 May 2016 11:31:42 +0200 Subject: RFR: JDK-8061777, , (zipfs) IllegalArgumentException in ZipCoder.toString when using Shitft_JIS In-Reply-To: <5748B056.3090903@oracle.com> References: <5748B056.3090903@oracle.com> Message-ID: <237367AB-CD71-4C9B-91F5-B5F4E0557FD1@oracle.com> Hi Sherman, Do you consider modifying the new ZipPath constructor you added to accept a boolean value for UTF-8 encoding? If so you can more clearly document the behaviour and avoid duplication of the operators in ZipFileSystem e.g.: return new ZipPath(this, first, zc.isUTF8()); Paul. > On 27 May 2016, at 22:38, Xueming Shen wrote: > > Hi, > > Please help review the change for JDK-8061777. > > issue: https://bugs.openjdk.java.net/browse/JDK-8061777 > webrev: http://cr.openjdk.java.net/~sherman/8061777 > > Cause: ZipPath/ZipFileSystem uses byte[] as the internal underlying storage for > entry names (for better performance, as the "name" is stored as bytes inside > the zip/jar file, it is desirable to avoid the redundant String<->byte[] conversion, > if possible). With this design, it is natural to also work on byte[] directly for those > "path" operations, including the "normalization", which mainly is to remove the > redundant "/" and switch the "\" to "/". This appears to be a problem for non-utf8 > encoded zip file (utf8 is the default encoding used to de/encode the entry name > for the Java jar/zip APIs), especially those double-byte encodings that have 0x5c > ('\') as one of the double-byte bytes. The 0x5c byte will be mistakenly normalized > to '\' if we normalize on the byte[] directly. The proposed change here is to > normalize on the "String" to avoid this problem. Given the fact that Java jar/zip > is specified to use utf-8 by default, to avoid the potential performance risk/cost > for most of the zip/jar files (if we switch completely to the String based operation) > the utf-8/byte[] path is still being used (as the default) when the encoding is utf-8. > The implementation only switches to "String based" code path when the encoding > is specifically specified as "non-utf8", which should be rare. > > Thanks, > Sherman From yasuenag at gmail.com Mon May 30 12:44:15 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 30 May 2016 21:44:15 +0900 Subject: PING: RFR: JDK-4347142: Need method to set Password protection to Zip entries In-Reply-To: References: <56F9A4F4.6040108@oracle.com> <5707E1E8.9060202@gmail.com> <5716b7c8.c8e4420a.f47c1.ffff9b05SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: <5cf23f12-3210-9466-07b1-bad98b6af59b@gmail.com> Hi Mark, I also agree to you. We had aimed to handle *traditional* zip encryption at first. However, we also want to handle *strong* zip encryption. (e.g. AES) As discussion in this mail thread, I'm sure that Java developers need this feature. So I want to move forward with this proposal. For example, I hope that JDK supports plugins to add encryption engines for zip archive. If JDK provides this enhancement, we are happy because we can focus to implement the zip encryption engine when we want another encryption algorithms. For that reason, I would like to propose a new JEP if it is appropriate. According to JEP 1 [1], OpenJDK committer can propose new JEP. If so, I will make a JEP in accordance with JEP 2 [2], and will send it to core-libs-dev for review. (I'm OpenJDK committer (ysuenaga), so I think I can send JEP request.) If you have better idea, I'm glad to hear your advice. Thanks, Yasumasa [1] http://openjdk.java.net/jeps/1 [2] http://openjdk.java.net/jeps/2 On 2016/04/25 17:49, KUBOTA Yuji wrote: > 2016-04-20 7:57 GMT+09:00 : >> I have to agree. I don't think it makes sense to add a known-vulnerable >> encryption algorithm to the JDK. It might work perfectly well for one >> use case but it will eventually be used by someone who doesn't take the >> time to understand it, assumes that it provides strong encryption when >> it doesn't, gets burned, and then blames Java. > > Yes, Mark. We never hope to make OpenJDK be blamed with our proposal. > > Mark, I am glad if you are interested in this proposal if using any strong > encryption algorithm like Sherman's implementation (AES encryption). > If so, we hope to continue discussion the better way to fill our needs > and given comments for improving OpenJDK. > > Thanks, > Yuji > From paul.sandoz at oracle.com Mon May 30 13:05:50 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 30 May 2016 15:05:50 +0200 Subject: RFR[9]: 8147585: Annotations with lambda expressions has parameters result in wrong behavior. In-Reply-To: <574BD6ED.70804@oracle.com> References: <574BD6ED.70804@oracle.com> Message-ID: <2C498716-8CF7-4F03-8B64-513C08207117@oracle.com> Hi Shilpi, You have found the right place but i am not sure your fix is entirely correct. (Tip: if you use -Xlog:exceptions=info you can observe the IAE exception when the annotation is processed) In your test you have: @Target(value = ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) @ interface LambdaWithParameter { Consumer f1 = a -> { System.out.println("lambda has parameter"); }; } @Target(value = ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) @ interface LambdaWithoutParameter { Runnable r = () -> System.out.println("lambda without parameter"); } Both of those annotations will have static synthetic methods generated by the compiler that the indy resolves and links to (look at the javap output). The former will have a method with one parameter. The code in sun/reflect/annotation/AnnotationType.java: for (Method method : methods) { if (method.getParameterTypes().length != 0) throw new IllegalArgumentException(method + " has params"); has thrown the IAE since 2004, but it?s not clear why it was added as opposed to something more general (see below). The correct fix appears to be to skip over any non-abstract/non-public methods. Thus only public abstract methods get processed. Your current fix now processes synthetic methods with parameters, in addition to those which were already processed such as synthetic methods without parameters, or even private methods that could have been generated by some tool. I dunno how much say the verifier has in all this, perhaps little or no say. Thus non-public/non-abstract methods could add inconsistent information to the data structures of AnnotationType. Perhaps this is mostly harmless? Perhaps Joel (CC?ed) can she some more light on this? Paul. > On 30 May 2016, at 08:00, shilpi.rastogi at oracle.com wrote: > > Hi All, > > Please review fix for https://bugs.openjdk.java.net/browse/JDK-8147585 > http://cr.openjdk.java.net/~srastogi/8147585/webrev.00/ > > Problem: Annotation with Lamda has parameters results into wrong behavior ( not considered as valid annotation) because > According to JLS "By virtue of the AnnotationTypeElementDeclaration production, a method declaration in an annotation type declaration cannot have formal parameters, type parameters, or a throws clause. The following production from ?4.3 is shown here for convenience:" > (Ref: https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.6.1) > > > Solution: We should skip synthetic methods during Annotation parsing. According to JLS "An annotation type has no elements other than those defined by the methods it explicitly declares." > (Ref https://docs.oracle.com/javase/specs/jls/se8/html/.html#jls-9jls-9.6.1) > > > Thanks, > Shilpi From andrey.x.nazarov at oracle.com Mon May 30 13:20:34 2016 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Mon, 30 May 2016 16:20:34 +0300 Subject: RFR: JDK-8157850 Jar tests should pass through VM options In-Reply-To: <758a2c4c-df6d-04dd-e581-4d267abc1c5d@oracle.com> References: <2da88f6b-b377-ac21-cc34-a0f2a1a566bf@oracle.com> <57460554.7080306@oracle.com> <57460E22.4060307@oracle.com> <758a2c4c-df6d-04dd-e581-4d267abc1c5d@oracle.com> Message-ID: <4dc84ac2-581b-1456-3abc-b6a5d2e9bf8b@oracle.com> Any updates, guys? --Andrey On 26.05.2016 19:20, Andrey Nazarov wrote: > Thanks for feedback guys. > > I've updated review > http://cr.openjdk.java.net/~anazarov/8157850/webrev.02/ > > Please sponsor this patch if you are OK. > > My use case is to run tests with different -Xms and -Xmx options. > Mostly due to I need to increase heap size to gather code coverage by > jcov. > > --Andrey > > On 25.05.2016 23:42, Jonathan Gibbons wrote: >> >> >> On 05/25/2016 01:33 PM, David Holmes wrote: >>> On 26/05/2016 6:04 AM, Jonathan Gibbons wrote: >>>> Using JAVA_OPTIONS for tools is conceptually wrong. >>>> >>>> JAVA_OPTIONS is specifically intended to pass options to VM instances, >>>> as created by a "java" command. It is not intended that you should >>>> prefix the options with -J and use them for arbitrary tools. >>> >>> I have to agree. There is no guarantee the options being passed for >>> the VM under test make any sense for the running of the jar tool in >>> the jar tests. I think a number of hotspot related test options >>> could cause problems here. >>> >>> Are there specific VM options that people think should be passed >>> through? The bug report has no detail at all. >>> >>> David >> >> Generally, I think that blindly passing through all the options >> regardless is as bad a programming practice as never passing them >> though. There are some that make sense to all VMs, like -ea, -esa >> etc, and maybe system properties, but for those, the VM options >> mechanism is generally good enough. (i.e. system properties >> test.vm.opts, test.tool.vm.opts) >> >> From a jtreg point of view, I'd be interested to know uses cases for >> passing additional more specific options to the VMs used to run tools >> like jar, jlink, javac, etc >> >> -- Jon. >> >> >> >>> >>>> The code in the webrev is also perverse for taking the trouble to >>>> split >>>> the string to a stream, collect the results into a list, convert the >>>> list back into a stream again and use .forEach. >>>> >>>> You could do better, and much simpler, with something like >>>> >>>> if (!option.isEmpty()) { >>>> commands.addAll(Arrays.asList(option.split("\\s+",-1))); >>>> } >>>> >>>> -- Jon >>>> >>>> >>>> On 05/25/2016 10:48 AM, Martin Buchholz wrote: >>>>> Hi Andrey, >>>>> >>>>> Looking at http://openjdk.java.net/jtreg/vmoptions.html, >>>>> I see we have both test.vm.opts and test.tool.vm.opts >>>>> and the latter is supposed to take care of adding "-J". >>>>> >>>>> + VM_OPTIONS.stream().map(opt -> "-J" + >>>>> opt).forEach(commands::add); >>>>> + JAVA_OPTIONS.stream().map(opt -> "-J" + >>>>> opt).forEach(commands::add); >>>>> >>>>> --- >>>>> >>>>> Maybe splitting on "\\s+" would be better. >>>>> >>>>> --- >>>>> >>>>> I think we should have test library methods to return the >>>>> List >>>>> for java subprocesses, one that could try hard to get the option >>>>> tokenization correct. >>>>> >>>>> --- >>>>> >>>>> >>>>> On Wed, May 25, 2016 at 9:07 AM, Andrey Nazarov >>>>> wrote: >>>>>> Some jar tests start VMs without passing vmoptions from jtreg. >>>>>> >>>>>> This fix pass jtreg's vmoptions and javaoptions to >>>>>> processes(java, jar, >>>>>> javac) started by tests. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~anazarov/8157850/webrev.01/ >>>>>> >>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8157850 >>>>>> >>>>>> --Andrey >>>>>> >>>> >> > From aleksej.efimov at oracle.com Mon May 30 17:14:04 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Mon, 30 May 2016 20:14:04 +0300 Subject: Review request JDK-8153944: wsimport and wsgen usage messages not printed In-Reply-To: References: <0E40526D-17C1-4E8E-B2D7-6099800A6965@oracle.com> <574600D5.5060306@oracle.com> Message-ID: <574C74DC.1090405@oracle.com> Hi Mandy, Looks good to me. Best Regards, Aleksej On 25/05/16 22:48, Mandy Chung wrote: >> On May 25, 2016, at 12:45 PM, Alan Bateman wrote: >> >> On 25/05/2016 20:29, Mandy Chung wrote: >>> wsgen and wsimport tools use the utility classes in java.xml.bind module to localize messages. Resource bundles are encapsulated in named modules and hence utility like com.sun.istack.internal.localization.LocalizableMessageFactory. >>> >>> The owner of the resource bundle should be the one loading ResourceBundle. The solution to this type of issue is to update the utility classes to accept a function to return ResourceBundle rather than by base name. Another alternative could do the localization locally within the module and this may not be applicable to JAX-WS since jdk.xml.ws is tightly coupled with java.xml.ws. >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153944/webrev.00 >>> >>> This patch touches quites a few files, one per supporting class to get messages from one resource bundle. The change is straight-forward and same pattern applies to each message file. >>> >> I don't know area but I looked at the changes and I get the gist of this. It would be good if Aleksej could review as he's the current connection to the upstream project that owns this code. >> > I mentioned this patch to Aleksej earlier. Aleksej - can you review this too? > > Mandy > From ramanand.patil at oracle.com Mon May 30 18:03:14 2016 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Mon, 30 May 2016 11:03:14 -0700 (PDT) Subject: RFR: 8151876: (tz) Support tzdata2016d In-Reply-To: References: <9b76a353-e477-4f59-b630-5185e9ce6c37@default> <5748494F.6060404@oracle.com> <12123364-e177-a744-7f24-68e4a8f87532@oracle.com> <57486210.7090205@oracle.com> Message-ID: <783f0b2f-43fb-40ed-9204-889b9a3c2570@default> Hi Masayoshi and All, ? Here is the updated Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.01/ ? As suggested by Masayoshi, I have kept the existing names unchanged. Also, this patch contains extra test case fixes for 1.?????? ?java/util/TimeZone/CheckDisplayNames.java 2.?????? java/util/TimeZone/Bug8149452.java The exclusion for the newly added TimeZones is added in these test cases where the entries are not present in the resources and the Short/Long display names fallback to the GMT?hh:mm format. ? ? Regards, Ramanand. ? From: Masayoshi Okutsu Sent: Saturday, May 28, 2016 10:58 AM To: Se?n Coffey; Ramanand Patil; i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Subject: Re: RFR: 8151876: (tz) Support tzdata2016d ? CLDR locale data defines time zone names, like this (in en.xml): ?????????????????????? ??????????????????????????????? ??????????????????????????????????????? Almaty Time ???????????????????????????????? ???????Almaty Standard Time ??????????????????????????????????????? Almaty Summer Time ??????????????????????????????? ??????????????????????? ? The CLDR converter tool tries to fill in the missing short names from the legacy TimeZoneNames data. Removing existing names causes some unexpected behavior. I think JDK-8157814 is an example of the unexpected behavior. And the suggested fix in JDK-8157814 looks to me like a workaround. I still think the existing names should be kept unchanged for this fix. Thanks, Masayoshi On 5/28/2016 12:04 AM, Se?n Coffey wrote: I guess there's a low risk of timezone not being identified if being parsed in through a formatter. Isn't such an approach discouraged though ? short IDs were already subject to change in tzdata releases. Ramanand found one issue by removal of these resource strings (so far) and that's captured in JDK-8157814 There's a decision to be made about how to use the GMT?hh:mm format for new releases given IANA's new short ID identifier mechanism. I think that could be discussed as a separate issue. I'd like to see us follow a similar approach to IANA and use GMT identifiers on new timezones and perhaps even consider using the IANA long name format also for the getDisplayName(..) calls that can be made. e.g. "Asia/Almaty" instead of "Alma-Ata Time" Regards, Sean. On 27/05/16 15:24, Masayoshi Okutsu wrote: This change seems to beyond my proposal that the "GMT?hh:mm" format is used for *new* zones with the "?hh" format. But this change removes *existing* zones which have changed to use the "?hh" format in tzdata. Can this cause any compatibility issues? And have we agreed to use the "GMT?hh:mm" format? Thanks, Masayoshi On 5/27/2016 10:19 PM, Se?n Coffey wrote: Looks fine to me Ramanand. the recent 2016d changes have introduced some boundary issues for JDK rule parsing and those issues can be followed up in separate issues like you say. Regards, Sean. On 26/05/16 14:22, Ramanand Patil wrote: HI all, Please review the latest TZDATA integration (tzdata2016d) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8151876 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erpatil/8151876/webrev.00/"http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/ Patch Contains: 1.?????? IANA tzdata2016d integration into JDK. [It also includes tzdata2016b and tzdata2016c which was not integrated]. 2.?????? "GMT[+ -]hh:mm" is used for formatting of the modified or newly added TimeZones in tzdata2016d. [This is done to accommodate the IANA's new system where the zones use numeric time zone abbreviations like "+04" instead of invented abbreviations like "ASTT".] 3.?????? Test case: java/time/test/java/time/format/TestZoneTextPrinterParser.java is updated to include the failures because of GMT[+ -]hh:mm format names. 4.?????? Few other failing tests: For few other failing tests, new linked bugs are created and will be addressed in a separate patch. Regards, Ramanand. ? ? ? ? From aph at redhat.com Mon May 30 20:17:56 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 30 May 2016 21:17:56 +0100 Subject: PING: RFR: JDK-4347142: Need method to set Password protection to Zip entries In-Reply-To: <5cf23f12-3210-9466-07b1-bad98b6af59b@gmail.com> References: <56F9A4F4.6040108@oracle.com> <5707E1E8.9060202@gmail.com> <5716b7c8.c8e4420a.f47c1.ffff9b05SMTPIN_ADDED_BROKEN@mx.google.com> <5cf23f12-3210-9466-07b1-bad98b6af59b@gmail.com> Message-ID: <574C9FF4.7090705@redhat.com> On 30/05/16 13:44, Yasumasa Suenaga wrote: > We had aimed to handle *traditional* zip encryption at first. > However, we also want to handle *strong* zip encryption. (e.g. AES) OpenJDK does not control the format of a zip file. To make such a change we'd have to negotiate with the other users of the .ZIP format. Andrew. From david.holmes at oracle.com Mon May 30 23:59:46 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 May 2016 09:59:46 +1000 Subject: RFR: JDK-8157850 Jar tests should pass through VM options In-Reply-To: <758a2c4c-df6d-04dd-e581-4d267abc1c5d@oracle.com> References: <2da88f6b-b377-ac21-cc34-a0f2a1a566bf@oracle.com> <57460554.7080306@oracle.com> <57460E22.4060307@oracle.com> <758a2c4c-df6d-04dd-e581-4d267abc1c5d@oracle.com> Message-ID: <3a06a763-56e0-22f1-69b7-24f388a8678f@oracle.com> On 27/05/2016 2:20 AM, Andrey Nazarov wrote: > Thanks for feedback guys. > > I've updated review http://cr.openjdk.java.net/~anazarov/8157850/webrev.02/ Using test.tool.vm.opts seems reasonable for jar and javac. > Please sponsor this patch if you are OK. Sorry not my area. Thanks, David > My use case is to run tests with different -Xms and -Xmx options. Mostly > due to I need to increase heap size to gather code coverage by jcov. > > --Andrey > > On 25.05.2016 23:42, Jonathan Gibbons wrote: >> >> >> On 05/25/2016 01:33 PM, David Holmes wrote: >>> On 26/05/2016 6:04 AM, Jonathan Gibbons wrote: >>>> Using JAVA_OPTIONS for tools is conceptually wrong. >>>> >>>> JAVA_OPTIONS is specifically intended to pass options to VM instances, >>>> as created by a "java" command. It is not intended that you should >>>> prefix the options with -J and use them for arbitrary tools. >>> >>> I have to agree. There is no guarantee the options being passed for >>> the VM under test make any sense for the running of the jar tool in >>> the jar tests. I think a number of hotspot related test options could >>> cause problems here. >>> >>> Are there specific VM options that people think should be passed >>> through? The bug report has no detail at all. >>> >>> David >> >> Generally, I think that blindly passing through all the options >> regardless is as bad a programming practice as never passing them >> though. There are some that make sense to all VMs, like -ea, -esa >> etc, and maybe system properties, but for those, the VM options >> mechanism is generally good enough. (i.e. system properties >> test.vm.opts, test.tool.vm.opts) >> >> From a jtreg point of view, I'd be interested to know uses cases for >> passing additional more specific options to the VMs used to run tools >> like jar, jlink, javac, etc >> >> -- Jon. >> >> >> >>> >>>> The code in the webrev is also perverse for taking the trouble to split >>>> the string to a stream, collect the results into a list, convert the >>>> list back into a stream again and use .forEach. >>>> >>>> You could do better, and much simpler, with something like >>>> >>>> if (!option.isEmpty()) { >>>> commands.addAll(Arrays.asList(option.split("\\s+",-1))); >>>> } >>>> >>>> -- Jon >>>> >>>> >>>> On 05/25/2016 10:48 AM, Martin Buchholz wrote: >>>>> Hi Andrey, >>>>> >>>>> Looking at http://openjdk.java.net/jtreg/vmoptions.html, >>>>> I see we have both test.vm.opts and test.tool.vm.opts >>>>> and the latter is supposed to take care of adding "-J". >>>>> >>>>> + VM_OPTIONS.stream().map(opt -> "-J" + >>>>> opt).forEach(commands::add); >>>>> + JAVA_OPTIONS.stream().map(opt -> "-J" + >>>>> opt).forEach(commands::add); >>>>> >>>>> --- >>>>> >>>>> Maybe splitting on "\\s+" would be better. >>>>> >>>>> --- >>>>> >>>>> I think we should have test library methods to return the List >>>>> for java subprocesses, one that could try hard to get the option >>>>> tokenization correct. >>>>> >>>>> --- >>>>> >>>>> >>>>> On Wed, May 25, 2016 at 9:07 AM, Andrey Nazarov >>>>> wrote: >>>>>> Some jar tests start VMs without passing vmoptions from jtreg. >>>>>> >>>>>> This fix pass jtreg's vmoptions and javaoptions to processes(java, >>>>>> jar, >>>>>> javac) started by tests. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~anazarov/8157850/webrev.01/ >>>>>> >>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8157850 >>>>>> >>>>>> --Andrey >>>>>> >>>> >> > From mandy.chung at oracle.com Tue May 31 02:59:01 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 30 May 2016 19:59:01 -0700 Subject: Review Request JDK-8152721: Java Web Start splash mechanism is not working in JDK9 In-Reply-To: <57492478.4030200@oracle.com> References: <73F0BDF7-51DB-486D-B9C3-EA89A0858B07@oracle.com> <57492478.4030200@oracle.com> Message-ID: <339A5D4A-AEC4-4F73-B5D6-A4268F7A00B9@oracle.com> > On May 27, 2016, at 9:54 PM, Alan Bateman wrote: > > On 28/05/2016 05:29, Mandy Chung wrote: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152721/webrev.00/ >> >> The launcher does not handle the new options with whitespace separated arguments properly. This patch applies that consistently in java.c I leave arg.c as is that Kumar/Henry can consider cleanup in the future. >> > The new options are handled correctly on the command, I think it's just the JDK internal JLI_Launch entry point where this was missed. The patch looks okay, I just wonder if there is there are any tests that could use this entry point. SelectVersion is called for launching any application. It processes -splash option separately from the launcher argument processing. To hit this bug, it will need to launch with the new module-system option together with -splash. I have verified with my modified version of a client test verifying the -splash option. I prefer to file a JBS issue for the client team to create a test for this if that?s okay with you. Mandy From Hiroshi.Ito at gs.com Tue May 31 03:36:18 2016 From: Hiroshi.Ito at gs.com (Ito, Hiroshi) Date: Tue, 31 May 2016 03:36:18 +0000 Subject: RFR: Implement RandomAccess spliterator Message-ID: Hi Paul, Thank you very much for your feedback, and apologize for the delay in response.. I have incorporated your comments in the attached patch. Please kindly take a look and let me know if you have further feedback. - Modified @implSpec to add a description in case the list implements RandomAccess. - Added modification checking in RandomAccessSpliterator, only when the list implements AbstractList. Sorry for the confusion about SubList. It was all about the concurrent modification checking, so adding the change above pretty much addressed my issue earlier. Thanks, Hiroshi -----Original Message----- From: Paul Sandoz [mailto:paul.sandoz at oracle.com] Sent: Thursday, May 12, 2016 8:46 PM To: Ito, Hiroshi [Tech] Cc: core-libs-dev at openjdk.java.net; Chan, Sunny [Tech]; Raab, Donald [Tech] Subject: Re: RFR: Implement RandomAccess spliterator Hi Hiroshi, This is a good example of what seems like a small feature and yet there are some unexpected complexities :-) We will need to refine the implementation specification of List.spliterator, which currently states: * @implSpec * The default implementation creates a * late-binding spliterator * from the list's {@code Iterator}. The spliterator inherits the * fail-fast properties of the list's iterator. Since the existing implementation is derived from the iterator: @Override default Spliterator spliterator() { return Spliterators.spliterator(this, Spliterator.ORDERED); } concurrent modification checking will occur. The RandomAccessSpliterator should also support modification checking, which i think requires it be an inner class to check co-mod state. I am struggling to understand the points you make about the spliterator of a sub-list of a Vector being required to be an iterator-based implementation. Since AbstractList.SubList can access a Vector's elements through List.get/set why cannot RandomAccessSpliterator? If we want to support random access spliterators on sub-lists i think we would anyway need to override the spliterator method to check for concurrent modification (as is the case of the iterator method). Paul. > On 11 May 2016, at 11:25, Ito, Hiroshi wrote: > > Hi, > > Please kindly review the attached patch for RandomAccessSpliterator implementation. > > Currently default implementation of spliterator is an IteratorSpliterator which is not optimal for RandomAccess data structures (besides ArrayList and Vector). This patch is to provide a default RandomAccessSpliterator implementation for RandomAccess data structure. > > The figures below demonstrate the performance difference before and after the change. Note the significant performance improvement in test SelectTest.parallel_lazy_streams_gsc (parallel streams performance test for non-JDK Lists that implement RandomAccess but don't yet implement their own spliterators). > > Benchmark code: https://github.com/goldmansachs/gs-collections/blob/master/jmh-tests/src/main/java/com/gs/collections/impl/jmh/SelectTest.java > > With IteratorSpliterator as default: > > Benchmark Mode Cnt Score Error Units > SelectTest.parallel_lazy_jdk thrpt 20 172.671 ? 14.231 ops/s > SelectTest.parallel_lazy_streams_gsc thrpt 20 20.662 ? 0.493 ops/s > SelectTest.serial_lazy_jdk thrpt 20 89.384 ? 4.431 ops/s > SelectTest.serial_lazy_streams_gsc thrpt 20 80.831 ? 7.875 ops/s > > With RandomAccessSpliterator as default: > > Benchmark Mode Cnt Score Error Units > SelectTest.parallel_lazy_jdk thrpt 20 174.190 ? 16.870 ops/s > SelectTest.parallel_lazy_streams_gsc thrpt 20 180.740 ? 9.594 ops/s > SelectTest.serial_lazy_jdk thrpt 20 85.719 ? 2.414 ops/s > SelectTest.serial_lazy_streams_gsc thrpt 20 78.760 ? 1.029 ops/s > > Majority of the patch is contributed by Paul Sandoz and he should be credited in the Contributed-by field. > > Along with this patch submission, we have a question for SubList spliterator implementation that we retained old behavior for now (i.e. return IteratorSpliterator, refer to RandomAccessSubList#spliterator()). We have found that Vector's subList is wrapped by RandomAccessSubList, that is RandomAccess but not a Vector anymore, and it expects to use IteratorSpliterator. We were not sure what's the best approach to distinguish Vector from other RandomAccess data structure within RandomAccessSublist, so we kept it return IteratorSpliterator for now. > > One approach could be to introduce VectorSubList that returns IteratorSpliterator (or an implementation similar to VectorSpliterator?). Then we could revert the spliterator() override in RandomAccessSublist. > > What would be your suggestion to handle this? > > Depending on your suggestion, we might fix the subList spliterator in this patch, or submit a separate patch if the amount of the change is significant. > > Thanks, > Hiroshi > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RandomAccessSpliterator_0531.patch.txt URL: From amaembo at gmail.com Tue May 31 04:44:35 2016 From: amaembo at gmail.com (Tagir F. Valeev) Date: Tue, 31 May 2016 10:44:35 +0600 Subject: RFR: Implement RandomAccess spliterator In-Reply-To: References: Message-ID: <1348820420.20160531104435@gmail.com> Hello! (disclaimer: I'm not an official reviewer) > ((AbstractList) lst).modCount; Raw-type casts should be replaced with AbstractList to avoid warning. > public RandomAccessSpliterator trySplit() Covariant return type seems to be unnecessary here as this spliterator is not public and covariant type is not used anywhere. On the other hand it generates a bridge method increasing class file size by ~100 bytes. I would prefer "public Spliterator trySplit()" here. > RandomAccessSpliterator(List list) { > this(list, 0, -1, list instanceof AbstractList ? ((AbstractList) list).modCount : 0); > assert list instanceof RandomAccess; > } I don't see why modCount is requested here from original list. Anyways it will be reinitialized in getFence(). It seems that using "this(list, 0, -1, 0)" would be just as fine. > for (; i < hi; ++i) { > @SuppressWarnings("unchecked") > E e = lst.get(i); > action.accept(e); > checkForComodification(mc); > } > return; For better performance ArrayList.spliterator() does not check for comodification on every iteration. I guess, here it's also possible to do this. Note that as lst.get() and especially action.accept() will unlikely to be inlined by JIT as such call sites are usually polymorphic in real applications. As a consequence, checkForComodification cannot be optimized to eliminate field load and instanceof check, so these operations will be performed on every iteration. forEachRemaining() implementation avoids this by storing field into local variable lst, but checkForComodification uses field, not local. Also note that AbstractList.subList().spliterator() should probably also be redefined (I guess, Paul already mentioned this). It should be linked to the original List, not to the subList to check comodification against the original list and also to reduce the indirection in .get() calls. I wonder if it's really necessary to go down to the List.spliterator(). Probably it would be ok to leave List.spliterator() as is, but redefine AbstractList.spliterator() only (so only implementations derived from AbstractList will benefit, but most of real-life lists extend AbstractList). This would eliminate those instanceof checks. With best regards, Tagir Valeev. IH> Hi Paul, IH> Thank you very much for your feedback, and apologize for the delay in response.. IH> I have incorporated your comments in the attached patch. Please IH> kindly take a look and let me know if you have further feedback. IH> - Modified @implSpec to add a description in case the list implements RandomAccess. IH> - Added modification checking in RandomAccessSpliterator, only IH> when the list implements AbstractList. IH> Sorry for the confusion about SubList. It was all about the IH> concurrent modification checking, so adding the change above IH> pretty much addressed my issue earlier. IH> Thanks, IH> Hiroshi IH> -----Original Message----- IH> From: Paul Sandoz [mailto:paul.sandoz at oracle.com] IH> Sent: Thursday, May 12, 2016 8:46 PM IH> To: Ito, Hiroshi [Tech] IH> Cc: core-libs-dev at openjdk.java.net; Chan, Sunny [Tech]; Raab, Donald [Tech] IH> Subject: Re: RFR: Implement RandomAccess spliterator IH> Hi Hiroshi, IH> This is a good example of what seems like a small feature and yet IH> there are some unexpected complexities :-) IH> We will need to refine the implementation specification of IH> List.spliterator, which currently states: IH> * @implSpec IH> * The default implementation creates a IH> * late-binding spliterator IH> * from the list's {@code Iterator}. The spliterator inherits the IH> * fail-fast properties of the list's iterator. IH> Since the existing implementation is derived from the iterator: IH> @Override IH> default Spliterator spliterator() { IH> return Spliterators.spliterator(this, Spliterator.ORDERED); IH> } IH> concurrent modification checking will occur. The IH> RandomAccessSpliterator should also support modification checking, IH> which i think requires it be an inner class to check co-mod state. IH> I am struggling to understand the points you make about the IH> spliterator of a sub-list of a Vector being required to be an IH> iterator-based implementation. Since AbstractList.SubList can IH> access a Vector's elements through List.get/set why cannot RandomAccessSpliterator? IH> If we want to support random access spliterators on sub-lists i IH> think we would anyway need to override the spliterator method to IH> check for concurrent modification (as is the case of the iterator method). IH> Paul. >> On 11 May 2016, at 11:25, Ito, Hiroshi wrote: >> >> Hi, >> >> Please kindly review the attached patch for RandomAccessSpliterator implementation. >> >> Currently default implementation of spliterator is an IteratorSpliterator which is not optimal for RandomAccess data structures (besides ArrayList and Vector). This patch is to provide a default RandomAccessSpliterator implementation for RandomAccess data structure. >> >> The figures below demonstrate the performance difference before and after the change. Note the significant performance improvement in test SelectTest.parallel_lazy_streams_gsc (parallel streams performance test for non-JDK Lists that implement RandomAccess but don't yet implement their own spliterators). >> >> Benchmark code: https://github.com/goldmansachs/gs-collections/blob/master/jmh-tests/src/main/java/com/gs/collections/impl/jmh/SelectTest.java >> >> With IteratorSpliterator as default: >> >> Benchmark Mode Cnt Score Error Units >> SelectTest.parallel_lazy_jdk thrpt 20 172.671 ? 14.231 ops/s >> SelectTest.parallel_lazy_streams_gsc thrpt 20 20.662 ? 0.493 ops/s >> SelectTest.serial_lazy_jdk thrpt 20 89.384 ? 4.431 ops/s >> SelectTest.serial_lazy_streams_gsc thrpt 20 80.831 ? 7.875 ops/s >> >> With RandomAccessSpliterator as default: >> >> Benchmark Mode Cnt Score Error Units >> SelectTest.parallel_lazy_jdk thrpt 20 174.190 ? 16.870 ops/s >> SelectTest.parallel_lazy_streams_gsc thrpt 20 180.740 ? 9.594 ops/s >> SelectTest.serial_lazy_jdk thrpt 20 85.719 ? 2.414 ops/s >> SelectTest.serial_lazy_streams_gsc thrpt 20 78.760 ? 1.029 ops/s >> >> Majority of the patch is contributed by Paul Sandoz and he should be credited in the Contributed-by field. >> >> Along with this patch submission, we have a question for SubList spliterator implementation that we retained old behavior for now (i.e. return IteratorSpliterator, refer to RandomAccessSubList#spliterator()). We have found that Vector's subList is wrapped by RandomAccessSubList, that is RandomAccess but not a Vector anymore, and it expects to use IteratorSpliterator. We were not sure what's the best approach to distinguish Vector from other RandomAccess data structure within RandomAccessSublist, so we kept it return IteratorSpliterator for now. >> >> One approach could be to introduce VectorSubList that returns IteratorSpliterator (or an implementation similar to VectorSpliterator?). Then we could revert the spliterator() override in RandomAccessSublist. >> >> What would be your suggestion to handle this? >> >> Depending on your suggestion, we might fix the subList spliterator in this patch, or submit a separate patch if the amount of the change is significant. >> >> Thanks, >> Hiroshi >> From xueming.shen at oracle.com Tue May 31 05:07:25 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 30 May 2016 22:07:25 -0700 Subject: RFR: JDK-8061777, , (zipfs) IllegalArgumentException in ZipCoder.toString when using Shitft_JIS In-Reply-To: <237367AB-CD71-4C9B-91F5-B5F4E0557FD1@oracle.com> References: <5748B056.3090903@oracle.com> <237367AB-CD71-4C9B-91F5-B5F4E0557FD1@oracle.com> Message-ID: Thanks Paul, updated accordingly. http://cr.openjdk.java.net/~sherman/8061777/webrev -sherman On 5/30/16 2:31 AM, Paul Sandoz wrote: > Hi Sherman, > > Do you consider modifying the new ZipPath constructor you added to accept a boolean value for UTF-8 encoding? > > If so you can more clearly document the behaviour and avoid duplication of the operators in ZipFileSystem e.g.: > > return new ZipPath(this, first, zc.isUTF8()); > > Paul. > >> On 27 May 2016, at 22:38, Xueming Shen wrote: >> >> Hi, >> >> Please help review the change for JDK-8061777. >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8061777 >> webrev: http://cr.openjdk.java.net/~sherman/8061777 >> >> Cause: ZipPath/ZipFileSystem uses byte[] as the internal underlying storage for >> entry names (for better performance, as the "name" is stored as bytes inside >> the zip/jar file, it is desirable to avoid the redundant String<->byte[] conversion, >> if possible). With this design, it is natural to also work on byte[] directly for those >> "path" operations, including the "normalization", which mainly is to remove the >> redundant "/" and switch the "\" to "/". This appears to be a problem for non-utf8 >> encoded zip file (utf8 is the default encoding used to de/encode the entry name >> for the Java jar/zip APIs), especially those double-byte encodings that have 0x5c >> ('\') as one of the double-byte bytes. The 0x5c byte will be mistakenly normalized >> to '\' if we normalize on the byte[] directly. The proposed change here is to >> normalize on the "String" to avoid this problem. Given the fact that Java jar/zip >> is specified to use utf-8 by default, to avoid the potential performance risk/cost >> for most of the zip/jar files (if we switch completely to the String based operation) >> the utf-8/byte[] path is still being used (as the default) when the encoding is utf-8. >> The implementation only switches to "String based" code path when the encoding >> is specifically specified as "non-utf8", which should be rare. >> >> Thanks, >> Sherman From Hiroshi.Ito at gs.com Tue May 31 05:11:38 2016 From: Hiroshi.Ito at gs.com (Ito, Hiroshi) Date: Tue, 31 May 2016 05:11:38 +0000 Subject: RFR: Implement RandomAccess spliterator In-Reply-To: <1348820420.20160531104435@gmail.com> References: <1348820420.20160531104435@gmail.com> Message-ID: <83e20d94fa614f87ba0ea7f2dcf8af3e@gsdghkp03etn2.firmwide.corp.gs.com> Thanks for your feedback! While I look into other feedback, one quick reply to this: > I wonder if it's really necessary to go down to the List.spliterator(). Probably it would be ok to leave List.spliterator() as is, but redefine AbstractList.spliterator() only (so only implementations derived from AbstractList will benefit, but most of real-life lists extend AbstractList). This would eliminate those instanceof checks. This needs to be done in List.spliterator() as the partciular use case we have is a List that doesn't extend AbstractList (code example below). https://github.com/eclipse/eclipse-collections/blob/master/eclipse-collections/src/main/java/org/eclipse/collections/impl/list/mutable/FastList.java Thanks, Hiroshi -----Original Message----- From: Tagir F. Valeev [mailto:amaembo at gmail.com] Sent: Tuesday, May 31, 2016 1:45 PM To: Ito, Hiroshi [Tech]; Paul Sandoz Cc: Raab, Donald [Tech]; core-libs-dev at openjdk.java.net; Chan, Sunny [Tech] Subject: Re: RFR: Implement RandomAccess spliterator Hello! (disclaimer: I'm not an official reviewer) > ((AbstractList) lst).modCount; Raw-type casts should be replaced with AbstractList to avoid warning. > public RandomAccessSpliterator trySplit() Covariant return type seems to be unnecessary here as this spliterator is not public and covariant type is not used anywhere. On the other hand it generates a bridge method increasing class file size by ~100 bytes. I would prefer "public Spliterator trySplit()" here. > RandomAccessSpliterator(List list) { > this(list, 0, -1, list instanceof AbstractList ? ((AbstractList) list).modCount : 0); > assert list instanceof RandomAccess; } I don't see why modCount is requested here from original list. Anyways it will be reinitialized in getFence(). It seems that using "this(list, 0, -1, 0)" would be just as fine. > for (; i < hi; ++i) { > @SuppressWarnings("unchecked") > E e = lst.get(i); > action.accept(e); > checkForComodification(mc); > } > return; For better performance ArrayList.spliterator() does not check for comodification on every iteration. I guess, here it's also possible to do this. Note that as lst.get() and especially action.accept() will unlikely to be inlined by JIT as such call sites are usually polymorphic in real applications. As a consequence, checkForComodification cannot be optimized to eliminate field load and instanceof check, so these operations will be performed on every iteration. forEachRemaining() implementation avoids this by storing field into local variable lst, but checkForComodification uses field, not local. Also note that AbstractList.subList().spliterator() should probably also be redefined (I guess, Paul already mentioned this). It should be linked to the original List, not to the subList to check comodification against the original list and also to reduce the indirection in .get() calls. I wonder if it's really necessary to go down to the List.spliterator(). Probably it would be ok to leave List.spliterator() as is, but redefine AbstractList.spliterator() only (so only implementations derived from AbstractList will benefit, but most of real-life lists extend AbstractList). This would eliminate those instanceof checks. With best regards, Tagir Valeev. IH> Hi Paul, IH> Thank you very much for your feedback, and apologize for the delay in response.. IH> I have incorporated your comments in the attached patch. Please IH> kindly take a look and let me know if you have further feedback. IH> - Modified @implSpec to add a description in case the list implements RandomAccess. IH> - Added modification checking in RandomAccessSpliterator, only when IH> the list implements AbstractList. IH> Sorry for the confusion about SubList. It was all about the IH> concurrent modification checking, so adding the change above pretty IH> much addressed my issue earlier. IH> Thanks, IH> Hiroshi IH> -----Original Message----- IH> From: Paul Sandoz [mailto:paul.sandoz at oracle.com] IH> Sent: Thursday, May 12, 2016 8:46 PM IH> To: Ito, Hiroshi [Tech] IH> Cc: core-libs-dev at openjdk.java.net; Chan, Sunny [Tech]; Raab, Donald IH> [Tech] IH> Subject: Re: RFR: Implement RandomAccess spliterator IH> Hi Hiroshi, IH> This is a good example of what seems like a small feature and yet IH> there are some unexpected complexities :-) IH> We will need to refine the implementation specification of IH> List.spliterator, which currently states: IH> * @implSpec IH> * The default implementation creates a IH> * late-binding IH> spliterator IH> * from the list's {@code Iterator}. The spliterator inherits the IH> * fail-fast properties of the list's iterator. IH> Since the existing implementation is derived from the iterator: IH> @Override IH> default Spliterator spliterator() { IH> return Spliterators.spliterator(this, Spliterator.ORDERED); IH> } IH> concurrent modification checking will occur. The IH> RandomAccessSpliterator should also support modification checking, IH> which i think requires it be an inner class to check co-mod state. IH> I am struggling to understand the points you make about the IH> spliterator of a sub-list of a Vector being required to be an IH> iterator-based implementation. Since AbstractList.SubList can access IH> a Vector's elements through List.get/set why cannot RandomAccessSpliterator? IH> If we want to support random access spliterators on sub-lists i IH> think we would anyway need to override the spliterator method to IH> check for concurrent modification (as is the case of the iterator method). IH> Paul. >> On 11 May 2016, at 11:25, Ito, Hiroshi wrote: >> >> Hi, >> >> Please kindly review the attached patch for RandomAccessSpliterator implementation. >> >> Currently default implementation of spliterator is an IteratorSpliterator which is not optimal for RandomAccess data structures (besides ArrayList and Vector). This patch is to provide a default RandomAccessSpliterator implementation for RandomAccess data structure. >> >> The figures below demonstrate the performance difference before and after the change. Note the significant performance improvement in test SelectTest.parallel_lazy_streams_gsc (parallel streams performance test for non-JDK Lists that implement RandomAccess but don't yet implement their own spliterators). >> >> Benchmark code: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_goldm >> ansachs_gs-2Dcollections_blob_master_jmh-2Dtests_src_main_java_com_gs >> _collections_impl_jmh_SelectTest.java&d=CwIDAw&c=7563p3e2zaQw0AB1wrFV >> gyagb2IE5rTZOYPxLxfZlX4&r=VPf6N-bfLPGZK6y8EINpNH-yzIbvHVyPq7pd9K2ZmWU >> &m=xwrjbGjxiPZsTHK8ertu4z2d_OlvBThrjZLWNGPXVeY&s=DFU5c5DqPw66D7n_0iYd >> 9nef2a3g5kzNnOtEnsWZ2YY&e= >> >> With IteratorSpliterator as default: >> >> Benchmark Mode Cnt Score Error Units >> SelectTest.parallel_lazy_jdk thrpt 20 172.671 ? 14.231 ops/s >> SelectTest.parallel_lazy_streams_gsc thrpt 20 20.662 ? 0.493 ops/s >> SelectTest.serial_lazy_jdk thrpt 20 89.384 ? 4.431 ops/s >> SelectTest.serial_lazy_streams_gsc thrpt 20 80.831 ? 7.875 ops/s >> >> With RandomAccessSpliterator as default: >> >> Benchmark Mode Cnt Score Error Units >> SelectTest.parallel_lazy_jdk thrpt 20 174.190 ? 16.870 ops/s >> SelectTest.parallel_lazy_streams_gsc thrpt 20 180.740 ? 9.594 ops/s >> SelectTest.serial_lazy_jdk thrpt 20 85.719 ? 2.414 ops/s >> SelectTest.serial_lazy_streams_gsc thrpt 20 78.760 ? 1.029 ops/s >> >> Majority of the patch is contributed by Paul Sandoz and he should be credited in the Contributed-by field. >> >> Along with this patch submission, we have a question for SubList spliterator implementation that we retained old behavior for now (i.e. return IteratorSpliterator, refer to RandomAccessSubList#spliterator()). We have found that Vector's subList is wrapped by RandomAccessSubList, that is RandomAccess but not a Vector anymore, and it expects to use IteratorSpliterator. We were not sure what's the best approach to distinguish Vector from other RandomAccess data structure within RandomAccessSublist, so we kept it return IteratorSpliterator for now. >> >> One approach could be to introduce VectorSubList that returns IteratorSpliterator (or an implementation similar to VectorSpliterator?). Then we could revert the spliterator() override in RandomAccessSublist. >> >> What would be your suggestion to handle this? >> >> Depending on your suggestion, we might fix the subList spliterator in this patch, or submit a separate patch if the amount of the change is significant. >> >> Thanks, >> Hiroshi >> From Alan.Bateman at oracle.com Tue May 31 05:56:02 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 31 May 2016 06:56:02 +0100 Subject: Review Request JDK-8152721: Java Web Start splash mechanism is not working in JDK9 In-Reply-To: <339A5D4A-AEC4-4F73-B5D6-A4268F7A00B9@oracle.com> References: <73F0BDF7-51DB-486D-B9C3-EA89A0858B07@oracle.com> <57492478.4030200@oracle.com> <339A5D4A-AEC4-4F73-B5D6-A4268F7A00B9@oracle.com> Message-ID: <574D2772.3040506@oracle.com> On 31/05/2016 03:59, Mandy Chung wrote: > SelectVersion is called for launching any application. It processes -splash option separately from the launcher argument processing. To hit this bug, it will need to launch with the new module-system option together with -splash. I have verified with my modified version of a client test verifying the -splash option. > > I prefer to file a JBS issue for the client team to create a test for this if that?s okay with you. > That should be okay as we should have tests for this option. -Alan From masayoshi.okutsu at oracle.com Tue May 31 06:06:40 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 31 May 2016 15:06:40 +0900 Subject: RFR: 8151876: (tz) Support tzdata2016d In-Reply-To: <783f0b2f-43fb-40ed-9204-889b9a3c2570@default> References: <9b76a353-e477-4f59-b630-5185e9ce6c37@default> <5748494F.6060404@oracle.com> <12123364-e177-a744-7f24-68e4a8f87532@oracle.com> <57486210.7090205@oracle.com> <783f0b2f-43fb-40ed-9204-889b9a3c2570@default> Message-ID: The CheckDisplayNames.java change is different from what I suggested and doesn't make sense. But we no longer need the test. I'd suggest CheckDisplayNames.java be removed. Otherwise, the fix looks OK to me. Masayoshi On 5/31/2016 3:03 AM, Ramanand Patil wrote: > > Hi Masayoshi and All, > > Here is the updated Webrev: > http://cr.openjdk.java.net/~rpatil/8151876/webrev.01/ > > > As suggested by Masayoshi, I have kept the existing names unchanged. > > > Also, this patch contains extra test case fixes for > > > 1./java/util/TimeZone/CheckDisplayNames.java/ > > > 2.java/util/TimeZone/Bug8149452.java > > The exclusion for the *newly* added TimeZones is added in these test > cases where the entries are not present in the resources and the > Short/Long display names fallback to the GMT?hh:mm format. > > Regards, > > Ramanand. > > *From:*Masayoshi Okutsu > *Sent:* Saturday, May 28, 2016 10:58 AM > *To:* Se?n Coffey; Ramanand Patil; i18n-dev at openjdk.java.net; > core-libs-dev at openjdk.java.net > *Subject:* Re: RFR: 8151876: (tz) Support tzdata2016d > > CLDR locale data defines time zone names, like this (in en.xml): > > > > Almaty Time > Almaty Standard Time > Almaty Summer Time > > > > The CLDR converter tool tries to fill in the missing short names from > the legacy TimeZoneNames data. Removing existing names causes some > unexpected behavior. I think JDK-8157814 is an example of the > unexpected behavior. And the suggested fix in JDK-8157814 looks to me > like a workaround. > > I still think the existing names should be kept unchanged for this fix. > > Thanks, > Masayoshi > > On 5/28/2016 12:04 AM, Se?n Coffey wrote: > > I guess there's a low risk of timezone not being identified if > being parsed in through a formatter. Isn't such an approach > discouraged though ? short IDs were already subject to change in > tzdata releases. Ramanand found one issue by removal of these > resource strings (so far) and that's captured in JDK-8157814 > > There's a decision to be made about how to use the GMT?hh:mm > format for new releases given IANA's new short ID identifier > mechanism. I think that could be discussed as a separate issue. > I'd like to see us follow a similar approach to IANA and use GMT > identifiers on new timezones and perhaps even consider using the > IANA long name format also for the getDisplayName(..) calls that > can be made. e.g. "Asia/Almaty" instead of "Alma-Ata Time" > > Regards, > > Sean. > > On 27/05/16 15:24, Masayoshi Okutsu wrote: > > This change seems to beyond my proposal that the "GMT?hh:mm" > format is used for *new* zones with the "?hh" format. But this > change removes *existing* zones which have changed to use the > "?hh" format in tzdata. Can this cause any compatibility issues? > > And have we agreed to use the "GMT?hh:mm" format? > > Thanks, > Masayoshi > > > On 5/27/2016 10:19 PM, Se?n Coffey wrote: > > Looks fine to me Ramanand. the recent 2016d changes have > introduced some boundary issues for JDK rule parsing and those > issues can be followed up in separate issues like you say. > > Regards, > Sean. > > On 26/05/16 14:22, Ramanand Patil wrote: > > HI all, > > Please review the latest TZDATA integration (tzdata2016d) to > JDK9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151876 > > Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/ > > > Patch Contains: > > 1. IANA tzdata2016d integration into JDK. [It also > includes tzdata2016b and tzdata2016c which was not integrated]. > > 2. "GMT[+ -]hh:mm" is used for formatting of the > modified or newly added TimeZones in tzdata2016d. > > [This is done to accommodate the IANA's new system where the > zones use numeric time zone abbreviations like "+04" instead > of invented abbreviations like "ASTT".] > > 3. Test case: > java/time/test/java/time/format/TestZoneTextPrinterParser.java > is updated to include the failures because of GMT[+ -]hh:mm > format names. > > 4. Few other failing tests: For few other failing tests, > new linked bugs are created and will be addressed in a > separate patch. > > > Regards, > > Ramanand. > From Hiroshi.Ito at gs.com Tue May 31 06:13:54 2016 From: Hiroshi.Ito at gs.com (Ito, Hiroshi) Date: Tue, 31 May 2016 06:13:54 +0000 Subject: RFR: Implement RandomAccess spliterator In-Reply-To: <1348820420.20160531104435@gmail.com> References: <1348820420.20160531104435@gmail.com> Message-ID: This is an interesting problem. > > for (; i < hi; ++i) { > > @SuppressWarnings("unchecked") > > E e = lst.get(i); > > action.accept(e); > > checkForComodification(mc); > > } > > return; > > For better performance ArrayList.spliterator() does not check for comodification on every iteration. I guess, here it's also possible to do this. Note that as lst.get() and especially action.accept() will unlikely to be inlined by JIT as such call sites are usually polymorphic in real applications. As a consequence, checkForComodification cannot be optimized to eliminate field load and instanceof check, so these operations will be performed on every iteration. forEachRemaining() implementation avoids this by storing field into local variable lst, but checkForComodification uses field, not local. The challenge here is that, unless we check comodification for every iteration, list.get(i) can throw IndexOutOfBoundsException when commodification (e.g. remove()) happens. That's what I faced in SpliteratorLateBindingFailFastTest. ArrayList can avoid this by leveraging its backing array. We don't have access to underlying data structure for generic List/AbstractList, so it's challenging to take similar approach. Appreciate any advice to address this! As for JIT optimization, would it help if checkForComodification() method takes a list as a parameter intead of always using field list, and we pass local variable lst within forEachRemaining() method? Thanks, Hiroshi -----Original Message----- From: Tagir F. Valeev [mailto:amaembo at gmail.com] Sent: Tuesday, May 31, 2016 1:45 PM To: Ito, Hiroshi [Tech]; Paul Sandoz Cc: Raab, Donald [Tech]; core-libs-dev at openjdk.java.net; Chan, Sunny [Tech] Subject: Re: RFR: Implement RandomAccess spliterator Hello! (disclaimer: I'm not an official reviewer) > ((AbstractList) lst).modCount; Raw-type casts should be replaced with AbstractList to avoid warning. > public RandomAccessSpliterator trySplit() Covariant return type seems to be unnecessary here as this spliterator is not public and covariant type is not used anywhere. On the other hand it generates a bridge method increasing class file size by ~100 bytes. I would prefer "public Spliterator trySplit()" here. > RandomAccessSpliterator(List list) { > this(list, 0, -1, list instanceof AbstractList ? ((AbstractList) list).modCount : 0); > assert list instanceof RandomAccess; } I don't see why modCount is requested here from original list. Anyways it will be reinitialized in getFence(). It seems that using "this(list, 0, -1, 0)" would be just as fine. > for (; i < hi; ++i) { > @SuppressWarnings("unchecked") > E e = lst.get(i); > action.accept(e); > checkForComodification(mc); > } > return; For better performance ArrayList.spliterator() does not check for comodification on every iteration. I guess, here it's also possible to do this. Note that as lst.get() and especially action.accept() will unlikely to be inlined by JIT as such call sites are usually polymorphic in real applications. As a consequence, checkForComodification cannot be optimized to eliminate field load and instanceof check, so these operations will be performed on every iteration. forEachRemaining() implementation avoids this by storing field into local variable lst, but checkForComodification uses field, not local. Also note that AbstractList.subList().spliterator() should probably also be redefined (I guess, Paul already mentioned this). It should be linked to the original List, not to the subList to check comodification against the original list and also to reduce the indirection in .get() calls. I wonder if it's really necessary to go down to the List.spliterator(). Probably it would be ok to leave List.spliterator() as is, but redefine AbstractList.spliterator() only (so only implementations derived from AbstractList will benefit, but most of real-life lists extend AbstractList). This would eliminate those instanceof checks. With best regards, Tagir Valeev. IH> Hi Paul, IH> Thank you very much for your feedback, and apologize for the delay in response.. IH> I have incorporated your comments in the attached patch. Please IH> kindly take a look and let me know if you have further feedback. IH> - Modified @implSpec to add a description in case the list implements RandomAccess. IH> - Added modification checking in RandomAccessSpliterator, only when IH> the list implements AbstractList. IH> Sorry for the confusion about SubList. It was all about the IH> concurrent modification checking, so adding the change above pretty IH> much addressed my issue earlier. IH> Thanks, IH> Hiroshi IH> -----Original Message----- IH> From: Paul Sandoz [mailto:paul.sandoz at oracle.com] IH> Sent: Thursday, May 12, 2016 8:46 PM IH> To: Ito, Hiroshi [Tech] IH> Cc: core-libs-dev at openjdk.java.net; Chan, Sunny [Tech]; Raab, Donald IH> [Tech] IH> Subject: Re: RFR: Implement RandomAccess spliterator IH> Hi Hiroshi, IH> This is a good example of what seems like a small feature and yet IH> there are some unexpected complexities :-) IH> We will need to refine the implementation specification of IH> List.spliterator, which currently states: IH> * @implSpec IH> * The default implementation creates a IH> * late-binding IH> spliterator IH> * from the list's {@code Iterator}. The spliterator inherits the IH> * fail-fast properties of the list's iterator. IH> Since the existing implementation is derived from the iterator: IH> @Override IH> default Spliterator spliterator() { IH> return Spliterators.spliterator(this, Spliterator.ORDERED); IH> } IH> concurrent modification checking will occur. The IH> RandomAccessSpliterator should also support modification checking, IH> which i think requires it be an inner class to check co-mod state. IH> I am struggling to understand the points you make about the IH> spliterator of a sub-list of a Vector being required to be an IH> iterator-based implementation. Since AbstractList.SubList can access IH> a Vector's elements through List.get/set why cannot RandomAccessSpliterator? IH> If we want to support random access spliterators on sub-lists i IH> think we would anyway need to override the spliterator method to IH> check for concurrent modification (as is the case of the iterator method). IH> Paul. >> On 11 May 2016, at 11:25, Ito, Hiroshi wrote: >> >> Hi, >> >> Please kindly review the attached patch for RandomAccessSpliterator implementation. >> >> Currently default implementation of spliterator is an IteratorSpliterator which is not optimal for RandomAccess data structures (besides ArrayList and Vector). This patch is to provide a default RandomAccessSpliterator implementation for RandomAccess data structure. >> >> The figures below demonstrate the performance difference before and after the change. Note the significant performance improvement in test SelectTest.parallel_lazy_streams_gsc (parallel streams performance test for non-JDK Lists that implement RandomAccess but don't yet implement their own spliterators). >> >> Benchmark code: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_goldm >> ansachs_gs-2Dcollections_blob_master_jmh-2Dtests_src_main_java_com_gs >> _collections_impl_jmh_SelectTest.java&d=CwIDAw&c=7563p3e2zaQw0AB1wrFV >> gyagb2IE5rTZOYPxLxfZlX4&r=VPf6N-bfLPGZK6y8EINpNH-yzIbvHVyPq7pd9K2ZmWU >> &m=xwrjbGjxiPZsTHK8ertu4z2d_OlvBThrjZLWNGPXVeY&s=DFU5c5DqPw66D7n_0iYd >> 9nef2a3g5kzNnOtEnsWZ2YY&e= >> >> With IteratorSpliterator as default: >> >> Benchmark Mode Cnt Score Error Units >> SelectTest.parallel_lazy_jdk thrpt 20 172.671 ? 14.231 ops/s >> SelectTest.parallel_lazy_streams_gsc thrpt 20 20.662 ? 0.493 ops/s >> SelectTest.serial_lazy_jdk thrpt 20 89.384 ? 4.431 ops/s >> SelectTest.serial_lazy_streams_gsc thrpt 20 80.831 ? 7.875 ops/s >> >> With RandomAccessSpliterator as default: >> >> Benchmark Mode Cnt Score Error Units >> SelectTest.parallel_lazy_jdk thrpt 20 174.190 ? 16.870 ops/s >> SelectTest.parallel_lazy_streams_gsc thrpt 20 180.740 ? 9.594 ops/s >> SelectTest.serial_lazy_jdk thrpt 20 85.719 ? 2.414 ops/s >> SelectTest.serial_lazy_streams_gsc thrpt 20 78.760 ? 1.029 ops/s >> >> Majority of the patch is contributed by Paul Sandoz and he should be credited in the Contributed-by field. >> >> Along with this patch submission, we have a question for SubList spliterator implementation that we retained old behavior for now (i.e. return IteratorSpliterator, refer to RandomAccessSubList#spliterator()). We have found that Vector's subList is wrapped by RandomAccessSubList, that is RandomAccess but not a Vector anymore, and it expects to use IteratorSpliterator. We were not sure what's the best approach to distinguish Vector from other RandomAccess data structure within RandomAccessSublist, so we kept it return IteratorSpliterator for now. >> >> One approach could be to introduce VectorSubList that returns IteratorSpliterator (or an implementation similar to VectorSpliterator?). Then we could revert the spliterator() override in RandomAccessSublist. >> >> What would be your suggestion to handle this? >> >> Depending on your suggestion, we might fix the subList spliterator in this patch, or submit a separate patch if the amount of the change is significant. >> >> Thanks, >> Hiroshi >> From shilpi.rastogi at oracle.com Tue May 31 08:35:27 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Tue, 31 May 2016 14:05:27 +0530 Subject: RFR[9]: 8147585: Annotations with lambda expressions has parameters result in wrong behavior. In-Reply-To: <2C498716-8CF7-4F03-8B64-513C08207117@oracle.com> References: <574BD6ED.70804@oracle.com> <2C498716-8CF7-4F03-8B64-513C08207117@oracle.com> Message-ID: <574D4CCF.5040606@oracle.com> Thanks Paul for comments. Please see http://cr.openjdk.java.net/~srastogi/8147585/webrev.01/ Now processing only public abstract methods of interface. Thanks, Shilpi On 5/30/2016 6:35 PM, Paul Sandoz wrote: > Hi Shilpi, > > You have found the right place but i am not sure your fix is entirely correct. > > (Tip: if you use -Xlog:exceptions=info you can observe the IAE exception when the annotation is processed) > > In your test you have: > > @Target(value = ElementType.METHOD) > @Retention(RetentionPolicy.RUNTIME) > @ interface LambdaWithParameter { > Consumer f1 = a -> { > System.out.println("lambda has parameter"); > }; > } > > @Target(value = ElementType.METHOD) > @Retention(RetentionPolicy.RUNTIME) > @ interface LambdaWithoutParameter { > Runnable r = () -> System.out.println("lambda without parameter"); > } > > > Both of those annotations will have static synthetic methods generated by the compiler that the indy resolves and links to (look at the javap output). The former will have a method with one parameter. > > > The code in sun/reflect/annotation/AnnotationType.java: > > for (Method method : methods) { > if (method.getParameterTypes().length != 0) > throw new IllegalArgumentException(method + " has params"); > > has thrown the IAE since 2004, but it?s not clear why it was added as opposed to something more general (see below). > > > The correct fix appears to be to skip over any non-abstract/non-public methods. Thus only public abstract methods get processed. > > Your current fix now processes synthetic methods with parameters, in addition to those which were already processed such as synthetic methods without parameters, or even private methods that could have been generated by some tool. I dunno how much say the verifier has in all this, perhaps little or no say. > > Thus non-public/non-abstract methods could add inconsistent information to the data structures of AnnotationType. Perhaps this is mostly harmless? > > Perhaps Joel (CC?ed) can she some more light on this? > > Paul. > > >> On 30 May 2016, at 08:00, shilpi.rastogi at oracle.com wrote: >> >> Hi All, >> >> Please review fix for https://bugs.openjdk.java.net/browse/JDK-8147585 >> http://cr.openjdk.java.net/~srastogi/8147585/webrev.00/ >> >> Problem: Annotation with Lamda has parameters results into wrong behavior ( not considered as valid annotation) because >> According to JLS "By virtue of the AnnotationTypeElementDeclaration production, a method declaration in an annotation type declaration cannot have formal parameters, type parameters, or a throws clause. The following production from ?4.3 is shown here for convenience:" >> (Ref: https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.6.1) >> >> >> Solution: We should skip synthetic methods during Annotation parsing. According to JLS "An annotation type has no elements other than those defined by the methods it explicitly declares." >> (Ref https://docs.oracle.com/javase/specs/jls/se8/html/.html#jls-9jls-9.6.1) >> >> >> Thanks, >> Shilpi From paul.sandoz at oracle.com Tue May 31 08:42:35 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 31 May 2016 10:42:35 +0200 Subject: RFR: JDK-8061777, , (zipfs) IllegalArgumentException in ZipCoder.toString when using Shitft_JIS In-Reply-To: References: <5748B056.3090903@oracle.com> <237367AB-CD71-4C9B-91F5-B5F4E0557FD1@oracle.com> Message-ID: > On 31 May 2016, at 07:07, Xueming Shen wrote: > > Thanks Paul, > > updated accordingly. > > http://cr.openjdk.java.net/~sherman/8061777/webrev > +1 Alas it?s awkward to do the converse for constructor accepting byte[] that may or may not be utf-8 given the "boolean normalized? parameter. Paul. From paul.sandoz at oracle.com Tue May 31 08:51:39 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 31 May 2016 10:51:39 +0200 Subject: RFR[9]: 8147585: Annotations with lambda expressions has parameters result in wrong behavior. In-Reply-To: <574D4CCF.5040606@oracle.com> References: <574BD6ED.70804@oracle.com> <2C498716-8CF7-4F03-8B64-513C08207117@oracle.com> <574D4CCF.5040606@oracle.com> Message-ID: > On 31 May 2016, at 10:35, shilpi.rastogi at oracle.com wrote: > > Thanks Paul for comments. > > Please see http://cr.openjdk.java.net/~srastogi/8147585/webrev.01/ > > Now processing only public abstract methods of interface. > Thanks. It would be good to get some got feedback from those wiser than I in this regard. Have you looked at the existing annotation-based tests to see if they test edge cases e.g. annotation classes generated with incorrect methods? that might give us some clues. Testing wise: - you can avoid the filtering of the test method by placing the annotations in another auxiliary class (my preference is to nest rather than using auxiliary classes, up to you) - there is a couple of minor style inconsistencies e.g. a space here "@ interface LambdaWithoutParameter" - 30 * @run testng/othervm -ea -esa AnnotationWithLambda You can just do: @run testng AnnotationWithLambda ? Thanks, Paul. > Thanks, > Shilpi > > On 5/30/2016 6:35 PM, Paul Sandoz wrote: >> Hi Shilpi, >> >> You have found the right place but i am not sure your fix is entirely correct. >> >> (Tip: if you use -Xlog:exceptions=info you can observe the IAE exception when the annotation is processed) >> >> In your test you have: >> >> @Target(value = ElementType.METHOD) >> @Retention(RetentionPolicy.RUNTIME) >> @ interface LambdaWithParameter { >> Consumer f1 = a -> { >> System.out.println("lambda has parameter"); >> }; >> } >> >> @Target(value = ElementType.METHOD) >> @Retention(RetentionPolicy.RUNTIME) >> @ interface LambdaWithoutParameter { >> Runnable r = () -> System.out.println("lambda without parameter"); >> } >> >> >> Both of those annotations will have static synthetic methods generated by the compiler that the indy resolves and links to (look at the javap output). The former will have a method with one parameter. >> >> >> The code in sun/reflect/annotation/AnnotationType.java: >> >> for (Method method : methods) { >> if (method.getParameterTypes().length != 0) >> throw new IllegalArgumentException(method + " has params"); >> >> has thrown the IAE since 2004, but it?s not clear why it was added as opposed to something more general (see below). >> >> >> The correct fix appears to be to skip over any non-abstract/non-public methods. Thus only public abstract methods get processed. >> >> Your current fix now processes synthetic methods with parameters, in addition to those which were already processed such as synthetic methods without parameters, or even private methods that could have been generated by some tool. I dunno how much say the verifier has in all this, perhaps little or no say. >> >> Thus non-public/non-abstract methods could add inconsistent information to the data structures of AnnotationType. Perhaps this is mostly harmless? >> >> Perhaps Joel (CC?ed) can she some more light on this? >> >> Paul. >> >> >>> On 30 May 2016, at 08:00, shilpi.rastogi at oracle.com wrote: >>> >>> Hi All, >>> >>> Please review fix for https://bugs.openjdk.java.net/browse/JDK-8147585 >>> http://cr.openjdk.java.net/~srastogi/8147585/webrev.00/ >>> >>> Problem: Annotation with Lamda has parameters results into wrong behavior ( not considered as valid annotation) because >>> According to JLS "By virtue of the AnnotationTypeElementDeclaration production, a method declaration in an annotation type declaration cannot have formal parameters, type parameters, or a throws clause. The following production from ?4.3 is shown here for convenience:" >>> (Ref: https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.6.1) >>> >>> >>> Solution: We should skip synthetic methods during Annotation parsing. According to JLS "An annotation type has no elements other than those defined by the methods it explicitly declares." >>> (Ref https://docs.oracle.com/javase/specs/jls/se8/html/.html#jls-9jls-9.6.1) >>> >>> >>> Thanks, >>> Shilpi > From ramanand.patil at oracle.com Tue May 31 09:29:18 2016 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Tue, 31 May 2016 02:29:18 -0700 (PDT) Subject: RFR: 8151876: (tz) Support tzdata2016d In-Reply-To: References: <9b76a353-e477-4f59-b630-5185e9ce6c37@default> <5748494F.6060404@oracle.com> <12123364-e177-a744-7f24-68e4a8f87532@oracle.com> <57486210.7090205@oracle.com> <783f0b2f-43fb-40ed-9204-889b9a3c2570@default> Message-ID: <0c729de0-1b64-4e4f-b655-e477a4c66e81@default> Hi Masayoshi, ? Thank you, I will delete this test before pushing the patch. ? ? Regards, Ramanand. ? From: Masayoshi Okutsu Sent: Tuesday, May 31, 2016 11:37 AM To: Ramanand Patil; Se?n Coffey; i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Subject: Re: RFR: 8151876: (tz) Support tzdata2016d ? The CheckDisplayNames.java change is different from what I suggested and doesn't make sense. But we no longer need the test. I'd suggest CheckDisplayNames.java be removed. Otherwise, the fix looks OK to me. Masayoshi ? On 5/31/2016 3:03 AM, Ramanand Patil wrote: Hi Masayoshi and All, ? Here is the updated Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erpatil/8151876/webrev.01/"http://cr.openjdk.java.net/~rpatil/8151876/webrev.01/ ? As suggested by Masayoshi, I have kept the existing names unchanged. Also, this patch contains extra test case fixes for 1.?? ?java/util/TimeZone/CheckDisplayNames.java 2.?? java/util/TimeZone/Bug8149452.java The exclusion for the newly added TimeZones is added in these test cases where the entries are not present in the resources and the Short/Long display names fallback to the GMT?hh:mm format. ? ? Regards, Ramanand. ? From: Masayoshi Okutsu Sent: Saturday, May 28, 2016 10:58 AM To: Se?n Coffey; Ramanand Patil; HYPERLINK "mailto:i18n-dev at openjdk.java.net"i18n-dev at openjdk.java.net; HYPERLINK "mailto:core-libs-dev at openjdk.java.net"core-libs-dev at openjdk.java.net Subject: Re: RFR: 8151876: (tz) Support tzdata2016d ? CLDR locale data defines time zone names, like this (in en.xml): ?????????????????????? ??????????????????????????????? ??????????????????????????????????????? Almaty Time ???????????????????????????????? ???????Almaty Standard Time ??????????????????????????????????????? Almaty Summer Time ??????????????????????????????? ??????????????????????? ? The CLDR converter tool tries to fill in the missing short names from the legacy TimeZoneNames data. Removing existing names causes some unexpected behavior. I think JDK-8157814 is an example of the unexpected behavior. And the suggested fix in JDK-8157814 looks to me like a workaround. I still think the existing names should be kept unchanged for this fix. Thanks, Masayoshi On 5/28/2016 12:04 AM, Se?n Coffey wrote: I guess there's a low risk of timezone not being identified if being parsed in through a formatter. Isn't such an approach discouraged though ? short IDs were already subject to change in tzdata releases. Ramanand found one issue by removal of these resource strings (so far) and that's captured in JDK-8157814 There's a decision to be made about how to use the GMT?hh:mm format for new releases given IANA's new short ID identifier mechanism. I think that could be discussed as a separate issue. I'd like to see us follow a similar approach to IANA and use GMT identifiers on new timezones and perhaps even consider using the IANA long name format also for the getDisplayName(..) calls that can be made. e.g. "Asia/Almaty" instead of "Alma-Ata Time" Regards, Sean. On 27/05/16 15:24, Masayoshi Okutsu wrote: This change seems to beyond my proposal that the "GMT?hh:mm" format is used for *new* zones with the "?hh" format. But this change removes *existing* zones which have changed to use the "?hh" format in tzdata. Can this cause any compatibility issues? And have we agreed to use the "GMT?hh:mm" format? Thanks, Masayoshi On 5/27/2016 10:19 PM, Se?n Coffey wrote: Looks fine to me Ramanand. the recent 2016d changes have introduced some boundary issues for JDK rule parsing and those issues can be followed up in separate issues like you say. Regards, Sean. On 26/05/16 14:22, Ramanand Patil wrote: HI all, Please review the latest TZDATA integration (tzdata2016d) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8151876 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erpatil/8151876/webrev.00/"http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/ Patch Contains: 1.?????? IANA tzdata2016d integration into JDK. [It also includes tzdata2016b and tzdata2016c which was not integrated]. 2.?????? "GMT[+ -]hh:mm" is used for formatting of the modified or newly added TimeZones in tzdata2016d. [This is done to accommodate the IANA's new system where the zones use numeric time zone abbreviations like "+04" instead of invented abbreviations like "ASTT".] 3.?????? Test case: java/time/test/java/time/format/TestZoneTextPrinterParser.java is updated to include the failures because of GMT[+ -]hh:mm format names. 4.?????? Few other failing tests: For few other failing tests, new linked bugs are created and will be addressed in a separate patch. Regards, Ramanand. ? ? ? ? ? From sean.coffey at oracle.com Tue May 31 09:34:50 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 31 May 2016 10:34:50 +0100 Subject: RFR: 8151876: (tz) Support tzdata2016d In-Reply-To: References: <9b76a353-e477-4f59-b630-5185e9ce6c37@default> <5748494F.6060404@oracle.com> <12123364-e177-a744-7f24-68e4a8f87532@oracle.com> <57486210.7090205@oracle.com> <783f0b2f-43fb-40ed-9204-889b9a3c2570@default> Message-ID: Masayoshi, I still think the test adds value. At minimum it identifies timezones which don't have a localised string in the JRE provider. We need to start another discussion about how best to represent timezone names for newly added timezones. At the moment, short and long formats will be of "GMT?hh:mm" format. I suggest we use the IANA timezone name for the long format name in future (e.g. "Asia/Tomsk" instead of "GMT+06:00") For the sake of getting this into the JDK code lines, I suggest we go ahead with your suggestion to remove the test for now. I've also reviewed this Ramanand. Your edits look fine (including test removal for now) Regards, Sean. On 31/05/2016 07:06, Masayoshi Okutsu wrote: > > The CheckDisplayNames.java change is different from what I suggested > and doesn't make sense. But we no longer need the test. I'd suggest > CheckDisplayNames.java be removed. Otherwise, the fix looks OK to me. > > Masayoshi > > > On 5/31/2016 3:03 AM, Ramanand Patil wrote: >> >> Hi Masayoshi and All, >> >> Here is the updated Webrev: >> http://cr.openjdk.java.net/~rpatil/8151876/webrev.01/ >> >> >> As suggested by Masayoshi, I have kept the existing names unchanged. >> >> >> Also, this patch contains extra test case fixes for >> >> >> 1./java/util/TimeZone/CheckDisplayNames.java/ >> >> >> 2.java/util/TimeZone/Bug8149452.java >> >> The exclusion for the *newly* added TimeZones is added in these test >> cases where the entries are not present in the resources and the >> Short/Long display names fallback to the GMT?hh:mm format. >> >> Regards, >> >> Ramanand. >> >> *From:*Masayoshi Okutsu >> *Sent:* Saturday, May 28, 2016 10:58 AM >> *To:* Se?n Coffey; Ramanand Patil; i18n-dev at openjdk.java.net; >> core-libs-dev at openjdk.java.net >> *Subject:* Re: RFR: 8151876: (tz) Support tzdata2016d >> >> CLDR locale data defines time zone names, like this (in en.xml): >> >> >> >> Almaty Time >> Almaty Standard Time >> Almaty Summer Time >> >> >> >> The CLDR converter tool tries to fill in the missing short names from >> the legacy TimeZoneNames data. Removing existing names causes some >> unexpected behavior. I think JDK-8157814 is an example of the >> unexpected behavior. And the suggested fix in JDK-8157814 looks to me >> like a workaround. >> >> I still think the existing names should be kept unchanged for this fix. >> >> Thanks, >> Masayoshi >> >> On 5/28/2016 12:04 AM, Se?n Coffey wrote: >> >> I guess there's a low risk of timezone not being identified if >> being parsed in through a formatter. Isn't such an approach >> discouraged though ? short IDs were already subject to change in >> tzdata releases. Ramanand found one issue by removal of these >> resource strings (so far) and that's captured in JDK-8157814 >> >> There's a decision to be made about how to use the GMT?hh:mm >> format for new releases given IANA's new short ID identifier >> mechanism. I think that could be discussed as a separate issue. >> I'd like to see us follow a similar approach to IANA and use GMT >> identifiers on new timezones and perhaps even consider using the >> IANA long name format also for the getDisplayName(..) calls that >> can be made. e.g. "Asia/Almaty" instead of "Alma-Ata Time" >> >> Regards, >> >> Sean. >> >> On 27/05/16 15:24, Masayoshi Okutsu wrote: >> >> This change seems to beyond my proposal that the "GMT?hh:mm" >> format is used for *new* zones with the "?hh" format. But >> this change removes *existing* zones which have changed to >> use the "?hh" format in tzdata. Can this cause any >> compatibility issues? >> >> And have we agreed to use the "GMT?hh:mm" format? >> >> Thanks, >> Masayoshi >> >> >> On 5/27/2016 10:19 PM, Se?n Coffey wrote: >> >> Looks fine to me Ramanand. the recent 2016d changes have >> introduced some boundary issues for JDK rule parsing and >> those issues can be followed up in separate issues like you say. >> >> Regards, >> Sean. >> >> On 26/05/16 14:22, Ramanand Patil wrote: >> >> HI all, >> >> Please review the latest TZDATA integration (tzdata2016d) to >> JDK9. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8151876 >> >> Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/ >> >> >> Patch Contains: >> >> 1. IANA tzdata2016d integration into JDK. [It also >> includes tzdata2016b and tzdata2016c which was not integrated]. >> >> 2. "GMT[+ -]hh:mm" is used for formatting of the >> modified or newly added TimeZones in tzdata2016d. >> >> [This is done to accommodate the IANA's new system where the >> zones use numeric time zone abbreviations like "+04" instead >> of invented abbreviations like "ASTT".] >> >> 3. Test case: >> java/time/test/java/time/format/TestZoneTextPrinterParser.java >> is updated to include the failures because of GMT[+ -]hh:mm >> format names. >> >> 4. Few other failing tests: For few other failing >> tests, new linked bugs are created and will be addressed in a >> separate patch. >> >> >> Regards, >> >> Ramanand. >> > From sean.mullan at oracle.com Tue May 31 12:16:40 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 31 May 2016 08:16:40 -0400 Subject: RFR 8154189: Deprivilege java.sql and java.sql.rowset module In-Reply-To: References: <9EC5BB9E-DDBC-4361-B71C-1F983F1C1C5F@oracle.com> Message-ID: <574D80A8.2050300@oracle.com> On 05/27/2016 02:10 PM, Lance Andersen wrote: >> The change looks fine. > Thank you >> > >> >It?s okay to grants AllPermission to get started. It?d be nice if we could grant fine-grained permissions in the future. > Agree, it is something to try and work towards. Hi Lance, Could you file a separate RFE for doing that (unless you have already)? Please add my name to the watch list. Thanks, Sean From shilpi.rastogi at oracle.com Tue May 31 12:17:11 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Tue, 31 May 2016 17:47:11 +0530 Subject: RFR[9]: 8147585: Annotations with lambda expressions has parameters result in wrong behavior. In-Reply-To: References: <574BD6ED.70804@oracle.com> <2C498716-8CF7-4F03-8B64-513C08207117@oracle.com> <574D4CCF.5040606@oracle.com> Message-ID: <574D80C7.1090106@oracle.com> Hi All, Please see updated webrev http://cr.openjdk.java.net/~srastogi/8147585/webrev.02/ On 5/31/2016 2:21 PM, Paul Sandoz wrote: >> On 31 May 2016, at 10:35, shilpi.rastogi at oracle.com wrote: >> >> Thanks Paul for comments. >> >> Please see http://cr.openjdk.java.net/~srastogi/8147585/webrev.01/ >> >> Now processing only public abstract methods of interface. >> > Thanks. It would be good to get some got feedback from those wiser than I in this regard. > > Have you looked at the existing annotation-based tests to see if they test edge cases e.g. annotation classes generated with incorrect methods? that might give us some clues. I saw existing annotation-based test, valid modifier for annotations, valid method for annotation tests we are checking in javac code. default, static, private modifier we are restricting at compile time so we can not add test cases for this (compilation will fail). So only scenario i can add is for synthetic methods. ( according to my assumption) In AnnotationType.java public Method[] run() { // Initialize memberTypes and defaultValues return annotationClass.getDeclaredMethods(); } }); As here, calling getDeclaredMethods() on annotationclass and getDeclaredMethods() doc says https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods-- "Returns an array containing Method objects reflecting all the declared methods of the class or interface represented by this Class object, including public, protected, default (package) access, and private methods, but excluding inherited methods." Doc did not mention anything about synthetic methods so i am not sure this is expected behavior or not. If yes, Could you please suggest how to add testcases to test synthetic method? Shall I use ASM? Regards, Shilpi > > Testing wise: > > - you can avoid the filtering of the test method by placing the annotations in another auxiliary class (my preference is to nest rather than using auxiliary classes, up to you) > > - there is a couple of minor style inconsistencies e.g. a space here "@ interface LambdaWithoutParameter" > > - 30 * @run testng/othervm -ea -esa AnnotationWithLambda > > You can just do: > > @run testng AnnotationWithLambda > > ? > > Thanks, > Paul. > > > > >> Thanks, >> Shilpi >> >> On 5/30/2016 6:35 PM, Paul Sandoz wrote: >>> Hi Shilpi, >>> >>> You have found the right place but i am not sure your fix is entirely correct. >>> >>> (Tip: if you use -Xlog:exceptions=info you can observe the IAE exception when the annotation is processed) >>> >>> In your test you have: >>> >>> @Target(value = ElementType.METHOD) >>> @Retention(RetentionPolicy.RUNTIME) >>> @ interface LambdaWithParameter { >>> Consumer f1 = a -> { >>> System.out.println("lambda has parameter"); >>> }; >>> } >>> >>> @Target(value = ElementType.METHOD) >>> @Retention(RetentionPolicy.RUNTIME) >>> @ interface LambdaWithoutParameter { >>> Runnable r = () -> System.out.println("lambda without parameter"); >>> } >>> >>> >>> Both of those annotations will have static synthetic methods generated by the compiler that the indy resolves and links to (look at the javap output). The former will have a method with one parameter. >>> >>> >>> The code in sun/reflect/annotation/AnnotationType.java: >>> >>> for (Method method : methods) { >>> if (method.getParameterTypes().length != 0) >>> throw new IllegalArgumentException(method + " has params"); >>> >>> has thrown the IAE since 2004, but it?s not clear why it was added as opposed to something more general (see below). >>> >>> >>> The correct fix appears to be to skip over any non-abstract/non-public methods. Thus only public abstract methods get processed. >>> >>> Your current fix now processes synthetic methods with parameters, in addition to those which were already processed such as synthetic methods without parameters, or even private methods that could have been generated by some tool. I dunno how much say the verifier has in all this, perhaps little or no say. >>> >>> Thus non-public/non-abstract methods could add inconsistent information to the data structures of AnnotationType. Perhaps this is mostly harmless? >>> >>> Perhaps Joel (CC?ed) can she some more light on this? >>> >>> Paul. >>> >>> >>>> On 30 May 2016, at 08:00, shilpi.rastogi at oracle.com wrote: >>>> >>>> Hi All, >>>> >>>> Please review fix for https://bugs.openjdk.java.net/browse/JDK-8147585 >>>> http://cr.openjdk.java.net/~srastogi/8147585/webrev.00/ >>>> >>>> Problem: Annotation with Lamda has parameters results into wrong behavior ( not considered as valid annotation) because >>>> According to JLS "By virtue of the AnnotationTypeElementDeclaration production, a method declaration in an annotation type declaration cannot have formal parameters, type parameters, or a throws clause. The following production from ?4.3 is shown here for convenience:" >>>> (Ref: https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.6.1) >>>> >>>> >>>> Solution: We should skip synthetic methods during Annotation parsing. According to JLS "An annotation type has no elements other than those defined by the methods it explicitly declares." >>>> (Ref https://docs.oracle.com/javase/specs/jls/se8/html/.html#jls-9jls-9.6.1) >>>> >>>> >>>> Thanks, >>>> Shilpi From lance.andersen at oracle.com Tue May 31 12:32:56 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 31 May 2016 08:32:56 -0400 Subject: RFR 8154189: Deprivilege java.sql and java.sql.rowset module In-Reply-To: <574D80A8.2050300@oracle.com> References: <9EC5BB9E-DDBC-4361-B71C-1F983F1C1C5F@oracle.com> <574D80A8.2050300@oracle.com> Message-ID: <5F2F2A4A-E027-4D1F-A1A8-6CB29D6FDA64@oracle.com> Hi Sean, Yes I will and add you to the watch list? Best Lance > On May 31, 2016, at 8:16 AM, Sean Mullan wrote: > > On 05/27/2016 02:10 PM, Lance Andersen wrote: >>> The change looks fine. >> Thank you >>> > >>> >It?s okay to grants AllPermission to get started. It?d be nice if we could grant fine-grained permissions in the future. >> Agree, it is something to try and work towards. > > Hi Lance, > > Could you file a separate RFE for doing that (unless you have already)? Please add my name to the watch list. > > Thanks, > Sean 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 Ulf.Zibis at CoSoCo.de Tue May 31 13:27:16 2016 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 31 May 2016 15:27:16 +0200 Subject: RFR: JDK-8061777, , (zipfs) IllegalArgumentException in ZipCoder.toString when using Shitft_JIS In-Reply-To: References: <5748B056.3090903@oracle.com> <237367AB-CD71-4C9B-91F5-B5F4E0557FD1@oracle.com> Message-ID: <574D9134.6010304@CoSoCo.de> Hi Sherman, 1.) wouldn't it be better to have a public getBytes() in AbstractStringBuilder? Then you could save the array copy with sb.toString() here: 178 return new ZipPath(this, sb.toString(), zc.isUTF8()); 525 return zfs.getBytes(to.toString()); You could simplify even more. 2.) No need for fork on isUTF8 in ZFS.iteratorOf() and for parameter isUTF8: 55 ZipPath(ZipFileSystem zfs, byte[] path, boolean normalized) 56 { 57 this.zfs = zfs; 58 if (normalized) 59 this.path = path; 60 // if zfs is NOT in utf8, normalize the path as "String" 61 // to avoid incorrectly normalizing byte '0x5c' (as '\') 62 // to '/'. 63 else if (zfs.zc.isUTF8()) 64 this.path = normalize(path); 65 else 66 this.path = normalize(zfs.getString(path)); 67 } 64 ZipPath(ZipFileSystem zfs, String path) { 65 this.zfs = zfs; 66 // if zfs is NOT in utf8, normalize the path as "String" 67 // to avoid incorrectly normalizing byte '0x5c' (as '\') 68 // to '/'. 69 if (zfs.zc.isUTF8()) { 70 this.path = normalize(zfs.getBytes(path)); 71 } else { 72 this.path = normalize(path); 73 } 74 } 75 3.) We could benefit from better byte array performance for all one byte charsets, e.g. common Windows-1252: With: if (zfs.zc.isOneByte()) this.path = normalize(path, zfs.zc.backSlashCode, zfs.zc.slashCode); 4.) We could do the same for all double byte charsets and benefit from the new intrinsic accessor methods on byte arrays/buffers with VarHandles. 5.) As alternative to 2.) consider moving the string concatenation to ZipPath constructor. I believe, this would make things more simple and less redundant: ZipPath(ZipFileSystem zfs, String first, String... more) 6.) Avoid String instatiation especially when called from child paths iterator *loop*. Instead: 500 if (len > 1 && prevC == '/') 501 path = path.substring(0, len - 1); 502 return zfs.getBytes(path); provide: 500 return zfs.getBytes(path, 0, len - (len > 1 && prevC == '/' ? 1 : 0 )); 7.) Last but not least, the normalize algorithm could be an additional usecase for http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6695386 with '\' as terminator. -Ulf Am 31.05.2016 um 07:07 schrieb Xueming Shen: > Thanks Paul, > > updated accordingly. > > http://cr.openjdk.java.net/~sherman/8061777/webrev > > -sherman > > On 5/30/16 2:31 AM, Paul Sandoz wrote: >> Hi Sherman, >> >> Do you consider modifying the new ZipPath constructor you added to accept a boolean value for >> UTF-8 encoding? >> >> If so you can more clearly document the behaviour and avoid duplication of the operators in >> ZipFileSystem e.g.: >> >> return new ZipPath(this, first, zc.isUTF8()); >> >> Paul. From scolebourne at joda.org Tue May 31 13:45:18 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 31 May 2016 14:45:18 +0100 Subject: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour In-Reply-To: <5746AA87.3040501@oracle.com> References: <5746AA87.3040501@oracle.com> Message-ID: Where the new patterns are described in Javadoc, there is no discussion of the difference between "H" and "HH". Add after "Patterns containing "HH" will format and parse a two digit hour, zero-padded if necessary. Patterns containing "H" will format with no zero-padding, and parse either one or two digits." "with colo" should be "with colon" As for the main code, I've had a go at a rewrite: https://gist.github.com/jodastephen/68857dd344e33bd6c0b3b4d24279d2e4 It is completely untested, and surely has mistakes, however as a design it seems reasonable. I agree that the tests need to cover these cases: - offset at end of line - offset followed by letters - offset followed by numbers Stephen On 26 May 2016 at 08:49, nadeesh tv wrote: > Hi all, > > Please review > > BugId : https://bugs.openjdk.java.net/browse/JDK-8066806 > > Issue: java.time.format.DateTimeFormatter cannot parse an offset with single > digit hour > > webrev: http://cr.openjdk.java.net/~ntv/8066806/webrev.03/ > > Solution: Added the suggested patterns but the parsing logic became too > complex. > Appreciate any suggestion to make the parsing less complicated > > -- > Thanks and Regards, > Nadeesh TV > From paul.sandoz at oracle.com Tue May 31 14:27:48 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 31 May 2016 16:27:48 +0200 Subject: RFR[9]: 8147585: Annotations with lambda expressions has parameters result in wrong behavior. In-Reply-To: <574D80C7.1090106@oracle.com> References: <574BD6ED.70804@oracle.com> <2C498716-8CF7-4F03-8B64-513C08207117@oracle.com> <574D4CCF.5040606@oracle.com> <574D80C7.1090106@oracle.com> Message-ID: <33BD21B1-C6F2-459B-9A93-E7D906AA09C0@oracle.com> > On 31 May 2016, at 14:17, shilpi.rastogi at oracle.com wrote: > > Hi All, > > Please see updated webrev http://cr.openjdk.java.net/~srastogi/8147585/webrev.02/ > I meant do something like this: static class MethodsWithAnnotations { @LambdaWithParameter public void testAnnotationLambdaWithParameter() { } @LambdaWithoutParameter public void testAnnotationLambdaWithoutParameter() { } } Then you don?t need to do: 49 if(!method.getName().equals("testAnnotationWithLambda")) { > On 5/31/2016 2:21 PM, Paul Sandoz wrote: >>> On 31 May 2016, at 10:35, shilpi.rastogi at oracle.com >>> wrote: >>> >>> Thanks Paul for comments. >>> >>> Please see >>> http://cr.openjdk.java.net/~srastogi/8147585/webrev.01/ >>> >>> >>> Now processing only public abstract methods of interface. >>> >>> >> Thanks. It would be good to get some got feedback from those wiser than I in this regard. >> >> Have you looked at the existing annotation-based tests to see if they test edge cases e.g. annotation classes generated with incorrect methods? that might give us some clues. >> > I saw existing annotation-based test, valid modifier for annotations, valid method for annotation tests we are checking in javac code. > default, static, private modifier we are restricting at compile time so we can not add test cases for this (compilation will fail). > We may be getting our wires crossed. I was wondering if there were some existing tests that generate annotation classes by directly producing byte code that would otherwise not be possible with javac. If there are it might give us some clues. I was not suggesting as part of this fix you write some such tests. > So only scenario i can add is for synthetic methods. ( according to my assumption) > In AnnotationType.java > > public Method[] run() { > // Initialize memberTypes and defaultValues > return annotationClass.getDeclaredMethods(); > } > }); > > As here, calling getDeclaredMethods() on annotationclass and getDeclaredMethods() doc says > > https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods-- > "Returns an array containing Method objects reflecting all the declared methods of the class or interface represented by this Class object, including public, protected, default (package) access, and private methods, but excluding inherited methods." > > Doc did not mention anything about synthetic methods so i am not sure this is expected behavior or not. A synthetic method is one that must one of public, protected, default (package) access, and private (i don?t actually know if synthetic methods are stricter in their scope). But i think we are deviating off topic, which is the processing of declared methods by AnnotationType to build up the annotation property metadata. I just want to be sure that skipping all non-public non-abstract methods when processing is not gonna cause issues. It seems obvious it should skip such methods, but it has not been implemented that way. Perhaps this is just an oversight, i dunno, but sometimes things in a JDK are there for a reason, and it?s often hard to know. We can try making an offering to the Java gods and looking out for the eagle that flies straight and narrow to the right, or alternatively ask someone more expert in this area :-) AFAICT from debugging a little in this area the additional information added by processing never gets exposed, so it?s just wasted space/time. Paul. > If yes, Could you please suggest how to add testcases to test synthetic method? > Shall I use ASM? > > Regards, > Shilp From shilpi.rastogi at oracle.com Tue May 31 15:49:39 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Tue, 31 May 2016 21:19:39 +0530 Subject: RFR[9]: 8147585: Annotations with lambda expressions has parameters result in wrong behavior. In-Reply-To: <33BD21B1-C6F2-459B-9A93-E7D906AA09C0@oracle.com> References: <574BD6ED.70804@oracle.com> <2C498716-8CF7-4F03-8B64-513C08207117@oracle.com> <574D4CCF.5040606@oracle.com> <574D80C7.1090106@oracle.com> <33BD21B1-C6F2-459B-9A93-E7D906AA09C0@oracle.com> Message-ID: <574DB293.5000100@oracle.com> Thanks Paul!! Please see http://cr.openjdk.java.net/~srastogi/8147585/webrev.03/ Thanks, Shilpi On 5/31/2016 7:57 PM, Paul Sandoz wrote: > >"Returns an array containing Method objects reflecting all the declared methods of the class or interface represented by this Class object, including public, protected, default (package) access, and private methods, but excluding inherited methods." From xueming.shen at oracle.com Tue May 31 17:08:17 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 31 May 2016 10:08:17 -0700 Subject: RFR: JDK-8061777, , (zipfs) IllegalArgumentException in ZipCoder.toString when using Shitft_JIS In-Reply-To: <574D9134.6010304@CoSoCo.de> References: <5748B056.3090903@oracle.com> <237367AB-CD71-4C9B-91F5-B5F4E0557FD1@oracle.com> <574D9134.6010304@CoSoCo.de> Message-ID: <70cecd98-874a-aee4-742f-468d9aeeb64f@oracle.com> Ulf, thanks for the suggestions! On 5/31/16 6:27 AM, Ulf Zibis wrote: > Hi Sherman, > > 1.) wouldn't it be better to have a public getBytes() in > AbstractStringBuilder? > Then you could save the array copy with sb.toString() here: > 178 return new ZipPath(this, sb.toString(), zc.isUTF8()); > 525 return zfs.getBytes(to.toString()); > > One single use case here probably is not a strong enough reason to add such a utility method into ASB. > You could simplify even more. > > 2.) No need for fork on isUTF8 in ZFS.iteratorOf() and for parameter > isUTF8: > 55 ZipPath(ZipFileSystem zfs, byte[] path, boolean normalized) > 56 { > 57 this.zfs = zfs; > 58 if (normalized) > 59 this.path = path; > 60 // if zfs is NOT in utf8, normalize the path as "String" > 61 // to avoid incorrectly normalizing byte '0x5c' (as '\') > 62 // to '/'. > 63 else if (zfs.zc.isUTF8()) > 64 this.path = normalize(path); > 65 else > 66 this.path = normalize(zfs.getString(path)); > 67 } > > 64 ZipPath(ZipFileSystem zfs, String path) { > 65 this.zfs = zfs; > 66 // if zfs is NOT in utf8, normalize the path as "String" > 67 // to avoid incorrectly normalizing byte '0x5c' (as '\') > 68 // to '/'. > 69 if (zfs.zc.isUTF8()) { > 70 this.path = normalize(zfs.getBytes(path)); > 71 } else { > 72 this.path = normalize(path); > 73 } > 74 } > 75 I was hesitated to exposure zfs.zc to be package private for some reason, that was why have the pair of zfs.getBytes/String(). But sure I can do it if it makes the communication clearer. webrev has been updated accordingly. http://cr.openjdk.java.net/~sherman/8061777/webrev > > > 6.) Avoid String instatiation especially when called from child paths > iterator *loop*. > Instead: > 500 if (len > 1 && prevC == '/') > 501 path = path.substring(0, len - 1); > 502 return zfs.getBytes(path); > provide: > 500 return zfs.getBytes(path, 0, len - (len > 1 && prevC == > '/' ? 1 : 0 )); > This can be a candidate for further optimization. Currently my assumption is that non-utf8 jar/zip files are not the main use cases for zipfs (assume most of them are the result of either the jar tool or j.u.zip apis), so I would wait to add a new method into zc. Hope this is fine with you. Sherman From kumar.x.srinivasan at oracle.com Tue May 31 17:07:56 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 31 May 2016 10:07:56 -0700 Subject: Review Request JDK-8152721: Java Web Start splash mechanism is not working in JDK9 In-Reply-To: <574D2772.3040506@oracle.com> References: <73F0BDF7-51DB-486D-B9C3-EA89A0858B07@oracle.com> <57492478.4030200@oracle.com> <339A5D4A-AEC4-4F73-B5D6-A4268F7A00B9@oracle.com> <574D2772.3040506@oracle.com> Message-ID: <574DC4EC.9040805@oracle.com> Hi Mandy, I am ok with the changes. Thanks Kumar > > > On 31/05/2016 03:59, Mandy Chung wrote: >> SelectVersion is called for launching any application. It processes >> -splash option separately from the launcher argument processing. To >> hit this bug, it will need to launch with the new module-system >> option together with -splash. I have verified with my modified >> version of a client test verifying the -splash option. >> >> I prefer to file a JBS issue for the client team to create a test for >> this if that?s okay with you. >> > That should be okay as we should have tests for this option. > > -Alan From rhillegas at comcast.net Mon May 30 18:48:15 2016 From: rhillegas at comcast.net (Richard Hillegas) Date: Mon, 30 May 2016 11:48:15 -0700 Subject: handling the deprecations introduced by early access builds 116 and 118 of jdk 9 Message-ID: <574C8AEF.1030609@comcast.net> Dalibor Topic recommended that I post this feedback on core-libs-dev. This is my feedback after ameliorating the deprecation warnings which surfaced when I compiled and tested Apache Derby with early access builds 116 and 118 of JDK 9. Derby is a pure Java relational database whose original code goes back almost 20 years. Other large, old code bases (like Weblogic) may have similar experiences. More detail on my experience can be found on the JIRA issue which tracks the Derby community's attempt to keep our code evergreen against JDK 9: https://issues.apache.org/jira/browse/DERBY-6856 o Deprecating autoboxing constructors - Deprecating the autoboxing constructors for primitive wrapper objects caused a large rototill of Derby code. That rototill was comparable in size to the changes made necessary by Java 5's introduction of generics. Hopefully, IDEs can automate much of this chore. o Deprecating Class.newInstance() - The deprecation of Class.newInstance() forced a similarly large rototill. The code became more verbose. Additional exceptions had to be caught and propagated up the call stack. For reasons which I don't understand, I had better luck using Class.getConstructor().newInstance() than Class.getDeclaredConstructor().newInstance(). But the former replacement code requires you to make constructors public. For some code bases, that may introduce security problems which are worse than the security problem being addressed by this deprecation. I hope that IDEs and the release notes for JDK 9 will provide some guidance for how to handle these issues. o Deprecating java.util.Observable and java.util.Observer - Two ameliorations are recommended at http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040436.html. The first suggestion (use the awt event model) runs very much counter to the whole intent of Jigsaw. That is because pulling in awt can bloat up an application with large, otherwise unneeded libraries. Using awt was out of the question for Derby, given that the community had already invested a great deal of effort in paring back Derby's dependencies in order to let the code run on JDK 8 compact profile 2. That left us with the other option: write your own replacement classes. If a lot of people end up having to write the same replacement code, then that argues for leaving this small but useful functionality in the JDK. I think that the people who advocated for this deprecation did not have good visibility into how widely these classes are being used in the wild. I recommend that this deprecation be re-evaluated. Thanks, -Rick From martinrb at google.com Tue May 31 17:23:00 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 31 May 2016 10:23:00 -0700 Subject: RFR: JDK-8157850 Jar tests should pass through VM options In-Reply-To: <3a06a763-56e0-22f1-69b7-24f388a8678f@oracle.com> References: <2da88f6b-b377-ac21-cc34-a0f2a1a566bf@oracle.com> <57460554.7080306@oracle.com> <57460E22.4060307@oracle.com> <758a2c4c-df6d-04dd-e581-4d267abc1c5d@oracle.com> <3a06a763-56e0-22f1-69b7-24f388a8678f@oracle.com> Message-ID: I approve this change. On Mon, May 30, 2016 at 4:59 PM, David Holmes wrote: > On 27/05/2016 2:20 AM, Andrey Nazarov wrote: >> >> Thanks for feedback guys. >> >> I've updated review >> http://cr.openjdk.java.net/~anazarov/8157850/webrev.02/ > > > Using test.tool.vm.opts seems reasonable for jar and javac. > >> Please sponsor this patch if you are OK. > > > Sorry not my area. > > Thanks, > David > > >> My use case is to run tests with different -Xms and -Xmx options. Mostly >> due to I need to increase heap size to gather code coverage by jcov. >> >> --Andrey >> >> On 25.05.2016 23:42, Jonathan Gibbons wrote: >>> >>> >>> >>> On 05/25/2016 01:33 PM, David Holmes wrote: >>>> >>>> On 26/05/2016 6:04 AM, Jonathan Gibbons wrote: >>>>> >>>>> Using JAVA_OPTIONS for tools is conceptually wrong. >>>>> >>>>> JAVA_OPTIONS is specifically intended to pass options to VM instances, >>>>> as created by a "java" command. It is not intended that you should >>>>> prefix the options with -J and use them for arbitrary tools. >>>> >>>> >>>> I have to agree. There is no guarantee the options being passed for >>>> the VM under test make any sense for the running of the jar tool in >>>> the jar tests. I think a number of hotspot related test options could >>>> cause problems here. >>>> >>>> Are there specific VM options that people think should be passed >>>> through? The bug report has no detail at all. >>>> >>>> David >>> >>> >>> Generally, I think that blindly passing through all the options >>> regardless is as bad a programming practice as never passing them >>> though. There are some that make sense to all VMs, like -ea, -esa >>> etc, and maybe system properties, but for those, the VM options >>> mechanism is generally good enough. (i.e. system properties >>> test.vm.opts, test.tool.vm.opts) >>> >>> From a jtreg point of view, I'd be interested to know uses cases for >>> passing additional more specific options to the VMs used to run tools >>> like jar, jlink, javac, etc >>> >>> -- Jon. >>> >>> >>> >>>> >>>>> The code in the webrev is also perverse for taking the trouble to split >>>>> the string to a stream, collect the results into a list, convert the >>>>> list back into a stream again and use .forEach. >>>>> >>>>> You could do better, and much simpler, with something like >>>>> >>>>> if (!option.isEmpty()) { >>>>> commands.addAll(Arrays.asList(option.split("\\s+",-1))); >>>>> } >>>>> >>>>> -- Jon >>>>> >>>>> >>>>> On 05/25/2016 10:48 AM, Martin Buchholz wrote: >>>>>> >>>>>> Hi Andrey, >>>>>> >>>>>> Looking at http://openjdk.java.net/jtreg/vmoptions.html, >>>>>> I see we have both test.vm.opts and test.tool.vm.opts >>>>>> and the latter is supposed to take care of adding "-J". >>>>>> >>>>>> + VM_OPTIONS.stream().map(opt -> "-J" + >>>>>> opt).forEach(commands::add); >>>>>> + JAVA_OPTIONS.stream().map(opt -> "-J" + >>>>>> opt).forEach(commands::add); >>>>>> >>>>>> --- >>>>>> >>>>>> Maybe splitting on "\\s+" would be better. >>>>>> >>>>>> --- >>>>>> >>>>>> I think we should have test library methods to return the List >>>>>> for java subprocesses, one that could try hard to get the option >>>>>> tokenization correct. >>>>>> >>>>>> --- >>>>>> >>>>>> >>>>>> On Wed, May 25, 2016 at 9:07 AM, Andrey Nazarov >>>>>> wrote: >>>>>>> >>>>>>> Some jar tests start VMs without passing vmoptions from jtreg. >>>>>>> >>>>>>> This fix pass jtreg's vmoptions and javaoptions to processes(java, >>>>>>> jar, >>>>>>> javac) started by tests. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~anazarov/8157850/webrev.01/ >>>>>>> >>>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8157850 >>>>>>> >>>>>>> --Andrey >>>>>>> >>>>> >>> >> > From nadeesh.tv at oracle.com Tue May 31 17:53:25 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Tue, 31 May 2016 23:23:25 +0530 Subject: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour In-Reply-To: References: <5746AA87.3040501@oracle.com> Message-ID: <574DCF95.20904@oracle.com> Hi Stephen, Thanks for the suggestions and the code. Regards, Nadeesh On 5/31/2016 7:15 PM, Stephen Colebourne wrote: > Where the new patterns are described in Javadoc, there is no > discussion of the difference between "H" and "HH". > > Add after > > "Patterns containing "HH" will format and parse a two digit hour, > zero-padded if necessary. Patterns containing "H" will format with no > zero-padding, and parse either one or two digits." > > "with colo" should be "with colon" > > As for the main code, I've had a go at a rewrite: > https://gist.github.com/jodastephen/68857dd344e33bd6c0b3b4d24279d2e4 > > It is completely untested, and surely has mistakes, however as a > design it seems reasonable. > > I agree that the tests need to cover these cases: > > - offset at end of line > - offset followed by letters > - offset followed by numbers > > Stephen > > > On 26 May 2016 at 08:49, nadeesh tv wrote: >> Hi all, >> >> Please review >> >> BugId : https://bugs.openjdk.java.net/browse/JDK-8066806 >> >> Issue: java.time.format.DateTimeFormatter cannot parse an offset with single >> digit hour >> >> webrev: http://cr.openjdk.java.net/~ntv/8066806/webrev.03/ >> >> Solution: Added the suggested patterns but the parsing logic became too >> complex. >> Appreciate any suggestion to make the parsing less complicated >> >> -- >> Thanks and Regards, >> Nadeesh TV >> -- Thanks and Regards, Nadeesh TV From sean.coffey at oracle.com Tue May 31 17:57:36 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 31 May 2016 18:57:36 +0100 Subject: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code In-Reply-To: <5739D4F3.70801@oracle.com> References: <5739C09B.7000302@oracle.com> <5739C246.9000908@oracle.com> <5739CEE1.2090903@oracle.com> <5739D4F3.70801@oracle.com> Message-ID: I've gone ahead with a trimmed down webrev as per Alan's request. new webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832.v2/webrev/ Regards, Sean. On 16/05/2016 15:10, Alan Bateman wrote: > > > On 16/05/2016 14:45, Se?n Coffey wrote: >> >> On 16/05/16 13:51, Alan Bateman wrote: >>> On 16/05/2016 13:44, Se?n Coffey wrote: >>>> Some extra capturing of context in exception handling. I've >>>> re-based the original suggested patch and added some minor edits. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8151832 >>>> webrev : >>>> http://cr.openjdk.java.net/~coffeys/webrev.8151832/webrev/index.html >>>> >>> Would it be possible to leave out the changes to the source files in >>> the module and loader directories for now? We have many changes to >>> this code coming that replace parts of this code and I think would >>> be better to do a pass over the exceptions in a few months once the >>> code is more stable. >> Yes, I can hold off. I figured such improvements might help people >> while they adopt and set up modules but let's cancel until the code >> stabilizes some more! >> > Thanks. The rest mostly look okay although I think several of these > exceptions in the jimage code need to re-examined - for example IOOBE > is thrown in several places where the root cause must be a corrupt or > truncated jimage file. > > -Alan > > From Roger.Riggs at Oracle.com Tue May 31 18:09:51 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 31 May 2016 14:09:51 -0400 Subject: RFR 9: 8158254 : Put java/time/test/java/time/TestClock_System on the problem list for Solaris Message-ID: Please review this change to add a java.time test to the ProblemList.txt, only for Solaris. A change[1] was tried for a more efficient way to read the current time but it didn't work out and had to be fixed. The original change propagated to the jdk9-master but the fix [2] has not yet. Jira: 8158128: regression: java/time/test/java/time/TestClock_System.java fails at test_OffsetRegular() -- old/test/ProblemList.txt 2016-05-31 12:31:46.530188722 -0400 +++ new/test/ProblemList.txt 2016-05-31 12:31:46.210188722 -0400 @@ -346,6 +346,13 @@ ############################################################################ +# jdk_time + +java/time/test/java/time/TestClock_System.java 8158128 solaris + + +############################################################################ + # jdk_util Thanks, Roger [1] JDK-8154710 Investigate use of in-memory low-resolution timestamps for Java and internal time API [2] 8157175 GetNanoTimeAdjustment.java fails with excessive adjustment error From lance.andersen at oracle.com Tue May 31 18:11:10 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 31 May 2016 14:11:10 -0400 Subject: RFR 9: 8158254 : Put java/time/test/java/time/TestClock_System on the problem list for Solaris In-Reply-To: References: Message-ID: <8BEB3A2F-48BF-4D16-988A-1FEA0C6E3261@oracle.com> +1 > On May 31, 2016, at 2:09 PM, Roger Riggs wrote: > > Please review this change to add a java.time test to the ProblemList.txt, only for Solaris. > > A change[1] was tried for a more efficient way to read the current time but it didn't work out > and had to be fixed. The original change propagated to the jdk9-master but the fix [2] has not yet. > > Jira: > > 8158128: regression: java/time/test/java/time/TestClock_System.java fails at test_OffsetRegular() > > -- old/test/ProblemList.txt 2016-05-31 12:31:46.530188722 -0400 > +++ new/test/ProblemList.txt 2016-05-31 12:31:46.210188722 -0400 > @@ -346,6 +346,13 @@ > > ############################################################################ > > +# jdk_time > + > +java/time/test/java/time/TestClock_System.java 8158128 solaris > + > + > +############################################################################ > + > # jdk_util > > Thanks, Roger > > > [1] JDK-8154710 Investigate use of in-memory low-resolution timestamps for Java and internal time API > > [2] 8157175 GetNanoTimeAdjustment.java fails with excessive adjustment error > > > 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 joe.darcy at oracle.com Tue May 31 18:16:43 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 31 May 2016 11:16:43 -0700 Subject: RFR 9: 8158254 : Put java/time/test/java/time/TestClock_System on the problem list for Solaris In-Reply-To: <8BEB3A2F-48BF-4D16-988A-1FEA0C6E3261@oracle.com> References: <8BEB3A2F-48BF-4D16-988A-1FEA0C6E3261@oracle.com> Message-ID: <73cb5a74-2738-18c2-0fb6-1bfba1a7fd1e@oracle.com> The syntax used elsewhere in the file is "solaris-all"; I'm not sure just "solaris" would have the right semantics. +1 if "solaris-all" were used. Thanks, -Joe On 5/31/2016 11:11 AM, Lance Andersen wrote: > +1 >> On May 31, 2016, at 2:09 PM, Roger Riggs wrote: >> >> Please review this change to add a java.time test to the ProblemList.txt, only for Solaris. >> >> A change[1] was tried for a more efficient way to read the current time but it didn't work out >> and had to be fixed. The original change propagated to the jdk9-master but the fix [2] has not yet. >> >> Jira: >> >> 8158128: regression: java/time/test/java/time/TestClock_System.java fails at test_OffsetRegular() >> >> -- old/test/ProblemList.txt 2016-05-31 12:31:46.530188722 -0400 >> +++ new/test/ProblemList.txt 2016-05-31 12:31:46.210188722 -0400 >> @@ -346,6 +346,13 @@ >> >> ############################################################################ >> >> +# jdk_time >> + >> +java/time/test/java/time/TestClock_System.java 8158128 solaris >> + >> + >> +############################################################################ >> + >> # jdk_util >> >> Thanks, Roger >> >> >> [1] JDK-8154710 Investigate use of in-memory low-resolution timestamps for Java and internal time API >> >> [2] 8157175 GetNanoTimeAdjustment.java fails with excessive adjustment error >> >> >> > > > 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 Tue May 31 18:22:19 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 31 May 2016 14:22:19 -0400 Subject: RFR 9: 8158254 : Put java/time/test/java/time/TestClock_System on the problem list for Solaris In-Reply-To: <73cb5a74-2738-18c2-0fb6-1bfba1a7fd1e@oracle.com> References: <8BEB3A2F-48BF-4D16-988A-1FEA0C6E3261@oracle.com> <73cb5a74-2738-18c2-0fb6-1bfba1a7fd1e@oracle.com> Message-ID: <40f4194f-8e67-023f-9d46-51feabb2467c@Oracle.com> Thanks Joe, Lance, Corrected to use solaris-all. Roger On 5/31/2016 2:16 PM, joe darcy wrote: > The syntax used elsewhere in the file is "solaris-all"; I'm not sure > just "solaris" would have the right semantics. > > +1 if "solaris-all" were used. > > Thanks, > > -Joe > > > On 5/31/2016 11:11 AM, Lance Andersen wrote: >> +1 >>> On May 31, 2016, at 2:09 PM, Roger Riggs >>> wrote: >>> >>> Please review this change to add a java.time test to the >>> ProblemList.txt, only for Solaris. >>> >>> A change[1] was tried for a more efficient way to read the current >>> time but it didn't work out >>> and had to be fixed. The original change propagated to the >>> jdk9-master but the fix [2] has not yet. >>> >>> Jira: >>> >>> 8158128: regression: >>> java/time/test/java/time/TestClock_System.java fails at >>> test_OffsetRegular() >>> >>> -- old/test/ProblemList.txt 2016-05-31 12:31:46.530188722 -0400 >>> +++ new/test/ProblemList.txt 2016-05-31 12:31:46.210188722 -0400 >>> @@ -346,6 +346,13 @@ >>> >>> ############################################################################ >>> >>> >>> +# jdk_time >>> + >>> +java/time/test/java/time/TestClock_System.java 8158128 solaris >>> + >>> + >>> +############################################################################ >>> >>> + >>> # jdk_util >>> >>> Thanks, Roger >>> >>> >>> [1] JDK-8154710 Investigate use of in-memory low-resolution >>> timestamps for Java and internal time API >>> >>> [2] 8157175 GetNanoTimeAdjustment.java fails with excessive >>> adjustment error >>> >>> >>> >> >> >> >> 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 pbenedict at apache.org Tue May 31 18:48:22 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 31 May 2016 13:48:22 -0500 Subject: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code In-Reply-To: References: <5739C09B.7000302@oracle.com> <5739C246.9000908@oracle.com> <5739CEE1.2090903@oracle.com> <5739D4F3.70801@oracle.com> Message-ID: Hi Sean, I just have a few minor comments. Nearly all the new messages follow the message/colon/space/details format. There are a few missing the space between the colon and details: *) ImageHeader: "jimage header not the correct size:" *) JrtPath throw new ProviderMismatchException("path class:" *) ConstructorFinder all new messages Some other observations: *) ImageLocation: why the beginning quote? throw new InternalError("\"Missing jimage attribute data"); *) JrtFileSystem: extra space before colon "option class : " + option.getClass().getName()); Cheers, Paul On Tue, May 31, 2016 at 12:57 PM, Se?n Coffey wrote: > I've gone ahead with a trimmed down webrev as per Alan's request. > > new webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832.v2/webrev/ > > Regards, > Sean. > > On 16/05/2016 15:10, Alan Bateman wrote: > >> >> >> On 16/05/2016 14:45, Se?n Coffey wrote: >> >>> >>> On 16/05/16 13:51, Alan Bateman wrote: >>> >>>> On 16/05/2016 13:44, Se?n Coffey wrote: >>>> >>>>> Some extra capturing of context in exception handling. I've re-based >>>>> the original suggested patch and added some minor edits. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8151832 >>>>> webrev : >>>>> http://cr.openjdk.java.net/~coffeys/webrev.8151832/webrev/index.html >>>>> >>>>> Would it be possible to leave out the changes to the source files in >>>> the module and loader directories for now? We have many changes to this >>>> code coming that replace parts of this code and I think would be better to >>>> do a pass over the exceptions in a few months once the code is more stable. >>>> >>> Yes, I can hold off. I figured such improvements might help people while >>> they adopt and set up modules but let's cancel until the code stabilizes >>> some more! >>> >>> Thanks. The rest mostly look okay although I think several of these >> exceptions in the jimage code need to re-examined - for example IOOBE is >> thrown in several places where the root cause must be a corrupt or >> truncated jimage file. >> >> -Alan >> >> >> > From sean.coffey at oracle.com Tue May 31 19:10:02 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 31 May 2016 20:10:02 +0100 Subject: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code In-Reply-To: References: <5739C09B.7000302@oracle.com> <5739C246.9000908@oracle.com> <5739CEE1.2090903@oracle.com> <5739D4F3.70801@oracle.com> Message-ID: <837fa3a2-7ace-cacc-eba0-cd6e85c59b14@oracle.com> Thanks Paul. Best to have consistent formatting. Webrev updated in place. On the beginning quote observation, I wasn't too such myself. Presumably a typo. I've removed for now. Regards, Sean. On 31/05/2016 19:48, Paul Benedict wrote: > Hi Sean, > > I just have a few minor comments. > > Nearly all the new messages follow the message/colon/space/details > format. There are a few missing the space between the colon and details: > *) ImageHeader: > "jimage header not the correct size:" > > *) JrtPath > throw new ProviderMismatchException("path class:" > > *) ConstructorFinder > all new messages > > Some other observations: > *) ImageLocation: why the beginning quote? > throw new InternalError("\"Missing jimage attribute data"); > > *) JrtFileSystem: extra space before colon > "option class : " + option.getClass().getName()); > > Cheers, > Paul > > On Tue, May 31, 2016 at 12:57 PM, Se?n Coffey > wrote: > > I've gone ahead with a trimmed down webrev as per Alan's request. > > new webrev : > http://cr.openjdk.java.net/~coffeys/webrev.8151832.v2/webrev/ > > > Regards, > Sean. > > On 16/05/2016 15:10, Alan Bateman wrote: > > > > On 16/05/2016 14:45, Se?n Coffey wrote: > > > On 16/05/16 13:51, Alan Bateman wrote: > > On 16/05/2016 13:44, Se?n Coffey wrote: > > Some extra capturing of context in exception > handling. I've re-based the original suggested > patch and added some minor edits. > > https://bugs.openjdk.java.net/browse/JDK-8151832 > webrev : > http://cr.openjdk.java.net/~coffeys/webrev.8151832/webrev/index.html > > > Would it be possible to leave out the changes to the > source files in the module and loader directories for > now? We have many changes to this code coming that > replace parts of this code and I think would be better > to do a pass over the exceptions in a few months once > the code is more stable. > > Yes, I can hold off. I figured such improvements might > help people while they adopt and set up modules but let's > cancel until the code stabilizes some more! > > Thanks. The rest mostly look okay although I think several of > these exceptions in the jimage code need to re-examined - for > example IOOBE is thrown in several places where the root cause > must be a corrupt or truncated jimage file. > > -Alan > > > > From joe.darcy at oracle.com Tue May 31 19:43:23 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 31 May 2016 12:43:23 -0700 Subject: JDK 9 RFR of JDK-5040830: (ann) please improve toString() for annotations containing exception proxies Message-ID: <34afa71f-039a-be68-c1c4-572dc737efd8@oracle.com> Hello, Some background, when everything is going well, the toString form of an annotation looks something like // Old non-erroneous annotation @DangerousAnnotation(utopia=BRIGADOON, thirtyTwoBitsAreNotEnough=42, classy=interface Fleeting, classies=[class java.lang.Object, int], moreClassies=[]) with newlines added for clarity. However, there are various kinds of problems that can occur with the data in an annotation and in those cases an exception proxy is created so that if the corresponding method is called an exception is thrown rather than the data being returned. In these cases the string form of an annotation with exceptions-that-would-be-thrown-if-methods-are-called looks like: // Current erroneous annotation @DangerousAnnotation(utopia=sun.reflect.annotation.EnumConstantNotPresentExceptionProxy at 766a8c91, thirtyTwoBitsAreNotEnough=sun.reflect.annotation.AnnotationTypeMismatchExceptionProxy at 1f40866a, classy=sun.reflect.annotation.TypeNotPresentExceptionProxy at 3de4f72b, classies=[class java.lang.Object, int], moreClassies=[]) Having the proxy implementation leak through to the string representation in this case is not helpful and the string can be made more informative. In addition, for Class-related values, the current form doesn't use the syntax which is legal in source code for annotations. Class-valued annotations are set using Class literal syntax, "Foo.class" rather than "class Foo", and arrays of Class-valued item should use braces ("{}") rather than brackets, ("[]"). For example, it would be better to have annotation string representations which looked like: // New non-erroneous annotation @DangerousAnnotation(utopia=BRIGADOON, thirtyTwoBitsAreNotEnough=42, classy=Fleeting.class, classies={java.lang.Object.class, int.class}, moreClassies={}) // New erroneous annotation @DangerousAnnotation(utopia=BRIGADOON /* Warning: constant not present! */, thirtyTwoBitsAreNotEnough=/* Warning type mismatch! "class java.lang.Integer[42]" */, classy=Fleeting.class /* Warning: type not present! */, classies={java.lang.Object.class, int.class}, moreClassies={}) Please review the code to implement these behavioral changes: 5040830: (ann) please improve toString() for annotations containing exception proxies http://cr.openjdk.java.net/~darcy/5040830.2 (If you have erroneous Class-value items in an array of Class values, then this throws an exception since the exception proxy cannot be stored into the Class[].) Thanks, -Joe From huizhe.wang at oracle.com Tue May 31 21:14:13 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 31 May 2016 14:14:13 -0700 Subject: RFR (JAXP) 8158246: Several api/org_xml/sax/helpers/XMLReader tests failed due to no SAXException occurs Message-ID: <574DFEA5.5020108@oracle.com> Hi, This issue was caused by the change 8152912 where the logic was changed so that the parser was directly instantiated when the className was within the DEFAULT_PACKAGE. The problem is that the className can be wrong even if it contains the DEFAULT_PACKAGE. The patch reverts the change 8152912 and adds a check for the default class name so that only if the specified className is the default parser, an instance is instantiated. JBS: https://bugs.openjdk.java.net/browse/JDK-8158246 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8158246/webrev/ 8152912 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8152912/webrev01/src/java.xml/share/classes/org/xml/sax/helpers/NewInstance.java.udiff.html Thanks, Joe From joe.darcy at oracle.com Tue May 31 22:17:55 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 31 May 2016 15:17:55 -0700 Subject: JDK 9 RFR of problem listing of java_sql_Timestamp.java Message-ID: <574E0D93.6060001@oracle.com> Hello, After the push for , the test java/beans/XMLEncoder/java_sql_Timestamp.java is failing across platforms. I'd like to problem list the test until the fix for JDK-8158281: "java_sql_Timestamp.java fails with AssertionError" is ready. Patch below. Thanks, -Joe --- a/test/ProblemList.txt Tue May 31 13:15:48 2016 -0700 +++ b/test/ProblemList.txt Tue May 31 15:16:18 2016 -0700 @@ -122,6 +122,8 @@ java/beans/Introspector/8132566/OverridePropertyInfoTest.java 8132565 generic-all java/beans/Introspector/8132566/OverrideUserDefPropertyInfoTest.java 8132565 generic-all +java/beans/XMLEncoder/java_sql_Timestamp.java 8158281 generic-all + ############################################################################ # jdk_lang From Sergey.Bylokhov at oracle.com Tue May 31 22:19:52 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 1 Jun 2016 01:19:52 +0300 Subject: JDK 9 RFR of problem listing of java_sql_Timestamp.java In-Reply-To: <574E0D93.6060001@oracle.com> References: <574E0D93.6060001@oracle.com> Message-ID: <8f168bc9-8b82-b5db-976d-470520b5fdf7@oracle.com> I think that we can fix the bug itself since the fix is trivial and already proposed by Mandy, no? On 01.06.16 1:17, Joseph D. Darcy wrote: > Hello, > > After the push for , the test > > java/beans/XMLEncoder/java_sql_Timestamp.java > > is failing across platforms. I'd like to problem list the test until the > fix for JDK-8158281: "java_sql_Timestamp.java fails with AssertionError" > is ready. > > Patch below. > > Thanks, > > -Joe > > --- a/test/ProblemList.txt Tue May 31 13:15:48 2016 -0700 > +++ b/test/ProblemList.txt Tue May 31 15:16:18 2016 -0700 > @@ -122,6 +122,8 @@ > java/beans/Introspector/8132566/OverridePropertyInfoTest.java 8132565 > generic-all > java/beans/Introspector/8132566/OverrideUserDefPropertyInfoTest.java > 8132565 generic-all > > +java/beans/XMLEncoder/java_sql_Timestamp.java 8158281 generic-all > + > ############################################################################ > > > # jdk_lang > -- Best regards, Sergey. From martinrb at google.com Tue May 31 23:52:28 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 31 May 2016 16:52:28 -0700 Subject: RFR: JDK-8157850 Jar tests should pass through VM options In-Reply-To: References: <2da88f6b-b377-ac21-cc34-a0f2a1a566bf@oracle.com> <57460554.7080306@oracle.com> <57460E22.4060307@oracle.com> <758a2c4c-df6d-04dd-e581-4d267abc1c5d@oracle.com> <3a06a763-56e0-22f1-69b7-24f388a8678f@oracle.com> Message-ID: Pushed. Can someone give Andrey some commit bits? On Tue, May 31, 2016 at 10:23 AM, Martin Buchholz wrote: > I approve this change. > > On Mon, May 30, 2016 at 4:59 PM, David Holmes wrote: >> On 27/05/2016 2:20 AM, Andrey Nazarov wrote: >>> >>> Thanks for feedback guys. >>> >>> I've updated review >>> http://cr.openjdk.java.net/~anazarov/8157850/webrev.02/ >> >> >> Using test.tool.vm.opts seems reasonable for jar and javac. >> >>> Please sponsor this patch if you are OK. >> >> >> Sorry not my area. >> >> Thanks, >> David >> >> >>> My use case is to run tests with different -Xms and -Xmx options. Mostly >>> due to I need to increase heap size to gather code coverage by jcov. >>> >>> --Andrey >>> >>> On 25.05.2016 23:42, Jonathan Gibbons wrote: >>>> >>>> >>>> >>>> On 05/25/2016 01:33 PM, David Holmes wrote: >>>>> >>>>> On 26/05/2016 6:04 AM, Jonathan Gibbons wrote: >>>>>> >>>>>> Using JAVA_OPTIONS for tools is conceptually wrong. >>>>>> >>>>>> JAVA_OPTIONS is specifically intended to pass options to VM instances, >>>>>> as created by a "java" command. It is not intended that you should >>>>>> prefix the options with -J and use them for arbitrary tools. >>>>> >>>>> >>>>> I have to agree. There is no guarantee the options being passed for >>>>> the VM under test make any sense for the running of the jar tool in >>>>> the jar tests. I think a number of hotspot related test options could >>>>> cause problems here. >>>>> >>>>> Are there specific VM options that people think should be passed >>>>> through? The bug report has no detail at all. >>>>> >>>>> David >>>> >>>> >>>> Generally, I think that blindly passing through all the options >>>> regardless is as bad a programming practice as never passing them >>>> though. There are some that make sense to all VMs, like -ea, -esa >>>> etc, and maybe system properties, but for those, the VM options >>>> mechanism is generally good enough. (i.e. system properties >>>> test.vm.opts, test.tool.vm.opts) >>>> >>>> From a jtreg point of view, I'd be interested to know uses cases for >>>> passing additional more specific options to the VMs used to run tools >>>> like jar, jlink, javac, etc >>>> >>>> -- Jon. >>>> >>>> >>>> >>>>> >>>>>> The code in the webrev is also perverse for taking the trouble to split >>>>>> the string to a stream, collect the results into a list, convert the >>>>>> list back into a stream again and use .forEach. >>>>>> >>>>>> You could do better, and much simpler, with something like >>>>>> >>>>>> if (!option.isEmpty()) { >>>>>> commands.addAll(Arrays.asList(option.split("\\s+",-1))); >>>>>> } >>>>>> >>>>>> -- Jon >>>>>> >>>>>> >>>>>> On 05/25/2016 10:48 AM, Martin Buchholz wrote: >>>>>>> >>>>>>> Hi Andrey, >>>>>>> >>>>>>> Looking at http://openjdk.java.net/jtreg/vmoptions.html, >>>>>>> I see we have both test.vm.opts and test.tool.vm.opts >>>>>>> and the latter is supposed to take care of adding "-J". >>>>>>> >>>>>>> + VM_OPTIONS.stream().map(opt -> "-J" + >>>>>>> opt).forEach(commands::add); >>>>>>> + JAVA_OPTIONS.stream().map(opt -> "-J" + >>>>>>> opt).forEach(commands::add); >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Maybe splitting on "\\s+" would be better. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> I think we should have test library methods to return the List >>>>>>> for java subprocesses, one that could try hard to get the option >>>>>>> tokenization correct. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> >>>>>>> On Wed, May 25, 2016 at 9:07 AM, Andrey Nazarov >>>>>>> wrote: >>>>>>>> >>>>>>>> Some jar tests start VMs without passing vmoptions from jtreg. >>>>>>>> >>>>>>>> This fix pass jtreg's vmoptions and javaoptions to processes(java, >>>>>>>> jar, >>>>>>>> javac) started by tests. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~anazarov/8157850/webrev.01/ >>>>>>>> >>>>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8157850 >>>>>>>> >>>>>>>> --Andrey >>>>>>>> >>>>>> >>>> >>> >>