From vivek.theeyarath at oracle.com Sun Apr 1 08:11:47 2018 From: vivek.theeyarath at oracle.com (Vivek Theeyarath) Date: Sun, 1 Apr 2018 01:11:47 -0700 (PDT) Subject: RFR: 8164781: Pattern.asPredicate specification is incomplete Message-ID: <99502bca-28b8-4d29-a5d7-7a2cae0c829a@default> Hi all, Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8164781 Webrev: http://cr.openjdk.java.net/~rraghavan/8164781/webrev.01/ Regards Vivek From uschindler at apache.org Sun Apr 1 10:56:48 2018 From: uschindler at apache.org (Uwe Schindler) Date: Sun, 01 Apr 2018 10:56:48 +0000 Subject: RFR: 8164781: Pattern.asPredicate specification is incomplete In-Reply-To: <99502bca-28b8-4d29-a5d7-7a2cae0c829a@default> References: <99502bca-28b8-4d29-a5d7-7a2cae0c829a@default> Message-ID: Hi, In general, I'd prefer to have a predicate that uses matches() instead of find(). In my code I have never used find() because in most cases you want to match the whole string anyways. Of course you can use ^ and $ but I don't like that leniency. If I write code, I prefer to be explicit in the code what should done. So I would prefer to add another asPredicate method that uses matches. I was stumbling on that several times. Uwe Am April 1, 2018 8:11:47 AM UTC schrieb Vivek Theeyarath : >Hi all, > > Please review. > >Bug: https://bugs.openjdk.java.net/browse/JDK-8164781 > >Webrev: http://cr.openjdk.java.net/~rraghavan/8164781/webrev.01/ > > > >Regards > >Vivek From huaming.li at oracle.com Mon Apr 2 10:33:06 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Mon, 2 Apr 2018 18:33:06 +0800 Subject: RFR of JDK-8188897: java/rmi/registry/reexport/Reexport.java failed with Port already in use Message-ID: would you please review the following patch? bug: https://bugs.openjdk.java.net/browse/JDK-8188897 webrev: http://cr.openjdk.java.net/~mli/8188897/webrev.00/ Thank you -Hamlin From paul.sandoz at oracle.com Mon Apr 2 17:56:14 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 2 Apr 2018 10:56:14 -0700 Subject: RFR: 8164781: Pattern.asPredicate specification is incomplete In-Reply-To: <99502bca-28b8-4d29-a5d7-7a2cae0c829a@default> References: <99502bca-28b8-4d29-a5d7-7a2cae0c829a@default> Message-ID: <9FED94A2-7351-4374-9139-0AB8ADBBFCC8@oracle.com> Hi, Looks good, expect for: 5823 * @return The predicate which can be used for finding on a string ?finding on a? ? is a little awkward to parse . I recommend to either change it back, since the first sentence of the method doc says what it means by matches, or being a little more verbose: The predicate which can be used for finding a match on a subsequence of a string You will need a CSR to document the clarification in specification behavior. ? To Uwe?s point, we could have chosen a more descriptive method name, e.g. asFinding/Predicate, leaving logical space for say any future asMatching/Predicate if we chose to add it. Paul. > On Apr 1, 2018, at 1:11 AM, Vivek Theeyarath wrote: > > Hi all, > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164781 > > Webrev: http://cr.openjdk.java.net/~rraghavan/8164781/webrev.01/ > > > > Regards > > Vivek From martinrb at google.com Mon Apr 2 18:01:41 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 2 Apr 2018 11:01:41 -0700 Subject: RFR: Some patches for sherman In-Reply-To: References: <26c8ce5e-4872-e5b9-00bb-8ea92a5c5fc4@gmail.com> <7FCC2320-00DA-457C-928D-0E545F73AF7C@oracle.com> Message-ID: On Fri, Mar 30, 2018 at 6:31 PM, Martin Buchholz wrote: > Thanks, John. > I need to adjust my expectations. The word "constant" means something > different to hotspot engineers. > > I'm still hoping to someday simply say, > "here's a final field - just go ahead and trust that it's truly final" > In retrospect, I think this wording in the docs raised my expectations: """a final stable field is treated as if it is really final from both the Java language and the HotSpot VM.""" > > On Fri, Mar 30, 2018 at 4:38 PM, John Rose wrote: > >> >> The docs for @Stable don't spell this out as clearly as one >> might want, but this sentence comes closest: "More specifically, >> the HotSpot VM will process non-null stable fields (final or >> otherwise) in a similar manner to static final fields with respect to >> promoting the field's value to a constant." >> > From martinrb at google.com Mon Apr 2 18:05:53 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 2 Apr 2018 11:05:53 -0700 Subject: RFR: 8164781: Pattern.asPredicate specification is incomplete In-Reply-To: References: <99502bca-28b8-4d29-a5d7-7a2cae0c829a@default> Message-ID: On Sun, Apr 1, 2018 at 3:56 AM, Uwe Schindler wrote: > > In general, I'd prefer to have a predicate that uses matches() instead of > find(). In my code I have never used find() because in most cases you want > to match the whole string anyways. Of course you can use ^ and $ but I > don't like that leniency. If I write code, I prefer to be explicit in the > code what should done. > I have the opposite experience. find()'s behavior is the default with grep and perl regexes, so the behavior of matches() is the one I trip over. From peter.levart at gmail.com Mon Apr 2 22:29:50 2018 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 3 Apr 2018 00:29:50 +0200 Subject: RFR: Some patches for sherman In-Reply-To: References: <26c8ce5e-4872-e5b9-00bb-8ea92a5c5fc4@gmail.com> <7FCC2320-00DA-457C-928D-0E545F73AF7C@oracle.com> Message-ID: <2fa8f4de-9b27-0b22-2703-d5e29881e08a@gmail.com> On 04/02/18 20:01, Martin Buchholz wrote: > > > On Fri, Mar 30, 2018 at 6:31 PM, Martin Buchholz > wrote: > > Thanks, John. > I need to adjust my expectations. The word "constant" means > something different to hotspot engineers. > > I'm still hoping to someday simply say, > "here's a final field - just go ahead and trust that it's truly final" > > > In retrospect, I think this wording in the docs raised my expectations: > > """a final stable field is treated as if it is really final from both > the Java language and the HotSpot VM.""" The thing is what you expect "really final field" to be treated like by VM. For its value to be hoisted out of loop it need not be really final at all, just not volatile. For its value to be compiled into a constant embedded into generated native code, it is not enough to be just really final - it must also be in an object that is considered constant. Regards, Peter > > On Fri, Mar 30, 2018 at 4:38 PM, John Rose > wrote: > > > The docs for @Stable don't spell this out as clearly as one > might want, but this sentence comes closest: ?"More specifically, > the HotSpot VM will process non-null stable fields (final or > otherwise) in a similar manner to static final fields with > respect to > promoting the field's value to a constant." > > From magnus.ihse.bursie at oracle.com Tue Apr 3 13:04:13 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 3 Apr 2018 15:04:13 +0200 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <5e7f7a0c-bf52-e095-ede6-a2599376cb22@oracle.com> Message-ID: <177cf215-9c5d-0834-1b1e-edb15515e344@oracle.com> (pruning cc-list somewhat) On 2018-03-29 08:16, Martin Buchholz wrote: > That surprises me. I'm quite certain that javah (or rather, java -h > nowadays) generate header files with JNIEXPORT and JNICALL. > > > As you can see in the jni.h and jni_md.h files, JNIEXPORT equals > __attribute__((visibility("default"))) for compilers that support > it (gcc and friends), and __declspec(dllexport) for Windows. This > means, that the symbol should be exported. (And it's ignored if > you use mapfiles aka linker scripts.) > > As for JNICALL, it's empty on most compilers, but evaluates to > __stdcall on Windows. This defines the calling convention to use. > This is required for JNI calls from Java. (Ask the JVM team why.) > While it's not technically required for calling from one dll to > another, it's good practice to use it all time to be consistent. > In any way, it doesn't hurt us. > > > Sure, I can see how JNIEXPORT and JNICALL are implemented, but what do > they */mean?/* > > For example, one might expect from the JNI prefix that these macros > are exclusively for use by JNI linking, i.e. unsupported except in the > output of javac -h.? But of course in practice they are used with > arbitrary symbols to communicate between components of user native > code, not just to communicate with the JVM.? Is that a bug? I think I see your point. JNIEXPORT currently has a dual role in OpenJDK. The primary role is as part of the JNI interface, as generated by javac -h. Since we have multiple native libraries definiting JNI entry points from Java, this is a proper usage. As such, it is "well defined", at least in the sense that the code is generated by javac, and can be assumed to be correct and not subject to user modifications. But we also use JNIEXPORT for symbol visibility for native library-to-native library calls, including calling the JVM. While this "works", it would be more proper to define a separate symbol for this use, e.g. JDK_EXPORT. Then JDK_EXPORT would have a well-defined meaning, and be used only internally in the OpenJDK project. If this is what you mean, I agree. I'm not sure I'm willing to put the time into separating between these two issues, however, but if you get backing from the rest of the project, and chose to persue this, I'll support you. :-) /Magnus From bob.vandette at oracle.com Tue Apr 3 14:09:56 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 3 Apr 2018 10:09:56 -0400 Subject: RFR: 81820709 - Container Awareness JEP Message-ID: Here is a first pass at an implementation of the Container Awareness JEP. This JEP adds an implementation of an internal API for the extraction of system metrics for processes running in Isolation Groups (Containers). The plan is to get the internal API integrated in JDK 11 with support for Linux x64 and then follow this work up with support for alternate platforms, the addition of a JMX MBean and Java Flight Recorder. JEP: https://bugs.openjdk.java.net/browse/JDK-8182070 JAVADOC: http://cr.openjdk.java.net/~bobv/8182070/v01/javadoc/jdk/internal/platform/Metrics.html WEBREV: http://cr.openjdk.java.net/~bobv/8182070/v01/webrev WEBREV including a Prototype MBEAN for exposing these Metrics: This prototype will not be integrated as part of this JEP. It?s for information only. http://cr.openjdk.java.net/~bobv/8182070/v01/mbean-proto/ This feature adds a new -XshowSetting option ?system? which displays the available system Metrics. % java -XshowSettings:system Operating System Metrics: Provider: cgroupv1 Effective CPU Count: 24 CPUTime per Processor: [0]: 52805305 (ns) [1]: 70799492 (ns) [2]: 27449618 (ns) [3]: 12957734 (ns) [4]: 38382720 (ns) [5]: 20325731 (ns) [6]: 36374924 (ns) [7]: 40279640 (ns) [8]: 17557347 (ns) [9]: 19056675 (ns) [10]: 66185888 (ns) [11]: 56539480 (ns) [12]: 10009386 (ns) [13]: 19139797 (ns) [14]: 2257349 (ns) [15]: 8712468 (ns) [16]: 10306911 (ns) [17]: 9814800 (ns) [18]: 3516611 (ns) [19]: 747174 (ns) [20]: 4380756 (ns) [21]: 11803118 (ns) [22]: 1076297 (ns) [23]: 8069315 (ns) CPU Usage is: 550599580 (ns) CPU User Usage is: 36 (ticks) CPU System Usage is: 10 (ticks) CPU Period: 100000 CPU Quota: -1 CPU Shares: -1 CPU Number of Periods: 0 CPU Number of Throttled Periods: 0 CPU Throttled Time: 0 CPUSet Exclusive: false CPUSet Memory Exclusive: false List of Processors, 24 total: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 List of Effective Processors, 24 total: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 List of Memory Nodes, 2 total: 0 1 List of Available Memory Nodes, 2 total: 0 1 CPUSet Memory Pressure Enabled: false CPUSet Memory Pressure: 0.0 Memory Failed Count: 0 Memory Limit: Unlimited Memory Used: 43.31M Max Memory Used: 48.82M Memory Soft Limit: Unlimited Memory & Swap Failed Count: 0.00K Memory & Swap Limit: Unlimited Memory & Swap Used: 43.93M Max Memory & Swap Used: 48.82M Kernel Memory Failed Count: 0.00K Kernel Memory Limit: Unlimited Kernel Memory Used: 0.00K Kernel Max Memory Used: 0.00K TCP Memory Failed Count: 0.00K TCP Memory Limit: Unlimited TCP Memory Used: 0.00K TCP Max Memory Used: 0.00K Out Of Memory Killer Enabled: true BLKIO: Number of I/O Operations Completed: 42 BLKIO: Bytes Transferred from disk: 4923392 Bob Vandette From Roger.Riggs at Oracle.com Tue Apr 3 14:48:24 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 3 Apr 2018 10:48:24 -0400 Subject: RFR of JDK-8188897: java/rmi/registry/reexport/Reexport.java failed with Port already in use In-Reply-To: References: Message-ID: <110f6c6e-61dc-89cf-aa97-cd989c8caabc@Oracle.com> Hi Hamlin, Instead of a simple time delay, it would be useful to wait for the RegistryVM to terminate. In killRegistry: 149,? adding subreg.waitFor() should be sufficient. 58: If using a 'for' loop it would be easier to understand if it included the usual start, increment and termination. Instead of burying it in the exception handler. 59, 102, 104: the introduction of the kill boolean makes the test harder to understand and seems to be unnecessary. ?the killRegistry() method already will only kill the subprocess if it still is alive. Roger On 4/2/2018 6:33 AM, Hamlin Li wrote: > would you please review the following patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8188897 > > webrev: http://cr.openjdk.java.net/~mli/8188897/webrev.00/ > > > Thank you > > -Hamlin > From andrew_m_leonard at uk.ibm.com Tue Apr 3 15:33:58 2018 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 3 Apr 2018 16:33:58 +0100 Subject: Proposal: Export InitializeEncoding for JVM access Message-ID: Hi, I would like to propose and find a sponsor for this change please, which is is export from libjava the JNU_InitializeEncoding() method, so that a JVM can initialize the platform encoding. Currently Java_java_lang_System_initProperties initializes the encoding, however for a generic JVM that will naturally provide it's own System implementation, the JVM needs a way to initialize this encoding directly. We can thus simply export it as per the change below.. There is precendence for doing this sort of export with Canonicalize(). Thanks Andrew diff --git a/src/java.base/share/native/libjava/jni_util.c b/src/java.base/share/native/libjava/jni_util.c --- a/src/java.base/share/native/libjava/jni_util.c +++ b/src/java.base/share/native/libjava/jni_util.c @@ -840,6 +840,15 @@ String_value_ID = (*env)->GetFieldID(env, strClazz, "value", "[B"); } +/* + * Export this method to allow JVM to initialize platform encoding explicitly. + */ +JNIEXPORT void JNICALL +JNU_InitializeEncoding(JNIEnv *env, const char *encname) +{ + InitializeEncoding(env, encname); +} + JNIEXPORT jstring NewStringPlatform(JNIEnv *env, const char *str) { Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From martinrb at google.com Tue Apr 3 18:16:00 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 3 Apr 2018 11:16:00 -0700 Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries In-Reply-To: <177cf215-9c5d-0834-1b1e-edb15515e344@oracle.com> References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com> <5e7f7a0c-bf52-e095-ede6-a2599376cb22@oracle.com> <177cf215-9c5d-0834-1b1e-edb15515e344@oracle.com> Message-ID: On Tue, Apr 3, 2018 at 6:04 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > (pruning cc-list somewhat) > > On 2018-03-29 08:16, Martin Buchholz wrote: > > That surprises me. I'm quite certain that javah (or rather, java -h > nowadays) generate header files with JNIEXPORT and JNICALL. > >> >> As you can see in the jni.h and jni_md.h files, JNIEXPORT equals >> __attribute__((visibility("default"))) for compilers that support it >> (gcc and friends), and __declspec(dllexport) for Windows. This means, that >> the symbol should be exported. (And it's ignored if you use mapfiles aka >> linker scripts.) >> >> As for JNICALL, it's empty on most compilers, but evaluates to __stdcall >> on Windows. This defines the calling convention to use. This is required >> for JNI calls from Java. (Ask the JVM team why.) While it's not technically >> required for calling from one dll to another, it's good practice to use it >> all time to be consistent. In any way, it doesn't hurt us. >> > > Sure, I can see how JNIEXPORT and JNICALL are implemented, but what do > they *mean?* > > For example, one might expect from the JNI prefix that these macros are > exclusively for use by JNI linking, i.e. unsupported except in the output > of javac -h. But of course in practice they are used with arbitrary > symbols to communicate between components of user native code, not just to > communicate with the JVM. Is that a bug? > > I think I see your point. JNIEXPORT currently has a dual role in OpenJDK. > The primary role is as part of the JNI interface, as generated by javac -h. > Since we have multiple native libraries definiting JNI entry points from > Java, this is a proper usage. As such, it is "well defined", at least in > the sense that the code is generated by javac, and can be assumed to be > correct and not subject to user modifications. > > But we also use JNIEXPORT for symbol visibility for native > library-to-native library calls, including calling the JVM. While this > "works", it would be more proper to define a separate symbol for this use, > e.g. JDK_EXPORT. Then JDK_EXPORT would have a well-defined meaning, and be > used only internally in the OpenJDK project. > > If this is what you mean, I agree. I'm not sure I'm willing to put the > time into separating between these two issues, however, but if you get > backing from the rest of the project, and chose to persue this, I'll > support you. :-) > Yes, I think we're in agreement. Even if JNIEXPORT is a purely internal mechanism - there should be some documentation. Since there is no other convenient mechanism in the C sources for creating "public native library symbols", it was probably inevitable that JNIEXPORT got repurposed. JNI support in the JDK needs a lot of love, but I'm already overcommitted elsewhere. From jonathan.gibbons at oracle.com Tue Apr 3 21:17:59 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 03 Apr 2018 14:17:59 -0700 Subject: RFR: 8200664: fix broken links in java.base docs Message-ID: <5AC3EF87.5060405@oracle.com> Please review a small update to fix some broken links in the java.base API docs. The change is necessary because when generating HTML 5 output, javadoc no longer has to encode method signatures into the restricted set of characters available in HTML 4 names. JBS: https://bugs.openjdk.java.net/browse/JDK-8200664 Webrev: http://cr.openjdk.java.net/~jjg/8200664/webrev.00/ -- Jon From ivan.gerasimov at oracle.com Tue Apr 3 23:22:22 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 3 Apr 2018 16:22:22 -0700 Subject: RFR 8200696 : Optimal initial capacity of java.lang.Class.enumConstantDirectory Message-ID: <640dfbab-6eec-b3e3-1b60-559c6137fc3c@oracle.com> Hello! Yet another occurrence of not-optimally pre-sized HashMap. When java.lang.Class.enumConstantDirectory is created, the initial capacity is set to be (2 * universe.length), which is more than necessary in some cases. Choosing the capacity optimally will allow us to save a few bytes with some enum classes. Would you please help review this trivial fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200696 WEBREV: http://cr.openjdk.java.net/~igerasim/8200696/00/webrev/ -- With kind regards, Ivan Gerasimov From david.holmes at oracle.com Tue Apr 3 23:49:20 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 Apr 2018 09:49:20 +1000 Subject: RFR 8200696 : Optimal initial capacity of java.lang.Class.enumConstantDirectory In-Reply-To: <640dfbab-6eec-b3e3-1b60-559c6137fc3c@oracle.com> References: <640dfbab-6eec-b3e3-1b60-559c6137fc3c@oracle.com> Message-ID: <9fe1d609-51f2-502b-7b92-b3a02be822c0@oracle.com> Hi Ivan, On 4/04/2018 9:22 AM, Ivan Gerasimov wrote: > Hello! > > Yet another occurrence of not-optimally pre-sized HashMap. > > When java.lang.Class.enumConstantDirectory is created, the initial > capacity is set to be (2 * universe.length), which is more than > necessary in some cases. > > Choosing the capacity optimally will allow us to save a few bytes with > some enum classes. How are you defining optimal? The bug report only gives one example where the current calculation produces a too large value. If the HashMap itself rounds up the initial capacity to a power of 2, how much extra space do we need compared to universe.length? Do we just need to pass (universe.length+1) to get the smallest power of 2 greater than universe.length? Thanks, David > Would you please help review this trivial fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200696 > WEBREV: http://cr.openjdk.java.net/~igerasim/8200696/00/webrev/ > From ivan.gerasimov at oracle.com Wed Apr 4 00:01:57 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 3 Apr 2018 17:01:57 -0700 Subject: RFR 8200696 : Optimal initial capacity of java.lang.Class.enumConstantDirectory In-Reply-To: <9fe1d609-51f2-502b-7b92-b3a02be822c0@oracle.com> References: <640dfbab-6eec-b3e3-1b60-559c6137fc3c@oracle.com> <9fe1d609-51f2-502b-7b92-b3a02be822c0@oracle.com> Message-ID: Hi David! On 4/3/18 4:49 PM, David Holmes wrote: > Hi Ivan, > > On 4/04/2018 9:22 AM, Ivan Gerasimov wrote: >> Hello! >> >> Yet another occurrence of not-optimally pre-sized HashMap. >> >> When java.lang.Class.enumConstantDirectory is created, the initial >> capacity is set to be (2 * universe.length), which is more than >> necessary in some cases. >> >> Choosing the capacity optimally will allow us to save a few bytes >> with some enum classes. > > How are you defining optimal? By optimal I meant the minimum value that will not make the internal storage to be reallocated during insertion. Here's a quotation from the documentation [1]: "If the initial capacity is greater than the maximum number of entries divided by the load factor, no rehash operations will ever occur." Given the default load factor 0.75, the formula (expectedSize / 0.75 + 1) gives us the optimal initial capacity. The testlibrary class testlibrary/OptimalCapacity.java is used to make sure that the chosen initial capacity is neither too low (so that no reallocations happen) nor too high (no memory is wasted). With kind regards, Ivan [1] https://docs.oracle.com/javase/10/docs/api/java/util/HashMap.html > The bug report only gives one example where the current calculation > produces a too large value. If the HashMap itself rounds up the > initial capacity to a power of 2, how much extra space do we need > compared to universe.length? Do we just need to pass > (universe.length+1) to get the smallest power of 2 greater than > universe.length? > > Thanks, > David > >> Would you please help review this trivial fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200696 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8200696/00/webrev/ >> > -- With kind regards, Ivan Gerasimov From stuart.marks at oracle.com Wed Apr 4 00:43:01 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 3 Apr 2018 17:43:01 -0700 Subject: RFR: 8164781: Pattern.asPredicate specification is incomplete In-Reply-To: <9FED94A2-7351-4374-9139-0AB8ADBBFCC8@oracle.com> References: <99502bca-28b8-4d29-a5d7-7a2cae0c829a@default> <9FED94A2-7351-4374-9139-0AB8ADBBFCC8@oracle.com> Message-ID: Hi Vivek, Thanks for taking on this task. In case it wasn't clear from Paul's mail, what I think you should do is continue with this fix as a doc-only (and test-only) change, and not modify the behavior of this method. Doing that would be an incompatible change. Uwe's point is a reasonable one, which is that you can't tell from the method name "asPredicate" whether it uses find() or match() semantics. Oh well, I think we just have to live with this, and document it clearly. Adding a method to create a Predicate that has match() semantics would be a fine task to consider separately. Also, in RegExTest.java, 4686 if (p.test("word1234")) { 4687 failCount++; 4688 } I think the logic should be negated, as the predicate should properly find the pattern in this string. Thanks, s'marks On 4/2/18 10:56 AM, Paul Sandoz wrote: > Hi, > > Looks good, expect for: > > 5823 * @return The predicate which can be used for finding on a string > > ?finding on a? ? is a little awkward to parse . I recommend to either change it back, since the first sentence of the method doc says what it means by matches, or being a little more verbose: > > The predicate which can be used for finding a match on a subsequence of a string > > You will need a CSR to document the clarification in specification behavior. > > ? > > To Uwe?s point, we could have chosen a more descriptive method name, e.g. asFinding/Predicate, leaving logical space for say any future asMatching/Predicate if we chose to add it. > > Paul. > > >> On Apr 1, 2018, at 1:11 AM, Vivek Theeyarath wrote: >> >> Hi all, >> >> Please review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8164781 >> >> Webrev: http://cr.openjdk.java.net/~rraghavan/8164781/webrev.01/ >> >> >> >> Regards >> >> Vivek > From stuart.marks at oracle.com Wed Apr 4 01:16:13 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 3 Apr 2018 18:16:13 -0700 Subject: RFR: 8164781: Pattern.asPredicate specification is incomplete In-Reply-To: References: <99502bca-28b8-4d29-a5d7-7a2cae0c829a@default> <9FED94A2-7351-4374-9139-0AB8ADBBFCC8@oracle.com> Message-ID: <9ef6ca9b-df94-69dc-14de-379a3f1183b8@oracle.com> On 4/3/18 5:43 PM, Stuart Marks wrote: > Adding a method to create a Predicate that has match() semantics would be a fine > task to consider separately. I notice I had already filed a bug for this: https://bugs.openjdk.java.net/browse/JDK-8184692 Feel free to pick it up. s'marks From david.holmes at oracle.com Wed Apr 4 01:41:58 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 Apr 2018 11:41:58 +1000 Subject: RFR 8200696 : Optimal initial capacity of java.lang.Class.enumConstantDirectory In-Reply-To: References: <640dfbab-6eec-b3e3-1b60-559c6137fc3c@oracle.com> <9fe1d609-51f2-502b-7b92-b3a02be822c0@oracle.com> Message-ID: Hi Ivan, On 4/04/2018 10:01 AM, Ivan Gerasimov wrote: > Hi David! > > > On 4/3/18 4:49 PM, David Holmes wrote: >> Hi Ivan, >> >> On 4/04/2018 9:22 AM, Ivan Gerasimov wrote: >>> Hello! >>> >>> Yet another occurrence of not-optimally pre-sized HashMap. >>> >>> When java.lang.Class.enumConstantDirectory is created, the initial >>> capacity is set to be (2 * universe.length), which is more than >>> necessary in some cases. >>> >>> Choosing the capacity optimally will allow us to save a few bytes >>> with some enum classes. >> >> How are you defining optimal? > By optimal I meant the minimum value that will not make the internal > storage to be reallocated during insertion. > > Here's a quotation from the documentation [1]: > "If the initial capacity is greater than the maximum number of entries > divided by the load factor, no rehash operations will ever occur." > > Given the default load factor 0.75, the formula (expectedSize / 0.75 + > 1) gives us the optimal initial capacity. Isn't it simpler to just do: new HashMap(universe.length, 1.0f); and change the load factor? Otherwise you have to allow for an extra 25% of space, and that is before it expands to be a power of 2 IIUC. David > The testlibrary class testlibrary/OptimalCapacity.java is used to make > sure that the chosen initial capacity is neither too low (so that no > reallocations happen) nor too high (no memory is wasted). > > With kind regards, > Ivan > > [1] https://docs.oracle.com/javase/10/docs/api/java/util/HashMap.html > > >> The bug report only gives one example where the current calculation >> produces a too large value. If the HashMap itself rounds up the >> initial capacity to a power of 2, how much extra space do we need >> compared to universe.length? Do we just need to pass >> (universe.length+1) to get the smallest power of 2 greater than >> universe.length? >> >> Thanks, >> David >> >>> Would you please help review this trivial fix? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200696 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8200696/00/webrev/ >>> >> > From joe.darcy at oracle.com Wed Apr 4 02:42:54 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 03 Apr 2018 19:42:54 -0700 Subject: RFR of JDK-8188897: java/rmi/registry/reexport/Reexport.java failed with Port already in use In-Reply-To: <110f6c6e-61dc-89cf-aa97-cd989c8caabc@Oracle.com> References: <110f6c6e-61dc-89cf-aa97-cd989c8caabc@Oracle.com> Message-ID: <5AC43BAE.7070601@oracle.com> Hello, Some general comments on the coding for tests like this: * It is preferable to avoid sleep in tests to avoid increasing the minimum amount of time a test takes to run. This helps limit the overall time it takes the test suite to run. * If timeouts are used, it is recommend to factor the maximum time waited with the jtreg timeout scaling factor; I don't recall its exact name. In other words, many of our tests are run on heavily loaded systems and the tests take longer than run than on typical laptops and workstations so jtreg is invoked with an timeout scaling factor. Individual tests should be sensitive to this scaling factor for any internal timeout that need to be used. HTH, -Joe On 4/3/2018 7:48 AM, Roger Riggs wrote: > Hi Hamlin, > > Instead of a simple time delay, it would be useful to wait for the > RegistryVM to terminate. > In killRegistry: 149, adding subreg.waitFor() should be sufficient. > > 58: If using a 'for' loop it would be easier to understand if it > included the usual start, increment and termination. > Instead of burying it in the exception handler. > > 59, 102, 104: the introduction of the kill boolean makes the test > harder to understand and seems to be unnecessary. > the killRegistry() method already will only kill the subprocess if it > still is alive. > > Roger > > On 4/2/2018 6:33 AM, Hamlin Li wrote: >> would you please review the following patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8188897 >> >> webrev: http://cr.openjdk.java.net/~mli/8188897/webrev.00/ >> >> >> Thank you >> >> -Hamlin >> > From david.holmes at oracle.com Wed Apr 4 03:15:12 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 Apr 2018 13:15:12 +1000 Subject: RFR 8200696 : Optimal initial capacity of java.lang.Class.enumConstantDirectory In-Reply-To: <5220b637-e39d-fd7f-12c6-77ecb05fc4be@oracle.com> References: <640dfbab-6eec-b3e3-1b60-559c6137fc3c@oracle.com> <9fe1d609-51f2-502b-7b92-b3a02be822c0@oracle.com> <5220b637-e39d-fd7f-12c6-77ecb05fc4be@oracle.com> Message-ID: <6974268d-378d-3fd2-bbf5-d7c1b199d37c@oracle.com> On 4/04/2018 1:06 PM, Ivan Gerasimov wrote: > Hi David! > > > On 4/3/18 6:41 PM, David Holmes wrote: >> Hi Ivan, >> >> On 4/04/2018 10:01 AM, Ivan Gerasimov wrote: >>> Hi David! >>> >>> >>> On 4/3/18 4:49 PM, David Holmes wrote: >>>> Hi Ivan, >>>> >>>> On 4/04/2018 9:22 AM, Ivan Gerasimov wrote: >>>>> Hello! >>>>> >>>>> Yet another occurrence of not-optimally pre-sized HashMap. >>>>> >>>>> When java.lang.Class.enumConstantDirectory is created, the initial >>>>> capacity is set to be (2 * universe.length), which is more than >>>>> necessary in some cases. >>>>> >>>>> Choosing the capacity optimally will allow us to save a few bytes >>>>> with some enum classes. >>>> >>>> How are you defining optimal? >>> By optimal I meant the minimum value that will not make the internal >>> storage to be reallocated during insertion. >>> >>> Here's a quotation from the documentation [1]: >>> "If the initial capacity is greater than the maximum number of >>> entries divided by the load factor, no rehash operations will ever >>> occur." >>> >>> Given the default load factor 0.75, the formula (expectedSize / 0.75 >>> + 1) gives us the optimal initial capacity. >> >> Isn't it simpler to just do: >> >> new HashMap(universe.length, 1.0f); >> >> and change the load factor? Otherwise you have to allow for an extra >> 25% of space, and that is before it expands to be a power of 2 IIUC. >> > Yes, it would be simpler of course. > However, the chance of a collision will also increase then. > Especially in cases when the number of entries is close (but not greater > than) to a power of 2. > > Not sure if it matters in this particular case, as the number of enum > values is likely to be relatively small, so the lookup will be fast anyway. > But I thought it would be better to keep the default load factor and > just set the initial capacity to the optimal value: minimum while not > causing reallocations during insertion. Okay. Thanks for explaining. The code could do with a comment explaining this, and the bug report certainly should explain it. Thanks, David > With kind regards, > Ivan > >> David >> >>> The testlibrary class testlibrary/OptimalCapacity.java is used to >>> make sure that the chosen initial capacity is neither too low (so >>> that no reallocations happen) nor too high (no memory is wasted). >>> >>> With kind regards, >>> Ivan >>> >>> [1] https://docs.oracle.com/javase/10/docs/api/java/util/HashMap.html >>> >>> >>>> The bug report only gives one example where the current calculation >>>> produces a too large value. If the HashMap itself rounds up the >>>> initial capacity to a power of 2, how much extra space do we need >>>> compared to universe.length? Do we just need to pass >>>> (universe.length+1) to get the smallest power of 2 greater than >>>> universe.length? >>>> >>>> Thanks, >>>> David >>>> >>>>> Would you please help review this trivial fix? >>>>> >>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200696 >>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8200696/00/webrev/ >>>>> >>>> >>> >> > From ivan.gerasimov at oracle.com Wed Apr 4 03:06:56 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 3 Apr 2018 20:06:56 -0700 Subject: RFR 8200696 : Optimal initial capacity of java.lang.Class.enumConstantDirectory In-Reply-To: References: <640dfbab-6eec-b3e3-1b60-559c6137fc3c@oracle.com> <9fe1d609-51f2-502b-7b92-b3a02be822c0@oracle.com> Message-ID: <5220b637-e39d-fd7f-12c6-77ecb05fc4be@oracle.com> Hi David! On 4/3/18 6:41 PM, David Holmes wrote: > Hi Ivan, > > On 4/04/2018 10:01 AM, Ivan Gerasimov wrote: >> Hi David! >> >> >> On 4/3/18 4:49 PM, David Holmes wrote: >>> Hi Ivan, >>> >>> On 4/04/2018 9:22 AM, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> Yet another occurrence of not-optimally pre-sized HashMap. >>>> >>>> When java.lang.Class.enumConstantDirectory is created, the initial >>>> capacity is set to be (2 * universe.length), which is more than >>>> necessary in some cases. >>>> >>>> Choosing the capacity optimally will allow us to save a few bytes >>>> with some enum classes. >>> >>> How are you defining optimal? >> By optimal I meant the minimum value that will not make the internal >> storage to be reallocated during insertion. >> >> Here's a quotation from the documentation [1]: >> "If the initial capacity is greater than the maximum number of >> entries divided by the load factor, no rehash operations will ever >> occur." >> >> Given the default load factor 0.75, the formula (expectedSize / 0.75 >> + 1) gives us the optimal initial capacity. > > Isn't it simpler to just do: > > new HashMap(universe.length, 1.0f); > > and change the load factor? Otherwise you have to allow for an extra > 25% of space, and that is before it expands to be a power of 2 IIUC. > Yes, it would be simpler of course. However, the chance of a collision will also increase then. Especially in cases when the number of entries is close (but not greater than) to a power of 2. Not sure if it matters in this particular case, as the number of enum values is likely to be relatively small, so the lookup will be fast anyway. But I thought it would be better to keep the default load factor and just set the initial capacity to the optimal value: minimum while not causing reallocations during insertion. With kind regards, Ivan > David > >> The testlibrary class testlibrary/OptimalCapacity.java is used to >> make sure that the chosen initial capacity is neither too low (so >> that no reallocations happen) nor too high (no memory is wasted). >> >> With kind regards, >> Ivan >> >> [1] https://docs.oracle.com/javase/10/docs/api/java/util/HashMap.html >> >> >>> The bug report only gives one example where the current calculation >>> produces a too large value. If the HashMap itself rounds up the >>> initial capacity to a power of 2, how much extra space do we need >>> compared to universe.length? Do we just need to pass >>> (universe.length+1) to get the smallest power of 2 greater than >>> universe.length? >>> >>> Thanks, >>> David >>> >>>> Would you please help review this trivial fix? >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200696 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8200696/00/webrev/ >>>> >>> >> > -- With kind regards, Ivan Gerasimov From huaming.li at oracle.com Wed Apr 4 03:35:30 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 4 Apr 2018 11:35:30 +0800 Subject: RFR of JDK-8188897: java/rmi/registry/reexport/Reexport.java failed with Port already in use In-Reply-To: <5AC43BAE.7070601@oracle.com> References: <110f6c6e-61dc-89cf-aa97-cd989c8caabc@Oracle.com> <5AC43BAE.7070601@oracle.com> Message-ID: <7c67de0d-f043-2ed8-d825-c9820eaf4d6a@oracle.com> Hi Joe, Roger, Thank you for reviewing, I have refactored the test more and fix as you suggested. please review http://cr.openjdk.java.net/~mli/8188897/webrev.01/ Thank you -Hamlin On 04/04/2018 10:42 AM, Joseph D. Darcy wrote: > Hello, > > Some general comments on the coding for tests like this: > > * It is preferable to avoid sleep in tests to avoid increasing the > minimum amount of time a test takes to run. This helps limit the > overall time it takes the test suite to run. > > * If timeouts are used, it is recommend to factor the maximum time > waited with the jtreg timeout scaling factor; I don't recall its exact > name. In other words, many of our tests are run on heavily loaded > systems and the tests take longer than run than on typical laptops and > workstations so jtreg is invoked with an timeout scaling factor. > Individual tests should be sensitive to this scaling factor for any > internal timeout that need to be used. > > HTH, > > -Joe > > On 4/3/2018 7:48 AM, Roger Riggs wrote: >> Hi Hamlin, >> >> Instead of a simple time delay, it would be useful to wait for the >> RegistryVM to terminate. >> In killRegistry: 149,? adding subreg.waitFor() should be sufficient. >> >> 58: If using a 'for' loop it would be easier to understand if it >> included the usual start, increment and termination. >> Instead of burying it in the exception handler. >> >> 59, 102, 104: the introduction of the kill boolean makes the test >> harder to understand and seems to be unnecessary. >> ?the killRegistry() method already will only kill the subprocess if >> it still is alive. >> >> Roger >> >> On 4/2/2018 6:33 AM, Hamlin Li wrote: >>> would you please review the following patch? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8188897 >>> >>> webrev: http://cr.openjdk.java.net/~mli/8188897/webrev.00/ >>> >>> >>> Thank you >>> >>> -Hamlin >>> >> > From huizhe.wang at oracle.com Wed Apr 4 04:13:57 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 3 Apr 2018 21:13:57 -0700 Subject: RFR: 8200664: fix broken links in java.base docs In-Reply-To: <5AC3EF87.5060405@oracle.com> References: <5AC3EF87.5060405@oracle.com> Message-ID: <6a6ab3ce-5c02-b7ef-4e3d-91697d9e49c5@oracle.com> Looks good to me. I verified the links using the Java SE 10 doc. --Joe On 4/3/2018 2:17 PM, Jonathan Gibbons wrote: > Please review a small update to fix some broken links in the java.base > API docs. > > The change is necessary because when generating HTML 5 output, javadoc > no longer has to encode method signatures into the restricted set of > characters > available in HTML 4 names. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8200664 > Webrev: http://cr.openjdk.java.net/~jjg/8200664/webrev.00/ > > -- Jon From vivek.theeyarath at oracle.com Wed Apr 4 06:54:04 2018 From: vivek.theeyarath at oracle.com (Vivek Theeyarath) Date: Tue, 3 Apr 2018 23:54:04 -0700 (PDT) Subject: RFR: 8164781: Pattern.asPredicate specification is incomplete In-Reply-To: References: <99502bca-28b8-4d29-a5d7-7a2cae0c829a@default> <9FED94A2-7351-4374-9139-0AB8ADBBFCC8@oracle.com> Message-ID: Hi, I have incorporated the changes as per the feedback and here is the updated webrev . http://cr.openjdk.java.net/~rraghavan/8164781/webrev.02/ . Bug: https://bugs.openjdk.java.net/browse/JDK-8164781 Here is the related csr https://bugs.openjdk.java.net/browse/JDK-8200603 I will try to address Uwe's point with a fix separately. Regards Vivek -----Original Message----- From: Stuart Marks Sent: Wednesday, April 04, 2018 6:13 AM To: Vivek Theeyarath Cc: Paul Sandoz ; Core-Libs-Dev Subject: Re: RFR: 8164781: Pattern.asPredicate specification is incomplete Hi Vivek, Thanks for taking on this task. In case it wasn't clear from Paul's mail, what I think you should do is continue with this fix as a doc-only (and test-only) change, and not modify the behavior of this method. Doing that would be an incompatible change. Uwe's point is a reasonable one, which is that you can't tell from the method name "asPredicate" whether it uses find() or match() semantics. Oh well, I think we just have to live with this, and document it clearly. Adding a method to create a Predicate that has match() semantics would be a fine task to consider separately. Also, in RegExTest.java, 4686 if (p.test("word1234")) { 4687 failCount++; 4688 } I think the logic should be negated, as the predicate should properly find the pattern in this string. Thanks, s'marks On 4/2/18 10:56 AM, Paul Sandoz wrote: > Hi, > > Looks good, expect for: > > 5823 * @return The predicate which can be used for finding on a string > > ?finding on a? ? is a little awkward to parse . I recommend to either change it back, since the first sentence of the method doc says what it means by matches, or being a little more verbose: > > The predicate which can be used for finding a match on a > subsequence of a string > > You will need a CSR to document the clarification in specification behavior. > > ? > > To Uwe?s point, we could have chosen a more descriptive method name, e.g. asFinding/Predicate, leaving logical space for say any future asMatching/Predicate if we chose to add it. > > Paul. > > >> On Apr 1, 2018, at 1:11 AM, Vivek Theeyarath wrote: >> >> Hi all, >> >> Please review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8164781 >> >> Webrev: http://cr.openjdk.java.net/~rraghavan/8164781/webrev.01/ >> >> >> >> Regards >> >> Vivek > From claes.redestad at oracle.com Wed Apr 4 06:56:46 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 4 Apr 2018 08:56:46 +0200 Subject: RFR 8200696 : Optimal initial capacity of java.lang.Class.enumConstantDirectory In-Reply-To: <640dfbab-6eec-b3e3-1b60-559c6137fc3c@oracle.com> References: <640dfbab-6eec-b3e3-1b60-559c6137fc3c@oracle.com> Message-ID: <0bc0a442-e9a4-3f62-50c8-57e76f09743b@oracle.com> Hi Ivan, looks good. Nit: maybe (int)(universe.length / 0.75f) + 1 to keep fp arithmetic to a minimum. /Claes On 2018-04-04 01:22, Ivan Gerasimov wrote: > Hello! > > Yet another occurrence of not-optimally pre-sized HashMap. > > When java.lang.Class.enumConstantDirectory is created, the initial > capacity is set to be (2 * universe.length), which is more than > necessary in some cases. > > Choosing the capacity optimally will allow us to save a few bytes with > some enum classes. > > Would you please help review this trivial fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200696 > WEBREV: http://cr.openjdk.java.net/~igerasim/8200696/00/webrev/ > From Alan.Bateman at oracle.com Wed Apr 4 06:57:10 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 Apr 2018 07:57:10 +0100 Subject: RFR: 8200664: fix broken links in java.base docs In-Reply-To: <5AC3EF87.5060405@oracle.com> References: <5AC3EF87.5060405@oracle.com> Message-ID: On 03/04/2018 22:17, Jonathan Gibbons wrote: > Please review a small update to fix some broken links in the java.base > API docs. > > The change is necessary because when generating HTML 5 output, javadoc > no longer has to encode method signatures into the restricted set of > characters > available in HTML 4 names. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8200664 > Webrev: http://cr.openjdk.java.net/~jjg/8200664/webrev.00/ This looks good to me. These dashes have always been confused in links so good that they will no longer be needed. -Alan From amy.lu at oracle.com Wed Apr 4 08:11:24 2018 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 4 Apr 2018 16:11:24 +0800 Subject: [11] RFR 8200703: Problem list jdk/jshell/ExceptionsTest.java fails on windows In-Reply-To: <57fb43a9-6da8-6a53-22d8-ee418700f8da@oracle.com> References: <57fb43a9-6da8-6a53-22d8-ee418700f8da@oracle.com> Message-ID: [Including core-libs-dev] Quick review needed. bug: https://bugs.openjdk.java.net/browse/JDK-8200703 webrev: http://cr.openjdk.java.net/~amlu/8200703/webrev.00/ Thanks, Amy On 04/04/2018 11:26 AM, Amy Lu wrote: > jdk/jshell/ExceptionsTest.java > > This test has been failing on Windows (JDK-8200701) since the push for > JDK-8198801. The test needs to be problem listed on Windows until a > full fix is developed. > > Please review the patch below. > > Thanks, > Amy > > > --- old/test/langtools/ProblemList.txt?? ?2018-04-04 > 11:17:19.000000000 +0800 > +++ new/test/langtools/ProblemList.txt?? ?2018-04-04 > 11:17:19.000000000 +0800 > @@ -38,6 +38,7 @@ > > ?jdk/jshell/UserJdiUserRemoteTest.java 8173079??? linux-all > ?jdk/jshell/UserInputTest.java 8169536??? generic-all > +jdk/jshell/ExceptionsTest.java 8200701??? windows-all > > ?########################################################################### > > ?# > From amy.lu at oracle.com Wed Apr 4 08:53:56 2018 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 4 Apr 2018 16:53:56 +0800 Subject: [11] RFR 8200703: Problem list jdk/jshell/ExceptionsTest.java fails on windows In-Reply-To: <5AC48ED2.6000900@oracle.com> References: <57fb43a9-6da8-6a53-22d8-ee418700f8da@oracle.com> <5AC48ED2.6000900@oracle.com> Message-ID: <2b58adbc-55dd-0fc2-ab1c-6dc9c4499b6a@oracle.com> Thank you Jan. Thanks, Amy On 04/04/2018 4:37 PM, Jan Lahoda wrote: > Hi, > > Ok to problem list. > > Jan > > On 4.4.2018 05:26, Amy Lu wrote: >> jdk/jshell/ExceptionsTest.java >> >> This test has been failing on Windows (JDK-8200701) since the push for >> JDK-8198801. The test needs to be problem listed on Windows until a full >> fix is developed. >> >> Please review the patch below. >> >> Thanks, >> Amy >> >> >> --- old/test/langtools/ProblemList.txt??? 2018-04-04 11:17:19.000000000 >> +0800 >> +++ new/test/langtools/ProblemList.txt??? 2018-04-04 11:17:19.000000000 >> +0800 >> @@ -38,6 +38,7 @@ >> >> ? jdk/jshell/UserJdiUserRemoteTest.java 8173079??? linux-all >> ? jdk/jshell/UserInputTest.java 8169536??? generic-all >> +jdk/jshell/ExceptionsTest.java 8200701??? windows-all >> >> ########################################################################### >> ? # >> From andrew_m_leonard at uk.ibm.com Wed Apr 4 12:17:23 2018 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Wed, 4 Apr 2018 13:17:23 +0100 Subject: RFR: Export InitializeEncoding for JVM access Message-ID: Hi, I would like to propose and find a sponsor for this change please, which is is export from libjava the JNU_InitializeEncoding() method, so that a JVM can initialize the platform encoding. Currently Java_java_lang_System_initProperties initializes the encoding, however for a generic JVM that will naturally provide it's own System implementation, the JVM needs a way to initialize this encoding directly. We can thus simply export it as per the change below.. There is precendence for doing this sort of export with Canonicalize(). Thanks Andrew diff --git a/src/java.base/share/native/libjava/jni_util.c b/src/java.base/share/native/libjava/jni_util.c --- a/src/java.base/share/native/libjava/jni_util.c +++ b/src/java.base/share/native/libjava/jni_util.c @@ -840,6 +840,15 @@ String_value_ID = (*env)->GetFieldID(env, strClazz, "value", "[B"); } +/* + * Export this method to allow JVM to initialize platform encoding explicitly. + */ +JNIEXPORT void JNICALL +JNU_InitializeEncoding(JNIEnv *env, const char *encname) +{ + InitializeEncoding(env, encname); +} + JNIEXPORT jstring NewStringPlatform(JNIEnv *env, const char *str) { Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From david.lloyd at redhat.com Wed Apr 4 13:51:42 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 4 Apr 2018 08:51:42 -0500 Subject: Patch fixing JDK-8176553 In-Reply-To: References: Message-ID: Is there anyone who would be willing to sponsor this change? On Tue, Jan 23, 2018 at 4:58 PM, Jan Kalina wrote: > Hi, > I has prepared trivial patch for bug JDK-8176553, which I has reported. > > I will welcome if it could be merged into JDK. > (The bug is present in JDK9 and JDK8 too.) > I am covered by Red Hat OCA. > > The patch is attached, bug reproducer is already in JIRA: > https://bugs.openjdk.java.net/browse/JDK-8176553 > > Thanks, > Jan Kalina -- - DML From david.lloyd at redhat.com Wed Apr 4 14:06:17 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 4 Apr 2018 09:06:17 -0500 Subject: Patch fixing JDK-8176553 In-Reply-To: References: Message-ID: Actually I've talked to Jan and we're going to try again with the more correct subject line & RFR. Thanks. On Wed, Apr 4, 2018 at 8:51 AM, David Lloyd wrote: > Is there anyone who would be willing to sponsor this change? > > On Tue, Jan 23, 2018 at 4:58 PM, Jan Kalina wrote: >> Hi, >> I has prepared trivial patch for bug JDK-8176553, which I has reported. >> >> I will welcome if it could be merged into JDK. >> (The bug is present in JDK9 and JDK8 too.) >> I am covered by Red Hat OCA. >> >> The patch is attached, bug reproducer is already in JIRA: >> https://bugs.openjdk.java.net/browse/JDK-8176553 >> >> Thanks, >> Jan Kalina > > > > -- > - DML -- - DML From jkalina at redhat.com Wed Apr 4 14:12:26 2018 From: jkalina at redhat.com (Jan Kalina) Date: Wed, 4 Apr 2018 16:12:26 +0200 Subject: RFR: [PATCH] 8176553 Fix LDAP referral loop Message-ID: Hi, I has prepared trivial patch for bug JDK-8176553, which I would like to get reviewed and sponsored. I am covered by Red Hat OCA. The bug affects upstream, JDK9 and JDK8 too. The reproducer is available in issue tracker: https://bugs.openjdk.java.net/browse/JDK-8176553 PATCH: ---------------------------------------------- diff --git a/src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java b/src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java --- a/src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java +++ b/src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java @@ -312,7 +312,8 @@ if ((refEx != null) && (refEx.hasMoreReferrals() || - refEx.hasMoreReferralExceptions())) { + refEx.hasMoreReferralExceptions()) && + ! (errEx instanceof LimitExceededException)) { if (homeCtx.handleReferrals == LdapClient.LDAP_REF_THROW) { throw (NamingException)(refEx.fillInStackTrace()); ---------------------------------------------- Thanks, Jan Kalina From Roger.Riggs at Oracle.com Wed Apr 4 14:15:18 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 4 Apr 2018 10:15:18 -0400 Subject: RFR of JDK-8188897: java/rmi/registry/reexport/Reexport.java failed with Port already in use In-Reply-To: <7c67de0d-f043-2ed8-d825-c9820eaf4d6a@oracle.com> References: <110f6c6e-61dc-89cf-aa97-cd989c8caabc@Oracle.com> <5AC43BAE.7070601@oracle.com> <7c67de0d-f043-2ed8-d825-c9820eaf4d6a@oracle.com> Message-ID: <0830767c-1502-54d1-5588-341731fd0aa3@Oracle.com> Hi Hamlin, Reexport.java: I think this change to use a separate process for the 2nd registry changes the test so that it does not address the original test case.? The original problem was the incorrect retention of an object in the object table when the create of a registry in the same process failed. Finally being able to create the registry in the same process assured that the object was not retained in the object table. Go back to creating the 2nd registry in the test process. RegistryVM.java: 2, the copyright update should be? "2017, 2018," range. (I'm? really not a fan of all the RegistryVM methods with the same name and minimal and implicit differences in their functions.? When reading the test, you have to go and read the RegistryVM method to see what it does.? I would have preferred that the full createRegistryVM (out, err, options, port) method was used directly in the tests.? In the case of a method used once, it is an inconvenience method, not a convenience). The new terminate() method is quite similar to the existing cleanup() method which does not wait. It would be a good cleanup to figure out if another method is really needed. The override is going to change the behavior of the existing uses of terminate(). It should be checked that it does not break any existing uses. 178: 187: The method comments are not consistent, one says forcibly and the other gracefully but both call requestExit and both call destroy(). Thanks, Roger On 4/3/2018 11:35 PM, Hamlin Li wrote: > Hi Joe, Roger, > > Thank you for reviewing, I have refactored the test more and fix as > you suggested. > > please review http://cr.openjdk.java.net/~mli/8188897/webrev.01/ > > Thank you > > -Hamlin > > > On 04/04/2018 10:42 AM, Joseph D. Darcy wrote: >> Hello, >> >> Some general comments on the coding for tests like this: >> >> * It is preferable to avoid sleep in tests to avoid increasing the >> minimum amount of time a test takes to run. This helps limit the >> overall time it takes the test suite to run. >> >> * If timeouts are used, it is recommend to factor the maximum time >> waited with the jtreg timeout scaling factor; I don't recall its >> exact name. In other words, many of our tests are run on heavily >> loaded systems and the tests take longer than run than on typical >> laptops and workstations so jtreg is invoked with an timeout scaling >> factor. Individual tests should be sensitive to this scaling factor >> for any internal timeout that need to be used. >> >> HTH, >> >> -Joe >> >> On 4/3/2018 7:48 AM, Roger Riggs wrote: >>> Hi Hamlin, >>> >>> Instead of a simple time delay, it would be useful to wait for the >>> RegistryVM to terminate. >>> In killRegistry: 149,? adding subreg.waitFor() should be sufficient. >>> >>> 58: If using a 'for' loop it would be easier to understand if it >>> included the usual start, increment and termination. >>> Instead of burying it in the exception handler. >>> >>> 59, 102, 104: the introduction of the kill boolean makes the test >>> harder to understand and seems to be unnecessary. >>> ?the killRegistry() method already will only kill the subprocess if >>> it still is alive. >>> >>> Roger >>> >>> On 4/2/2018 6:33 AM, Hamlin Li wrote: >>>> would you please review the following patch? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8188897 >>>> >>>> webrev: http://cr.openjdk.java.net/~mli/8188897/webrev.00/ >>>> >>>> >>>> Thank you >>>> >>>> -Hamlin >>>> >>> >> > From Alan.Bateman at oracle.com Wed Apr 4 14:15:30 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 Apr 2018 15:15:30 +0100 Subject: Patch fixing JDK-8176553 In-Reply-To: References: Message-ID: On 04/04/2018 15:06, David Lloyd wrote: > Actually I've talked to Jan and we're going to try again with the more > correct subject line & RFR. Thanks. > It would be good to see if a test can be developed too. -Alan From Roger.Riggs at Oracle.com Wed Apr 4 14:32:04 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 4 Apr 2018 10:32:04 -0400 Subject: RFR: Export InitializeEncoding for JVM access In-Reply-To: References: Message-ID: Hi Andrew, The function itself seems straightforward enough. Can you clarify the boundary that you are replacing?? The initialization has a lot of intermingled responsibilities and is quite sensitive. What else needs to be said about when it can be called and who should be calling it? I don't see the similarity to Canonicalize, which is not a supported interface, just exported for use within the implementation. Thanks, Roger On 4/4/2018 8:17 AM, Andrew Leonard wrote: > Hi, > I would like to propose and find a sponsor for this change please, which > is is export from libjava the JNU_InitializeEncoding() method, so that a > JVM can initialize the platform encoding. Currently > Java_java_lang_System_initProperties initializes the encoding, however for > > a generic JVM that will naturally provide it's own System implementation, > the JVM needs a way to initialize this encoding directly. We can thus > simply export it as per the change below.. There is precendence for doing > this sort of export with Canonicalize(). > Thanks > Andrew > > diff --git a/src/java.base/share/native/libjava/jni_util.c > b/src/java.base/share/native/libjava/jni_util.c > --- a/src/java.base/share/native/libjava/jni_util.c > +++ b/src/java.base/share/native/libjava/jni_util.c > @@ -840,6 +840,15 @@ > String_value_ID = (*env)->GetFieldID(env, strClazz, "value", "[B"); > } > > +/* > + * Export this method to allow JVM to initialize platform encoding > explicitly. > + */ > +JNIEXPORT void JNICALL > +JNU_InitializeEncoding(JNIEnv *env, const char *encname) > +{ > + InitializeEncoding(env, encname); > +} > + > JNIEXPORT jstring > NewStringPlatform(JNIEnv *env, const char *str) > { > > > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From jkalina at redhat.com Wed Apr 4 15:29:51 2018 From: jkalina at redhat.com (Jan Kalina) Date: Wed, 4 Apr 2018 17:29:51 +0200 Subject: RFR: [PATCH] 8176553 Fix LDAP referral loop In-Reply-To: References: Message-ID: Note: Test is not included, as it would require running LDAP server. (existing ldap tests in JDK use only mocks of the server) The patch was manually verified using reproducer attached to issue. On Wed, Apr 4, 2018 at 4:12 PM, Jan Kalina wrote: > Hi, > I has prepared trivial patch for bug JDK-8176553, > which I would like to get reviewed and sponsored. > > I am covered by Red Hat OCA. > > The bug affects upstream, JDK9 and JDK8 too. > > The reproducer is available in issue tracker: > https://bugs.openjdk.java.net/browse/JDK-8176553 > > PATCH: > ---------------------------------------------- > diff --git a/src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java > b/src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java > --- a/src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java > +++ b/src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java > @@ -312,7 +312,8 @@ > > if ((refEx != null) && > (refEx.hasMoreReferrals() || > - refEx.hasMoreReferralExceptions())) { > + refEx.hasMoreReferralExceptions()) && > + ! (errEx instanceof LimitExceededException)) { > > if (homeCtx.handleReferrals == LdapClient.LDAP_REF_THROW) { > throw (NamingException)(refEx.fillInStackTrace()); > ---------------------------------------------- > > Thanks, > Jan Kalina From vyom.tewari at oracle.com Wed Apr 4 15:35:17 2018 From: vyom.tewari at oracle.com (Vyom Tewari) Date: Wed, 4 Apr 2018 21:05:17 +0530 Subject: RFR: [PATCH] 8176553 Fix LDAP referral loop In-Reply-To: References: Message-ID: <5AC4F0B5.3080302@oracle.com> On 4/4/2018 8:59 PM, Jan Kalina wrote: > Note: Test is not included, as it would require running LDAP server. > (existing ldap tests in JDK use only mocks of the server) > > The patch was manually verified using reproducer attached to issue. Hi Jan, I ran the reproducer long back on my Linux box(Ubuntu 1604) on apacheDS 2 and it was not reproducible at my end. can you please let us know your environment detail. Thanks, Vyom > On Wed, Apr 4, 2018 at 4:12 PM, Jan Kalina wrote: >> Hi, >> I has prepared trivial patch for bug JDK-8176553, >> which I would like to get reviewed and sponsored. >> >> I am covered by Red Hat OCA. >> >> The bug affects upstream, JDK9 and JDK8 too. >> >> The reproducer is available in issue tracker: >> https://bugs.openjdk.java.net/browse/JDK-8176553 >> >> PATCH: >> ---------------------------------------------- >> diff --git a/src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java >> b/src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java >> --- a/src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java >> +++ b/src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java >> @@ -312,7 +312,8 @@ >> >> if ((refEx != null) && >> (refEx.hasMoreReferrals() || >> - refEx.hasMoreReferralExceptions())) { >> + refEx.hasMoreReferralExceptions()) && >> + ! (errEx instanceof LimitExceededException)) { >> >> if (homeCtx.handleReferrals == LdapClient.LDAP_REF_THROW) { >> throw (NamingException)(refEx.fillInStackTrace()); >> ---------------------------------------------- >> >> Thanks, >> Jan Kalina From adam.farley at uk.ibm.com Wed Apr 4 16:01:33 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 4 Apr 2018 16:01:33 +0000 Subject: RFR: JDK-8190187: C++ code calling JNI_CreateJavaVM can be killed by Java In-Reply-To: References: Message-ID: Hi All, I've attached the code to resolve JDK-8190187 Could a committer please take the fix (amended code attached, and available on request) and: 1) Complete the CSR process for the new JNI Return code. 2) Commit the changes that contain the Return code. And, optionally, 3) Perform 1 and 2 for the jdwp agent changes as well, so it can use this new functionality. Best Regards Adam Farley -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hg_diff.txt URL: From jkalina at redhat.com Wed Apr 4 16:05:32 2018 From: jkalina at redhat.com (Jan Kalina) Date: Wed, 4 Apr 2018 18:05:32 +0200 Subject: RFR: [PATCH] 8176553 Fix LDAP referral loop In-Reply-To: <5AC4F0B5.3080302@oracle.com> References: <5AC4F0B5.3080302@oracle.com> Message-ID: On Fedora 27, using latest Apache Directory Studio (ApacheDirectoryStudio-2.0.0.v20170904-M13-linux.gtk.x86_64.tar.gz) created new Apache DS 2.0.0, imported referrals.ldif and running JI9048012.java: export JAVA_HOME=/opt/jdk-9_linux-x64_bin/ $JAVA_HOME/bin/java JI9048012 >>>ou=test >>> >>>ldap://localhost:10389/ou=test,dc=example,dc=com >>>ldap://localhost:10389/dc=example,dc=com >>>ldap://localhost:10389/ou=test,dc=example,dc=com >>>ldap://localhost:10389/dc=example,dc=com >>>ldap://localhost:10389/ou=test,dc=example,dc=com >>>ldap://localhost:10389/dc=example,dc=com >>>ldap://localhost:10389/ou=test,dc=example,dc=com >>>ldap://localhost:10389/dc=example,dc=com >>>ldap://localhost:10389/ou=test,dc=example,dc=com >>>ldap://localhost:10389/dc=example,dc=com Output continues indefinitely, while LimitExceededException is EXPECTED, but it does not occur. On Wed, Apr 4, 2018 at 5:35 PM, Vyom Tewari wrote: > > > On 4/4/2018 8:59 PM, Jan Kalina wrote: >> >> Note: Test is not included, as it would require running LDAP server. >> (existing ldap tests in JDK use only mocks of the server) >> >> The patch was manually verified using reproducer attached to issue. > > Hi Jan, > > I ran the reproducer long back on my Linux box(Ubuntu 1604) on apacheDS 2 > and it was not reproducible at my end. can you please let us know your > environment detail. > Thanks, > Vyom > >> On Wed, Apr 4, 2018 at 4:12 PM, Jan Kalina wrote: >>> >>> Hi, >>> I has prepared trivial patch for bug JDK-8176553, >>> which I would like to get reviewed and sponsored. >>> >>> I am covered by Red Hat OCA. >>> >>> The bug affects upstream, JDK9 and JDK8 too. >>> >>> The reproducer is available in issue tracker: >>> https://bugs.openjdk.java.net/browse/JDK-8176553 >>> >>> PATCH: >>> ---------------------------------------------- >>> diff --git >>> a/src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java >>> >>> b/src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java >>> --- >>> a/src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java >>> +++ >>> b/src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java >>> @@ -312,7 +312,8 @@ >>> >>> if ((refEx != null) && >>> (refEx.hasMoreReferrals() || >>> - refEx.hasMoreReferralExceptions())) { >>> + refEx.hasMoreReferralExceptions()) && >>> + ! (errEx instanceof LimitExceededException)) { >>> >>> if (homeCtx.handleReferrals == LdapClient.LDAP_REF_THROW) { >>> throw (NamingException)(refEx.fillInStackTrace()); >>> ---------------------------------------------- >>> >>> Thanks, >>> Jan Kalina > > From jkalina at redhat.com Wed Apr 4 16:09:54 2018 From: jkalina at redhat.com (Jan Kalina) Date: Wed, 4 Apr 2018 18:09:54 +0200 Subject: RFR: [PATCH] 8176553 Fix LDAP referral loop In-Reply-To: References: <5AC4F0B5.3080302@oracle.com> Message-ID: Just note the LDIF expect the LDAP server running at: ldap://localhost:10389/dc=example,dc=com The "ref" needs to reference the same server to create referrals loop. If you are unable to reproduce, does it produce LimitExceededException for you? On Wed, Apr 4, 2018 at 6:05 PM, Jan Kalina wrote: > On Fedora 27, using latest Apache Directory Studio > (ApacheDirectoryStudio-2.0.0.v20170904-M13-linux.gtk.x86_64.tar.gz) > created new Apache DS 2.0.0, imported referrals.ldif > and running JI9048012.java: > > export JAVA_HOME=/opt/jdk-9_linux-x64_bin/ > $JAVA_HOME/bin/java JI9048012 >>>>ou=test >>>> >>>>ldap://localhost:10389/ou=test,dc=example,dc=com >>>>ldap://localhost:10389/dc=example,dc=com >>>>ldap://localhost:10389/ou=test,dc=example,dc=com >>>>ldap://localhost:10389/dc=example,dc=com >>>>ldap://localhost:10389/ou=test,dc=example,dc=com >>>>ldap://localhost:10389/dc=example,dc=com >>>>ldap://localhost:10389/ou=test,dc=example,dc=com >>>>ldap://localhost:10389/dc=example,dc=com >>>>ldap://localhost:10389/ou=test,dc=example,dc=com >>>>ldap://localhost:10389/dc=example,dc=com > > Output continues indefinitely, while LimitExceededException is EXPECTED, > but it does not occur. > > On Wed, Apr 4, 2018 at 5:35 PM, Vyom Tewari wrote: >> >> >> On 4/4/2018 8:59 PM, Jan Kalina wrote: >>> >>> Note: Test is not included, as it would require running LDAP server. >>> (existing ldap tests in JDK use only mocks of the server) >>> >>> The patch was manually verified using reproducer attached to issue. >> >> Hi Jan, >> >> I ran the reproducer long back on my Linux box(Ubuntu 1604) on apacheDS 2 >> and it was not reproducible at my end. can you please let us know your >> environment detail. >> Thanks, >> Vyom >> >>> On Wed, Apr 4, 2018 at 4:12 PM, Jan Kalina wrote: >>>> >>>> Hi, >>>> I has prepared trivial patch for bug JDK-8176553, >>>> which I would like to get reviewed and sponsored. >>>> >>>> I am covered by Red Hat OCA. >>>> >>>> The bug affects upstream, JDK9 and JDK8 too. >>>> >>>> The reproducer is available in issue tracker: >>>> https://bugs.openjdk.java.net/browse/JDK-8176553 >>>> >>>> PATCH: >>>> ---------------------------------------------- >>>> diff --git >>>> a/src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java >>>> >>>> b/src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java >>>> --- >>>> a/src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java >>>> +++ >>>> b/src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java >>>> @@ -312,7 +312,8 @@ >>>> >>>> if ((refEx != null) && >>>> (refEx.hasMoreReferrals() || >>>> - refEx.hasMoreReferralExceptions())) { >>>> + refEx.hasMoreReferralExceptions()) && >>>> + ! (errEx instanceof LimitExceededException)) { >>>> >>>> if (homeCtx.handleReferrals == LdapClient.LDAP_REF_THROW) { >>>> throw (NamingException)(refEx.fillInStackTrace()); >>>> ---------------------------------------------- >>>> >>>> Thanks, >>>> Jan Kalina >> >> From paul.sandoz at oracle.com Wed Apr 4 16:41:46 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 4 Apr 2018 09:41:46 -0700 Subject: RFR: 8164781: Pattern.asPredicate specification is incomplete In-Reply-To: References: <99502bca-28b8-4d29-a5d7-7a2cae0c829a@default> <9FED94A2-7351-4374-9139-0AB8ADBBFCC8@oracle.com> Message-ID: <65822972-87F7-4313-B6F8-A90E35579CF4@oracle.com> > On Apr 3, 2018, at 11:54 PM, Vivek Theeyarath wrote: > > Hi, > I have incorporated the changes as per the feedback and here is the updated webrev . > http://cr.openjdk.java.net/~rraghavan/8164781/webrev.02/ . > Bug: https://bugs.openjdk.java.net/browse/JDK-8164781 > +1 I know it?s picky, but would you mind sticking closer to the existing line length in the source file (no need for another review) Did you run the jtreg test to verify it passes? I missed the problem initially, glad Stuart caught it, but i presume the test would of reported a failure? if not there is something wrong with the test itself that should be investigated. > Here is the related csr https://bugs.openjdk.java.net/browse/JDK-8200603 > Ok, i tweaked some of the information (after creating a CSR one often needs to edit it to fill in the gaps). Can you blockquote the markdown for the embedded patch since the formatting is all messed up? Thanks, Paul. > I will try to address Uwe's point with a fix separately. > > Regards > Vivek > -----Original Message----- > From: Stuart Marks > Sent: Wednesday, April 04, 2018 6:13 AM > To: Vivek Theeyarath > Cc: Paul Sandoz ; Core-Libs-Dev > Subject: Re: RFR: 8164781: Pattern.asPredicate specification is incomplete > > Hi Vivek, > > Thanks for taking on this task. > > In case it wasn't clear from Paul's mail, what I think you should do is continue with this fix as a doc-only (and test-only) change, and not modify the behavior of this method. Doing that would be an incompatible change. > > Uwe's point is a reasonable one, which is that you can't tell from the method name "asPredicate" whether it uses find() or match() semantics. Oh well, I think we just have to live with this, and document it clearly. > > Adding a method to create a Predicate that has match() semantics would be a fine task to consider separately. > > Also, in RegExTest.java, > > 4686 if (p.test("word1234")) { > 4687 failCount++; > 4688 } > > I think the logic should be negated, as the predicate should properly find the pattern in this string. > > Thanks, > > s'marks > > On 4/2/18 10:56 AM, Paul Sandoz wrote: >> Hi, >> >> Looks good, expect for: >> >> 5823 * @return The predicate which can be used for finding on a string >> >> ?finding on a? ? is a little awkward to parse . I recommend to either change it back, since the first sentence of the method doc says what it means by matches, or being a little more verbose: >> >> The predicate which can be used for finding a match on a >> subsequence of a string >> >> You will need a CSR to document the clarification in specification behavior. >> >> ? >> >> To Uwe?s point, we could have chosen a more descriptive method name, e.g. asFinding/Predicate, leaving logical space for say any future asMatching/Predicate if we chose to add it. >> >> Paul. >> >> >>> On Apr 1, 2018, at 1:11 AM, Vivek Theeyarath wrote: >>> >>> Hi all, >>> >>> Please review. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164781 >>> >>> Webrev: http://cr.openjdk.java.net/~rraghavan/8164781/webrev.01/ >>> >>> >>> >>> Regards >>> >>> Vivek >> From vivek.theeyarath at oracle.com Wed Apr 4 17:47:37 2018 From: vivek.theeyarath at oracle.com (Vivek Theeyarath) Date: Wed, 4 Apr 2018 10:47:37 -0700 (PDT) Subject: RFR: 8184692: add Pattern.asMatchPredicate Message-ID: <74681017-e7fe-47e8-89ef-d804c9e5e77b@default> Hi All, Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8184692 Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.00/ The related jtreg test was run and the test passed . Regards Vivek From ivan.gerasimov at oracle.com Wed Apr 4 23:54:15 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 4 Apr 2018 16:54:15 -0700 Subject: RFR 8200696 : Optimal initial capacity of java.lang.Class.enumConstantDirectory In-Reply-To: <0bc0a442-e9a4-3f62-50c8-57e76f09743b@oracle.com> References: <640dfbab-6eec-b3e3-1b60-559c6137fc3c@oracle.com> <0bc0a442-e9a4-3f62-50c8-57e76f09743b@oracle.com> Message-ID: <3d4b61fa-5f6a-689c-d47e-7654f88ca1e6@oracle.com> Thanks David and Claes! I changed the expression to (int)(universe.length / 0.75f) + 1 before pushing the fix and updated the Jira bug with more details. With kind regards, Ivan On 4/3/18 11:56 PM, Claes Redestad wrote: > Hi Ivan, > > looks good. > > Nit: maybe (int)(universe.length / 0.75f) + 1 to keep fp arithmetic to > a minimum. > > /Claes > > On 2018-04-04 01:22, Ivan Gerasimov wrote: >> Hello! >> >> Yet another occurrence of not-optimally pre-sized HashMap. >> >> When java.lang.Class.enumConstantDirectory is created, the initial >> capacity is set to be (2 * universe.length), which is more than >> necessary in some cases. >> >> Choosing the capacity optimally will allow us to save a few bytes >> with some enum classes. >> >> Would you please help review this trivial fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200696 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8200696/00/webrev/ >> > > -- With kind regards, Ivan Gerasimov From andrey.x.nazarov at oracle.com Thu Apr 5 00:09:28 2018 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Wed, 4 Apr 2018 17:09:28 -0700 Subject: RFR: 8196750 [Testbug] tools/launcher tests need to tolerate unrelated warnings In-Reply-To: <5AB3BB30.3010305@oracle.com> References: <24606B9C-62ED-47F4-9805-EA9F6EEB47CF@oracle.com> <84decb80-8b3c-bf61-d6f7-6deaa8bcb9ea@oracle.com> <5AB3BB30.3010305@oracle.com> Message-ID: <60F33AFF-5705-4E60-9530-EBBA3A9DA91F@oracle.com> > On 22 Mar 2018, at 07:18, Kumar Srinivasan wrote: > > David, > > Why would the VM emit these warnings if the deprecated vm flag > is not being used ? > > Andrey, > As for the reviews I am ok with InfoStreams, wrt. ToolOpts it is not at all apparent, > maybe more comments explaining what is going on ? Added more comments. see http://cr.openjdk.java.net/~anazarov/JDK-8196750/webrev.02/ > > Kumar > > >> Hi Andrei, >> >> On 22/03/2018 11:12 AM, Andrey Nazarov wrote: >>> Hi, >>> >>> Please review fix in launcher tests. >>> >>> Review: http://cr.openjdk.java.net/~anazarov/JDK-8196750/webrev/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196750?filter=-1 >> >> test/jdk/tools/launcher/ToolsOpts.java >> >> I don't understand how the change fixes the problem. IIUC the problem is that the test expects the output to consist of the command-line passed to the tool. Instead if it contains a Warning from the VM, it won't match and so we fail. The new code no longer uses a String[] and no longer assumes that output[i] == args[i], but it still searches the current "output" value for a match with one of the args. But that will still fail if what we actually have is a Warning. ?? I would have expected to see the Warning strings filtered out more directly. >> >> The other test change seems reasonable. >> >> Thanks, >> David >> >>> ?Thanks, >>> Andrei >>> > From jonathan.gibbons at oracle.com Thu Apr 5 00:21:16 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 04 Apr 2018 17:21:16 -0700 Subject: RFR: 8200888: typo in name of exception in @throws Message-ID: <5AC56BFC.5090200@oracle.com> Please review this tiny fix to a typo in the name of an exception in @throws: No webrev; here's the change: NullPointerExcpetion -> NullPointerException diff -r 3930c4d4f805 src/java.base/share/classes/java/text/ChoiceFormat.java --- a/src/java.base/share/classes/java/text/ChoiceFormat.java Wed Apr 04 14:42:53 2018 -0700 +++ b/src/java.base/share/classes/java/text/ChoiceFormat.java Wed Apr 04 17:12:53 2018 -0700 @@ -312,7 +312,7 @@ * Constructs with limits and corresponding formats based on the pattern. * * @param newPattern the new pattern string - * @exception NullPointerExcpetion if {@code newPattern} is + * @exception NullPointerException if {@code newPattern} is * {@code null} * @see #applyPattern */ JBS: https://bugs.openjdk.java.net/browse/JDK-8200888 -- Jon From brian.burkhalter at oracle.com Thu Apr 5 00:23:02 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 4 Apr 2018 17:23:02 -0700 Subject: RFR: 8200888: typo in name of exception in @throws In-Reply-To: <5AC56BFC.5090200@oracle.com> References: <5AC56BFC.5090200@oracle.com> Message-ID: +1 Brian On Apr 4, 2018, at 5:21 PM, Jonathan Gibbons wrote: > Please review this tiny fix to a typo in the name of an exception in @throws: > > [?] > > JBS: https://bugs.openjdk.java.net/browse/JDK-8200888 From joe.darcy at oracle.com Thu Apr 5 00:24:08 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 04 Apr 2018 17:24:08 -0700 Subject: RFR: 8200888: typo in name of exception in @throws In-Reply-To: <5AC56BFC.5090200@oracle.com> References: <5AC56BFC.5090200@oracle.com> Message-ID: <5AC56CA8.1080901@oracle.com> Looks fine; even better if @exception is replaced with @throws :-) -Joe On 4/4/2018 5:21 PM, Jonathan Gibbons wrote: > Please review this tiny fix to a typo in the name of an exception in > @throws: > > No webrev; here's the change: NullPointerExcpetion -> > NullPointerException > > diff -r 3930c4d4f805 > src/java.base/share/classes/java/text/ChoiceFormat.java > --- a/src/java.base/share/classes/java/text/ChoiceFormat.java Wed Apr > 04 14:42:53 2018 -0700 > +++ b/src/java.base/share/classes/java/text/ChoiceFormat.java Wed Apr > 04 17:12:53 2018 -0700 > @@ -312,7 +312,7 @@ > * Constructs with limits and corresponding formats based on the > pattern. > * > * @param newPattern the new pattern string > - * @exception NullPointerExcpetion if {@code newPattern} is > + * @exception NullPointerException if {@code newPattern} is > * {@code null} > * @see #applyPattern > */ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8200888 > > -- Jon From jonathan.gibbons at oracle.com Thu Apr 5 00:47:40 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 04 Apr 2018 17:47:40 -0700 Subject: RFR: 8200888: typo in name of exception in @throws In-Reply-To: <5AC56CA8.1080901@oracle.com> References: <5AC56BFC.5090200@oracle.com> <5AC56CA8.1080901@oracle.com> Message-ID: <5AC5722C.4060607@oracle.com> Thanks, Joe, The use of @exception is pervasive in this file, so I think consistency wins over localized stylistic changes. But yes, maybe we should do more global updates at some point. -- Jon On 04/04/2018 05:24 PM, Joseph D. Darcy wrote: > Looks fine; even better if @exception is replaced with @throws :-) > > -Joe > > On 4/4/2018 5:21 PM, Jonathan Gibbons wrote: >> Please review this tiny fix to a typo in the name of an exception in >> @throws: >> >> No webrev; here's the change: NullPointerExcpetion -> >> NullPointerException >> >> diff -r 3930c4d4f805 >> src/java.base/share/classes/java/text/ChoiceFormat.java >> --- a/src/java.base/share/classes/java/text/ChoiceFormat.java Wed Apr >> 04 14:42:53 2018 -0700 >> +++ b/src/java.base/share/classes/java/text/ChoiceFormat.java Wed Apr >> 04 17:12:53 2018 -0700 >> @@ -312,7 +312,7 @@ >> * Constructs with limits and corresponding formats based on the >> pattern. >> * >> * @param newPattern the new pattern string >> - * @exception NullPointerExcpetion if {@code newPattern} is >> + * @exception NullPointerException if {@code newPattern} is >> * {@code null} >> * @see #applyPattern >> */ >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8200888 >> >> -- Jon > From martinrb at google.com Thu Apr 5 03:47:15 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 4 Apr 2018 20:47:15 -0700 Subject: RFR: More cleanup patches In-Reply-To: <9244499d-625e-e191-4304-9e37f12dbfee@oracle.com> References: <9244499d-625e-e191-4304-9e37f12dbfee@oracle.com> Message-ID: On Fri, Mar 30, 2018 at 3:53 AM, Alan Bateman wrote: > > 8200125: Fix some classloader/module typos >> http://cr.openjdk.java.net/~martin/webrevs/jdk/loader-typos/ >> https://bugs.openjdk.java.net/browse/JDK-8200125 >> > Most of these are okay but you've dropped the text "defined to this > ClassLoader" from the findClassInModuleOrNull methods. Can we leave that > text as they really mean "this" class loader, these methods do not delegate. OK, I'm dropping that part of the change. From martinrb at google.com Thu Apr 5 04:24:39 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 4 Apr 2018 21:24:39 -0700 Subject: RFR 8200696 : Optimal initial capacity of java.lang.Class.enumConstantDirectory In-Reply-To: <3d4b61fa-5f6a-689c-d47e-7654f88ca1e6@oracle.com> References: <640dfbab-6eec-b3e3-1b60-559c6137fc3c@oracle.com> <0bc0a442-e9a4-3f62-50c8-57e76f09743b@oracle.com> <3d4b61fa-5f6a-689c-d47e-7654f88ca1e6@oracle.com> Message-ID: Hi Ivan, I'm seeing [2018-04-04 20:56:11,999] Agent[1]: stderr: WARNING: An illegal reflective access operation has occurred [2018-04-04 20:56:11,999] Agent[1]: stderr: WARNING: Illegal reflective access by jdk.testlibrary.OptimalCapacity (file:/tmp/jtr-BHhgGo/classes/lib/testlibrary/) to field java.util.HashMap.table [2018-04-04 20:56:11,999] Agent[1]: stderr: WARNING: Please consider reporting this to the maintainers of jdk.testlibrary.OptimalCapacity which seems likely a result of this change? On Wed, Apr 4, 2018 at 4:54 PM, Ivan Gerasimov wrote: > Thanks David and Claes! > > I changed the expression to (int)(universe.length / 0.75f) + 1 before > pushing the fix and updated the Jira bug with more details. > > With kind regards, > > Ivan > > > > On 4/3/18 11:56 PM, Claes Redestad wrote: > >> Hi Ivan, >> >> looks good. >> >> Nit: maybe (int)(universe.length / 0.75f) + 1 to keep fp arithmetic to a >> minimum. >> >> /Claes >> >> On 2018-04-04 01:22, Ivan Gerasimov wrote: >> >>> Hello! >>> >>> Yet another occurrence of not-optimally pre-sized HashMap. >>> >>> When java.lang.Class.enumConstantDirectory is created, the initial >>> capacity is set to be (2 * universe.length), which is more than necessary >>> in some cases. >>> >>> Choosing the capacity optimally will allow us to save a few bytes with >>> some enum classes. >>> >>> Would you please help review this trivial fix? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200696 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8200696/00/webrev/ >>> >>> >> >> > -- > With kind regards, > Ivan Gerasimov > > From ivan.gerasimov at oracle.com Thu Apr 5 06:49:52 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 4 Apr 2018 23:49:52 -0700 Subject: RFR 8200696 : Optimal initial capacity of java.lang.Class.enumConstantDirectory In-Reply-To: References: <640dfbab-6eec-b3e3-1b60-559c6137fc3c@oracle.com> <0bc0a442-e9a4-3f62-50c8-57e76f09743b@oracle.com> <3d4b61fa-5f6a-689c-d47e-7654f88ca1e6@oracle.com> Message-ID: Hi Martin! Ah bummer! Missing @modules java.base/java.util:open in the test. Sorry about that. Let me fix it with the fix for a similar issue JDK-8200788 that I've just filed. With kind regards, Ivan On 4/4/18 9:24 PM, Martin Buchholz wrote: > Hi Ivan, > I'm seeing > > [2018-04-04 20:56:11,999] Agent[1]: stderr: WARNING: An illegal > reflective access operation has occurred > [2018-04-04 20:56:11,999] Agent[1]: stderr: WARNING: Illegal > reflective access by jdk.testlibrary.OptimalCapacity > (file:/tmp/jtr-BHhgGo/classes/lib/testlibrary/) to field > java.util.HashMap.table > [2018-04-04 20:56:11,999] Agent[1]: stderr: WARNING: Please consider > reporting this to the maintainers of jdk.testlibrary.OptimalCapacity > > which seems likely a result of this change? > > On Wed, Apr 4, 2018 at 4:54 PM, Ivan Gerasimov > > wrote: > > Thanks David and Claes! > > I changed the expression to (int)(universe.length / 0.75f) + 1 > before pushing the fix and updated the Jira bug with more details. > > With kind regards, > > Ivan > > > > On 4/3/18 11:56 PM, Claes Redestad wrote: > > Hi Ivan, > > looks good. > > Nit: maybe (int)(universe.length / 0.75f) + 1 to keep fp > arithmetic to a minimum. > > /Claes > > On 2018-04-04 01:22, Ivan Gerasimov wrote: > > Hello! > > Yet another occurrence of not-optimally pre-sized HashMap. > > When java.lang.Class.enumConstantDirectory is created, the > initial capacity is set to be (2 * universe.length), which > is more than necessary in some cases. > > Choosing the capacity optimally will allow us to save a > few bytes with some enum classes. > > Would you please help review this trivial fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200696 > > WEBREV: > http://cr.openjdk.java.net/~igerasim/8200696/00/webrev/ > > > > > > -- > With kind regards, > Ivan Gerasimov > > -- With kind regards, Ivan Gerasimov From ivan.gerasimov at oracle.com Thu Apr 5 07:04:56 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 5 Apr 2018 00:04:56 -0700 Subject: RFR 8200788 : Optimal initial capacity of java.lang.VarHandle.AccessMode.methodNameToAccessMode Message-ID: <3f2db600-6960-50ff-c42f-8a753a4b8ad5@oracle.com> Hello! Yet another HashMap that can be preallocated more accurately. Currently, the map is created as the following: // Initial capacity of # values is sufficient to avoid resizes // for the smallest table size (32) methodNameToAccessMode = new HashMap<>(AccessMode.values().length); Even though the comment suggests that no resizes of the table should occur, in fact the threshold is calculated as 32 * 0.75 = 24, so when 24th element is inserted then the internal storage is reallocated and the content of the table is reinserted. Also, a missing @modules line is added to the regression test that was pushed with the fix for JDK-8200696. Would you please help review this? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200788 WEBREV: http://cr.openjdk.java.net/~igerasim/8200788/00/webrev/ -- With kind regards, Ivan Gerasimov From andrew_m_leonard at uk.ibm.com Thu Apr 5 09:49:09 2018 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 5 Apr 2018 10:49:09 +0100 Subject: RFR: Export InitializeEncoding for JVM access Message-ID: Hi Roger, The OpenJ9 VM implementation provides its own java.lang.System, which performs similar type early-on VM initialization to the OpenJDK core library classes. The basic reason for invoking the method is to initialize the platform encoding either called from a related core library method, eg.initProperties(), or from the VM in the early stages of initialization. My suggested comparison with canonicalize was based on it's indicated usage: /* * Export the platform dependent path canonicalization so that * VM can find it when loading system classes. * This function is also used by the instrumentation agent. */ extern int canonicalize(char *path, const char *out, int len); JNIEXPORT int Canonicalize(JNIEnv *unused, char *orig, char *out, int len) { /* canonicalize an already natived path */ return canonicalize(orig, out, len); } Many thanks, Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From vivek.theeyarath at oracle.com Thu Apr 5 10:34:33 2018 From: vivek.theeyarath at oracle.com (Vivek Theeyarath) Date: Thu, 5 Apr 2018 03:34:33 -0700 (PDT) Subject: RFR: 8164781: Pattern.asPredicate specification is incomplete In-Reply-To: <65822972-87F7-4313-B6F8-A90E35579CF4@oracle.com> References: <99502bca-28b8-4d29-a5d7-7a2cae0c829a@default> <9FED94A2-7351-4374-9139-0AB8ADBBFCC8@oracle.com> <65822972-87F7-4313-B6F8-A90E35579CF4@oracle.com> Message-ID: >> >> Hi, >> I have incorporated the changes as per the feedback and here is the updated webrev . >> http://cr.openjdk.java.net/~rraghavan/8164781/webrev.02/ . >>Bug: https://bugs.openjdk.java.net/browse/JDK-8164781 >> >+1 Thanks Paul >I know it?s picky, but would you mind sticking closer to the existing line length in the source file >(no need for another review) Here is my attempt. Hope it is better now. http://cr.openjdk.java.net/~rraghavan/8164781/webrev.03 >Did you run the jtreg test to verify it passes? I missed the problem initially, glad Stuart caught it, but i presume the test would of reported a failure? if not there is something wrong with the test itself that should be investigated. I missed it earlier. As you rightly pointed out, without Stuart's inputs the test fails and it passes with it as expected. >> Here is the related csr https://bugs.openjdk.java.net/browse/JDK-8200603 >> >Ok, i tweaked some of the information (after creating a CSR one often needs to edit it to fill in the gaps). >Can you blockquote the markdown for the embedded patch since the formatting is all messed up? I have restored the formatting. Hope it would suffice. https://bugs.openjdk.java.net/browse/JDK-8200603 Regards Vivek From claes.redestad at oracle.com Thu Apr 5 13:03:56 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 5 Apr 2018 15:03:56 +0200 Subject: RFR 8200788 : Optimal initial capacity of java.lang.VarHandle.AccessMode.methodNameToAccessMode In-Reply-To: <3f2db600-6960-50ff-c42f-8a753a4b8ad5@oracle.com> References: <3f2db600-6960-50ff-c42f-8a753a4b8ad5@oracle.com> Message-ID: Hi, looks ok, but the cost/benefit ration of adding a standalone regression test for every such inefficiency seems dubious to me. Could we group these together, somewhere? Bonus startup points if you rewrote so that AccessMode.values() is only called once, since it clones the backing array. /Claes On 2018-04-05 09:04, Ivan Gerasimov wrote: > Hello! > > Yet another HashMap that can be preallocated more accurately. > > Currently, the map is created as the following: > ??????????? // Initial capacity of # values is sufficient to avoid > resizes > ??????????? // for the smallest table size (32) > ??????????? methodNameToAccessMode = new > HashMap<>(AccessMode.values().length); > > Even though the comment suggests that no resizes of the table should > occur, in fact the threshold is calculated as 32 * 0.75 = 24, so when > 24th element is inserted then the internal storage is reallocated and > the content of the table is reinserted. > > Also, a missing @modules line is added to the regression test that was > pushed with the fix for JDK-8200696. > > Would you please help review this? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200788 > WEBREV: http://cr.openjdk.java.net/~igerasim/8200788/00/webrev/ > From roger.riggs at oracle.com Thu Apr 5 13:04:41 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 5 Apr 2018 09:04:41 -0400 Subject: RFR: 8164781: Pattern.asPredicate specification is incomplete In-Reply-To: References: <99502bca-28b8-4d29-a5d7-7a2cae0c829a@default> <9FED94A2-7351-4374-9139-0AB8ADBBFCC8@oracle.com> <65822972-87F7-4313-B6F8-A90E35579CF4@oracle.com> Message-ID: <6a065c19-7ee9-5d9f-2a6a-606a73e5647d@oracle.com> Hi Vivek, Can we do something to make the first sentence less confusing? How about: * Creates a predicate that tests a given input string for a subsequence that matches this pattern. -or- * Creates a predicate that tests if this pattern is found in a given input string. Thanks, Roger On 4/5/18 6:34 AM, Vivek Theeyarath wrote: >>> Hi, >>> I have incorporated the changes as per the feedback and here is the updated webrev . >>> http://cr.openjdk.java.net/~rraghavan/8164781/webrev.02/ . >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164781 >>> >> +1 > Thanks Paul > >> I know it?s picky, but would you mind sticking closer to the existing line length in the source file >> (no need for another review) > Here is my attempt. Hope it is better now. http://cr.openjdk.java.net/~rraghavan/8164781/webrev.03 > >> Did you run the jtreg test to verify it passes? I missed the problem initially, glad Stuart caught it, but i presume the test would of reported a failure? if not there is something wrong with the test itself that should be investigated. > > I missed it earlier. As you rightly pointed out, without Stuart's inputs the test fails and it passes with it as expected. > >>> Here is the related csr https://bugs.openjdk.java.net/browse/JDK-8200603 >>> >> Ok, i tweaked some of the information (after creating a CSR one often needs to edit it to fill in the gaps). >> Can you blockquote the markdown for the embedded patch since the formatting is all messed up? > I have restored the formatting. Hope it would suffice. > https://bugs.openjdk.java.net/browse/JDK-8200603 > > Regards > Vivek From claes.redestad at oracle.com Thu Apr 5 13:42:29 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 5 Apr 2018 15:42:29 +0200 Subject: RFR: 8201178: Remove sun.nio.cs.FastCharsetProvider Message-ID: <01647ef0-72b0-2270-6d42-29616b40f382@oracle.com> Hi, since JDK-8073152 sun.nio.cs.FastCharsetProvider is unused and can be removed. Patch: hg rm src/java.base/share/classes/sun/nio/cs/FastCharsetProvider.java Bug: https://bugs.openjdk.java.net/browse/JDK-8201178 Thanks! /Claes From Alan.Bateman at oracle.com Thu Apr 5 15:04:32 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 Apr 2018 16:04:32 +0100 Subject: RFR: 8201178: Remove sun.nio.cs.FastCharsetProvider In-Reply-To: <01647ef0-72b0-2270-6d42-29616b40f382@oracle.com> References: <01647ef0-72b0-2270-6d42-29616b40f382@oracle.com> Message-ID: <64703880-2120-20c9-e713-4d653397c2bc@oracle.com> On 05/04/2018 14:42, Claes Redestad wrote: > Hi, > > since JDK-8073152 sun.nio.cs.FastCharsetProvider is unused and can be > removed. > > Patch: > hg rm src/java.base/share/classes/sun/nio/cs/FastCharsetProvider.java > > Bug: https://bugs.openjdk.java.net/browse/JDK-8201178 I don't see any references to it (checked the tests too) so I think it's safe to remove it. -Alan From shade at redhat.com Thu Apr 5 15:33:40 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 5 Apr 2018 17:33:40 +0200 Subject: RFR [10] 8194554: filterArguments runs multiple filters in the wrong order Message-ID: Hi, Please review this jdk10 backport. Original JDK 11 bug: https://bugs.openjdk.java.net/browse/JDK-8194554 Original JDK 11 fix: http://hg.openjdk.java.net/jdk/jdk/rev/050352ed64d5 Please note the discussion in JBS comments about the issue. It seems to include the more verbose specification text, and Rob says it makes the patch not directly backportable. Therefore, requesting to backport without the Javadoc change. I just dropped that single line from the original changeset: 8194554: filterArguments runs multiple filters in the wrong order Reviewed-by: psandoz, jrose diff -r b09e56145e11 -r ab2dc3096cdb src/java.base/share/classes/java/lang/invoke/MethodHandles.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Thu Mar 08 04:23:31 2018 +0000 +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Wed Jan 17 15:17:50 2018 -0800 @@ -3836,11 +3836,12 @@ MethodHandle filterArguments(MethodHandle target, int pos, MethodHandle... filters) { filterArgumentsCheckArity(target, pos, filters); MethodHandle adapter = target; - int curPos = pos-1; // pre-incremented - for (MethodHandle filter : filters) { - curPos += 1; + // process filters in reverse order so that the invocation of + // the resulting adapter will invoke the filters in left-to-right order + for (int i = filters.length - 1; i >= 0; --i) { + MethodHandle filter = filters[i]; if (filter == null) continue; // ignore null elements of filters - adapter = filterArgument(adapter, curPos, filter); + adapter = filterArgument(adapter, pos + i, filter); } return adapter; } diff -r b09e56145e11 -r ab2dc3096cdb test/jdk/java/lang/invoke/FilterArgumentsTest.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/jdk/java/lang/invoke/FilterArgumentsTest.java Wed Jan 17 15:17:50 2018 -0800 @@ -0,0 +1,132 @@ +/* + * Copyright (c) 2018, 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. + * + * 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. + */ + +/* + * @test + * @bug 8194554 + * @run testng/othervm test.java.lang.invoke.FilterArgumentsTest + */ + +package test.java.lang.invoke; + +import java.lang.invoke.MethodHandle; +import java.lang.invoke.MethodHandles; +import java.util.ArrayList; +import java.util.List; + +import static java.lang.invoke.MethodHandles.*; +import static java.lang.invoke.MethodType.methodType; + +import org.testng.annotations.*; +import static org.testng.Assert.*; + +public class FilterArgumentsTest { + + @Test + public static void testFilterA_B_C() throws Throwable { + FilterTest test = new FilterTest( + filterArguments(MH_TEST, 0, MH_FILTER_A, MH_FILTER_B, MH_FILTER_C)); + test.run(List.of("A", "B", "C")); + } + + @Test + public static void testFilterA_B() throws Throwable { + FilterTest test = new FilterTest( + filterArguments(MH_TEST, 0, MH_FILTER_A, MH_FILTER_B)); + test.run(List.of("A", "B")); + } + + @Test + public static void testFilterB_C() throws Throwable { + FilterTest test = new FilterTest( + filterArguments(MH_TEST, 1, MH_FILTER_B, MH_FILTER_C)); + test.run(List.of("B", "C")); + } + + @Test + public static void testFilterB() throws Throwable { + FilterTest test = new FilterTest(filterArguments(MH_TEST, 1, MH_FILTER_B)); + test.run(List.of("B")); + } + + @Test + public static void testFilterC() throws Throwable { + FilterTest test = new FilterTest(filterArguments(MH_TEST, 2, MH_FILTER_C)); + test.run(List.of("C")); + } + + static class FilterTest { + static List filters = new ArrayList<>(); + + final MethodHandle mh; + FilterTest(MethodHandle mh) { + this.mh = mh; + } + + void run(List expected) throws Throwable { + filters.clear(); + assertEquals("x-0-z", (String)mh.invokeExact("x", 0, 'z')); + assertEquals(expected, filters); + } + + static String filterA(String s) { + filters.add("A"); + return s; + } + + static int filterB(int value) { + filters.add("B"); + return value; + } + + static char filterC(char c) { + filters.add("C"); + return c; + } + + static String test(String s, int i, char c) { + return s + "-" + i + "-" + c; + } + } + + static final MethodHandle MH_TEST; + static final MethodHandle MH_FILTER_A; + static final MethodHandle MH_FILTER_B; + static final MethodHandle MH_FILTER_C; + static final Lookup LOOKUP = MethodHandles.lookup(); + + static { + try { + MH_TEST = LOOKUP.findStatic(FilterTest.class, "test", + methodType(String.class, String.class, int.class, char.class)); + MH_FILTER_A = LOOKUP.findStatic(FilterTest.class, "filterA", + methodType(String.class, String.class)); + MH_FILTER_B = LOOKUP.findStatic(FilterTest.class, "filterB", + methodType(int.class, int.class)); + MH_FILTER_C = LOOKUP.findStatic(FilterTest.class, "filterC", + methodType(char.class, char.class)); + } catch (Exception e) { + throw new RuntimeException(e); + } + } +} Thanks, -Aleksey From martinrb at google.com Thu Apr 5 16:43:20 2018 From: martinrb at google.com (Martin Buchholz) Date: Thu, 5 Apr 2018 09:43:20 -0700 Subject: RFR: jsr166 jdk integration 2018-04 Message-ID: http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html 8200728: Docs (Comparison of Stack and Deque methods) for Deque is not correct' src/main/java/util/Deque.java http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/Deque-Stack/index.html https://bugs.openjdk.java.net/browse/JDK-8200728 8200520: forkjoin tasks interrupted after shutdown http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/ForkJoinPool-shutdown/index.html https://bugs.openjdk.java.net/browse/JDK-8200520 8200258: Improve CopyOnWriteArrayList subList code http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/CopyOnWriteArrayList-subList/index.html https://bugs.openjdk.java.net/browse/JDK-8200258 8197531: Miscellaneous changes imported from jsr166 CVS 2018-04 http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html https://bugs.openjdk.java.net/browse/JDK-8197531 From alexandr.miloslavskiy at gmail.com Mon Apr 2 21:50:28 2018 From: alexandr.miloslavskiy at gmail.com (Alexander Miloslavskiy) Date: Tue, 3 Apr 2018 00:50:28 +0300 Subject: 8194734 : Handle to jimage file inherited into child processes (win) Message-ID: The problem in this bug is that jimage file is mistakenly opened with "inherit by child processes" flag. In our case, the child process is started with Runtime.exec() and serves as updater that can also replace embedded JRE. However, due to jimage ("lib/modules") file handle being inherited, embedded JRE can not be replaced. The bug was introduced in commits "8087181: Move native jimage code to its own library (maybe libjimage)" Before this commit, os::open() was used in libjimage code and it handles file inheritance correctly, see: /hotspot/src/share/vm/classfile/imageFile.cpp * ImageFileReader::open() uses os::open(_name, 0, O_RDONLY) /hotspot/src/os/windows/vm/os_windows.cpp * os::open() calls to ::open(pathbuf, oflag | O_BINARY | O_NOINHERIT, mode); /hotspot/src/os/linux/vm/os_linux.cpp * os::open() uses both O_CLOEXEC and FD_CLOEXEC After this commit, a new osSupport::openReadOnly() is implemented and it does not handle file inheritance properly. Please find patch attached. As far as I understand from OpenJDK's "How to contribute" page, I need a "sponsor" who will get this patch applied. Windows - compiled and tested: Bug fixed. Ubuntu - compiled and tested: Bug did not occur before my patch due to another bug in childProcess() function (src/java.base/unix/native/libjava/childproc.c) According to my debugging, FD_CLOEXEC is applied to jimage file there because childProcess() thinks that it's a error pipe (FAIL_FILENO). Should the bug in childProcess() be fixed, it can unearth currently fixed bug. -------------- next part -------------- # HG changeset patch # User Alexander Miloslavskiy # Date 1522703926 -10800 # Tue Apr 03 00:18:46 2018 +0300 # Node ID 87954e967cc67cab4b480a4ec7ff54a334e0f4ce # Parent de0fd2c8a401a564f06d42fac15559154c42358a 8194734: jimage file descriptor was inherited into processes started with Runtime.exec() Summary: Prevented inheritance with FD_CLOEXEC on unix, O_NOINHERIT on windows. Refactoring: added O_RDONLY (equals 0) Refactoring: added O_BINARY on windows (currently ignored by osSupport::read and osSupport::map_memory) diff -r de0fd2c8a401 -r 87954e967cc6 src/java.base/unix/native/libjimage/osSupport_unix.cpp --- a/src/java.base/unix/native/libjimage/osSupport_unix.cpp Fri Mar 30 14:36:18 2018 -0700 +++ b/src/java.base/unix/native/libjimage/osSupport_unix.cpp Tue Apr 03 00:18:46 2018 +0300 @@ -38,7 +38,16 @@ * Return the file descriptor. */ jint osSupport::openReadOnly(const char *path) { - return ::open(path, 0); + int fd = ::open(path, O_RDONLY); + + // jimage file descriptors must not be inherited by child processes. + // This is especially true for child processes started with Runtime.exec (see 8194734) + #ifdef FD_CLOEXEC + int flags = ::fcntl(fd, F_GETFD); + ::fcntl(fd, F_SETFD, flags | FD_CLOEXEC); + #endif + + return fd; } /** diff -r de0fd2c8a401 -r 87954e967cc6 src/java.base/windows/native/libjimage/osSupport_windows.cpp --- a/src/java.base/windows/native/libjimage/osSupport_windows.cpp Fri Mar 30 14:36:18 2018 -0700 +++ b/src/java.base/windows/native/libjimage/osSupport_windows.cpp Tue Apr 03 00:18:46 2018 +0300 @@ -38,7 +38,9 @@ * Return the file descriptor. */ jint osSupport::openReadOnly(const char *path) { - return ::open(path, 0, 0); + // jimage file descriptors must not be inherited by child processes. + // This is especially true for child processes started with Runtime.exec (see 8194734) + return ::open(path, O_BINARY | O_NOINHERIT, O_RDONLY); } /** From cushon at google.com Thu Apr 5 17:57:55 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 05 Apr 2018 17:57:55 +0000 Subject: RFR 7183985: Class.getAnnotation() throws an ArrayStoreException when the annotation class not present In-Reply-To: References: <1f87dd21-701b-975c-a1c1-f1d9ed2f1eaf@oracle.com> <5A90B204.4070005@oracle.com> <5A960359.4070507@oracle.com> Message-ID: Hi, Is there any more feedback on the patch? On Wed, Feb 28, 2018 at 4:26 PM Liam Miller-Cushon wrote: > On Wed, Feb 28, 2018 at 4:13 PM, Martin Buchholz > wrote: > >> Follow their lead and rename your method to assertArrayEquals >> > > Done: http://cr.openjdk.java.net/~cushon/7183985/webrev.04/ > From kumar.x.srinivasan at oracle.com Thu Apr 5 18:49:00 2018 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 05 Apr 2018 11:49:00 -0700 Subject: RFR: 8196750 [Testbug] tools/launcher tests need to tolerate unrelated warnings In-Reply-To: <60F33AFF-5705-4E60-9530-EBBA3A9DA91F@oracle.com> References: <24606B9C-62ED-47F4-9805-EA9F6EEB47CF@oracle.com> <84decb80-8b3c-bf61-d6f7-6deaa8bcb9ea@oracle.com> <5AB3BB30.3010305@oracle.com> <60F33AFF-5705-4E60-9530-EBBA3A9DA91F@oracle.com> Message-ID: <5AC66F9C.9020308@oracle.com> Looks good, thanks for doing this!. Kumar On 4/4/2018 5:09 PM, Andrey Nazarov wrote: > >> On 22 Mar 2018, at 07:18, Kumar Srinivasan wrote: >> >> David, >> >> Why would the VM emit these warnings if the deprecated vm flag >> is not being used ? >> >> Andrey, >> As for the reviews I am ok with InfoStreams, wrt. ToolOpts it is not at all apparent, >> maybe more comments explaining what is going on ? > Added more comments. > see http://cr.openjdk.java.net/~anazarov/JDK-8196750/webrev.02/ >> Kumar >> >> >>> Hi Andrei, >>> >>> On 22/03/2018 11:12 AM, Andrey Nazarov wrote: >>>> Hi, >>>> >>>> Please review fix in launcher tests. >>>> >>>> Review: http://cr.openjdk.java.net/~anazarov/JDK-8196750/webrev/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196750?filter=-1 >>> test/jdk/tools/launcher/ToolsOpts.java >>> >>> I don't understand how the change fixes the problem. IIUC the problem is that the test expects the output to consist of the command-line passed to the tool. Instead if it contains a Warning from the VM, it won't match and so we fail. The new code no longer uses a String[] and no longer assumes that output[i] == args[i], but it still searches the current "output" value for a match with one of the args. But that will still fail if what we actually have is a Warning. ?? I would have expected to see the Warning strings filtered out more directly. >>> >>> The other test change seems reasonable. >>> >>> Thanks, >>> David >>> >>>> ?Thanks, >>>> Andrei >>>> From ivan.gerasimov at oracle.com Thu Apr 5 20:48:15 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 5 Apr 2018 13:48:15 -0700 Subject: RFR 8200788 : Optimal initial capacity of java.lang.VarHandle.AccessMode.methodNameToAccessMode In-Reply-To: References: <3f2db600-6960-50ff-c42f-8a753a4b8ad5@oracle.com> Message-ID: <5af75de9-068e-39ee-94fd-9cbc63631760@oracle.com> Thanks for review Claes! On 4/5/18 6:03 AM, Claes Redestad wrote: > Hi, > > looks ok, but the cost/benefit ration of adding a standalone > regression test for every > such inefficiency seems dubious to me. Could we group these together, > somewhere? > Yes, I agree that this kind of tests should be combined with other sanity checks. However, I think it would be better organized, if the tests are placed in the tested-class specific directory. So, if we have some other sanity tests for VarHandle.AccessMode, then they probably should be combined with this one to save resources. > Bonus startup points if you rewrote so that AccessMode.values() is > only called once, > since it clones the backing array. > Good point. I'll do that before pushing. With kind regards, Ivan > /Claes > > On 2018-04-05 09:04, Ivan Gerasimov wrote: >> Hello! >> >> Yet another HashMap that can be preallocated more accurately. >> >> Currently, the map is created as the following: >> // Initial capacity of # values is sufficient to avoid >> resizes >> // for the smallest table size (32) >> methodNameToAccessMode = new >> HashMap<>(AccessMode.values().length); >> >> Even though the comment suggests that no resizes of the table should >> occur, in fact the threshold is calculated as 32 * 0.75 = 24, so when >> 24th element is inserted then the internal storage is reallocated and >> the content of the table is reinserted. >> >> Also, a missing @modules line is added to the regression test that >> was pushed with the fix for JDK-8200696. >> >> Would you please help review this? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200788 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8200788/00/webrev/ >> > > -- With kind regards, Ivan Gerasimov From tprintezis at twitter.com Thu Apr 5 21:45:48 2018 From: tprintezis at twitter.com (Tony Printezis) Date: Thu, 5 Apr 2018 14:45:48 -0700 Subject: Promptly freeing the per-thread cached direct buffers when a thread exits Message-ID: Hi all, We recently hit another interesting issue with the NIO thread-local DirectByteBuffer cache. One of our services seems to create and drop threads at regular intervals. I assume this is due to a thread pool dynamically resizing itself. Let's say a thread starts, lives long enough for its Thread object to be promoted to the old gen (along with its cached direct buffer), then exits. This will result in its cached direct buffer(s) being unreachable in the old gen and will only be reclaimed after the next full GC / concurrent GC cycle. Interestingly, the service in question does concurrent GC cycles really infrequently (one every few days) as it has a really low promotion rate. This results in the JVM's total direct size constantly increasing (which is effectively a native buffer leak). Has anyone come across this issue before? There are a few obvious ways to mitigate this, e.g., cause a Full GC / concurrent GC cycle at regular intervals. However, the best solution IMHO is to explicitly free any direct buffers that are still in the cache when a thread exits. I'll be happy to implement this and test it internally at Twitter, if it's not on anyone else's radar. However, to do what I'm proposing I need some sort of thread exit hook. Unfortunately, there doesn't seem to be one. Would proposing to introduce thread exit hooks be reasonable? Or is everyone going to freak out? :-) The hooks can be either per-Thread or even per-ThreadLocal. And it's OK if the hooks can only be used within java.base. FWIW, I did a simple prototype of this (I call the hooks from Thread::exit) and it seems to work as expected. Any thoughts / feedback on this will be very appreciated. Thanks, Tony ????? Tony Printezis | @TonyPrintezis | tprintezis at twitter.com From david.holmes at oracle.com Thu Apr 5 22:07:19 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 6 Apr 2018 08:07:19 +1000 Subject: Promptly freeing the per-thread cached direct buffers when a thread exits In-Reply-To: References: Message-ID: <92e33b4e-a05d-47fe-e4d1-418f3dc4c2d4@oracle.com> Hi Tony, On 6/04/2018 7:45 AM, Tony Printezis wrote: > Hi all, > > We recently hit another interesting issue with the NIO thread-local > DirectByteBuffer cache. One of our services seems to create and drop If it's in a ThreadLocal then aren't you just asking for thread-locals to be cleared at thread exit? Cheers, David > threads at regular intervals. I assume this is due to a thread pool > dynamically resizing itself. > > Let's say a thread starts, lives long enough for its Thread object to be > promoted to the old gen (along with its cached direct buffer), then exits. > This will result in its cached direct buffer(s) being unreachable in the > old gen and will only be reclaimed after the next full GC / concurrent GC > cycle. > > Interestingly, the service in question does concurrent GC cycles really > infrequently (one every few days) as it has a really low promotion rate. > This results in the JVM's total direct size constantly increasing (which is > effectively a native buffer leak). > > Has anyone come across this issue before? > > There are a few obvious ways to mitigate this, e.g., cause a Full GC / > concurrent GC cycle at regular intervals. However, the best solution IMHO > is to explicitly free any direct buffers that are still in the cache when a > thread exits. > > I'll be happy to implement this and test it internally at Twitter, if it's > not on anyone else's radar. However, to do what I'm proposing I need some > sort of thread exit hook. Unfortunately, there doesn't seem to be one. > > Would proposing to introduce thread exit hooks be reasonable? Or is > everyone going to freak out? :-) The hooks can be either per-Thread or even > per-ThreadLocal. And it's OK if the hooks can only be used within java.base. > > FWIW, I did a simple prototype of this (I call the hooks from Thread::exit) > and it seems to work as expected. > > Any thoughts / feedback on this will be very appreciated. > > Thanks, > > Tony > > > > ????? > Tony Printezis | @TonyPrintezis | tprintezis at twitter.com > From david.lloyd at redhat.com Thu Apr 5 22:23:30 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 5 Apr 2018 17:23:30 -0500 Subject: Promptly freeing the per-thread cached direct buffers when a thread exits In-Reply-To: References: Message-ID: On Thu, Apr 5, 2018 at 4:45 PM, Tony Printezis wrote: > Would proposing to introduce thread exit hooks be reasonable? Or is > everyone going to freak out? :-) The hooks can be either per-Thread or even > per-ThreadLocal. And it's OK if the hooks can only be used within java.base. User-accessible thread exit hooks would be nice, from a user perspective. From a JDK perspective - it adds new opportunities for user code to jam things up, so it's a tradeoff. ThreadLocal clearing on thread exit would have been nice back in the beginning, but now I think it would be a fairly substantial behavior change. Adding a new exit() method on ThreadLocal would be better (but not perfect) compatibility-wise, and see prior note about users jamming things up... I think that at a minimum, explicitly releasing thread-local NIO direct buffers on thread exit (without introducing a user facing API) is probably safe. Some kind of user-accessible hook would be nice, but I can't imagine it would take anything less than a massive discussion to get there. -- - DML From paul.sandoz at oracle.com Thu Apr 5 22:25:38 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 5 Apr 2018 15:25:38 -0700 Subject: RFR 8200788 : Optimal initial capacity of java.lang.VarHandle.AccessMode.methodNameToAccessMode In-Reply-To: <3f2db600-6960-50ff-c42f-8a753a4b8ad5@oracle.com> References: <3f2db600-6960-50ff-c42f-8a753a4b8ad5@oracle.com> Message-ID: <31F5D36B-86D1-4E9E-83A6-03371D92D7DE@oracle.com> > On Apr 5, 2018, at 12:04 AM, Ivan Gerasimov wrote: > > Hello! > > Yet another HashMap that can be preallocated more accurately. > > Currently, the map is created as the following: > // Initial capacity of # values is sufficient to avoid resizes > // for the smallest table size (32) > methodNameToAccessMode = new HashMap<>(AccessMode.values().length); > > Even though the comment suggests that no resizes of the table should occur, in fact the threshold is calculated as 32 * 0.75 = 24, so when 24th element is inserted then the internal storage is reallocated and the content of the table is reinserted. > Thanks for fixing this. I suspect that code and comment were written when there were fewer access modes. Paul. > Also, a missing @modules line is added to the regression test that was pushed with the fix for JDK-8200696. > > Would you please help review this? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200788 > WEBREV: http://cr.openjdk.java.net/~igerasim/8200788/00/webrev/ > > -- > With kind regards, > Ivan Gerasimov > From paul.sandoz at oracle.com Fri Apr 6 01:02:34 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 5 Apr 2018 18:02:34 -0700 Subject: RFR: 8164781: Pattern.asPredicate specification is incomplete In-Reply-To: References: <99502bca-28b8-4d29-a5d7-7a2cae0c829a@default> <9FED94A2-7351-4374-9139-0AB8ADBBFCC8@oracle.com> <65822972-87F7-4313-B6F8-A90E35579CF4@oracle.com> Message-ID: <7ED19535-F0A9-4682-849F-80958EE38669@oracle.com> > On Apr 5, 2018, at 3:34 AM, Vivek Theeyarath wrote: > >>> >>> Hi, >>> I have incorporated the changes as per the feedback and here is the updated webrev . >>> http://cr.openjdk.java.net/~rraghavan/8164781/webrev.02/ . >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164781 >>> > >> +1 > Thanks Paul > >> I know it?s picky, but would you mind sticking closer to the existing line length in the source file >> (no need for another review) > Here is my attempt. Hope it is better now. http://cr.openjdk.java.net/~rraghavan/8164781/webrev.03 > Nope, still not aligned to ~80 chars. >> Did you run the jtreg test to verify it passes? I missed the problem initially, glad Stuart caught it, but i presume the test would of reported a failure? if not there is something wrong with the test itself that should be investigated. > > > I missed it earlier. As you rightly pointed out, without Stuart's inputs the test fails and it passes with it as expected. > >>> Here is the related csr https://bugs.openjdk.java.net/browse/JDK-8200603 >>> > >> Ok, i tweaked some of the information (after creating a CSR one often needs to edit it to fill in the gaps). > >> Can you blockquote the markdown for the embedded patch since the formatting is all messed up? > > I have restored the formatting. Hope it would suffice. > https://bugs.openjdk.java.net/browse/JDK-8200603 > Much better. Paul. From paul.sandoz at oracle.com Fri Apr 6 01:25:15 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 5 Apr 2018 18:25:15 -0700 Subject: RFR: 8184692: add Pattern.asMatchPredicate In-Reply-To: <74681017-e7fe-47e8-89ef-d804c9e5e77b@default> References: <74681017-e7fe-47e8-89ef-d804c9e5e77b@default> Message-ID: <6AF1056A-D9AB-4C8C-9708-96CBCF40B2CB@oracle.com> > On Apr 4, 2018, at 10:47 AM, Vivek Theeyarath wrote: > > Hi All, > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8184692 > > Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.00/ > Like with your other patch, alignment to ~80 chars would be good, as that is mostly consistent with other code in the same source file. Let?s not use the word ?find" here, so as not to confuse with matcher(s).find(). 5833 * @return The predicate which can be used for finding if an input string matches this pattern. I suggest: @return The predicate which can be used for matching an input string against this pattern You could also add a @see Matcher#matches Paul. > > > The related jtreg test was run and the test passed . > > > > Regards > > Vivek From vivek.theeyarath at oracle.com Fri Apr 6 06:39:56 2018 From: vivek.theeyarath at oracle.com (Vivek Theeyarath) Date: Thu, 5 Apr 2018 23:39:56 -0700 (PDT) Subject: RFR: 8164781: Pattern.asPredicate specification is incomplete In-Reply-To: <6a065c19-7ee9-5d9f-2a6a-606a73e5647d@oracle.com> References: <99502bca-28b8-4d29-a5d7-7a2cae0c829a@default> <9FED94A2-7351-4374-9139-0AB8ADBBFCC8@oracle.com> <65822972-87F7-4313-B6F8-A90E35579CF4@oracle.com> <6a065c19-7ee9-5d9f-2a6a-606a73e5647d@oracle.com> Message-ID: <7960a074-abc6-4220-b629-71e0f18b0b49@default> Hi Roger, The sentence has been changed and here is the updated one http://cr.openjdk.java.net/~rraghavan/8164781/webrev.04/ . The line length has also been fixed as suggested by Paul to adhere to ~80 chars. I have finalized the csr too. Regards Vivek -----Original Message----- From: Roger Riggs Sent: Thursday, April 05, 2018 6:35 PM To: core-libs-dev at openjdk.java.net Subject: Re: RFR: 8164781: Pattern.asPredicate specification is incomplete Hi Vivek, Can we do something to make the first sentence less confusing? How about: * Creates a predicate that tests a given input string for a subsequence that matches this pattern. -or- * Creates a predicate that tests if this pattern is found in a given input string. Thanks, Roger On 4/5/18 6:34 AM, Vivek Theeyarath wrote: >>> Hi, >>> I have incorporated the changes as per the feedback and here is the updated webrev . >>> http://cr.openjdk.java.net/~rraghavan/8164781/webrev.02/ . >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164781 >>> >> +1 > Thanks Paul > >> I know it?s picky, but would you mind sticking closer to the existing >> line length in the source file (no need for another review) > Here is my attempt. Hope it is better now. > http://cr.openjdk.java.net/~rraghavan/8164781/webrev.03 > >> Did you run the jtreg test to verify it passes? I missed the problem initially, glad Stuart caught it, but i presume the test would of reported a failure? if not there is something wrong with the test itself that should be investigated. > > I missed it earlier. As you rightly pointed out, without Stuart's inputs the test fails and it passes with it as expected. > >>> Here is the related csr >>> https://bugs.openjdk.java.net/browse/JDK-8200603 >>> >> Ok, i tweaked some of the information (after creating a CSR one often needs to edit it to fill in the gaps). >> Can you blockquote the markdown for the embedded patch since the formatting is all messed up? > I have restored the formatting. Hope it would suffice. > https://bugs.openjdk.java.net/browse/JDK-8200603 > > Regards > Vivek From Alan.Bateman at oracle.com Fri Apr 6 08:02:49 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 6 Apr 2018 09:02:49 +0100 Subject: Promptly freeing the per-thread cached direct buffers when a thread exits In-Reply-To: References: Message-ID: On 05/04/2018 22:45, Tony Printezis wrote: > Hi all, > > We recently hit another interesting issue with the NIO thread-local > DirectByteBuffer cache. One of our services seems to create and drop > threads at regular intervals. I assume this is due to a thread pool > dynamically resizing itself. > > Let's say a thread starts, lives long enough for its Thread object to be > promoted to the old gen (along with its cached direct buffer), then exits. > This will result in its cached direct buffer(s) being unreachable in the > old gen and will only be reclaimed after the next full GC / concurrent GC > cycle. > Right, if a short lived thread does I/O with a buffer backed by an array in the heap then any direct buffers in its thread local cache won't be freed until there is a GC and reference processing. It's something that I've prototyped a few times and always leaned towards not exposing anything in the API, instead just hooking into the thread exit to clear the buffer cache. One thing to watch out for is that the buffer cache may not exist (as the thread didn't do any I/O with heap buffers) so you'll end up creating (an empty) buffer cache at thread exit. That is benign of course but still unsettling to have additional code executing at this time. -Alan From peter.levart at gmail.com Fri Apr 6 12:49:13 2018 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 6 Apr 2018 14:49:13 +0200 Subject: Promptly freeing the per-thread cached direct buffers when a thread exits In-Reply-To: References: Message-ID: <26ab7bff-3442-798c-1655-8ac058ec39bd@gmail.com> On 04/06/2018 10:02 AM, Alan Bateman wrote: > On 05/04/2018 22:45, Tony Printezis wrote: >> Hi all, >> >> We recently hit another interesting issue with the NIO thread-local >> DirectByteBuffer cache. One of our services seems to create and drop >> threads at regular intervals. I assume this is due to a thread pool >> dynamically resizing itself. >> >> Let's say a thread starts, lives long enough for its Thread object to be >> promoted to the old gen (along with its cached direct buffer), then >> exits. >> This will result in its cached direct buffer(s) being unreachable in the >> old gen and will only be reclaimed after the next full GC / >> concurrent GC >> cycle. >> > Right, if a short lived thread does I/O with a buffer backed by an > array in the heap then any direct buffers in its thread local cache > won't be freed until there is a GC and reference processing. It's > something that I've prototyped a few times and always leaned towards > not exposing anything in the API, instead just hooking into the thread > exit to clear the buffer cache. One thing to watch out for is that the > buffer cache may not exist (as the thread didn't do any I/O with heap > buffers) so you'll end up creating (an empty) buffer cache at thread > exit. That is benign of course but still unsettling to have additional > code executing at this time. > > -Alan An internal method, let's say ThreadLocal.probe(), that would return thread-local value only if it has already been initialized, would be helpfull. Maybe it could be exposed as new public API too. I remember that I needed it in the past: ??? public T probe() { ??????? Thread t = Thread.currentThread(); ??????? ThreadLocalMap map = getMap(t); ??????? if (map != null) { ??????????? ThreadLocalMap.Entry e = map.getEntry(this); ??????????? if (e != null) { ??????????????? @SuppressWarnings("unchecked") ??????????????? T result = (T)e.value; ??????????????? return result; ??????????? } ??????? } ??????? return null; ??? } Regards, Peter From tprintezis at twitter.com Fri Apr 6 13:46:33 2018 From: tprintezis at twitter.com (Tony Printezis) Date: Fri, 6 Apr 2018 06:46:33 -0700 Subject: Promptly freeing the per-thread cached direct buffers when a thread exits In-Reply-To: <92e33b4e-a05d-47fe-e4d1-418f3dc4c2d4@oracle.com> References: <92e33b4e-a05d-47fe-e4d1-418f3dc4c2d4@oracle.com> Message-ID: Hi David, ThreadLocals getting cleared is not enough. The threadLocals field is cleared by Thread::exit: private void exit() { ... threadLocals = null; ... } but this doesn?t really do anything. The GC has to run, find the direct buffer in the ThreadLocal unreachable, and queue its Cleaner for processing. I?m looking for a hook to explicitly reclaim the direct buffer when Thread::exit is called. Tony ????? Tony Printezis | @TonyPrintezis | tprintezis at twitter.com On April 5, 2018 at 6:07:26 PM, David Holmes (david.holmes at oracle.com) wrote: Hi Tony, On 6/04/2018 7:45 AM, Tony Printezis wrote: > Hi all, > > We recently hit another interesting issue with the NIO thread-local > DirectByteBuffer cache. One of our services seems to create and drop If it's in a ThreadLocal then aren't you just asking for thread-locals to be cleared at thread exit? Cheers, David > threads at regular intervals. I assume this is due to a thread pool > dynamically resizing itself. > > Let's say a thread starts, lives long enough for its Thread object to be > promoted to the old gen (along with its cached direct buffer), then exits. > This will result in its cached direct buffer(s) being unreachable in the > old gen and will only be reclaimed after the next full GC / concurrent GC > cycle. > > Interestingly, the service in question does concurrent GC cycles really > infrequently (one every few days) as it has a really low promotion rate. > This results in the JVM's total direct size constantly increasing (which is > effectively a native buffer leak). > > Has anyone come across this issue before? > > There are a few obvious ways to mitigate this, e.g., cause a Full GC / > concurrent GC cycle at regular intervals. However, the best solution IMHO > is to explicitly free any direct buffers that are still in the cache when a > thread exits. > > I'll be happy to implement this and test it internally at Twitter, if it's > not on anyone else's radar. However, to do what I'm proposing I need some > sort of thread exit hook. Unfortunately, there doesn't seem to be one. > > Would proposing to introduce thread exit hooks be reasonable? Or is > everyone going to freak out? :-) The hooks can be either per-Thread or even > per-ThreadLocal. And it's OK if the hooks can only be used within java.base. > > FWIW, I did a simple prototype of this (I call the hooks from Thread::exit) > and it seems to work as expected. > > Any thoughts / feedback on this will be very appreciated. > > Thanks, > > Tony > > > > ????? > Tony Printezis | @TonyPrintezis | tprintezis at twitter.com > From Roger.Riggs at Oracle.com Fri Apr 6 13:50:33 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 6 Apr 2018 09:50:33 -0400 Subject: RFR 8200706: Better cleanup for open/test/jdk/java/lang/ProcessBuilder/DestroyTest.java Message-ID: <5f376d4c-1b2d-5570-656c-521c60c7f7c0@Oracle.com> Please review an intermittent test bug/cleanup improvement that places temporary files in the directory that is auto-cleaned by jtreg. Webrev: ?http://cr.openjdk.java.net/~rriggs/webrev-clean-destroy-8200706/ Thanks, Roger From tprintezis at twitter.com Fri Apr 6 13:57:34 2018 From: tprintezis at twitter.com (Tony Printezis) Date: Fri, 6 Apr 2018 06:57:34 -0700 Subject: Promptly freeing the per-thread cached direct buffers when a thread exits In-Reply-To: References: Message-ID: Hi David, Thanks for your thoughts. Please see inline. ????? Tony Printezis | @TonyPrintezis | tprintezis at twitter.com On April 5, 2018 at 6:24:11 PM, David Lloyd (david.lloyd at redhat.com) wrote: On Thu, Apr 5, 2018 at 4:45 PM, Tony Printezis wrote: > Would proposing to introduce thread exit hooks be reasonable? Or is > everyone going to freak out? :-) The hooks can be either per-Thread or even > per-ThreadLocal. And it's OK if the hooks can only be used within java.base. User-accessible thread exit hooks would be nice, from a user perspective. From a JDK perspective - it adds new opportunities for user code to jam things up, so it's a tradeoff. ?just like finalizers. :-) Yeah, I get that. Which is why I was a bit reluctant to bring it up. Which is why I proposed to only make it available within java.base? ThreadLocal clearing Could you clarify what you mean by ThreadLocal clearing? on thread exit would have been nice back in the beginning, but now I think it would be a fairly substantial behavior change. Adding a new exit() method on ThreadLocal would be better (but not perfect) compatibility-wise, and see prior note about users jamming things up... I like the suggestion to add an overridable exit() method to ThreadLocal. If you want to avoid calling user code by Thread::exit, would adding ThreadLocals (which are tagged appropriately) to a queue for later processing a better approach (similar to the mechanism used for References / ReferencesQueues)? The user can of course create a memory leak by not polling the queue frequently enough. But, that?s also the case for References. And at least user code cannot block Thread::exit. I think that at a minimum, explicitly releasing thread-local NIO direct buffers on thread exit (without introducing a user facing API) is probably safe. I?m also pretty sure it?s safe. I should have mentioned that the thread-local direct buffers are actually explicitly freed when they are not put back in the cache. So, it should be safe to also explicitly free any that are in the cache when the thread exits. Some kind of user-accessible hook would be nice, but I can't imagine it would take anything less than a massive discussion to get there. I?d like to avoid a massive discussion, which is why I proposed to only make it available within java.base. Tony -- - DML From tprintezis at twitter.com Fri Apr 6 14:08:12 2018 From: tprintezis at twitter.com (Tony Printezis) Date: Fri, 6 Apr 2018 07:08:12 -0700 Subject: Promptly freeing the per-thread cached direct buffers when a thread exits In-Reply-To: References: Message-ID: Hi Alan, Calling sun.nio directly from java.lang seemed a bit dodgy to me, which is why I proposed some type of exit hook (maybe I overthought this?). But that?d be OK, could make this change a lot simpler. :-) And, yes, I came across the issue of not being able to query whether a ThreadLocal exists on a Thread when I implemented my prototype. Which is why I think introducing an exit hook on ThreadLocal, instead of Thread, is probably the better approach (it will only be called if the ThreadLocal exists). Tony ????? Tony Printezis | @TonyPrintezis | tprintezis at twitter.com On April 6, 2018 at 4:02:56 AM, Alan Bateman (alan.bateman at oracle.com) wrote: On 05/04/2018 22:45, Tony Printezis wrote: > Hi all, > > We recently hit another interesting issue with the NIO thread-local > DirectByteBuffer cache. One of our services seems to create and drop > threads at regular intervals. I assume this is due to a thread pool > dynamically resizing itself. > > Let's say a thread starts, lives long enough for its Thread object to be > promoted to the old gen (along with its cached direct buffer), then exits. > This will result in its cached direct buffer(s) being unreachable in the > old gen and will only be reclaimed after the next full GC / concurrent GC > cycle. > Right, if a short lived thread does I/O with a buffer backed by an array in the heap then any direct buffers in its thread local cache won't be freed until there is a GC and reference processing. It's something that I've prototyped a few times and always leaned towards not exposing anything in the API, instead just hooking into the thread exit to clear the buffer cache. One thing to watch out for is that the buffer cache may not exist (as the thread didn't do any I/O with heap buffers) so you'll end up creating (an empty) buffer cache at thread exit. That is benign of course but still unsettling to have additional code executing at this time. -Alan From tprintezis at twitter.com Fri Apr 6 14:14:26 2018 From: tprintezis at twitter.com (Tony Printezis) Date: Fri, 6 Apr 2018 07:14:26 -0700 Subject: Promptly freeing the per-thread cached direct buffers when a thread exits In-Reply-To: <26ab7bff-3442-798c-1655-8ac058ec39bd@gmail.com> References: <26ab7bff-3442-798c-1655-8ac058ec39bd@gmail.com> Message-ID: Was there a reason why this was not introduced in the first place? Tony ????? Tony Printezis | @TonyPrintezis | tprintezis at twitter.com On April 6, 2018 at 8:49:17 AM, Peter Levart (peter.levart at gmail.com) wrote: On 04/06/2018 10:02 AM, Alan Bateman wrote: > On 05/04/2018 22:45, Tony Printezis wrote: >> Hi all, >> >> We recently hit another interesting issue with the NIO thread-local >> DirectByteBuffer cache. One of our services seems to create and drop >> threads at regular intervals. I assume this is due to a thread pool >> dynamically resizing itself. >> >> Let's say a thread starts, lives long enough for its Thread object to be >> promoted to the old gen (along with its cached direct buffer), then >> exits. >> This will result in its cached direct buffer(s) being unreachable in the >> old gen and will only be reclaimed after the next full GC / >> concurrent GC >> cycle. >> > Right, if a short lived thread does I/O with a buffer backed by an > array in the heap then any direct buffers in its thread local cache > won't be freed until there is a GC and reference processing. It's > something that I've prototyped a few times and always leaned towards > not exposing anything in the API, instead just hooking into the thread > exit to clear the buffer cache. One thing to watch out for is that the > buffer cache may not exist (as the thread didn't do any I/O with heap > buffers) so you'll end up creating (an empty) buffer cache at thread > exit. That is benign of course but still unsettling to have additional > code executing at this time. > > -Alan An internal method, let's say ThreadLocal.probe(), that would return thread-local value only if it has already been initialized, would be helpfull. Maybe it could be exposed as new public API too. I remember that I needed it in the past: public T probe() { Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) { ThreadLocalMap.Entry e = map.getEntry(this); if (e != null) { @SuppressWarnings("unchecked") T result = (T)e.value; return result; } } return null; } Regards, Peter From Roger.Riggs at Oracle.com Fri Apr 6 14:39:07 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 6 Apr 2018 10:39:07 -0400 Subject: RFR: Export InitializeEncoding for JVM access In-Reply-To: References: Message-ID: Hi Andrew, Would it be sufficient to export the InitializeEncoding entry point? Introducing a JNU_xx name may imply a level of support that is unwarranted since it is part of system initialization and may change as needed by the implementation. Simply exporting it would put it on par with Canonicalize. Thanks, Roger p.s. Tracking issue: https://bugs.openjdk.java.net/browse/JDK-8201246 On 4/5/2018 5:49 AM, Andrew Leonard wrote: > Hi Roger, > The OpenJ9 VM implementation provides its own java.lang.System, which > performs similar type early-on VM initialization to the OpenJDK core > library classes. The basic reason for invoking the method is to > initialize the platform encoding either called from a related core > library method, eg.initProperties(), or from the VM in the early > stages of initialization. > > My suggested comparison with canonicalize was based on it's indicated > usage: > /* > ?* Export the platform dependent path canonicalization so that > ?* VM can find it when loading system classes. > ?* This function is also used by the instrumentation agent. > ?*/ > extern int canonicalize(char *path, const char *out, int len); > > JNIEXPORT int > Canonicalize(JNIEnv *unused, char *orig, char *out, int len) > { > /* canonicalize an already natived path */ > return canonicalize(orig, out, len); > } > > > Many thanks, > Andrew > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From david.lloyd at redhat.com Fri Apr 6 16:15:29 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 6 Apr 2018 11:15:29 -0500 Subject: Promptly freeing the per-thread cached direct buffers when a thread exits In-Reply-To: References: Message-ID: On Fri, Apr 6, 2018 at 8:57 AM, Tony Printezis wrote: >> ThreadLocal clearing > > Could you clarify what you mean by ThreadLocal clearing? I mean calling ThreadLocal#remove(). > I like the suggestion to add an overridable exit() method to ThreadLocal. If > you want to avoid calling user code by Thread::exit, would adding > ThreadLocals (which are tagged appropriately) to a queue for later > processing a better approach (similar to the mechanism used for References / > ReferencesQueues)? The user can of course create a memory leak by not > polling the queue frequently enough. But, that?s also the case for > References. And at least user code cannot block Thread::exit. It's more complexity, and at some point you have to ask: is it better to block thread A or thread B? At least blocking thread A is somewhat expected. -- - DML From paul.sandoz at oracle.com Fri Apr 6 16:15:28 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 6 Apr 2018 09:15:28 -0700 Subject: RFR 8200706: Better cleanup for open/test/jdk/java/lang/ProcessBuilder/DestroyTest.java In-Reply-To: <5f376d4c-1b2d-5570-656c-521c60c7f7c0@Oracle.com> References: <5f376d4c-1b2d-5570-656c-521c60c7f7c0@Oracle.com> Message-ID: <6F4B326E-01A6-4C7A-A2BC-4C3749D8DED4@oracle.com> > On Apr 6, 2018, at 6:50 AM, Roger Riggs wrote: > > Please review an intermittent test bug/cleanup improvement that places temporary > files in the directory that is auto-cleaned by jtreg. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-clean-destroy-8200706/ > Looks ok, while you are there, and up to you, you might consider a little refactor of the if/else so there is no repetition of the temp file creation code since it?s the same on all but windows e.g: if (osName.startsWith("Windows")) { return new WindowsTest(); } File userDir = new File(System.getProperty("user.dir", ".")); File tmpFile = File.createTempFile("ProcessTrap-", ".sh?, userDir)); if (osName.startsWith("Linux") == true) { return return new UnixTest(tempFile); } else if ? ... return null; Paul. > Thanks, Roger > From lance.andersen at oracle.com Fri Apr 6 16:27:31 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 6 Apr 2018 12:27:31 -0400 Subject: RFR 8200706: Better cleanup for open/test/jdk/java/lang/ProcessBuilder/DestroyTest.java In-Reply-To: <5f376d4c-1b2d-5570-656c-521c60c7f7c0@Oracle.com> References: <5f376d4c-1b2d-5570-656c-521c60c7f7c0@Oracle.com> Message-ID: <550E6330-4DA3-4841-A725-FDCE28C2AA11@oracle.com> Hi Roger, I think what you have is OK. Best Lance > On Apr 6, 2018, at 9:50 AM, Roger Riggs wrote: > > Please review an intermittent test bug/cleanup improvement that places temporary > files in the directory that is auto-cleaned by jtreg. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-clean-destroy-8200706/ > > Thanks, Roger > 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 Apr 6 16:45:22 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 6 Apr 2018 17:45:22 +0100 Subject: Promptly freeing the per-thread cached direct buffers when a thread exits In-Reply-To: References: Message-ID: <48cadc5a-f648-e594-58f4-fe50dbbf8fd7@oracle.com> On 06/04/2018 15:08, Tony Printezis wrote: > Hi Alan, > > Calling sun.nio directly from java.lang seemed a bit dodgy to me, > which is why I proposed some type of exit hook (maybe I overthought > this?). But that?d be OK, could make this change a lot simpler. :-) > And, yes, I came across the issue of not being able to query whether a > ThreadLocal exists on a Thread when I implemented my prototype. Which > is why I think introducing an exit hook on ThreadLocal, instead of > Thread, is probably the better approach (it will only be called if the > ThreadLocal exists). > java.lang.Thread is already tightly connected to blocking I/O operations (Thread::interrupt for example). In any case, the concern with exposing exit hooks in the API is that it means running arbitrary code when exiting, something that would need a lot of consideration before going there. -Alan From Roger.Riggs at Oracle.com Fri Apr 6 16:55:46 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 6 Apr 2018 12:55:46 -0400 Subject: RFR 8200706: Better cleanup for open/test/jdk/java/lang/ProcessBuilder/DestroyTest.java In-Reply-To: <6F4B326E-01A6-4C7A-A2BC-4C3749D8DED4@oracle.com> References: <5f376d4c-1b2d-5570-656c-521c60c7f7c0@Oracle.com> <6F4B326E-01A6-4C7A-A2BC-4C3749D8DED4@oracle.com> Message-ID: <2db4df8a-2e6f-ce38-36db-dcf7cf939fa1@Oracle.com> Thanks Lance, Paul, I will refactor the code, update in place: http://cr.openjdk.java.net/~rriggs/webrev-clean-destroy-8200706/ And I am retesting. Thanks, Roger On 4/6/2018 12:15 PM, Paul Sandoz wrote: > >> On Apr 6, 2018, at 6:50 AM, Roger Riggs wrote: >> >> Please review an intermittent test bug/cleanup improvement that places temporary >> files in the directory that is auto-cleaned by jtreg. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-clean-destroy-8200706/ >> > Looks ok, while you are there, and up to you, you might consider a little refactor of the if/else so there is no repetition of the temp file creation code since it?s the same on all but windows e.g: > > if (osName.startsWith("Windows")) { > return new WindowsTest(); > } > > File userDir = new File(System.getProperty("user.dir", ".")); > File tmpFile = File.createTempFile("ProcessTrap-", ".sh?, userDir)); > if (osName.startsWith("Linux") == true) { > return return new UnixTest(tempFile); > } else if ? > ... > return null; > > Paul. > >> Thanks, Roger >> From tprintezis at twitter.com Fri Apr 6 17:11:39 2018 From: tprintezis at twitter.com (Tony Printezis) Date: Fri, 6 Apr 2018 10:11:39 -0700 Subject: Promptly freeing the per-thread cached direct buffers when a thread exits In-Reply-To: References: Message-ID: ????? Tony Printezis | @TonyPrintezis | tprintezis at twitter.com On April 6, 2018 at 12:16:10 PM, David Lloyd (david.lloyd at redhat.com) wrote: On Fri, Apr 6, 2018 at 8:57 AM, Tony Printezis wrote: >> ThreadLocal clearing > > Could you clarify what you mean by ThreadLocal clearing? I mean calling ThreadLocal#remove(). I see. So, anyone who subclasses ThreadLocal can override remove(). And if remove() is called by Thread::exit, it can be used as an exit hook. (David Holmes, if this is what you meant in your e-mail: apologies; I misunderstood.) > I like the suggestion to add an overridable exit() method to ThreadLocal. If > you want to avoid calling user code by Thread::exit, would adding > ThreadLocals (which are tagged appropriately) to a queue for later > processing a better approach (similar to the mechanism used for References / > ReferencesQueues)? The user can of course create a memory leak by not > polling the queue frequently enough. But, that?s also the case for > References. And at least user code cannot block Thread::exit. It's more complexity, and at some point you have to ask: is it better to block thread A or thread B? At least blocking thread A is somewhat expected. I agree re: it?d add complexity. #simplify :-) Tony -- - DML From tprintezis at twitter.com Fri Apr 6 17:17:41 2018 From: tprintezis at twitter.com (Tony Printezis) Date: Fri, 6 Apr 2018 10:17:41 -0700 Subject: Promptly freeing the per-thread cached direct buffers when a thread exits In-Reply-To: <48cadc5a-f648-e594-58f4-fe50dbbf8fd7@oracle.com> References: <48cadc5a-f648-e594-58f4-fe50dbbf8fd7@oracle.com> Message-ID: Hi Alan, Ah, I hadn?t realized that there?s already some tight coupling between Thread and nio. OK, I?ll just call into sun.nio directly and see what the reviewers say. :-) Is there a CR for this already? Or should I create one? Tony ????? Tony Printezis | @TonyPrintezis | tprintezis at twitter.com On April 6, 2018 at 12:45:29 PM, Alan Bateman (alan.bateman at oracle.com) wrote: On 06/04/2018 15:08, Tony Printezis wrote: Hi Alan, Calling sun.nio directly from java.lang seemed a bit dodgy to me, which is why I proposed some type of exit hook (maybe I overthought this?). But that?d be OK, could make this change a lot simpler. :-) And, yes, I came across the issue of not being able to query whether a ThreadLocal exists on a Thread when I implemented my prototype. Which is why I think introducing an exit hook on ThreadLocal, instead of Thread, is probably the better approach (it will only be called if the ThreadLocal exists). java.lang.Thread is already tightly connected to blocking I/O operations (Thread::interrupt for example). In any case, the concern with exposing exit hooks in the API is that it means running arbitrary code when exiting, something that would need a lot of consideration before going there. -Alan From Alan.Bateman at oracle.com Fri Apr 6 18:11:03 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 6 Apr 2018 19:11:03 +0100 Subject: 8194734 : Handle to jimage file inherited into child processes (win) In-Reply-To: References: Message-ID: On 02/04/2018 22:50, Alexander Miloslavskiy wrote: > The problem in this bug is that jimage file is mistakenly opened with > "inherit by child processes" flag. In our case, the child process is > started with Runtime.exec() and serves as updater that can also > replace embedded JRE. However, due to jimage ("lib/modules") file > handle being inherited, embedded JRE can not be replaced. > > The bug was introduced in commits "8087181: Move native jimage code to > its own library (maybe libjimage)" cc'ing Jim Laskey as he recently picked up JDK-8194734. The update to osSupport_Windows.cpp looks okay.? I think it would be useful to discuss the osSupport_unix.cpp change further as the childproc code is supported to close the file descriptors. Martin might know about this. -Alan From alexandr.miloslavskiy at gmail.com Fri Apr 6 19:39:44 2018 From: alexandr.miloslavskiy at gmail.com (Alexander Miloslavskiy) Date: Fri, 6 Apr 2018 22:39:44 +0300 Subject: 8194734 : Handle to jimage file inherited into child processes (win) In-Reply-To: References: Message-ID: <72c96cf9-a81c-192e-bda1-35768a6ecad3@gmail.com> > The update to osSupport_Windows.cpp looks okay. I think it would be > useful to discuss the osSupport_unix.cpp change further as the > childproc code is supported to close the file descriptors. childproc code uses some dark magic to figure which files to close. At the moment, closeDescriptors() will close all files which has descriptors bigger then from_fd (4). However, jimage ends up having descriptor 3, so it's not closed. On the other hand, childproc expects descriptor 3 to be occupied by a pipe to parent (FAIL_FILENO). This means that currently, dark magic is already broken. The only reason for jimage to not go into child process is being mistaken with FAIL_FILENO. One way of fixing bug in childproc could be increasing FAIL_FILENO to match its actual value of file descriptor. This way, jimage will no longer be mistaken with FAIL_FILENO and therefore, it will NOT be closed. With all this in mind, I believe it wouldn't hurt to explicitly say that jimage must not be inherited, without relying on current implementation of childproc. That makes a sturdy and clean code. When this patch is accepted, I can also work on fixing bugs in childproc, if that is considered worthy. From martinrb at google.com Fri Apr 6 21:01:26 2018 From: martinrb at google.com (Martin Buchholz) Date: Fri, 6 Apr 2018 14:01:26 -0700 Subject: 8194734 : Handle to jimage file inherited into child processes (win) In-Reply-To: <72c96cf9-a81c-192e-bda1-35768a6ecad3@gmail.com> References: <72c96cf9-a81c-192e-bda1-35768a6ecad3@gmail.com> Message-ID: History: The design on Unix was that all file descriptors greater than 3 are closed on fork and before exec. But regardless of that, we should try to set the CLOEXEC bit on all our file descriptor (who knows, there might be native code that does fork+exec). File descriptor 3 is indeed deep magic, used for error reporting. It's a serious bug if FAIL_FILENO ends up being used for something other than the error reporting pipe. I don't think I'm the last (or the first!) person who touched this. On Fri, Apr 6, 2018 at 12:39 PM, Alexander Miloslavskiy < alexandr.miloslavskiy at gmail.com> wrote: > > The update to osSupport_Windows.cpp looks okay. I think it would be > > useful to discuss the osSupport_unix.cpp change further as the > > childproc code is supported to close the file descriptors. > > childproc code uses some dark magic to figure which files to close. At the > moment, closeDescriptors() will close all files which has descriptors > bigger then from_fd (4). However, jimage ends up having descriptor 3, so > it's not closed. On the other hand, childproc expects descriptor 3 to be > occupied by a pipe to parent (FAIL_FILENO). This means that currently, dark > magic is already broken. The only reason for jimage to not go into child > process is being mistaken with FAIL_FILENO. > > One way of fixing bug in childproc could be increasing FAIL_FILENO to > match its actual value of file descriptor. This way, jimage will no longer > be mistaken with FAIL_FILENO and therefore, it will NOT be closed. > > With all this in mind, I believe it wouldn't hurt to explicitly say that > jimage must not be inherited, without relying on current implementation of > childproc. That makes a sturdy and clean code. > > When this patch is accepted, I can also work on fixing bugs in childproc, > if that is considered worthy. > From leventov.ru at gmail.com Fri Apr 6 21:35:25 2018 From: leventov.ru at gmail.com (Roman Leventov) Date: Sat, 7 Apr 2018 00:35:25 +0300 Subject: Use iterator() in AbstractList.equals() instead of listIterator() Message-ID: iterator() has chances to be slightly more efficient than listIterator(). At very least AbstractList's own ListItr implementation contains one more implicit field referencing the base class, so objects of AbstractList.ListItr are often 8 bytes bigger than objects of AbstractList.Itr. From andrey.x.nazarov at oracle.com Sat Apr 7 00:10:24 2018 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Fri, 6 Apr 2018 17:10:24 -0700 Subject: RFR: 8178867: tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java failed to clean up files Message-ID: <59A267A5-804D-457B-A7EB-2750E02EF057@oracle.com> Hi, Please review fix in Jlink test. The fix is to close the Stream which works with a file system. Review: http://cr.openjdk.java.net/~anazarov/JDK-8178867/webrev.01 JBS: https://bugs.openjdk.java.net/browse/JDK-8178867 ?Thanks, Andrei From paul.sandoz at oracle.com Sat Apr 7 00:15:54 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 6 Apr 2018 17:15:54 -0700 Subject: RFR 8199875: Require first parameter type of a condy bootstrap to be Lookup Message-ID: <8B902361-938A-465B-8589-CC844FD7C250@oracle.com> Hi, Please review this patch to constrain constant dynamic bootstrap methods to methods whose first parameter type is MethodHandles.Lookup. http://cr.openjdk.java.net/~psandoz/jdk/JDK-8199875-condy-bsm-lookup/webrev/ We are conservatively diverging from invoke dynamic bootstrap method invocation behaviour to possibly diverge further in the future and allow for constant dynamic bootstrap methods that are invoked without the lookup/name/type arguments. The change enables further divergence in a future release without breaking compatibility. This would make it easier to use existing methods as bootstrap methods rather than invoking via a level of indirection for explicit wrappers or using ConstantBootstraps.invoke. The experience garnered from prototyping language and low-level library features informs us this is useful. CSR is here: https://bugs.openjdk.java.net/browse/JDK-8201268 Thanks, Paul. From john.r.rose at oracle.com Sat Apr 7 05:32:38 2018 From: john.r.rose at oracle.com (John Rose) Date: Fri, 6 Apr 2018 22:32:38 -0700 Subject: RFR 8199875: Require first parameter type of a condy bootstrap to be Lookup In-Reply-To: <8B902361-938A-465B-8589-CC844FD7C250@oracle.com> References: <8B902361-938A-465B-8589-CC844FD7C250@oracle.com> Message-ID: <5D4E2874-4A3A-4418-AC5A-1A21DF9EF70C@oracle.com> Reviewed; it's good. The javadoc text doesn't need to predict the future; it just needs to document the present specification. So the sentence that begins "This constraint allows for the future possibility?" is not really necessary. It's certainly not normative. ? John On Apr 6, 2018, at 5:15 PM, Paul Sandoz wrote: > > Hi, > > Please review this patch to constrain constant dynamic bootstrap methods to methods whose first parameter type is MethodHandles.Lookup. > > http://cr.openjdk.java.net/~psandoz/jdk/JDK-8199875-condy-bsm-lookup/webrev/ > > We are conservatively diverging from invoke dynamic bootstrap method invocation behaviour to possibly diverge further in the future and allow for constant dynamic bootstrap methods that are invoked without the lookup/name/type arguments. The change enables further divergence in a future release without breaking compatibility. > > This would make it easier to use existing methods as bootstrap methods rather than invoking via a level of indirection for explicit wrappers or using ConstantBootstraps.invoke. The experience garnered from prototyping language and low-level library features informs us this is useful. > > CSR is here: > > https://bugs.openjdk.java.net/browse/JDK-8201268 > > Thanks, > Paul. From huaming.li at oracle.com Sun Apr 8 08:10:21 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Sun, 8 Apr 2018 16:10:21 +0800 Subject: RFR of JDK-8188897: java/rmi/registry/reexport/Reexport.java failed with Port already in use In-Reply-To: <0830767c-1502-54d1-5588-341731fd0aa3@Oracle.com> References: <110f6c6e-61dc-89cf-aa97-cd989c8caabc@Oracle.com> <5AC43BAE.7070601@oracle.com> <7c67de0d-f043-2ed8-d825-c9820eaf4d6a@oracle.com> <0830767c-1502-54d1-5588-341731fd0aa3@Oracle.com> Message-ID: <27541c2d-ae81-192d-d436-8da036d85635@oracle.com> Hi Roger, I have changed to not use RegistryVM at all, please review the patch: http://cr.openjdk.java.net/~mli/8188897/webrev.02/ Thank you -Hamlin On 04/04/2018 10:15 PM, Roger Riggs wrote: > Hi Hamlin, > > Reexport.java: > > I think this change to use a separate process for the 2nd registry > changes the test so that it does not > address the original test case.? The original problem was the > incorrect retention of an object in > the object table when the create of a registry in the same process > failed. > Finally being able to create the registry in the same process assured > that the object was not > retained in the object table. > > Go back to creating the 2nd registry in the test process. > > > RegistryVM.java: 2, the copyright update should be? "2017, 2018," range. > > (I'm? really not a fan of all the RegistryVM methods with the same > name and minimal and implicit > differences in their functions.? When reading the test, you have to go > and read the RegistryVM method > to see what it does.? I would have preferred that the full > createRegistryVM (out, err, options, port) method > was used directly in the tests.? In the case of a method used once, it > is an inconvenience method, not a convenience). > > The new terminate() method is quite similar to the existing cleanup() > method which does not wait. > It would be a good cleanup to figure out if another method is really > needed. > The override is going to change the behavior of the existing uses of > terminate(). > It should be checked that it does not break any existing uses. > > 178: 187: The method comments are not consistent, one says forcibly > and the other gracefully > but both call requestExit and both call destroy(). > > Thanks, Roger > > > On 4/3/2018 11:35 PM, Hamlin Li wrote: >> Hi Joe, Roger, >> >> Thank you for reviewing, I have refactored the test more and fix as >> you suggested. >> >> please review http://cr.openjdk.java.net/~mli/8188897/webrev.01/ >> >> Thank you >> >> -Hamlin >> >> >> On 04/04/2018 10:42 AM, Joseph D. Darcy wrote: >>> Hello, >>> >>> Some general comments on the coding for tests like this: >>> >>> * It is preferable to avoid sleep in tests to avoid increasing the >>> minimum amount of time a test takes to run. This helps limit the >>> overall time it takes the test suite to run. >>> >>> * If timeouts are used, it is recommend to factor the maximum time >>> waited with the jtreg timeout scaling factor; I don't recall its >>> exact name. In other words, many of our tests are run on heavily >>> loaded systems and the tests take longer than run than on typical >>> laptops and workstations so jtreg is invoked with an timeout scaling >>> factor. Individual tests should be sensitive to this scaling factor >>> for any internal timeout that need to be used. >>> >>> HTH, >>> >>> -Joe >>> >>> On 4/3/2018 7:48 AM, Roger Riggs wrote: >>>> Hi Hamlin, >>>> >>>> Instead of a simple time delay, it would be useful to wait for the >>>> RegistryVM to terminate. >>>> In killRegistry: 149,? adding subreg.waitFor() should be sufficient. >>>> >>>> 58: If using a 'for' loop it would be easier to understand if it >>>> included the usual start, increment and termination. >>>> Instead of burying it in the exception handler. >>>> >>>> 59, 102, 104: the introduction of the kill boolean makes the test >>>> harder to understand and seems to be unnecessary. >>>> ?the killRegistry() method already will only kill the subprocess if >>>> it still is alive. >>>> >>>> Roger >>>> >>>> On 4/2/2018 6:33 AM, Hamlin Li wrote: >>>>> would you please review the following patch? >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8188897 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~mli/8188897/webrev.00/ >>>>> >>>>> >>>>> Thank you >>>>> >>>>> -Hamlin >>>>> >>>> >>> >> > From Alan.Bateman at oracle.com Sun Apr 8 16:26:34 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 8 Apr 2018 17:26:34 +0100 Subject: 8194734 : Handle to jimage file inherited into child processes (win) In-Reply-To: References: <72c96cf9-a81c-192e-bda1-35768a6ecad3@gmail.com> Message-ID: <8391fe5f-dfd1-5f9f-628b-cfcb2d263492@oracle.com> On 06/04/2018 22:01, Martin Buchholz wrote: > History: > The design on Unix was that all file descriptors greater than 3 are > closed on fork and before exec. > But regardless of that, we should try to set the CLOEXEC bit on all > our file descriptor (who knows, there might be native code that does > fork+exec). > File descriptor 3 is indeed deep magic, used for error reporting.? > It's a serious bug if FAIL_FILENO ends up being used for something > other than the error reporting pipe. > I don't think I'm the last (or the first!) person who touched this. STDERR_FILENO is 2 so I'm curious which error reporting pipe is bring discussed here. The jimage file is opened very early when initializing the VM so it will get a low file descriptor number, seems to be 3. The only surprise is that it doesn't close as it shouldn't need the file descriptor after it mmapped. -Alan From Alan.Bateman at oracle.com Sun Apr 8 16:28:43 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 8 Apr 2018 17:28:43 +0100 Subject: Promptly freeing the per-thread cached direct buffers when a thread exits In-Reply-To: References: <48cadc5a-f648-e594-58f4-fe50dbbf8fd7@oracle.com> Message-ID: <0da2e4b8-4b1b-c8dc-ebee-60a2fffe1f07@oracle.com> On 06/04/2018 18:17, Tony Printezis wrote: > Hi Alan, > > Ah, I hadn?t realized that there?s already some tight coupling between > Thread and nio. OK, I?ll just call into sun.nio directly and see what > the reviewers say. :-) Is there a CR for this already? Or should I > create one? > I think it should be possible to come up with something clean so that at least code in java.base can register simple callbacks to execute at thread exit time. There are only one or two areas that will need this. -Alan From alexandr.miloslavskiy at gmail.com Sun Apr 8 16:33:36 2018 From: alexandr.miloslavskiy at gmail.com (Alexander Miloslavskiy) Date: Sun, 8 Apr 2018 19:33:36 +0300 Subject: 8194734 : Handle to jimage file inherited into child processes (win) In-Reply-To: <8391fe5f-dfd1-5f9f-628b-cfcb2d263492@oracle.com> References: <72c96cf9-a81c-192e-bda1-35768a6ecad3@gmail.com> <8391fe5f-dfd1-5f9f-628b-cfcb2d263492@oracle.com> Message-ID: <88478302-f9ae-0f57-2c8c-bef0c5a35410@gmail.com> > STDERR_FILENO is 2 so I'm curious which error reporting pipe is bring > discussed here. We're discussing line 365 of childproc.c http://hg.openjdk.java.net/jdk/jdk/file/8bdf2b5f472d/src/java.base/unix/native/libjava/childproc.c From alexandr.miloslavskiy at gmail.com Sun Apr 8 17:18:34 2018 From: alexandr.miloslavskiy at gmail.com (Alexander Miloslavskiy) Date: Sun, 8 Apr 2018 20:18:34 +0300 Subject: 8194734 : Handle to jimage file inherited into child processes (win) In-Reply-To: <8391fe5f-dfd1-5f9f-628b-cfcb2d263492@oracle.com> References: <72c96cf9-a81c-192e-bda1-35768a6ecad3@gmail.com> <8391fe5f-dfd1-5f9f-628b-cfcb2d263492@oracle.com> Message-ID: <9ab8e2b9-3c21-0343-bd9c-a53ac81fee6e@gmail.com> > The only surprise is that it doesn't close as it shouldn't need the > file descriptor after it mmapped. Indeed, both on Windows and Unix file descriptor can be closed after mapping. On the other hand, ImageFileReader is not prepared for that. See http://hg.openjdk.java.net/jdk/jdk/file/8bdf2b5f472d/src/java.base/share/native/libjimage/imageFile.cpp ImageFileReader::get_resource() uses ImageFileReader::read_at() if resource is not compressed. Furthermore, ImageFileReader::get_resource() uses ImageFileReader::read_at() if not entire jimage is mapped. This happens if architecture is not 64-bit. Even if these code paths are changed, I still think that closing file descriptor can be unexpected and will provoke future bugs. From martinrb at google.com Sun Apr 8 18:06:22 2018 From: martinrb at google.com (Martin Buchholz) Date: Sun, 8 Apr 2018 11:06:22 -0700 Subject: 8194734 : Handle to jimage file inherited into child processes (win) In-Reply-To: References: Message-ID: On Mon, Apr 2, 2018 at 2:50 PM, Alexander Miloslavskiy < alexandr.miloslavskiy at gmail.com> wrote: > The problem in this bug is that jimage file is mistakenly opened with > "inherit by child processes" flag. In our case, the child process is > started with Runtime.exec() and serves as updater that can also replace > embedded JRE. However, due to jimage ("lib/modules") file handle being > inherited, embedded JRE can not be replaced. > > The bug was introduced in commits "8087181: Move native jimage code to its > own library (maybe libjimage)" > > Before this commit, os::open() was used in libjimage code and it handles > file inheritance correctly, see: > /hotspot/src/share/vm/classfile/imageFile.cpp > * ImageFileReader::open() uses os::open(_name, 0, O_RDONLY) > /hotspot/src/os/windows/vm/os_windows.cpp > * os::open() calls to ::open(pathbuf, oflag | O_BINARY | O_NOINHERIT, > mode); > /hotspot/src/os/linux/vm/os_linux.cpp > * os::open() uses both O_CLOEXEC and FD_CLOEXEC > After this commit, a new osSupport::openReadOnly() is implemented and it > does not handle file inheritance properly. > I'm still only half paying attention, but I agree with Alexander that the low-level infrastructure in libjimage is fishy. The rule should be that file descriptors created by the JDK should have the CLOEXEC bit on. (Too many parts of the JDK create their own low-level C infrastructure - we're not good at sharing.) But even if the CLOEXEC bit was forgotten, the subprocess code should still succeed in closing that fd and use FAIL_FILENO for the error reporting pipe in childproc.c. From alexandr.miloslavskiy at gmail.com Sun Apr 8 18:56:18 2018 From: alexandr.miloslavskiy at gmail.com (Alexander Miloslavskiy) Date: Sun, 8 Apr 2018 21:56:18 +0300 Subject: 8194734 : Handle to jimage file inherited into child processes (win) In-Reply-To: References: Message-ID: <3efdeaaa-7cb7-15b7-05fe-7409997e44ba@gmail.com> > I'm still only half paying attention, but I agree with Alexander that > the low-level infrastructure in libjimage is fishy.? The rule should be > that file descriptors created by the JDK should have the CLOEXEC bit on. > > But even if the CLOEXEC bit was forgotten, the subprocess code should > still succeed in closing that fd and use FAIL_FILENO for the error > reporting pipe in childproc.c. That's two independent problems and I suggest adressing them one at a time. I anyone willing to get my patch applied? I do not have commiter rights yet, but my OCA is already processed. From martinrb at google.com Sun Apr 8 19:09:46 2018 From: martinrb at google.com (Martin Buchholz) Date: Sun, 8 Apr 2018 12:09:46 -0700 Subject: 8194734 : Handle to jimage file inherited into child processes (win) In-Reply-To: <3efdeaaa-7cb7-15b7-05fe-7409997e44ba@gmail.com> References: <3efdeaaa-7cb7-15b7-05fe-7409997e44ba@gmail.com> Message-ID: I'm hoping that JDK core libraries overall do a better job of reusing the code in e.g. src/hotspot/os/linux/os_linux:os::open somehow, that actually gets the CLOEXEC bit right. On Sun, Apr 8, 2018 at 11:56 AM, Alexander Miloslavskiy < alexandr.miloslavskiy at gmail.com> wrote: > I'm still only half paying attention, but I agree with Alexander that the >> low-level infrastructure in libjimage is fishy. The rule should be that >> file descriptors created by the JDK should have the CLOEXEC bit on. >> >> But even if the CLOEXEC bit was forgotten, the subprocess code should >> still succeed in closing that fd and use FAIL_FILENO for the error >> reporting pipe in childproc.c. >> > > That's two independent problems and I suggest adressing them one at a time. > > I anyone willing to get my patch applied? I do not have commiter rights > yet, but my OCA is already processed. > From alexandr.miloslavskiy at gmail.com Sun Apr 8 19:18:01 2018 From: alexandr.miloslavskiy at gmail.com (Alexander Miloslavskiy) Date: Sun, 8 Apr 2018 22:18:01 +0300 Subject: 8194734 : Handle to jimage file inherited into child processes (win) In-Reply-To: References: <3efdeaaa-7cb7-15b7-05fe-7409997e44ba@gmail.com> Message-ID: <2714a6ea-dd6d-2d4a-28fa-6a1ff6d86f18@gmail.com> > I'm hoping that JDK core libraries overall do a better job of reusing > the code in e.g. > src/hotspot/os/linux/os_linux:os::open > somehow, that actually gets the CLOEXEC bit right. os::open is exactly what was used in libjimage before the bug was introduced. I already described it in my first mail. I'm rarther new with all this. I understand it that hotspot is some sort of staging grounds for alpha features? If so, I can understand why libjimage no longer uses it. Also, it felt reasonable to me that someone wanted a library with dependencies minimzed. From martinrb at google.com Sun Apr 8 19:35:31 2018 From: martinrb at google.com (Martin Buchholz) Date: Sun, 8 Apr 2018 12:35:31 -0700 Subject: Promptly freeing the per-thread cached direct buffers when a thread exits In-Reply-To: References: Message-ID: On Fri, Apr 6, 2018 at 1:02 AM, Alan Bateman wrote: > On 05/04/2018 22:45, Tony Printezis wrote: > >> >> We recently hit another interesting issue with the NIO thread-local >> DirectByteBuffer cache. One of our services seems to create and drop >> threads at regular intervals. I assume this is due to a thread pool >> dynamically resizing itself. >> > ThreadPoolExecutor will replace any worker thread that had a throwing task, but that only happens on execute, (not submit, because of additional wrapping by a Future). Perhaps a mistake that is too late to fix. Keep your own worker threads from dying by making sure that all tasks are Future-wrapped. From david.holmes at oracle.com Mon Apr 9 06:25:36 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 9 Apr 2018 16:25:36 +1000 Subject: Promptly freeing the per-thread cached direct buffers when a thread exits In-Reply-To: References: Message-ID: <024118aa-c6c7-b88e-f70f-0aab9aba3fc5@oracle.com> On 7/04/2018 3:11 AM, Tony Printezis wrote: > ????? > Tony Printezis | @TonyPrintezis | tprintezis at twitter.com > > > On April 6, 2018 at 12:16:10 PM, David Lloyd (david.lloyd at redhat.com) wrote: > > On Fri, Apr 6, 2018 at 8:57 AM, Tony Printezis > wrote: >>> ThreadLocal clearing >> >> Could you clarify what you mean by ThreadLocal clearing? > > I mean calling ThreadLocal#remove(). > > > I see. So, anyone who subclasses ThreadLocal can override remove(). And if > remove() is called by Thread::exit, it can be used as an exit hook. (David > Holmes, if this is what you meant in your e-mail: apologies; I > misunderstood.) Absolutely! ... Well kind of ... okay actually no, I wasn't thinking at that level of detail yet. ;-) Cheers, David H. > > > >> I like the suggestion to add an overridable exit() method to ThreadLocal. > If >> you want to avoid calling user code by Thread::exit, would adding >> ThreadLocals (which are tagged appropriately) to a queue for later >> processing a better approach (similar to the mechanism used for > References / >> ReferencesQueues)? The user can of course create a memory leak by not >> polling the queue frequently enough. But, that?s also the case for >> References. And at least user code cannot block Thread::exit. > > It's more complexity, and at some point you have to ask: is it better > to block thread A or thread B? At least blocking thread A is somewhat > expected. > > > I agree re: it?d add complexity. #simplify :-) > > Tony > > > From peter.levart at gmail.com Mon Apr 9 07:50:57 2018 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 9 Apr 2018 09:50:57 +0200 Subject: Promptly freeing the per-thread cached direct buffers when a thread exits In-Reply-To: <024118aa-c6c7-b88e-f70f-0aab9aba3fc5@oracle.com> References: <024118aa-c6c7-b88e-f70f-0aab9aba3fc5@oracle.com> Message-ID: <497d8aaa-0c94-50f5-155c-25c533f8dfd5@gmail.com> On 04/09/18 08:25, David Holmes wrote: > > > On 7/04/2018 3:11 AM, Tony Printezis wrote: >> ????? >> Tony Printezis | @TonyPrintezis | tprintezis at twitter.com >> >> >> On April 6, 2018 at 12:16:10 PM, David Lloyd (david.lloyd at redhat.com) >> wrote: >> >> On Fri, Apr 6, 2018 at 8:57 AM, Tony Printezis >> wrote: >>>> ThreadLocal clearing >>> >>> Could you clarify what you mean by ThreadLocal clearing? >> >> I mean calling ThreadLocal#remove(). >> >> >> I see. So, anyone who subclasses ThreadLocal can override remove(). >> And if >> remove() is called by Thread::exit, it can be used as an exit hook. >> (David >> Holmes, if this is what you meant in your e-mail: apologies; I >> misunderstood.) > > Absolutely! ... Well kind of ... okay actually no, I wasn't thinking > at that level of detail yet. ;-) > > Cheers, > David H. There's no need in calling ThreadLocal.remove() at thread exit as Thread.exit() method already does that (sort of): ??? private void exit() { ??? ??? ... ??????? threadLocals = null; ??????? inheritableThreadLocals = null; ??? ??? ... After thread exits, ThreadLocal values associated with it are no longer reachable from its Thread object. The problem Tony faces is that by the time this happens, direct ByteBuffer's that were cached using such ThreadLocal value, are already moved to old GC generation, waiting for full GC to release them together with direct memory they are holding. So what is needed is an internal call-back registration API Alan is proposing and (maybe just internal) probing method for ThreadLocal that return(s) the associated value only when it has already been initialized. Regards, Peter > >> >> >> >>> I like the suggestion to add an overridable exit() method to >>> ThreadLocal. >> If >>> you want to avoid calling user code by Thread::exit, would adding >>> ThreadLocals (which are tagged appropriately) to a queue for later >>> processing a better approach (similar to the mechanism used for >> References / >>> ReferencesQueues)? The user can of course create a memory leak by not >>> polling the queue frequently enough. But, that?s also the case for >>> References. And at least user code cannot block Thread::exit. >> >> It's more complexity, and at some point you have to ask: is it better >> to block thread A or thread B? At least blocking thread A is somewhat >> expected. >> >> >> I agree re: it?d add complexity. #simplify :-) >> >> Tony >> >> >> From david.holmes at oracle.com Mon Apr 9 08:33:30 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 9 Apr 2018 18:33:30 +1000 Subject: Promptly freeing the per-thread cached direct buffers when a thread exits In-Reply-To: <497d8aaa-0c94-50f5-155c-25c533f8dfd5@gmail.com> References: <024118aa-c6c7-b88e-f70f-0aab9aba3fc5@oracle.com> <497d8aaa-0c94-50f5-155c-25c533f8dfd5@gmail.com> Message-ID: Hi Peter, On 9/04/2018 5:50 PM, Peter Levart wrote: > > > On 04/09/18 08:25, David Holmes wrote: >> >> >> On 7/04/2018 3:11 AM, Tony Printezis wrote: >>> ????? >>> Tony Printezis | @TonyPrintezis | tprintezis at twitter.com >>> >>> >>> On April 6, 2018 at 12:16:10 PM, David Lloyd (david.lloyd at redhat.com) >>> wrote: >>> >>> On Fri, Apr 6, 2018 at 8:57 AM, Tony Printezis >>> wrote: >>>>> ThreadLocal clearing >>>> >>>> Could you clarify what you mean by ThreadLocal clearing? >>> >>> I mean calling ThreadLocal#remove(). >>> >>> >>> I see. So, anyone who subclasses ThreadLocal can override remove(). >>> And if >>> remove() is called by Thread::exit, it can be used as an exit hook. >>> (David >>> Holmes, if this is what you meant in your e-mail: apologies; I >>> misunderstood.) >> >> Absolutely! ... Well kind of ... okay actually no, I wasn't thinking >> at that level of detail yet. ;-) >> >> Cheers, >> David H. > > There's no need in calling ThreadLocal.remove() at thread exit as > Thread.exit() method already does that (sort of): > > ??? private void exit() { > ??? ??? ... > ??????? threadLocals = null; > ??????? inheritableThreadLocals = null; > ??? ??? ... > > After thread exits, ThreadLocal values associated with it are no longer > reachable from its Thread object. > > The problem Tony faces is that by the time this happens, direct > ByteBuffer's that were cached using such ThreadLocal value, are already > moved to old GC generation, waiting for full GC to release them together > with direct memory they are holding. Right. So the suggestion was to call ThreadLocal.remove() instead (as well as?) so that you could define a custom ThreadLocal class for the buffers that override remove() to actually release the buffer directly. David ----- > So what is needed is an internal call-back registration API Alan is > proposing and (maybe just internal) probing method for ThreadLocal that > return(s) the associated value only when it has already been initialized. > > Regards, Peter > >> >>> >>> >>> >>>> I like the suggestion to add an overridable exit() method to >>>> ThreadLocal. >>> If >>>> you want to avoid calling user code by Thread::exit, would adding >>>> ThreadLocals (which are tagged appropriately) to a queue for later >>>> processing a better approach (similar to the mechanism used for >>> References / >>>> ReferencesQueues)? The user can of course create a memory leak by not >>>> polling the queue frequently enough. But, that?s also the case for >>>> References. And at least user code cannot block Thread::exit. >>> >>> It's more complexity, and at some point you have to ask: is it better >>> to block thread A or thread B? At least blocking thread A is somewhat >>> expected. >>> >>> >>> I agree re: it?d add complexity. #simplify :-) >>> >>> Tony >>> >>> >>> > From vivek.theeyarath at oracle.com Mon Apr 9 09:05:24 2018 From: vivek.theeyarath at oracle.com (Vivek Theeyarath) Date: Mon, 9 Apr 2018 02:05:24 -0700 (PDT) Subject: RFR: 8184692: add Pattern.asMatchPredicate In-Reply-To: <6AF1056A-D9AB-4C8C-9708-96CBCF40B2CB@oracle.com> References: <74681017-e7fe-47e8-89ef-d804c9e5e77b@default> <6AF1056A-D9AB-4C8C-9708-96CBCF40B2CB@oracle.com> Message-ID: <6e08e8d1-4052-40f9-ac30-514f3a83ef97@default> Hi, Please find the updated webrev after incorporating Paul's comments. http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.02/ Also, I have created a csr for this issue https://bugs.openjdk.java.net/browse/JDK-8201308 . Regards Vivek -----Original Message----- From: Paul Sandoz Sent: Friday, April 06, 2018 6:55 AM To: Vivek Theeyarath Cc: Core-Libs-Dev Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate > On Apr 4, 2018, at 10:47 AM, Vivek Theeyarath wrote: > > Hi All, > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8184692 > > Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.00/ > Like with your other patch, alignment to ~80 chars would be good, as that is mostly consistent with other code in the same source file. Let?s not use the word ?find" here, so as not to confuse with matcher(s).find(). 5833 * @return The predicate which can be used for finding if an input string matches this pattern. I suggest: @return The predicate which can be used for matching an input string against this pattern You could also add a @see Matcher#matches Paul. > > > The related jtreg test was run and the test passed . > > > > Regards > > Vivek From shade at redhat.com Mon Apr 9 09:52:53 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 9 Apr 2018 11:52:53 +0200 Subject: RFR [10] 8194554: filterArguments runs multiple filters in the wrong order In-Reply-To: References: Message-ID: <27b68487-ef1e-bf09-11f3-6682923720db@redhat.com> Ping. -Aleksey On 04/05/2018 05:33 PM, Aleksey Shipilev wrote: > Hi, > > Please review this jdk10 backport. > > Original JDK 11 bug: > https://bugs.openjdk.java.net/browse/JDK-8194554 > > Original JDK 11 fix: > http://hg.openjdk.java.net/jdk/jdk/rev/050352ed64d5 > > Please note the discussion in JBS comments about the issue. It seems to include the more verbose > specification text, and Rob says it makes the patch not directly backportable. Therefore, requesting > to backport without the Javadoc change. I just dropped that single line from the original changeset: > > > 8194554: filterArguments runs multiple filters in the wrong order > Reviewed-by: psandoz, jrose > > diff -r b09e56145e11 -r ab2dc3096cdb src/java.base/share/classes/java/lang/invoke/MethodHandles.java > --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Thu Mar 08 04:23:31 2018 +0000 > +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Wed Jan 17 15:17:50 2018 -0800 > @@ -3836,11 +3836,12 @@ > MethodHandle filterArguments(MethodHandle target, int pos, MethodHandle... filters) { > filterArgumentsCheckArity(target, pos, filters); > MethodHandle adapter = target; > - int curPos = pos-1; // pre-incremented > - for (MethodHandle filter : filters) { > - curPos += 1; > + // process filters in reverse order so that the invocation of > + // the resulting adapter will invoke the filters in left-to-right order > + for (int i = filters.length - 1; i >= 0; --i) { > + MethodHandle filter = filters[i]; > if (filter == null) continue; // ignore null elements of filters > - adapter = filterArgument(adapter, curPos, filter); > + adapter = filterArgument(adapter, pos + i, filter); > } > return adapter; > } > diff -r b09e56145e11 -r ab2dc3096cdb test/jdk/java/lang/invoke/FilterArgumentsTest.java > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/test/jdk/java/lang/invoke/FilterArgumentsTest.java Wed Jan 17 15:17:50 2018 -0800 > @@ -0,0 +1,132 @@ > +/* > + * Copyright (c) 2018, 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. > + * > + * 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. > + */ > + > +/* > + * @test > + * @bug 8194554 > + * @run testng/othervm test.java.lang.invoke.FilterArgumentsTest > + */ > + > +package test.java.lang.invoke; > + > +import java.lang.invoke.MethodHandle; > +import java.lang.invoke.MethodHandles; > +import java.util.ArrayList; > +import java.util.List; > + > +import static java.lang.invoke.MethodHandles.*; > +import static java.lang.invoke.MethodType.methodType; > + > +import org.testng.annotations.*; > +import static org.testng.Assert.*; > + > +public class FilterArgumentsTest { > + > + @Test > + public static void testFilterA_B_C() throws Throwable { > + FilterTest test = new FilterTest( > + filterArguments(MH_TEST, 0, MH_FILTER_A, MH_FILTER_B, MH_FILTER_C)); > + test.run(List.of("A", "B", "C")); > + } > + > + @Test > + public static void testFilterA_B() throws Throwable { > + FilterTest test = new FilterTest( > + filterArguments(MH_TEST, 0, MH_FILTER_A, MH_FILTER_B)); > + test.run(List.of("A", "B")); > + } > + > + @Test > + public static void testFilterB_C() throws Throwable { > + FilterTest test = new FilterTest( > + filterArguments(MH_TEST, 1, MH_FILTER_B, MH_FILTER_C)); > + test.run(List.of("B", "C")); > + } > + > + @Test > + public static void testFilterB() throws Throwable { > + FilterTest test = new FilterTest(filterArguments(MH_TEST, 1, MH_FILTER_B)); > + test.run(List.of("B")); > + } > + > + @Test > + public static void testFilterC() throws Throwable { > + FilterTest test = new FilterTest(filterArguments(MH_TEST, 2, MH_FILTER_C)); > + test.run(List.of("C")); > + } > + > + static class FilterTest { > + static List filters = new ArrayList<>(); > + > + final MethodHandle mh; > + FilterTest(MethodHandle mh) { > + this.mh = mh; > + } > + > + void run(List expected) throws Throwable { > + filters.clear(); > + assertEquals("x-0-z", (String)mh.invokeExact("x", 0, 'z')); > + assertEquals(expected, filters); > + } > + > + static String filterA(String s) { > + filters.add("A"); > + return s; > + } > + > + static int filterB(int value) { > + filters.add("B"); > + return value; > + } > + > + static char filterC(char c) { > + filters.add("C"); > + return c; > + } > + > + static String test(String s, int i, char c) { > + return s + "-" + i + "-" + c; > + } > + } > + > + static final MethodHandle MH_TEST; > + static final MethodHandle MH_FILTER_A; > + static final MethodHandle MH_FILTER_B; > + static final MethodHandle MH_FILTER_C; > + static final Lookup LOOKUP = MethodHandles.lookup(); > + > + static { > + try { > + MH_TEST = LOOKUP.findStatic(FilterTest.class, "test", > + methodType(String.class, String.class, int.class, char.class)); > + MH_FILTER_A = LOOKUP.findStatic(FilterTest.class, "filterA", > + methodType(String.class, String.class)); > + MH_FILTER_B = LOOKUP.findStatic(FilterTest.class, "filterB", > + methodType(int.class, int.class)); > + MH_FILTER_C = LOOKUP.findStatic(FilterTest.class, "filterC", > + methodType(char.class, char.class)); > + } catch (Exception e) { > + throw new RuntimeException(e); > + } > + } > +} > > > Thanks, > -Aleksey > From peter.levart at gmail.com Mon Apr 9 10:21:24 2018 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 9 Apr 2018 12:21:24 +0200 Subject: Promptly freeing the per-thread cached direct buffers when a thread exits In-Reply-To: References: <024118aa-c6c7-b88e-f70f-0aab9aba3fc5@oracle.com> <497d8aaa-0c94-50f5-155c-25c533f8dfd5@gmail.com> Message-ID: <879e3e70-74b4-e234-4abb-812c0c3f3f94@gmail.com> On 04/09/18 10:33, David Holmes wrote: >> After thread exits, ThreadLocal values associated with it are no >> longer reachable from its Thread object. >> >> The problem Tony faces is that by the time this happens, direct >> ByteBuffer's that were cached using such ThreadLocal value, are >> already moved to old GC generation, waiting for full GC to release >> them together with direct memory they are holding. > > Right. So the suggestion was to call ThreadLocal.remove() instead (as > well as?) so that you could define a custom ThreadLocal class for the > buffers that override remove() to actually release the buffer directly. > > David Ah, of course. But the concern is that custom code at thread-exit is not desirable. Alan is propagating private internal API. Here's a prototype: http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.00/ Would something like this be acceptable? Regards, Peter From peter.levart at gmail.com Mon Apr 9 10:26:49 2018 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 9 Apr 2018 12:26:49 +0200 Subject: Promptly freeing the per-thread cached direct buffers when a thread exits In-Reply-To: <879e3e70-74b4-e234-4abb-812c0c3f3f94@gmail.com> References: <024118aa-c6c7-b88e-f70f-0aab9aba3fc5@oracle.com> <497d8aaa-0c94-50f5-155c-25c533f8dfd5@gmail.com> <879e3e70-74b4-e234-4abb-812c0c3f3f94@gmail.com> Message-ID: <00642ac7-612f-1fd7-ee1a-d36218dacd12@gmail.com> On 04/09/18 12:21, Peter Levart wrote: > > > On 04/09/18 10:33, David Holmes wrote: >>> After thread exits, ThreadLocal values associated with it are no >>> longer reachable from its Thread object. >>> >>> The problem Tony faces is that by the time this happens, direct >>> ByteBuffer's that were cached using such ThreadLocal value, are >>> already moved to old GC generation, waiting for full GC to release >>> them together with direct memory they are holding. >> >> Right. So the suggestion was to call ThreadLocal.remove() instead (as >> well as?) so that you could define a custom ThreadLocal class for the >> buffers that override remove() to actually release the buffer directly. >> >> David > > Ah, of course. But the concern is that custom code at thread-exit is > not desirable. Alan is propagating private internal API. Here's a > prototype: > > http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.00/ > > Would something like this be acceptable? > > Regards, Peter > If adding a field to Thread class is a concern, I can modify this to use a special ThreadLocal instance to keep registered callback(s) per thread. Regards, Peter From andrew_m_leonard at uk.ibm.com Mon Apr 9 12:57:12 2018 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 9 Apr 2018 13:57:12 +0100 Subject: RFR: Export InitializeEncoding for JVM access In-Reply-To: References: Message-ID: Thanks for the feedback Roger, Yes, exporting the InitializeEncoding entry point would make sense, keeping it consistent with Canonicalize(). I have attached the new patch below: Many thanks Andrew diff --git a/src/java.base/share/native/libjava/jni_util.c b/src/java.base/share/native/libjava/jni_util.c --- a/src/java.base/share/native/libjava/jni_util.c +++ b/src/java.base/share/native/libjava/jni_util.c @@ -774,8 +774,10 @@ return newSizedStringJava(env, str, len); } -/* Initialize the fast encoding from the encoding name. */ -void +/* Initialize the fast encoding from the encoding name. + * Export InitializeEncoding so that the VM can initialize it if required. + */ +JNIEXPORT void InitializeEncoding(JNIEnv *env, const char *encname) { jclass strClazz = NULL; Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Roger Riggs To: Andrew Leonard Cc: core-libs-dev at openjdk.java.net Date: 06/04/2018 15:39 Subject: Re: RFR: Export InitializeEncoding for JVM access Hi Andrew, Would it be sufficient to export the InitializeEncoding entry point? Introducing a JNU_xx name may imply a level of support that is unwarranted since it is part of system initialization and may change as needed by the implementation. Simply exporting it would put it on par with Canonicalize. Thanks, Roger p.s. Tracking issue: https://bugs.openjdk.java.net/browse/JDK-8201246 On 4/5/2018 5:49 AM, Andrew Leonard wrote: Hi Roger, The OpenJ9 VM implementation provides its own java.lang.System, which performs similar type early-on VM initialization to the OpenJDK core library classes. The basic reason for invoking the method is to initialize the platform encoding either called from a related core library method, eg.initProperties(), or from the VM in the early stages of initialization. My suggested comparison with canonicalize was based on it's indicated usage: /* * Export the platform dependent path canonicalization so that * VM can find it when loading system classes. * This function is also used by the instrumentation agent. */ extern int canonicalize(char *path, const char *out, int len); JNIEXPORT int Canonicalize(JNIEnv *unused, char *orig, char *out, int len) { /* canonicalize an already natived path */ return canonicalize(orig, out, len); } Many thanks, Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From claes.redestad at oracle.com Mon Apr 9 13:45:32 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 9 Apr 2018 15:45:32 +0200 Subject: RFR: 8201179: Regression due loading java.nio.charset.StandardCharsets during bootstrap Message-ID: <7ea2f974-4c7d-0b4f-2262-d23604eb39dd@oracle.com> Hi, JDK-8200310 cleaned up java.nio.charset.StandardCharsets to not use Charset.forName, but also removed the optimization to have unconditionally loaded charsets set up static INSTANCE constants, which means that many systems the java.nio.charset.StandardCharsets will be initialized in System.initPhase1. This should be avoided since at this point the VM is just booting up and any code executed delays initialization of JIT etc. Webrev: http://cr.openjdk.java.net/~redestad/8201179/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8201179 This patch makes all the constants in j.n.c.StandardCharsets use new INSTANCE fields of each respective Charset and adds some comments as to why they exist. I also think we should avoid depending on j.n.c.StandardCharsets within java.base as to not accidentally execute more code in initPhase1 than absolutely necessary, so I've changed uses in core packages (java.lang, java.util, java.zip...) to use the internal alternative. Thanks! /Claes From Alan.Bateman at oracle.com Mon Apr 9 14:26:09 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 9 Apr 2018 15:26:09 +0100 Subject: Promptly freeing the per-thread cached direct buffers when a thread exits In-Reply-To: <00642ac7-612f-1fd7-ee1a-d36218dacd12@gmail.com> References: <024118aa-c6c7-b88e-f70f-0aab9aba3fc5@oracle.com> <497d8aaa-0c94-50f5-155c-25c533f8dfd5@gmail.com> <879e3e70-74b4-e234-4abb-812c0c3f3f94@gmail.com> <00642ac7-612f-1fd7-ee1a-d36218dacd12@gmail.com> Message-ID: On 09/04/2018 11:26, Peter Levart wrote: > > If adding a field to Thread class is a concern, I can modify this to > use a special ThreadLocal instance to keep registered callback(s) per > thread. Thanks for the prototype, that is along the lines of what I was thinking. I also think it would be good to prototype is as a thread local so that there isn't another Thread field. Another thought: if threads are guaranteed to free the cached buffers then we may be able to create the direct buffer without an associated cleaner. -Alan From roger.riggs at oracle.com Mon Apr 9 15:41:26 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 9 Apr 2018 11:41:26 -0400 Subject: RFR: 8184692: add Pattern.asMatchPredicate In-Reply-To: <6e08e8d1-4052-40f9-ac30-514f3a83ef97@default> References: <74681017-e7fe-47e8-89ef-d804c9e5e77b@default> <6AF1056A-D9AB-4C8C-9708-96CBCF40B2CB@oracle.com> <6e08e8d1-4052-40f9-ac30-514f3a83ef97@default> Message-ID: Hi Vivek, As with Pattern.asPredicate the first sentence can be improved. Creates a predicate that tests if this pattern matches the entire region. 5833: As with the original issue, perhaps adding the word 'whole' or 'entire' will make it clearer that the pattern must match then entire input string. 5827:? Split into two sentences, the second one starting? "For example," 5840: add a blank line between methods Regards, Roger On 4/9/18 5:05 AM, Vivek Theeyarath wrote: > Hi, > Please find the updated webrev after incorporating Paul's comments. http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.02/ > > Also, I have created a csr for this issue https://bugs.openjdk.java.net/browse/JDK-8201308 . > > Regards > Vivek > -----Original Message----- > From: Paul Sandoz > Sent: Friday, April 06, 2018 6:55 AM > To: Vivek Theeyarath > Cc: Core-Libs-Dev > Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate > > > >> On Apr 4, 2018, at 10:47 AM, Vivek Theeyarath wrote: >> >> Hi All, >> >> Please review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8184692 >> >> Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.00/ >> > Like with your other patch, alignment to ~80 chars would be good, as that is mostly consistent with other code in the same source file. > > Let?s not use the word ?find" here, so as not to confuse with matcher(s).find(). > > 5833 * @return The predicate which can be used for finding if an input string matches this pattern. > > I suggest: > > @return The predicate which can be used for matching an input string against this pattern > > You could also add a @see Matcher#matches > > Paul. > >> >> The related jtreg test was run and the test passed . >> >> >> >> Regards >> >> Vivek From paul.sandoz at oracle.com Mon Apr 9 15:55:01 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 9 Apr 2018 08:55:01 -0700 Subject: RFR: 8184692: add Pattern.asMatchPredicate In-Reply-To: References: <74681017-e7fe-47e8-89ef-d804c9e5e77b@default> <6AF1056A-D9AB-4C8C-9708-96CBCF40B2CB@oracle.com> <6e08e8d1-4052-40f9-ac30-514f3a83ef97@default> Message-ID: <3D98152E-5456-473B-9613-E0D5EDEBBC2C@oracle.com> > On Apr 9, 2018, at 8:41 AM, Roger Riggs wrote: > > Hi Vivek, > > As with Pattern.asPredicate the first sentence can be improved. > > Creates a predicate that tests if this pattern matches the entire region. > The region of what? region is clear from the context of a Matcher, but less so from the context of Pattern. Paul. > 5833: As with the original issue, perhaps adding the word 'whole' or 'entire' will make it clearer that > the pattern must match then entire input string. > > 5827: Split into two sentences, the second one starting "For example," > > 5840: add a blank line between methods > > Regards, Roger > > > On 4/9/18 5:05 AM, Vivek Theeyarath wrote: >> Hi, >> Please find the updated webrev after incorporating Paul's comments. http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.02/ >> >> Also, I have created a csr for this issue https://bugs.openjdk.java.net/browse/JDK-8201308 . >> >> Regards >> Vivek >> -----Original Message----- >> From: Paul Sandoz >> Sent: Friday, April 06, 2018 6:55 AM >> To: Vivek Theeyarath >> Cc: Core-Libs-Dev >> Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate >> >> >> >>> On Apr 4, 2018, at 10:47 AM, Vivek Theeyarath wrote: >>> >>> Hi All, >>> >>> Please review. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8184692 >>> >>> Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.00/ >>> >> Like with your other patch, alignment to ~80 chars would be good, as that is mostly consistent with other code in the same source file. >> >> Let?s not use the word ?find" here, so as not to confuse with matcher(s).find(). >> >> 5833 * @return The predicate which can be used for finding if an input string matches this pattern. >> >> I suggest: >> >> @return The predicate which can be used for matching an input string against this pattern >> >> You could also add a @see Matcher#matches >> >> Paul. >> >>> >>> The related jtreg test was run and the test passed . >>> >>> >>> >>> Regards >>> >>> Vivek > From xueming.shen at oracle.com Mon Apr 9 16:17:30 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 09 Apr 2018 09:17:30 -0700 Subject: RFR: 8184692: add Pattern.asMatchPredicate In-Reply-To: References: <74681017-e7fe-47e8-89ef-d804c9e5e77b@default> <6AF1056A-D9AB-4C8C-9708-96CBCF40B2CB@oracle.com> <6e08e8d1-4052-40f9-ac30-514f3a83ef97@default> Message-ID: <5ACB921A.7020807@oracle.com> Paul, I don't recall any particular reason why we did Predicate asPredicate() instead of Predicate asPredicate() back 1.8? mutability? sherman On 4/9/18, 8:41 AM, Roger Riggs wrote: > Hi Vivek, > > As with Pattern.asPredicate the first sentence can be improved. > > Creates a predicate that tests if this pattern matches the entire > region. > > 5833: As with the original issue, perhaps adding the word 'whole' or > 'entire' will make it clearer that > the pattern must match then entire input string. > > 5827: Split into two sentences, the second one starting "For example," > > 5840: add a blank line between methods > > Regards, Roger > > > On 4/9/18 5:05 AM, Vivek Theeyarath wrote: >> Hi, >> Please find the updated webrev after incorporating Paul's >> comments. http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.02/ >> >> Also, I have created a csr for this issue >> https://bugs.openjdk.java.net/browse/JDK-8201308 . >> >> Regards >> Vivek >> -----Original Message----- >> From: Paul Sandoz >> Sent: Friday, April 06, 2018 6:55 AM >> To: Vivek Theeyarath >> Cc: Core-Libs-Dev >> Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate >> >> >> >>> On Apr 4, 2018, at 10:47 AM, Vivek Theeyarath >>> wrote: >>> >>> Hi All, >>> >>> Please review. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8184692 >>> >>> Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.00/ >>> >> Like with your other patch, alignment to ~80 chars would be good, as >> that is mostly consistent with other code in the same source file. >> >> Let?s not use the word ?find" here, so as not to confuse with >> matcher(s).find(). >> >> 5833 * @return The predicate which can be used for finding if >> an input string matches this pattern. >> >> I suggest: >> >> @return The predicate which can be used for matching an input string >> against this pattern >> >> You could also add a @see Matcher#matches >> >> Paul. >> >>> >>> The related jtreg test was run and the test passed . >>> >>> >>> >>> Regards >>> >>> Vivek > From martinrb at google.com Mon Apr 9 16:47:26 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 9 Apr 2018 09:47:26 -0700 Subject: RFR: 8201179: Regression due loading java.nio.charset.StandardCharsets during bootstrap In-Reply-To: <7ea2f974-4c7d-0b4f-2262-d23604eb39dd@oracle.com> References: <7ea2f974-4c7d-0b4f-2262-d23604eb39dd@oracle.com> Message-ID: Thanks, Claes. I like very much how you've been reducing java startup every release, but ... I'm bothered by the small but eternal overhead of the INSTANCE fields ... It looks like the UTF_16* charsets don't need INSTANCE fields since they will not be referenced anywhere else in java.base - can we at least get rid of those, despite the asymmetry? A heroic optimization would be to create a StandardCharsets with only the 3 special fields and then somehow retransform the class to add some more final static fields after phase1 is over (but I have no idea what it would take). On Mon, Apr 9, 2018 at 6:45 AM, Claes Redestad wrote: > Hi, > > JDK-8200310 cleaned up java.nio.charset.StandardCharsets to not use > Charset.forName, but also removed the optimization to have unconditionally > loaded charsets set up static INSTANCE constants, which means that many > systems the java.nio.charset.StandardCharsets will be initialized in > System.initPhase1. > > This should be avoided since at this point the VM is just booting up and > any code executed delays initialization of JIT etc. > > Webrev: http://cr.openjdk.java.net/~redestad/8201179/open.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8201179 > > This patch makes all the constants in j.n.c.StandardCharsets use new > INSTANCE fields of each respective Charset and adds some comments as to why > they exist. > > I also think we should avoid depending on j.n.c.StandardCharsets within > java.base as to not accidentally execute more code in initPhase1 than > absolutely necessary, so I've changed uses in core packages (java.lang, > java.util, java.zip...) to use the internal alternative. > > Thanks! > > /Claes > > From paul.sandoz at oracle.com Mon Apr 9 17:43:28 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 9 Apr 2018 10:43:28 -0700 Subject: RFR: 8184692: add Pattern.asMatchPredicate In-Reply-To: <5ACB921A.7020807@oracle.com> References: <74681017-e7fe-47e8-89ef-d804c9e5e77b@default> <6AF1056A-D9AB-4C8C-9708-96CBCF40B2CB@oracle.com> <6e08e8d1-4052-40f9-ac30-514f3a83ef97@default> <5ACB921A.7020807@oracle.com> Message-ID: <72D1C903-99E5-4DF9-BBB5-DA727F159FF3@oracle.com> > On Apr 9, 2018, at 9:17 AM, Xueming Shen wrote: > > > Paul, > > I don't recall any particular reason why we did Predicate asPredicate() instead > of Predicate asPredicate() back 1.8? mutability? > Hmm? me neither i would like to think it was not an oversight :-) Mutability should not be an issue *locally* for the predicate implementation since it captures no mutable state. I suspect we erred on the side of immutability in general, so the predicate would be safe to use if there were any concurrent operation going on. I believe we could revisit this decision (as a separate issue) and a change to Predicate would be both source and binary compatible. However, i would be inclined to leave things as they are and stick to the overall immutability story. Paul. From paul.sandoz at oracle.com Mon Apr 9 17:58:07 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 9 Apr 2018 10:58:07 -0700 Subject: RFR [10] 8194554: filterArguments runs multiple filters in the wrong order In-Reply-To: <27b68487-ef1e-bf09-11f3-6682923720db@redhat.com> References: <27b68487-ef1e-bf09-11f3-6682923720db@redhat.com> Message-ID: I am supportive of this change (the risk to impacting order-dependent stateful MH filter code is smaller than the risk of hitting a string concatenation bug). (We erred on the side of this being a bug and not being a spec change given the pseudo-code in the Java doc.) IIRC this will require a nod of approval from the project lead. Paul. > On Apr 9, 2018, at 2:52 AM, Aleksey Shipilev wrote: > > Ping. > > -Aleksey > > On 04/05/2018 05:33 PM, Aleksey Shipilev wrote: >> Hi, >> >> Please review this jdk10 backport. >> >> Original JDK 11 bug: >> https://bugs.openjdk.java.net/browse/JDK-8194554 >> >> Original JDK 11 fix: >> http://hg.openjdk.java.net/jdk/jdk/rev/050352ed64d5 >> >> Please note the discussion in JBS comments about the issue. It seems to include the more verbose >> specification text, and Rob says it makes the patch not directly backportable. Therefore, requesting >> to backport without the Javadoc change. I just dropped that single line from the original changeset: >> >> >> 8194554: filterArguments runs multiple filters in the wrong order >> Reviewed-by: psandoz, jrose >> >> diff -r b09e56145e11 -r ab2dc3096cdb src/java.base/share/classes/java/lang/invoke/MethodHandles.java >> --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Thu Mar 08 04:23:31 2018 +0000 >> +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Wed Jan 17 15:17:50 2018 -0800 >> @@ -3836,11 +3836,12 @@ >> MethodHandle filterArguments(MethodHandle target, int pos, MethodHandle... filters) { >> filterArgumentsCheckArity(target, pos, filters); >> MethodHandle adapter = target; >> - int curPos = pos-1; // pre-incremented >> - for (MethodHandle filter : filters) { >> - curPos += 1; >> + // process filters in reverse order so that the invocation of >> + // the resulting adapter will invoke the filters in left-to-right order >> + for (int i = filters.length - 1; i >= 0; --i) { >> + MethodHandle filter = filters[i]; >> if (filter == null) continue; // ignore null elements of filters >> - adapter = filterArgument(adapter, curPos, filter); >> + adapter = filterArgument(adapter, pos + i, filter); >> } >> return adapter; >> } >> diff -r b09e56145e11 -r ab2dc3096cdb test/jdk/java/lang/invoke/FilterArgumentsTest.java >> --- /dev/null Thu Jan 01 00:00:00 1970 +0000 >> +++ b/test/jdk/java/lang/invoke/FilterArgumentsTest.java Wed Jan 17 15:17:50 2018 -0800 >> @@ -0,0 +1,132 @@ >> +/* >> + * Copyright (c) 2018, 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. >> + * >> + * 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. >> + */ >> + >> +/* >> + * @test >> + * @bug 8194554 >> + * @run testng/othervm test.java.lang.invoke.FilterArgumentsTest >> + */ >> + >> +package test.java.lang.invoke; >> + >> +import java.lang.invoke.MethodHandle; >> +import java.lang.invoke.MethodHandles; >> +import java.util.ArrayList; >> +import java.util.List; >> + >> +import static java.lang.invoke.MethodHandles.*; >> +import static java.lang.invoke.MethodType.methodType; >> + >> +import org.testng.annotations.*; >> +import static org.testng.Assert.*; >> + >> +public class FilterArgumentsTest { >> + >> + @Test >> + public static void testFilterA_B_C() throws Throwable { >> + FilterTest test = new FilterTest( >> + filterArguments(MH_TEST, 0, MH_FILTER_A, MH_FILTER_B, MH_FILTER_C)); >> + test.run(List.of("A", "B", "C")); >> + } >> + >> + @Test >> + public static void testFilterA_B() throws Throwable { >> + FilterTest test = new FilterTest( >> + filterArguments(MH_TEST, 0, MH_FILTER_A, MH_FILTER_B)); >> + test.run(List.of("A", "B")); >> + } >> + >> + @Test >> + public static void testFilterB_C() throws Throwable { >> + FilterTest test = new FilterTest( >> + filterArguments(MH_TEST, 1, MH_FILTER_B, MH_FILTER_C)); >> + test.run(List.of("B", "C")); >> + } >> + >> + @Test >> + public static void testFilterB() throws Throwable { >> + FilterTest test = new FilterTest(filterArguments(MH_TEST, 1, MH_FILTER_B)); >> + test.run(List.of("B")); >> + } >> + >> + @Test >> + public static void testFilterC() throws Throwable { >> + FilterTest test = new FilterTest(filterArguments(MH_TEST, 2, MH_FILTER_C)); >> + test.run(List.of("C")); >> + } >> + >> + static class FilterTest { >> + static List filters = new ArrayList<>(); >> + >> + final MethodHandle mh; >> + FilterTest(MethodHandle mh) { >> + this.mh = mh; >> + } >> + >> + void run(List expected) throws Throwable { >> + filters.clear(); >> + assertEquals("x-0-z", (String)mh.invokeExact("x", 0, 'z')); >> + assertEquals(expected, filters); >> + } >> + >> + static String filterA(String s) { >> + filters.add("A"); >> + return s; >> + } >> + >> + static int filterB(int value) { >> + filters.add("B"); >> + return value; >> + } >> + >> + static char filterC(char c) { >> + filters.add("C"); >> + return c; >> + } >> + >> + static String test(String s, int i, char c) { >> + return s + "-" + i + "-" + c; >> + } >> + } >> + >> + static final MethodHandle MH_TEST; >> + static final MethodHandle MH_FILTER_A; >> + static final MethodHandle MH_FILTER_B; >> + static final MethodHandle MH_FILTER_C; >> + static final Lookup LOOKUP = MethodHandles.lookup(); >> + >> + static { >> + try { >> + MH_TEST = LOOKUP.findStatic(FilterTest.class, "test", >> + methodType(String.class, String.class, int.class, char.class)); >> + MH_FILTER_A = LOOKUP.findStatic(FilterTest.class, "filterA", >> + methodType(String.class, String.class)); >> + MH_FILTER_B = LOOKUP.findStatic(FilterTest.class, "filterB", >> + methodType(int.class, int.class)); >> + MH_FILTER_C = LOOKUP.findStatic(FilterTest.class, "filterC", >> + methodType(char.class, char.class)); >> + } catch (Exception e) { >> + throw new RuntimeException(e); >> + } >> + } >> +} >> >> >> Thanks, >> -Aleksey >> > From Roger.Riggs at Oracle.com Mon Apr 9 18:52:42 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 9 Apr 2018 14:52:42 -0400 Subject: RFR: Export InitializeEncoding for JVM access In-Reply-To: References: Message-ID: Hi Andrew, ok,? it turns out the prototype in jni_util.h also needs to be updated to be consistent for Windows and Solaris. And no surprise, there are no test failures. I put an updated webrev in: ? http://cr.openjdk.java.net/~rriggs/webrev-encoding-8201246/ If there are no more comments, I'll commit tomorrow. Regards, Roger On 4/9/2018 8:57 AM, Andrew Leonard wrote: > Thanks for the feedback Roger, > Yes, exporting the InitializeEncoding entry point would make sense, > keeping it consistent with Canonicalize(). I have attached the new > patch below: > Many thanks > Andrew > > > diff --git a/src/java.base/share/native/libjava/jni_util.c > b/src/java.base/share/native/libjava/jni_util.c > --- a/src/java.base/share/native/libjava/jni_util.c > +++ b/src/java.base/share/native/libjava/jni_util.c > @@ -774,8 +774,10 @@ > ?return newSizedStringJava(env, str, len); > ?} > > -/* Initialize the fast encoding from the encoding name. */ > -void > +/* Initialize the fast encoding from the encoding name. > + * Export InitializeEncoding so that the VM can initialize it if > required. > + */ > +JNIEXPORT void > ?InitializeEncoding(JNIEnv *env, const char *encname) > ?{ > ?jclass strClazz = NULL; > > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: Roger Riggs > To: Andrew Leonard > Cc: core-libs-dev at openjdk.java.net > Date: 06/04/2018 15:39 > Subject: Re: RFR: Export InitializeEncoding for JVM access > ------------------------------------------------------------------------ > > > > Hi Andrew, > > Would it be sufficient to export the InitializeEncoding entry point? > > Introducing a JNU_xx name may imply a level of support that is > unwarranted since > it is part of system initialization and may change as needed by the > implementation. > Simply exporting it would put it on par with Canonicalize. > > Thanks, Roger > > p.s. Tracking issue: > _https://bugs.openjdk.java.net/browse/JDK-8201246_ > > > On 4/5/2018 5:49 AM, Andrew Leonard wrote: > Hi Roger, > The OpenJ9 VM implementation provides its own java.lang.System, which > performs similar type early-on VM initialization to the OpenJDK core > library classes. The basic reason for invoking the method is to > initialize the platform encoding either called from a related core > library method, eg.initProperties(), or from the VM in the early > stages of initialization. > > My suggested comparison with canonicalize was based on it's indicated > usage: > /* > ?* Export the platform dependent path canonicalization so that > ?* VM can find it when loading system classes. > ?* This function is also used by the instrumentation agent. > ?*/ > extern int canonicalize(char *path, const char *out, int len); > > JNIEXPORT int > Canonicalize(JNIEnv *unused, char *orig, char *out, int len) > { > ? ? /* canonicalize an already natived path */ > ? ? return canonicalize(orig, out, len); > } > > > Many thanks, > Andrew > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: _andrew_m_leonard at uk.ibm.com_ > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Roger.Riggs at Oracle.com Mon Apr 9 19:09:26 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 9 Apr 2018 15:09:26 -0400 Subject: RFR of JDK-8188897: java/rmi/registry/reexport/Reexport.java failed with Port already in use In-Reply-To: <27541c2d-ae81-192d-d436-8da036d85635@oracle.com> References: <110f6c6e-61dc-89cf-aa97-cd989c8caabc@Oracle.com> <5AC43BAE.7070601@oracle.com> <7c67de0d-f043-2ed8-d825-c9820eaf4d6a@oracle.com> <0830767c-1502-54d1-5588-341731fd0aa3@Oracle.com> <27541c2d-ae81-192d-d436-8da036d85635@oracle.com> Message-ID: Hi Hamlin, Great, the new busy port algorithm looks better. The port assigned will always be one that was available and is now busy to prevent the registry creation. As expected, there is a small window? between the (try-with-finally) close of the server socket channel and the 2nd createReg.? But that can't be avoided.? If the port is re-used in that gap the test will fail.? (And the exception handler at 77 will see an in-use and retry). 67: The exception being caught is already one thrown by TestLibrary.bomb so it would be cleaner to just re-throw e;? or better yet, just don't bother to catch the exception. That exception should cause the test to fail. It may be personal coding style but the createReg method with a boolean flag to suppress the exception is just more confusing that putting the code in-line in the two places it is used. Thanks, Roger On 4/8/2018 4:10 AM, Hamlin Li wrote: > Hi Roger, > > I have changed to not use RegistryVM at all, please review the patch: > http://cr.openjdk.java.net/~mli/8188897/webrev.02/ > > Thank you > > -Hamlin > > > On 04/04/2018 10:15 PM, Roger Riggs wrote: >> Hi Hamlin, >> >> Reexport.java: >> >> I think this change to use a separate process for the 2nd registry >> changes the test so that it does not >> address the original test case.? The original problem was the >> incorrect retention of an object in >> the object table when the create of a registry in the same process >> failed. >> Finally being able to create the registry in the same process assured >> that the object was not >> retained in the object table. >> >> Go back to creating the 2nd registry in the test process. >> >> >> RegistryVM.java: 2, the copyright update should be? "2017, 2018," range. >> >> (I'm? really not a fan of all the RegistryVM methods with the same >> name and minimal and implicit >> differences in their functions.? When reading the test, you have to >> go and read the RegistryVM method >> to see what it does.? I would have preferred that the full >> createRegistryVM (out, err, options, port) method >> was used directly in the tests.? In the case of a method used once, >> it is an inconvenience method, not a convenience). >> >> The new terminate() method is quite similar to the existing cleanup() >> method which does not wait. >> It would be a good cleanup to figure out if another method is really >> needed. >> The override is going to change the behavior of the existing uses of >> terminate(). >> It should be checked that it does not break any existing uses. >> >> 178: 187: The method comments are not consistent, one says forcibly >> and the other gracefully >> but both call requestExit and both call destroy(). >> >> Thanks, Roger >> >> >> On 4/3/2018 11:35 PM, Hamlin Li wrote: >>> Hi Joe, Roger, >>> >>> Thank you for reviewing, I have refactored the test more and fix as >>> you suggested. >>> >>> please review http://cr.openjdk.java.net/~mli/8188897/webrev.01/ >>> >>> Thank you >>> >>> -Hamlin >>> >>> >>> On 04/04/2018 10:42 AM, Joseph D. Darcy wrote: >>>> Hello, >>>> >>>> Some general comments on the coding for tests like this: >>>> >>>> * It is preferable to avoid sleep in tests to avoid increasing the >>>> minimum amount of time a test takes to run. This helps limit the >>>> overall time it takes the test suite to run. >>>> >>>> * If timeouts are used, it is recommend to factor the maximum time >>>> waited with the jtreg timeout scaling factor; I don't recall its >>>> exact name. In other words, many of our tests are run on heavily >>>> loaded systems and the tests take longer than run than on typical >>>> laptops and workstations so jtreg is invoked with an timeout >>>> scaling factor. Individual tests should be sensitive to this >>>> scaling factor for any internal timeout that need to be used. >>>> >>>> HTH, >>>> >>>> -Joe >>>> >>>> On 4/3/2018 7:48 AM, Roger Riggs wrote: >>>>> Hi Hamlin, >>>>> >>>>> Instead of a simple time delay, it would be useful to wait for the >>>>> RegistryVM to terminate. >>>>> In killRegistry: 149,? adding subreg.waitFor() should be sufficient. >>>>> >>>>> 58: If using a 'for' loop it would be easier to understand if it >>>>> included the usual start, increment and termination. >>>>> Instead of burying it in the exception handler. >>>>> >>>>> 59, 102, 104: the introduction of the kill boolean makes the test >>>>> harder to understand and seems to be unnecessary. >>>>> ?the killRegistry() method already will only kill the subprocess >>>>> if it still is alive. >>>>> >>>>> Roger >>>>> >>>>> On 4/2/2018 6:33 AM, Hamlin Li wrote: >>>>>> would you please review the following patch? >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8188897 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~mli/8188897/webrev.00/ >>>>>> >>>>>> >>>>>> Thank you >>>>>> >>>>>> -Hamlin >>>>>> >>>>> >>>> >>> >> > From paul.sandoz at oracle.com Mon Apr 9 19:58:32 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 9 Apr 2018 12:58:32 -0700 Subject: RFR: jsr166 jdk integration 2018-04 In-Reply-To: References: Message-ID: Looks good. ForkJoinPool.java ? 356 * readers must tolerate null slots. Worker queues are at odd 357 * indices. Shared (submission) queues are at even indices, up to 358 * a maximum of 64 slots, to limit growth even if array needs to 359 * expand to add more workers. Grouping them together in this way 360 * simplifies and speeds up task scanning. Minor typo: ?even if array? -> ?even if the array? I don?t claim to understand most of the updates to ForkJoinPool, there is more going on here from looking at the CVS logs (helpful to tease apart various changes), which is ok. Paul. > On Apr 5, 2018, at 9:43 AM, Martin Buchholz wrote: > > http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html > > 8200728: Docs (Comparison of Stack and Deque methods) for Deque is not correct' src/main/java/util/Deque.java > http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/Deque-Stack/index.html > https://bugs.openjdk.java.net/browse/JDK-8200728 > > 8200520: forkjoin tasks interrupted after shutdown > http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/ForkJoinPool-shutdown/index.html > https://bugs.openjdk.java.net/browse/JDK-8200520 > > 8200258: Improve CopyOnWriteArrayList subList code > http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/CopyOnWriteArrayList-subList/index.html > https://bugs.openjdk.java.net/browse/JDK-8200258 > > 8197531: Miscellaneous changes imported from jsr166 CVS 2018-04 > http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html > https://bugs.openjdk.java.net/browse/JDK-8197531 > From naoto.sato at oracle.com Mon Apr 9 20:20:02 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 9 Apr 2018 13:20:02 -0700 Subject: [11] RFR: 8189784: Parsing with Java 9 AKST timezone returns the SystemV variant of the timezone Message-ID: <8f639e94-1564-17b2-d999-31f46c9a1a08@oracle.com> Hello, Please review the changes to the following issue: https://bugs.openjdk.java.net/browse/JDK-8189784 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8189784/webrev.02/ There were two causes of the issue. One was that j.t.f.ZoneName contained hard coded mappings based on the old CLDR data and never been updated. The other reason was that CLDR's deprecated zones ("SystemV" ones, in this case) were not properly replaced. I am including build-dev for the review, as the change includes generating ZoneName mapping at the build time from the template. Naoto From martinrb at google.com Mon Apr 9 20:29:13 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 9 Apr 2018 13:29:13 -0700 Subject: RFR: jsr166 jdk integration 2018-04 In-Reply-To: References: Message-ID: On Mon, Apr 9, 2018 at 12:58 PM, Paul Sandoz wrote: > > Minor typo: ?even if array? -> ?even if the array? > > typo fixed From paul.sandoz at oracle.com Mon Apr 9 21:31:52 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 9 Apr 2018 14:31:52 -0700 Subject: RFR 8199875: Require first parameter type of a condy bootstrap to be Lookup In-Reply-To: <5D4E2874-4A3A-4418-AC5A-1A21DF9EF70C@oracle.com> References: <8B902361-938A-465B-8589-CC844FD7C250@oracle.com> <5D4E2874-4A3A-4418-AC5A-1A21DF9EF70C@oracle.com> Message-ID: > On Apr 6, 2018, at 10:32 PM, John Rose wrote: > > Reviewed; it's good. > Thanks. > The javadoc text doesn't need to predict the future; it just needs to document > the present specification. So the sentence that begins "This constraint allows for > the future possibility?" is not really necessary. It's certainly not normative. > Dan did some surgery on the package doc when doing the condy spec work. We both agreed that text here was generally non-normative where as the VM specification provides the normative text. I felt i could not leave the current situation dangling without some explanation, since it introduces an obvious difference between indy and condy leaving the reader wondering the benefit might be. I?ll update and preface with ?Note: ? to make the distinction clearer. It does make me wonder whether we should proceed less conservatively and implement now the support condy invocation of BSMs without meta-data. Paul. > ? John > > On Apr 6, 2018, at 5:15 PM, Paul Sandoz wrote: >> >> Hi, >> >> Please review this patch to constrain constant dynamic bootstrap methods to methods whose first parameter type is MethodHandles.Lookup. >> >> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8199875-condy-bsm-lookup/webrev/ >> >> We are conservatively diverging from invoke dynamic bootstrap method invocation behaviour to possibly diverge further in the future and allow for constant dynamic bootstrap methods that are invoked without the lookup/name/type arguments. The change enables further divergence in a future release without breaking compatibility. >> >> This would make it easier to use existing methods as bootstrap methods rather than invoking via a level of indirection for explicit wrappers or using ConstantBootstraps.invoke. The experience garnered from prototyping language and low-level library features informs us this is useful. >> >> CSR is here: >> >> https://bugs.openjdk.java.net/browse/JDK-8201268 >> >> Thanks, >> Paul. > From stevenschlansker at gmail.com Mon Apr 9 22:49:32 2018 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Mon, 9 Apr 2018 15:49:32 -0700 Subject: Future.get(Duration)? Message-ID: <65B8AD4E-AF3D-40F9-A9E3-BDEB6349AB91@gmail.com> Hi core-libs-dev, Future.get(int, TimeUnit) is great, it allows you to put a timeout. Duration is great, it's a common way to cart a duration around, and some frameworks can parse it for you, say you have an injector (Spring in this case) that can handle: @Value("my-timeout:PT10s") Duration timeout; Now, you might obviously try to write: myFuture.get(timeout); // ARGH only to find out that instead you have to do some convoluted construction like myFuture.get(timeout.toMillis(), TimeUnit.MILLISECONDS); // :( How about a super simple added method to Future? default T get(Duration timeout) throws TimeoutException { return get(timeout.toMillis(), TimeUnit.MILLISECONDS); // maybe this should handle nanos, but you get the idea } Thanks for considering! From martinrb at google.com Mon Apr 9 22:58:18 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 9 Apr 2018 15:58:18 -0700 Subject: Future.get(Duration)? In-Reply-To: <65B8AD4E-AF3D-40F9-A9E3-BDEB6349AB91@gmail.com> References: <65B8AD4E-AF3D-40F9-A9E3-BDEB6349AB91@gmail.com> Message-ID: https://bugs.openjdk.java.net/browse/JDK-8201344 On Mon, Apr 9, 2018 at 3:49 PM, Steven Schlansker < stevenschlansker at gmail.com> wrote: > Hi core-libs-dev, > > Future.get(int, TimeUnit) is great, it allows you to put a timeout. > > Duration is great, it's a common way to cart a duration around, and some > frameworks can parse it for you, say > you have an injector (Spring in this case) that can handle: > > @Value("my-timeout:PT10s") > Duration timeout; > > Now, you might obviously try to write: > > myFuture.get(timeout); // ARGH > > only to find out that instead you have to do some convoluted construction > like > > myFuture.get(timeout.toMillis(), TimeUnit.MILLISECONDS); // :( > > How about a super simple added method to Future? > > default T get(Duration timeout) throws TimeoutException { > return get(timeout.toMillis(), TimeUnit.MILLISECONDS); // maybe this > should handle nanos, but you get the idea > } > > Thanks for considering! > > From kevinb at google.com Mon Apr 9 23:10:53 2018 From: kevinb at google.com (Kevin Bourrillion) Date: Mon, 9 Apr 2018 16:10:53 -0700 Subject: stripIndent() behavior Message-ID: On Tue, Mar 13, 2018 at 6:47 AM, Jim Laskey wrote: C. Margin management. With introduction of multi-line Raw String Literals, > developers will have to deal with the extraneous spacing introduced by > indenting and formatting string bodies. > > Note that for all the methods in this group, if the first line is empty > then it is removed and if the last is empty then it is removed. This > removal provides a means for developers that use delimiters on separate > lines to bracket string bodies. +1 I think this is a good idea, which I didn't notice at first. For Google Style, I can imagine ending up requiring newlines inside the delimiters, as it makes the raw text embedded in your source code fit nicely into an imaginary rectangle. > public String trimIndent() > This method determines a representative line in the string body that has a > non-whitespace character closest to the left margin. Once that line has > been determined, the number of leading whitespaces is tallied to produce a > minimal indent amount. Consequently, the result of the method is a string > with the minimal indent amount removed from each line. The first line is > unaffected since it is preceded by the open delimiter. The type of > whitespace used (spaces or tabs) does not affect the result as long as the > developer is consistent with the whitespace used. > (now stripIndent) I've accumulated a few questions/comments on this. 1. When choosing the amount to trim, it ought to ignore blank lines and only-whitespace lines, right? 2. Is it really appropriate to automatically remove trailing whitespace? My feeling is that if it creates some kind of problem at runtime, they can just remove it from their source. Or call the method that's explicitly for that. But in general... tws in, tws out...? (Again though, lines that are otherwise empty aside from tws need to not gum up the works (#1).) 3. If the input contains *any* tab characters at all (except any that are part of the trailing whitespace), then this method cannot know that it isn't jumbling the end result, and maybe it should just throw. Google Style completely banishes tabs from source flies, but among the many projects that don't there are going to be countless examples where tabs and spaces are mixed in a haphazard fashion that the developer isn't even remotely aware of. We should consider whether we're comfortable with surprising realignment of their text, or would be better off throwing. The remedy for the user in that case is either to nuke the tabs from this part of their source, or call a method like `detab(int myTabStop)` first. 4. Honestly, my #1 complaint with this method is that it is so well-suited to the needs of RSLs embedded in Java source that we are going to want to call it every. single. time. As unpleasant as that sounds, at this point I think all the alternatives might be considerably worse. So, this isn't going to end up making the language feature itself feel very elegant. I really wish we could come up with two syntactic options so that one could be auto-unindenting, but I know how hard that would be. 5. If we do end up in a world where we have to call this for almost every one of our tens of thousands of multi-line RSLs... is it strange that I feel like I would prefer it was static? It seems like it would look a lot more normal that way visually. Ugh... foo( bar, ` first line second line third line `.stripIndent(), baz); vs. foo( bar, stripIndent(` first line second line third line `), baz); I don't feel great about this, but I just really don't feel happy about all our RSLs looking like the top snippet. public String trimMarkers(String leftMarker, String rightMarker) > At first, I was drawn to this method, because I liked how it clearly "called out" the sections that were embedded RSLs and made them stand out from the surrounding code. (When I imagine a long RSL that itself contains Java code, and then I open my editor somewhere in the middle of that - wow, how misleading!) However, I quickly realized that the markers are terribly invasive, ruining your ability to paste in, paste out, and rewrap paragraphs. And although I could use this when I want conceptually to stripIndent but I need to preserve a certain fixed amount of indentation on every line, I still think I would rather use stripIndent and then just call a method to restore the specific amount of indentation I want. So in summary, currently I can't see why we would ever use this method. FYI. On top of *that*, I have no idea what "right markers" are good for, nor what customizing the marker choice is good for (other than creating more needless variation between different pieces of code). -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com From erik.joelsson at oracle.com Mon Apr 9 23:15:33 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 9 Apr 2018 16:15:33 -0700 Subject: [11] RFR: 8189784: Parsing with Java 9 AKST timezone returns the SystemV variant of the timezone In-Reply-To: <8f639e94-1564-17b2-d999-31f46c9a1a08@oracle.com> References: <8f639e94-1564-17b2-d999-31f46c9a1a08@oracle.com> Message-ID: Hello Naoto, Looks good, just a style issue. When breaking a recipe line, please add 4 additional spaces (after the tab) for continuation indent [1]. In this case I would also advocate breaking the line sooner to make side by side comparisons easier in the future. /Erik [1] http://openjdk.java.net/groups/build/doc/code-conventions.html On 2018-04-09 13:20, Naoto Sato wrote: > Hello, > > Please review the changes to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8189784 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8189784/webrev.02/ > > There were two causes of the issue. One was that j.t.f.ZoneName > contained hard coded mappings based on the old CLDR data and never > been updated. The other reason was that CLDR's deprecated zones > ("SystemV" ones, in this case) were not properly replaced. > > I am including build-dev for the review, as the change includes > generating ZoneName mapping at the build time from the template. > > Naoto From naoto.sato at oracle.com Tue Apr 10 01:00:18 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 9 Apr 2018 18:00:18 -0700 Subject: [11] RFR: 8189784: Parsing with Java 9 AKST timezone returns the SystemV variant of the timezone In-Reply-To: References: <8f639e94-1564-17b2-d999-31f46c9a1a08@oracle.com> Message-ID: Thanks, Erik. Modified GensrcCLDR.gmk as suggested: http://cr.openjdk.java.net/~naoto/8189784/webrev.03/ Naoto On 4/9/18 4:15 PM, Erik Joelsson wrote: > Hello Naoto, > > Looks good, just a style issue. > > When breaking a recipe line, please add 4 additional spaces (after the > tab) for continuation indent [1]. In this case I would also advocate > breaking the line sooner to make side by side comparisons easier in the > future. > > /Erik > > [1] http://openjdk.java.net/groups/build/doc/code-conventions.html > > On 2018-04-09 13:20, Naoto Sato wrote: >> Hello, >> >> Please review the changes to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8189784 >> >> The proposed changeset is located at: >> >> http://cr.openjdk.java.net/~naoto/8189784/webrev.02/ >> >> There were two causes of the issue. One was that j.t.f.ZoneName >> contained hard coded mappings based on the old CLDR data and never >> been updated. The other reason was that CLDR's deprecated zones >> ("SystemV" ones, in this case) were not properly replaced. >> >> I am including build-dev for the review, as the change includes >> generating ZoneName mapping at the build time from the template. >> >> Naoto > From huaming.li at oracle.com Tue Apr 10 02:49:24 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Tue, 10 Apr 2018 10:49:24 +0800 Subject: RFR of JDK-8188897: java/rmi/registry/reexport/Reexport.java failed with Port already in use In-Reply-To: References: <110f6c6e-61dc-89cf-aa97-cd989c8caabc@Oracle.com> <5AC43BAE.7070601@oracle.com> <7c67de0d-f043-2ed8-d825-c9820eaf4d6a@oracle.com> <0830767c-1502-54d1-5588-341731fd0aa3@Oracle.com> <27541c2d-ae81-192d-d436-8da036d85635@oracle.com> Message-ID: On 10/04/2018 3:09 AM, Roger Riggs wrote: > Hi Hamlin, Hi Roger, Thank you for review. > > Great, the new busy port algorithm looks better. > The port assigned will always be one that was available and is now > busy to prevent the registry creation. > > As expected, there is a small window? between the (try-with-finally) > close of the server socket channel > and the 2nd createReg.? But that can't be avoided.? If the port is > re-used in that gap > the test will fail.? (And the exception handler at 77 will see an > in-use and retry). Yes, you're right. > > 67: The exception being caught is already one thrown by > TestLibrary.bomb so it would be > cleaner to just re-throw e;? or better yet, just don't bother to catch > the exception. > That exception should cause the test to fail. It's to catch IOException by ServerSocketChannel.open, bind. Seems it's a little confusing, so I declare at main function to throw IOException. > > It may be personal coding style but the createReg method with a > boolean flag to suppress > the exception is just more confusing that putting the code in-line in > the two places it is used. I think it's mainly because of original parameter name remoteOK, so rename it as expectException, and move it to the last parameter. new webrev is updated in place: http://cr.openjdk.java.net/~mli/8188897/webrev.02/ Thank you -Hamlin > > Thanks, Roger > > > On 4/8/2018 4:10 AM, Hamlin Li wrote: >> Hi Roger, >> >> I have changed to not use RegistryVM at all, please review the patch: >> http://cr.openjdk.java.net/~mli/8188897/webrev.02/ >> >> Thank you >> >> -Hamlin >> >> >> On 04/04/2018 10:15 PM, Roger Riggs wrote: >>> Hi Hamlin, >>> >>> Reexport.java: >>> >>> I think this change to use a separate process for the 2nd registry >>> changes the test so that it does not >>> address the original test case.? The original problem was the >>> incorrect retention of an object in >>> the object table when the create of a registry in the same process >>> failed. >>> Finally being able to create the registry in the same process >>> assured that the object was not >>> retained in the object table. >>> >>> Go back to creating the 2nd registry in the test process. >>> >>> >>> RegistryVM.java: 2, the copyright update should be? "2017, 2018," >>> range. >>> >>> (I'm? really not a fan of all the RegistryVM methods with the same >>> name and minimal and implicit >>> differences in their functions.? When reading the test, you have to >>> go and read the RegistryVM method >>> to see what it does.? I would have preferred that the full >>> createRegistryVM (out, err, options, port) method >>> was used directly in the tests.? In the case of a method used once, >>> it is an inconvenience method, not a convenience). >>> >>> The new terminate() method is quite similar to the existing >>> cleanup() method which does not wait. >>> It would be a good cleanup to figure out if another method is really >>> needed. >>> The override is going to change the behavior of the existing uses of >>> terminate(). >>> It should be checked that it does not break any existing uses. >>> >>> 178: 187: The method comments are not consistent, one says forcibly >>> and the other gracefully >>> but both call requestExit and both call destroy(). >>> >>> Thanks, Roger >>> >>> >>> On 4/3/2018 11:35 PM, Hamlin Li wrote: >>>> Hi Joe, Roger, >>>> >>>> Thank you for reviewing, I have refactored the test more and fix as >>>> you suggested. >>>> >>>> please review http://cr.openjdk.java.net/~mli/8188897/webrev.01/ >>>> >>>> Thank you >>>> >>>> -Hamlin >>>> >>>> >>>> On 04/04/2018 10:42 AM, Joseph D. Darcy wrote: >>>>> Hello, >>>>> >>>>> Some general comments on the coding for tests like this: >>>>> >>>>> * It is preferable to avoid sleep in tests to avoid increasing the >>>>> minimum amount of time a test takes to run. This helps limit the >>>>> overall time it takes the test suite to run. >>>>> >>>>> * If timeouts are used, it is recommend to factor the maximum time >>>>> waited with the jtreg timeout scaling factor; I don't recall its >>>>> exact name. In other words, many of our tests are run on heavily >>>>> loaded systems and the tests take longer than run than on typical >>>>> laptops and workstations so jtreg is invoked with an timeout >>>>> scaling factor. Individual tests should be sensitive to this >>>>> scaling factor for any internal timeout that need to be used. >>>>> >>>>> HTH, >>>>> >>>>> -Joe >>>>> >>>>> On 4/3/2018 7:48 AM, Roger Riggs wrote: >>>>>> Hi Hamlin, >>>>>> >>>>>> Instead of a simple time delay, it would be useful to wait for >>>>>> the RegistryVM to terminate. >>>>>> In killRegistry: 149,? adding subreg.waitFor() should be sufficient. >>>>>> >>>>>> 58: If using a 'for' loop it would be easier to understand if it >>>>>> included the usual start, increment and termination. >>>>>> Instead of burying it in the exception handler. >>>>>> >>>>>> 59, 102, 104: the introduction of the kill boolean makes the test >>>>>> harder to understand and seems to be unnecessary. >>>>>> ?the killRegistry() method already will only kill the subprocess >>>>>> if it still is alive. >>>>>> >>>>>> Roger >>>>>> >>>>>> On 4/2/2018 6:33 AM, Hamlin Li wrote: >>>>>>> would you please review the following patch? >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8188897 >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~mli/8188897/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Thank you >>>>>>> >>>>>>> -Hamlin >>>>>>> >>>>>> >>>>> >>>> >>> >> > From vivek.theeyarath at oracle.com Tue Apr 10 02:53:24 2018 From: vivek.theeyarath at oracle.com (Vivek Theeyarath) Date: Mon, 9 Apr 2018 19:53:24 -0700 (PDT) Subject: RFR: 8184692: add Pattern.asMatchPredicate In-Reply-To: <3D98152E-5456-473B-9613-E0D5EDEBBC2C@oracle.com> References: <74681017-e7fe-47e8-89ef-d804c9e5e77b@default> <6AF1056A-D9AB-4C8C-9708-96CBCF40B2CB@oracle.com> <6e08e8d1-4052-40f9-ac30-514f3a83ef97@default> <3D98152E-5456-473B-9613-E0D5EDEBBC2C@oracle.com> Message-ID: Thanks Paul / Roger for the inputs. I have updated the javadoc based on the inputs. http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.03 . Please review. Regards Vivek -----Original Message----- From: Paul Sandoz Sent: Monday, April 09, 2018 9:25 PM To: Roger Riggs Cc: Core-Libs-Dev Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate > On Apr 9, 2018, at 8:41 AM, Roger Riggs wrote: > > Hi Vivek, > > As with Pattern.asPredicate the first sentence can be improved. > > Creates a predicate that tests if this pattern matches the entire region. > The region of what? region is clear from the context of a Matcher, but less so from the context of Pattern. Paul. > 5833: As with the original issue, perhaps adding the word 'whole' or > 'entire' will make it clearer that the pattern must match then entire input string. > > 5827: Split into two sentences, the second one starting "For example," > > 5840: add a blank line between methods > > Regards, Roger > > > On 4/9/18 5:05 AM, Vivek Theeyarath wrote: >> Hi, >> Please find the updated webrev after incorporating Paul's comments. >> http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.02/ >> >> Also, I have created a csr for this issue https://bugs.openjdk.java.net/browse/JDK-8201308 . >> >> Regards >> Vivek >> -----Original Message----- >> From: Paul Sandoz >> Sent: Friday, April 06, 2018 6:55 AM >> To: Vivek Theeyarath >> Cc: Core-Libs-Dev >> Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate >> >> >> >>> On Apr 4, 2018, at 10:47 AM, Vivek Theeyarath wrote: >>> >>> Hi All, >>> >>> Please review. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8184692 >>> >>> Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.00/ >>> >> Like with your other patch, alignment to ~80 chars would be good, as that is mostly consistent with other code in the same source file. >> >> Let?s not use the word ?find" here, so as not to confuse with matcher(s).find(). >> >> 5833 * @return The predicate which can be used for finding if an input string matches this pattern. >> >> I suggest: >> >> @return The predicate which can be used for matching an input string >> against this pattern >> >> You could also add a @see Matcher#matches >> >> Paul. >> >>> >>> The related jtreg test was run and the test passed . >>> >>> >>> >>> Regards >>> >>> Vivek > From felix.yang at oracle.com Tue Apr 10 03:15:22 2018 From: felix.yang at oracle.com (Felix Yang) Date: Tue, 10 Apr 2018 11:15:22 +0800 Subject: RFR 8201348, ProblemList update for bugid associated with SSLSocketParametersTest.sh Message-ID: Hi, ??? please review a minor change on the associated bug id in ProblemList.txt. Bug: ??? https://bugs.openjdk.java.net/browse/JDK-8201348 Patch: diff -r f088ec60bed5 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt? Mon Apr 09 10:39:29 2018 -0700 +++ b/test/jdk/ProblemList.txt? Mon Apr 09 19:26:47 2018 -0700 @@ -778,7 +778,7 @@ ?com/sun/jndi/ldap/LdapTimeoutTest.java 8151678 linux-all -javax/rmi/ssl/SSLSocketParametersTest.sh 8194663 generic-all +javax/rmi/ssl/SSLSocketParametersTest.sh 8162906 generic-all ?############################################################################ Thanks, Felix From Alan.Bateman at oracle.com Tue Apr 10 06:42:25 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Apr 2018 07:42:25 +0100 Subject: RFR [10] 8194554: filterArguments runs multiple filters in the wrong order In-Reply-To: References: <27b68487-ef1e-bf09-11f3-6682923720db@redhat.com> Message-ID: On 09/04/2018 18:58, Paul Sandoz wrote: > I am supportive of this change (the risk to impacting order-dependent stateful MH filter code is smaller than the risk of hitting a string concatenation bug). (We erred on the side of this being a bug and not being a spec change given the pseudo-code in the Java doc.) > > IIRC this will require a nod of approval from the project lead. > > Paul. I think this is a CSR for Java SE 11 first as it adds a testable assertion to the spec and also changes existing behavior. -Alan From andrew_m_leonard at uk.ibm.com Tue Apr 10 08:15:09 2018 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 10 Apr 2018 09:15:09 +0100 Subject: RFR: Export InitializeEncoding for JVM access In-Reply-To: References: Message-ID: Many thanks Roger, much appreciated. Cheers Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Roger Riggs To: Andrew Leonard Cc: core-libs-dev at openjdk.java.net Date: 09/04/2018 19:52 Subject: Re: RFR: Export InitializeEncoding for JVM access Hi Andrew, ok, it turns out the prototype in jni_util.h also needs to be updated to be consistent for Windows and Solaris. And no surprise, there are no test failures. I put an updated webrev in: http://cr.openjdk.java.net/~rriggs/webrev-encoding-8201246/ If there are no more comments, I'll commit tomorrow. Regards, Roger On 4/9/2018 8:57 AM, Andrew Leonard wrote: Thanks for the feedback Roger, Yes, exporting the InitializeEncoding entry point would make sense, keeping it consistent with Canonicalize(). I have attached the new patch below: Many thanks Andrew diff --git a/src/java.base/share/native/libjava/jni_util.c b/src/java.base/share/native/libjava/jni_util.c --- a/src/java.base/share/native/libjava/jni_util.c +++ b/src/java.base/share/native/libjava/jni_util.c @@ -774,8 +774,10 @@ return newSizedStringJava(env, str, len); } -/* Initialize the fast encoding from the encoding name. */ -void +/* Initialize the fast encoding from the encoding name. + * Export InitializeEncoding so that the VM can initialize it if required. + */ +JNIEXPORT void InitializeEncoding(JNIEnv *env, const char *encname) { jclass strClazz = NULL; Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Roger Riggs To: Andrew Leonard Cc: core-libs-dev at openjdk.java.net Date: 06/04/2018 15:39 Subject: Re: RFR: Export InitializeEncoding for JVM access Hi Andrew, Would it be sufficient to export the InitializeEncoding entry point? Introducing a JNU_xx name may imply a level of support that is unwarranted since it is part of system initialization and may change as needed by the implementation. Simply exporting it would put it on par with Canonicalize. Thanks, Roger p.s. Tracking issue: https://bugs.openjdk.java.net/browse/JDK-8201246 On 4/5/2018 5:49 AM, Andrew Leonard wrote: Hi Roger, The OpenJ9 VM implementation provides its own java.lang.System, which performs similar type early-on VM initialization to the OpenJDK core library classes. The basic reason for invoking the method is to initialize the platform encoding either called from a related core library method, eg.initProperties(), or from the VM in the early stages of initialization. My suggested comparison with canonicalize was based on it's indicated usage: /* * Export the platform dependent path canonicalization so that * VM can find it when loading system classes. * This function is also used by the instrumentation agent. */ extern int canonicalize(char *path, const char *out, int len); JNIEXPORT int Canonicalize(JNIEnv *unused, char *orig, char *out, int len) { /* canonicalize an already natived path */ return canonicalize(orig, out, len); } Many thanks, Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From lance.andersen at oracle.com Tue Apr 10 10:18:43 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 10 Apr 2018 06:18:43 -0400 Subject: RFR 8201348, ProblemList update for bugid associated with SSLSocketParametersTest.sh In-Reply-To: References: Message-ID: <55AAF02F-E365-46E9-AEF9-EDA36F849C4C@oracle.com> +1 > On Apr 9, 2018, at 11:15 PM, Felix Yang wrote: > > Hi, > > please review a minor change on the associated bug id in ProblemList.txt. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8201348 > > Patch: > > diff -r f088ec60bed5 test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt Mon Apr 09 10:39:29 2018 -0700 > +++ b/test/jdk/ProblemList.txt Mon Apr 09 19:26:47 2018 -0700 > @@ -778,7 +778,7 @@ > > com/sun/jndi/ldap/LdapTimeoutTest.java 8151678 linux-all > > -javax/rmi/ssl/SSLSocketParametersTest.sh 8194663 generic-all > +javax/rmi/ssl/SSLSocketParametersTest.sh 8162906 generic-all > > ############################################################################ > > > Thanks, > > Felix > 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 shade at redhat.com Tue Apr 10 10:21:12 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 10 Apr 2018 12:21:12 +0200 Subject: RFR [10] 8194554: filterArguments runs multiple filters in the wrong order In-Reply-To: References: <27b68487-ef1e-bf09-11f3-6682923720db@redhat.com> Message-ID: <2052b4d5-0318-7ba5-79c3-e8f1c5afa0f1@redhat.com> On 04/10/2018 08:42 AM, Alan Bateman wrote: > On 09/04/2018 18:58, Paul Sandoz wrote: >> I am supportive of this change (the risk to impacting order-dependent stateful MH filter code is >> smaller than the risk of hitting a string concatenation bug). (We erred on the side of this being >> a bug and not being a spec change given the pseudo-code in the Java doc.) >> >> IIRC this will require a nod of approval from the project lead. >> >> Paul. > I think this is a CSR for Java SE 11 first as it adds a testable assertion to the spec and also > changes existing behavior. Ok, fine! Paul, can you submit the CSR for this? -Aleksey From Roger.Riggs at Oracle.com Tue Apr 10 15:38:14 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 10 Apr 2018 11:38:14 -0400 Subject: RFR of JDK-8188897: java/rmi/registry/reexport/Reexport.java failed with Port already in use In-Reply-To: References: <110f6c6e-61dc-89cf-aa97-cd989c8caabc@Oracle.com> <5AC43BAE.7070601@oracle.com> <7c67de0d-f043-2ed8-d825-c9820eaf4d6a@oracle.com> <0830767c-1502-54d1-5588-341731fd0aa3@Oracle.com> <27541c2d-ae81-192d-d436-8da036d85635@oracle.com> Message-ID: <5e4682f6-e36d-8efb-feae-6860b35c2f14@Oracle.com> Hi Hamlin, Looks good, Thanks for the updates. On 4/9/2018 10:49 PM, Hamlin Li wrote: > > On 10/04/2018 3:09 AM, Roger Riggs wrote: >> Hi Hamlin, > Hi Roger, > > Thank you for review. >> >> Great, the new busy port algorithm looks better. >> The port assigned will always be one that was available and is now >> busy to prevent the registry creation. >> >> As expected, there is a small window? between the (try-with-finally) >> close of the server socket channel >> and the 2nd createReg.? But that can't be avoided.? If the port is >> re-used in that gap >> the test will fail.? (And the exception handler at 77 will see an >> in-use and retry). > Yes, you're right. >> >> 67: The exception being caught is already one thrown by >> TestLibrary.bomb so it would be >> cleaner to just re-throw e;? or better yet, just don't bother to >> catch the exception. >> That exception should cause the test to fail. > It's to catch IOException by ServerSocketChannel.open, bind. Seems > it's a little confusing, so I declare at main function to throw > IOException. >> >> It may be personal coding style but the createReg method with a >> boolean flag to suppress >> the exception is just more confusing that putting the code in-line in >> the two places it is used. > I think it's mainly because of original parameter name remoteOK, so > rename it as expectException, and move it to the last parameter. > > new webrev is updated in place: > http://cr.openjdk.java.net/~mli/8188897/webrev.02/ > > Thank you > -Hamlin >> >> Thanks, Roger >> >> >> On 4/8/2018 4:10 AM, Hamlin Li wrote: >>> Hi Roger, >>> >>> I have changed to not use RegistryVM at all, please review the >>> patch: http://cr.openjdk.java.net/~mli/8188897/webrev.02/ >>> >>> Thank you >>> >>> -Hamlin >>> >>> >>> On 04/04/2018 10:15 PM, Roger Riggs wrote: >>>> Hi Hamlin, >>>> >>>> Reexport.java: >>>> >>>> I think this change to use a separate process for the 2nd registry >>>> changes the test so that it does not >>>> address the original test case.? The original problem was the >>>> incorrect retention of an object in >>>> the object table when the create of a registry in the same process >>>> failed. >>>> Finally being able to create the registry in the same process >>>> assured that the object was not >>>> retained in the object table. >>>> >>>> Go back to creating the 2nd registry in the test process. >>>> >>>> >>>> RegistryVM.java: 2, the copyright update should be? "2017, 2018," >>>> range. >>>> >>>> (I'm? really not a fan of all the RegistryVM methods with the same >>>> name and minimal and implicit >>>> differences in their functions.? When reading the test, you have to >>>> go and read the RegistryVM method >>>> to see what it does.? I would have preferred that the full >>>> createRegistryVM (out, err, options, port) method >>>> was used directly in the tests.? In the case of a method used once, >>>> it is an inconvenience method, not a convenience). >>>> >>>> The new terminate() method is quite similar to the existing >>>> cleanup() method which does not wait. >>>> It would be a good cleanup to figure out if another method is >>>> really needed. >>>> The override is going to change the behavior of the existing uses >>>> of terminate(). >>>> It should be checked that it does not break any existing uses. >>>> >>>> 178: 187: The method comments are not consistent, one says forcibly >>>> and the other gracefully >>>> but both call requestExit and both call destroy(). >>>> >>>> Thanks, Roger >>>> >>>> >>>> On 4/3/2018 11:35 PM, Hamlin Li wrote: >>>>> Hi Joe, Roger, >>>>> >>>>> Thank you for reviewing, I have refactored the test more and fix >>>>> as you suggested. >>>>> >>>>> please review http://cr.openjdk.java.net/~mli/8188897/webrev.01/ >>>>> >>>>> Thank you >>>>> >>>>> -Hamlin >>>>> >>>>> >>>>> On 04/04/2018 10:42 AM, Joseph D. Darcy wrote: >>>>>> Hello, >>>>>> >>>>>> Some general comments on the coding for tests like this: >>>>>> >>>>>> * It is preferable to avoid sleep in tests to avoid increasing >>>>>> the minimum amount of time a test takes to run. This helps limit >>>>>> the overall time it takes the test suite to run. >>>>>> >>>>>> * If timeouts are used, it is recommend to factor the maximum >>>>>> time waited with the jtreg timeout scaling factor; I don't recall >>>>>> its exact name. In other words, many of our tests are run on >>>>>> heavily loaded systems and the tests take longer than run than on >>>>>> typical laptops and workstations so jtreg is invoked with an >>>>>> timeout scaling factor. Individual tests should be sensitive to >>>>>> this scaling factor for any internal timeout that need to be used. >>>>>> >>>>>> HTH, >>>>>> >>>>>> -Joe >>>>>> >>>>>> On 4/3/2018 7:48 AM, Roger Riggs wrote: >>>>>>> Hi Hamlin, >>>>>>> >>>>>>> Instead of a simple time delay, it would be useful to wait for >>>>>>> the RegistryVM to terminate. >>>>>>> In killRegistry: 149,? adding subreg.waitFor() should be >>>>>>> sufficient. >>>>>>> >>>>>>> 58: If using a 'for' loop it would be easier to understand if it >>>>>>> included the usual start, increment and termination. >>>>>>> Instead of burying it in the exception handler. >>>>>>> >>>>>>> 59, 102, 104: the introduction of the kill boolean makes the >>>>>>> test harder to understand and seems to be unnecessary. >>>>>>> ?the killRegistry() method already will only kill the subprocess >>>>>>> if it still is alive. >>>>>>> >>>>>>> Roger >>>>>>> >>>>>>> On 4/2/2018 6:33 AM, Hamlin Li wrote: >>>>>>>> would you please review the following patch? >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8188897 >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~mli/8188897/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> Thank you >>>>>>>> >>>>>>>> -Hamlin >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From erik.joelsson at oracle.com Tue Apr 10 16:29:20 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 10 Apr 2018 09:29:20 -0700 Subject: [11] RFR: 8189784: Parsing with Java 9 AKST timezone returns the SystemV variant of the timezone In-Reply-To: References: <8f639e94-1564-17b2-d999-31f46c9a1a08@oracle.com> Message-ID: This looks very good. Thanks! (reviewed build part) /Erik On 2018-04-09 18:00, naoto.sato at oracle.com wrote: > Thanks, Erik. Modified GensrcCLDR.gmk as suggested: > > http://cr.openjdk.java.net/~naoto/8189784/webrev.03/ > > Naoto > > On 4/9/18 4:15 PM, Erik Joelsson wrote: >> Hello Naoto, >> >> Looks good, just a style issue. >> >> When breaking a recipe line, please add 4 additional spaces (after >> the tab) for continuation indent [1]. In this case I would also >> advocate breaking the line sooner to make side by side comparisons >> easier in the future. >> >> /Erik >> >> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html >> >> On 2018-04-09 13:20, Naoto Sato wrote: >>> Hello, >>> >>> Please review the changes to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8189784 >>> >>> The proposed changeset is located at: >>> >>> http://cr.openjdk.java.net/~naoto/8189784/webrev.02/ >>> >>> There were two causes of the issue. One was that j.t.f.ZoneName >>> contained hard coded mappings based on the old CLDR data and never >>> been updated. The other reason was that CLDR's deprecated zones >>> ("SystemV" ones, in this case) were not properly replaced. >>> >>> I am including build-dev for the review, as the change includes >>> generating ZoneName mapping at the build time from the template. >>> >>> Naoto >> From paul.sandoz at oracle.com Tue Apr 10 16:40:19 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 10 Apr 2018 09:40:19 -0700 Subject: RFR [10] 8194554: filterArguments runs multiple filters in the wrong order In-Reply-To: <2052b4d5-0318-7ba5-79c3-e8f1c5afa0f1@redhat.com> References: <27b68487-ef1e-bf09-11f3-6682923720db@redhat.com> <2052b4d5-0318-7ba5-79c3-e8f1c5afa0f1@redhat.com> Message-ID: <179EAD92-9A75-4682-9330-897624B994A4@oracle.com> > On Apr 10, 2018, at 3:21 AM, Aleksey Shipilev wrote: > > On 04/10/2018 08:42 AM, Alan Bateman wrote: >> On 09/04/2018 18:58, Paul Sandoz wrote: >>> I am supportive of this change (the risk to impacting order-dependent stateful MH filter code is >>> smaller than the risk of hitting a string concatenation bug). (We erred on the side of this being >>> a bug and not being a spec change given the pseudo-code in the Java doc.) >>> >>> IIRC this will require a nod of approval from the project lead. >>> >>> Paul. >> I think this is a CSR for Java SE 11 first as it adds a testable assertion to the spec and also >> changes existing behavior. > Note that the testable assertion was already in the spec, just buried in the normative pseudocode. So this is really about clarification from the spec perspective. And of course any bug fix can change behavior. In hindsight i would be more inclined to do a CSR if a bug fix is required to conform to specification. > Ok, fine! Paul, can you submit the CSR for this? > Here we go: https://bugs.openjdk.java.net/browse/JDK-8201371 Kindly requesting a reviewer. Thanks, Paul. From shade at redhat.com Tue Apr 10 17:08:40 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 10 Apr 2018 19:08:40 +0200 Subject: RFR [10] 8194554: filterArguments runs multiple filters in the wrong order In-Reply-To: <179EAD92-9A75-4682-9330-897624B994A4@oracle.com> References: <27b68487-ef1e-bf09-11f3-6682923720db@redhat.com> <2052b4d5-0318-7ba5-79c3-e8f1c5afa0f1@redhat.com> <179EAD92-9A75-4682-9330-897624B994A4@oracle.com> Message-ID: <433f9831-cd33-2867-af4c-fdb1d9e0d633@redhat.com> On 04/10/2018 06:40 PM, Paul Sandoz wrote: > Here we go: > > ??https://bugs.openjdk.java.net/browse/JDK-8201371 > > Kindly requesting a reviewer. Not sure if that counts for CSR, but added myself as Reviewer there. -Aleksey From andrey.x.nazarov at oracle.com Tue Apr 10 18:44:27 2018 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Tue, 10 Apr 2018 11:44:27 -0700 Subject: RFR: 8178867: tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java failed to clean up files In-Reply-To: <59A267A5-804D-457B-A7EB-2750E02EF057@oracle.com> References: <59A267A5-804D-457B-A7EB-2750E02EF057@oracle.com> Message-ID: Anyone? > On 6 Apr 2018, at 17:10, Andrey Nazarov wrote: > > Hi, > > Please review fix in Jlink test. The fix is to close the Stream which works with a file system. > > Review: http://cr.openjdk.java.net/~anazarov/JDK-8178867/webrev.01 > JBS: https://bugs.openjdk.java.net/browse/JDK-8178867 > > ?Thanks, > Andrei From Alan.Bateman at oracle.com Tue Apr 10 18:47:52 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Apr 2018 19:47:52 +0100 Subject: RFR: 8178867: tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java failed to clean up files In-Reply-To: References: <59A267A5-804D-457B-A7EB-2750E02EF057@oracle.com> Message-ID: <9bba47d4-b704-012a-df15-54b43b2f11e8@oracle.com> On 10/04/2018 19:44, Andrey Nazarov wrote: > Anyone? > >> On 6 Apr 2018, at 17:10, Andrey Nazarov wrote: >> >> Hi, >> >> Please review fix in Jlink test. The fix is to close the Stream which works with a file system. >> >> Review: http://cr.openjdk.java.net/~anazarov/JDK-8178867/webrev.01 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8178867 >> If you want, you can get rid of temporary javaFiles list and use .forEach(args::add) instead. -Alan From jonathan.gibbons at oracle.com Tue Apr 10 18:48:18 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 10 Apr 2018 11:48:18 -0700 Subject: RFR: 8178867: tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java failed to clean up files In-Reply-To: References: <59A267A5-804D-457B-A7EB-2750E02EF057@oracle.com> Message-ID: <07e4a4dc-43d4-f6ee-09ba-1d0850911881@oracle.com> +1 On 4/10/18 11:44 AM, Andrey Nazarov wrote: > Anyone? > >> On 6 Apr 2018, at 17:10, Andrey Nazarov wrote: >> >> Hi, >> >> Please review fix in Jlink test. The fix is to close the Stream which works with a file system. >> >> Review: http://cr.openjdk.java.net/~anazarov/JDK-8178867/webrev.01 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8178867 >> >> ?Thanks, >> Andrei From andrey.x.nazarov at oracle.com Tue Apr 10 19:03:02 2018 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Tue, 10 Apr 2018 12:03:02 -0700 Subject: RFR: 8178867: tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java failed to clean up files In-Reply-To: <9bba47d4-b704-012a-df15-54b43b2f11e8@oracle.com> References: <59A267A5-804D-457B-A7EB-2750E02EF057@oracle.com> <9bba47d4-b704-012a-df15-54b43b2f11e8@oracle.com> Message-ID: <059D315A-5C90-4D0A-BA42-384C099806F8@oracle.com> > On 10 Apr 2018, at 11:47, Alan Bateman wrote: > > On 10/04/2018 19:44, Andrey Nazarov wrote: >> Anyone? >> >>> On 6 Apr 2018, at 17:10, Andrey Nazarov wrote: >>> >>> Hi, >>> >>> Please review fix in Jlink test. The fix is to close the Stream which works with a file system. >>> >>> Review: http://cr.openjdk.java.net/~anazarov/JDK-8178867/webrev.01 >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8178867 >>> > If you want, you can get rid of temporary javaFiles list and use .forEach(args::add) instead. Yes. It looks cleaner. http://cr.openjdk.java.net/~anazarov/JDK-8178867/webrev.03 > > -Alan From paul.sandoz at oracle.com Tue Apr 10 19:05:57 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 10 Apr 2018 12:05:57 -0700 Subject: RFR: 8178867: tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java failed to clean up files In-Reply-To: <9bba47d4-b704-012a-df15-54b43b2f11e8@oracle.com> References: <59A267A5-804D-457B-A7EB-2750E02EF057@oracle.com> <9bba47d4-b704-012a-df15-54b43b2f11e8@oracle.com> Message-ID: > On Apr 10, 2018, at 11:47 AM, Alan Bateman wrote: > > On 10/04/2018 19:44, Andrey Nazarov wrote: >> Anyone? >> >>> On 6 Apr 2018, at 17:10, Andrey Nazarov wrote: >>> >>> Hi, >>> >>> Please review fix in Jlink test. The fix is to close the Stream which works with a file system. >>> >>> Review: http://cr.openjdk.java.net/~anazarov/JDK-8178867/webrev.01 >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8178867 >>> > If you want, you can get rid of temporary javaFiles list and use .forEach(args::add) instead. > Yes. Not suggesting you do this, just for educational purposes you can also do this (not tested) e.g.: var argStream = Stream.of("-d", destination.toString(), "--module-source-path", srcpath); try (var pathStream = Files.walk(source)) { argStream = Stream.concat(argStream, pathStream.map(Path::toString).filter(s -> s.endsWith(".java"))); int rc = JAVAC_TOOL.run(System.out, System.err, argStream.toArray(String[]::new)); Assert.assertEquals(rc, 0); } Paul. From Alan.Bateman at oracle.com Tue Apr 10 19:25:10 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Apr 2018 20:25:10 +0100 Subject: RFR: 8178867: tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java failed to clean up files In-Reply-To: <059D315A-5C90-4D0A-BA42-384C099806F8@oracle.com> References: <59A267A5-804D-457B-A7EB-2750E02EF057@oracle.com> <9bba47d4-b704-012a-df15-54b43b2f11e8@oracle.com> <059D315A-5C90-4D0A-BA42-384C099806F8@oracle.com> Message-ID: On 10/04/2018 20:03, Andrey Nazarov wrote: > >> On 10 Apr 2018, at 11:47, Alan Bateman wrote: >> >> On 10/04/2018 19:44, Andrey Nazarov wrote: >>> Anyone? >>> >>>> On 6 Apr 2018, at 17:10, Andrey Nazarov wrote: >>>> >>>> Hi, >>>> >>>> Please review fix in Jlink test. The fix is to close the Stream which works with a file system. >>>> >>>> Review: http://cr.openjdk.java.net/~anazarov/JDK-8178867/webrev.01 >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8178867 >>>> >> If you want, you can get rid of temporary javaFiles list and use .forEach(args::add) instead. > Yes. It looks cleaner. http://cr.openjdk.java.net/~anazarov/JDK-8178867/webrev.03 I agree with Paul that it would be nice to replace new ArrayList<>(List.of("-d", ... )) too but what you have is okay. -Alan From brian.goetz at oracle.com Tue Apr 10 20:50:30 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 10 Apr 2018 16:50:30 -0400 Subject: stripIndent() behavior In-Reply-To: References: Message-ID: > (now stripIndent) > > I've accumulated a few questions/comments on this. > > 1. When choosing the amount to trim, it ought to ignore blank lines and > only-whitespace lines, right? Seems right. > 2. Is it really appropriate to automatically remove trailing whitespace? I'm not sure about this either.? The reason that RSLs will have "extra" whitespace that needs to be stripped is that we want to indent the RSL snippet relative to the Java code (and as you point out, the IDE may do that automatically for us.)? But if there's trailing whitespace, its because the user put it there, and who is it hurting?? It might be significant. > 3. If the input contains *any* tab characters at all (except any that are > part of the trailing whitespace), then this method cannot know that it > isn't jumbling the end result, and maybe it should just throw. I think there's a middle ground, where it strips any common whitespace prefix.? So if every line starts with tab-tab-space-space, it can safely strip this. > 5. If we do end up in a world where we have to call this for almost every > one of our tens of thousands of multi-line RSLs... is it strange that I > feel like I would prefer it was static? It seems like it would look a lot > more normal that way visually. Ugh... I think this is likely to vary subjectively a lot.? Some people like that the instance method is mostly out of the way; others like the up-front shouting of the static method. The reason we can't have both is then we can't resolve the method reference String::strip as a Function, which seems a useful thing to do. > On top of *that*, I have no idea what "right markers" are good for, nor > what customizing the marker choice is good for (other than creating more > needless variation between different pieces of code). > String asciiArtFTW = ````````` ??? `? BOO? ` ??? `````````.trimMarkers("`", "`"); From kevinb at google.com Tue Apr 10 21:18:57 2018 From: kevinb at google.com (Kevin Bourrillion) Date: Tue, 10 Apr 2018 14:18:57 -0700 Subject: stripIndent() behavior In-Reply-To: References: Message-ID: On Tue, Apr 10, 2018 at 1:50 PM, Brian Goetz wrote: > > > 3. If the input contains *any* tab characters at all (except any that are >> part of the trailing whitespace), then this method cannot know that it >> isn't jumbling the end result, and maybe it should just throw. >> > I think there's a middle ground, where it strips any common whitespace > prefix. So if every line starts with tab-tab-space-space, it can safely > strip this. My point is that this is *not* safe, if by "safe" we mean "you will see the same relative indentation you saw in the source". *Any* tab has the potential to suddenly be worth a different number of spaces, once some prefix of any kind has been removed. I would *like* to not worry about this, but we have to accept that the programmers who will be hurt most will be the most novice. 5. If we do end up in a world where we have to call this for almost every >> one of our tens of thousands of multi-line RSLs... is it strange that I >> feel like I would prefer it was static? It seems like it would look a lot >> more normal that way visually. Ugh... >> > I think this is likely to vary subjectively a lot. Some people like that > the instance method is mostly out of the way; others like the up-front > shouting of the static method. > Is it just potayto, potahto, or does one of the snippets above appear a lot more consistent with how Java code has always looked? On top of *that*, I have no idea what "right markers" are good for, nor >> what customizing the marker choice is good for (other than creating more >> needless variation between different pieces of code). >> >> > String asciiArtFTW = > ````````` > ` BOO ` > `````````.trimMarkers("`", "`"); > > Ha, well, I did say "good" for :-) -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com From emcmanus at google.com Tue Apr 10 21:48:07 2018 From: emcmanus at google.com (=?UTF-8?Q?=C3=89amonn_McManus?=) Date: Tue, 10 Apr 2018 21:48:07 +0000 Subject: stripIndent() behavior In-Reply-To: References: Message-ID: > > 3. If the input contains *any* tab characters at all (except any that are > > part of the trailing whitespace), then this method cannot know that it > > isn't jumbling the end result, and maybe it should just throw. > I think there's a middle ground, where it strips any common whitespace > prefix. So if every line starts with tab-tab-space-space, it can safely > strip this. I'm afraid that's not true. In practice if you are using tabs at all it is very easy in many editors to end up with a mix of spaces and tabs. So you could easy have (with 8-space tabs) one line that has 3 tabs at the start, and another that has 2 tabs and 8 spaces. For example with Emacs you can get this just by hitting delete after a tab and then hitting space. You would nevertheless want stripIndent to remove the indentation from both lines, since they look identical. The situation is made worse by the fact that there are two common conventions for tab width, 4 or 8. I think the only way to avoid these problems is for stripIndent to throw if its argument has any tabs, or at least any tabs in leading whitespace, and provide a separate method `detab` whose argument says what the width of a tab stop is. (Just to be sure: this method should arrange for tab stops to be at positions 4N or 8N, where the first column is column 0. So a tab can expand into 1 to 4 spaces, or 1 to 8 spaces.) Then users operating in tab-free codebases can just write .stripIndent(), and users in tab-infected codebases can write .detab(4).stripIndent(). The alternative is to expose novice users to many hours of exasperation. Tabs are generally invisible, so you can imagine someone trying to figure out why two lines that look exactly the same ended up treated differently. Users may not even know there is such a thing as a tab character. (If stripIndent throws, it should have a helpful message that suggests calling detab(N) and that the value of n should probably be 4 or 8.) > String asciiArtFTW = > ````````` > ` BOO ` > `````````.trimMarkers("`", "`"); I'm not sure I get that. It doesn't correspond to anything I've ever wanted to do, even in languages that already have multiline strings. At least, could we have an overload that just takes the starting marker, for the overwhelmingly commoner case where you only want to strip at the start? -- ?amonn On Tue, 10 Apr 2018 at 13:50, Brian Goetz wrote: > > (now stripIndent) > > > > I've accumulated a few questions/comments on this. > > > > 1. When choosing the amount to trim, it ought to ignore blank lines and > > only-whitespace lines, right? > Seems right. > > 2. Is it really appropriate to automatically remove trailing whitespace? > I'm not sure about this either. The reason that RSLs will have "extra" > whitespace that needs to be stripped is that we want to indent the RSL > snippet relative to the Java code (and as you point out, the IDE may do > that automatically for us.) But if there's trailing whitespace, its > because the user put it there, and who is it hurting? It might be > significant. > > 3. If the input contains *any* tab characters at all (except any that are > > part of the trailing whitespace), then this method cannot know that it > > isn't jumbling the end result, and maybe it should just throw. > I think there's a middle ground, where it strips any common whitespace > prefix. So if every line starts with tab-tab-space-space, it can safely > strip this. > > 5. If we do end up in a world where we have to call this for almost every > > one of our tens of thousands of multi-line RSLs... is it strange that I > > feel like I would prefer it was static? It seems like it would look a lot > > more normal that way visually. Ugh... > I think this is likely to vary subjectively a lot. Some people like > that the instance method is mostly out of the way; others like the > up-front shouting of the static method. > The reason we can't have both is then we can't resolve the method > reference String::strip as a Function, which seems a > useful thing to do. > > On top of *that*, I have no idea what "right markers" are good for, nor > > what customizing the marker choice is good for (other than creating more > > needless variation between different pieces of code). > > > String asciiArtFTW = > ````````` > ` BOO ` > `````````.trimMarkers("`", "`"); From brian.goetz at oracle.com Tue Apr 10 22:21:02 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 10 Apr 2018 18:21:02 -0400 Subject: stripIndent() behavior In-Reply-To: References: Message-ID: On 4/10/2018 5:18 PM, Kevin Bourrillion wrote: > > On Tue, Apr 10, 2018 at 1:50 PM, Brian Goetz > wrote: > > > 3. If the input contains *any* tab characters at all (except > any that are > part of the trailing whitespace), then this method cannot know > that it > isn't jumbling the end result, and maybe it should just throw. > > I think there's a middle ground, where it strips any common > whitespace prefix.? So if every line starts with > tab-tab-space-space, it can safely strip this. > > > My point is that this is /not/?safe, if by "safe" we mean "you will > see the same relative indentation you saw in the source". /Any/?tab > has the potential to suddenly be worth a different number of spaces, > once some prefix of any kind has been removed. That's not what I mean by safe.? I mean that one could have reasonably predicted what string was going to result.? Developers who use randomly mixed spaces and tabs do not deserve to see the same relative indentation. While I personally dislike tabs, I accept that some people like them, and if used responsibly and consistently, we can all get along.? But using them inconsistently across lines of a multiple-line expression, or using them after leading spaces, are not high on my list of situations we should cater to. > > > 5. If we do end up in a world where we have to call this for > almost every > one of our tens of thousands of multi-line RSLs... is it > strange that I > feel like I would prefer it was static? It seems like it would > look a lot > more normal that way visually. Ugh... > > I think this is likely to vary subjectively a lot.? Some people > like that the instance method is mostly out of the way; others > like the up-front shouting of the static method. > > > Is it just potayto, potahto, or does one of the snippets above appear > a lot more consistent with how Java code has always looked? I think its pota{y,h}to as to which is more likely to trigger indignation at the compiler for having forced them to muck up their code.? And, a certain degree of fashion; chaining is "in" these days. From brian.goetz at oracle.com Tue Apr 10 22:27:38 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 10 Apr 2018 18:27:38 -0400 Subject: stripIndent() behavior In-Reply-To: References: Message-ID: <2f91d5f3-18ff-fe8d-d827-3537798c7d06@oracle.com> I think this is "throwing" the baby out with the bathwater.? It is punishing those who can use tabs responsibly for the sins of those who cannot. You have to commit three sins before you have a problem: ?- using tabs at all ?- using tabs inconsistently across the lines of a single expression; ?- using tabs after you've already used spaces on a line. While I am sure that there are people who do so, it just seems unreasonable to me to throw in the presence of tabs because someone, somewhere, might commit these three sins together and *be confused by the result*.? (So, no, it's not the only option.) Note that IDEs can also highlight code that would be inappropriately mangled as a result, so people learn not to commit all three of the sins listed. On 4/10/2018 5:39 PM, ?amonn McManus wrote: >>> 3. If the input contains *any* tab characters at all (except any that > are >>> part of the trailing whitespace), then this method cannot know that it >>> isn't jumbling the end result, and maybe it should just throw. >> I think there's a middle ground, where it strips any common whitespace >> prefix. So if every line starts with tab-tab-space-space, it can safely >> strip this. > I'm afraid that's not true. In practice if you are using tabs at all it is > very easy in many editors to end up with a mix of spaces and tabs. So you > could easy have (with 8-space tabs) one line that has 3 tabs at the start, > and another that has 2 tabs and 8 spaces. For example with Emacs you can > get this just by hitting delete after a tab and then hitting space. You > would nevertheless want stripIndent to remove the indentation from both > lines, since they look identical. > > The situation is made worse by the fact that there are two common > conventions for tab width, 4 or 8. > > I think the only way to avoid these problems is for stripIndent to throw if > its argument has any tabs, or at least any tabs in leading whitespace, and > provide a separate method `detab` whose argument says what the width of a > tab stop is. (Just to be sure: this method should arrange for tab stops to > be at positions 4N or 8N, where the first column is column 0. So a tab can > expand into 1 to 4 spaces, or 1 to 8 spaces.) > > Then users operating in tab-free codebases can just write .stripIndent(), > and users in tab-infected codebases can write .detab(4).stripIndent(). > > The alternative is to expose novice users to many hours of exasperation. > Tabs are generally invisible, so you can imagine someone trying to figure > out why two lines that look exactly the same ended up treated differently. > Users may not even know there is such a thing as a tab character. (If > stripIndent throws, it should have a helpful message that suggests calling > detab(N) and that the value of n should probably be 4 or 8.) > >> String asciiArtFTW = >> ````````` >> ` BOO ` >> `````````.trimMarkers("`", "`"); > I'm not sure I get that. It doesn't correspond to anything I've ever wanted > to do, even in languages that already have multiline strings. At least, > could we have an overload that just takes the starting marker, for the > overwhelmingly commoner case where you only want to strip at the start? > > On Tue, 10 Apr 2018 at 13:50, Brian Goetz wrote: > > > >>> (now stripIndent) >>> >>> I've accumulated a few questions/comments on this. >>> >>> 1. When choosing the amount to trim, it ought to ignore blank lines and >>> only-whitespace lines, right? >> Seems right. >>> 2. Is it really appropriate to automatically remove trailing whitespace? >> I'm not sure about this either. The reason that RSLs will have "extra" >> whitespace that needs to be stripped is that we want to indent the RSL >> snippet relative to the Java code (and as you point out, the IDE may do >> that automatically for us.) But if there's trailing whitespace, its >> because the user put it there, and who is it hurting? It might be >> significant. >>> 3. If the input contains *any* tab characters at all (except any that > are >>> part of the trailing whitespace), then this method cannot know that it >>> isn't jumbling the end result, and maybe it should just throw. >> I think there's a middle ground, where it strips any common whitespace >> prefix. So if every line starts with tab-tab-space-space, it can safely >> strip this. >>> 5. If we do end up in a world where we have to call this for almost > every >>> one of our tens of thousands of multi-line RSLs... is it strange that I >>> feel like I would prefer it was static? It seems like it would look a > lot >>> more normal that way visually. Ugh... >> I think this is likely to vary subjectively a lot. Some people like >> that the instance method is mostly out of the way; others like the >> up-front shouting of the static method. >> The reason we can't have both is then we can't resolve the method >> reference String::strip as a Function, which seems a >> useful thing to do. >>> On top of *that*, I have no idea what "right markers" are good for, nor >>> what customizing the marker choice is good for (other than creating more >>> needless variation between different pieces of code). >>> >> String asciiArtFTW = >> ````````` >> ` BOO ` >> `````````.trimMarkers("`", "`"); From kevinb at google.com Wed Apr 11 00:07:41 2018 From: kevinb at google.com (Kevin Bourrillion) Date: Tue, 10 Apr 2018 17:07:41 -0700 Subject: stripIndent() behavior In-Reply-To: <2f91d5f3-18ff-fe8d-d827-3537798c7d06@oracle.com> References: <2f91d5f3-18ff-fe8d-d827-3537798c7d06@oracle.com> Message-ID: I've also been trying to sort out just how much we should really weight this risk. We can make a best-effort for the mixed-tabs case by making sure stripIndent() only removes an absolutely *identical* prefix from each line. After that, yes, they may still get a misaligned result at runtime (note that that could happen *anyway* just by having a different tab stop in that environment vs. the editor), and that's not good, but actually throwing to force them to clean up their whitespace seems a magnitude too severe. On Tue, Apr 10, 2018 at 3:27 PM, Brian Goetz wrote: > I think this is "throwing" the baby out with the bathwater. It is > punishing those who can use tabs responsibly for the sins of those who > cannot. > > You have to commit three sins before you have a problem: > - using tabs at all > - using tabs inconsistently across the lines of a single expression; > - using tabs after you've already used spaces on a line. > > While I am sure that there are people who do so, it just seems > unreasonable to me to throw in the presence of tabs because someone, > somewhere, might commit these three sins together and *be confused by the > result*. (So, no, it's not the only option.) > > Note that IDEs can also highlight code that would be inappropriately > mangled as a result, so people learn not to commit all three of the sins > listed. > > > On 4/10/2018 5:39 PM, ?amonn McManus wrote: > >> 3. If the input contains *any* tab characters at all (except any that >>>> >>> are >> >>> part of the trailing whitespace), then this method cannot know that it >>>> isn't jumbling the end result, and maybe it should just throw. >>>> >>> I think there's a middle ground, where it strips any common whitespace >>> prefix. So if every line starts with tab-tab-space-space, it can safely >>> strip this. >>> >> I'm afraid that's not true. In practice if you are using tabs at all it is >> very easy in many editors to end up with a mix of spaces and tabs. So you >> could easy have (with 8-space tabs) one line that has 3 tabs at the start, >> and another that has 2 tabs and 8 spaces. For example with Emacs you can >> get this just by hitting delete after a tab and then hitting space. You >> would nevertheless want stripIndent to remove the indentation from both >> lines, since they look identical. >> >> The situation is made worse by the fact that there are two common >> conventions for tab width, 4 or 8. >> >> I think the only way to avoid these problems is for stripIndent to throw >> if >> its argument has any tabs, or at least any tabs in leading whitespace, and >> provide a separate method `detab` whose argument says what the width of a >> tab stop is. (Just to be sure: this method should arrange for tab stops to >> be at positions 4N or 8N, where the first column is column 0. So a tab can >> expand into 1 to 4 spaces, or 1 to 8 spaces.) >> >> Then users operating in tab-free codebases can just write .stripIndent(), >> and users in tab-infected codebases can write .detab(4).stripIndent(). >> >> The alternative is to expose novice users to many hours of exasperation. >> Tabs are generally invisible, so you can imagine someone trying to figure >> out why two lines that look exactly the same ended up treated differently. >> Users may not even know there is such a thing as a tab character. (If >> stripIndent throws, it should have a helpful message that suggests calling >> detab(N) and that the value of n should probably be 4 or 8.) >> >> String asciiArtFTW = >>> ````````` >>> ` BOO ` >>> `````````.trimMarkers("`", "`"); >>> >> I'm not sure I get that. It doesn't correspond to anything I've ever >> wanted >> to do, even in languages that already have multiline strings. At least, >> could we have an overload that just takes the starting marker, for the >> overwhelmingly commoner case where you only want to strip at the start? >> >> On Tue, 10 Apr 2018 at 13:50, Brian Goetz wrote: >> >> >> >> (now stripIndent) >>>> >>>> I've accumulated a few questions/comments on this. >>>> >>>> 1. When choosing the amount to trim, it ought to ignore blank lines and >>>> only-whitespace lines, right? >>>> >>> Seems right. >>> >>>> 2. Is it really appropriate to automatically remove trailing whitespace? >>>> >>> I'm not sure about this either. The reason that RSLs will have "extra" >>> whitespace that needs to be stripped is that we want to indent the RSL >>> snippet relative to the Java code (and as you point out, the IDE may do >>> that automatically for us.) But if there's trailing whitespace, its >>> because the user put it there, and who is it hurting? It might be >>> significant. >>> >>>> 3. If the input contains *any* tab characters at all (except any that >>>> >>> are >> >>> part of the trailing whitespace), then this method cannot know that it >>>> isn't jumbling the end result, and maybe it should just throw. >>>> >>> I think there's a middle ground, where it strips any common whitespace >>> prefix. So if every line starts with tab-tab-space-space, it can safely >>> strip this. >>> >>>> 5. If we do end up in a world where we have to call this for almost >>>> >>> every >> >>> one of our tens of thousands of multi-line RSLs... is it strange that I >>>> feel like I would prefer it was static? It seems like it would look a >>>> >>> lot >> >>> more normal that way visually. Ugh... >>>> >>> I think this is likely to vary subjectively a lot. Some people like >>> that the instance method is mostly out of the way; others like the >>> up-front shouting of the static method. >>> The reason we can't have both is then we can't resolve the method >>> reference String::strip as a Function, which seems a >>> useful thing to do. >>> >>>> On top of *that*, I have no idea what "right markers" are good for, nor >>>> what customizing the marker choice is good for (other than creating more >>>> needless variation between different pieces of code). >>>> >>>> String asciiArtFTW = >>> ````````` >>> ` BOO ` >>> `````````.trimMarkers("`", "`"); >>> >> > -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com From xueming.shen at oracle.com Wed Apr 11 03:49:01 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 10 Apr 2018 20:49:01 -0700 Subject: [JDK-6341887] RFR: Patch V3: java.util.zip: Add ByteBuffer methods to Inflater/Deflater In-Reply-To: References: <5AB53E95.9080308@oracle.com> <10728b43-110c-5dc3-1fdb-2e0241e3a0ff@oracle.com> <5ABC6DCF.10504@oracle.com> <6a2c6a54-9174-5815-80c1-35029931e0f2@oracle.com> <5ABE6B4A.1010701@oracle.com> <5ABE6E64.1060806@oracle.com> Message-ID: <5ACD85AD.4010009@oracle.com> Hi David, The CSR has been approved https://bugs.openjdk.java.net/browse/JDK-8200527 API docs have been updated slightly based on the review suggestion. (1) added some words in the class spec for both Inflater and Deflater. |*

* This class deflates sequences of bytes into ZLIB compressed data format. * The input byte sequence is provided in either byte array or byte buffer, * via one of the {@code setInput()} methods. The output byte sequence is * written to the output byte array or byte buffer passed to the * {@code deflate()} methods. *

| |*

* This class inflates sequences of ZLIB compressed bytes. The input byte * sequence is provided in either byte array or byte buffer, via one of the * {@code setInput()} methods. The output byte sequence is written to the * output byte array or byte buffer passed to the {@code deflate()} methods. *

| (2) adjusted the workding a little for those setInput() methods | *

* One of the {@code setInput()} methods should be called whenever * {@code needsInput()} returns true indicating that more input data * is required. *

| Two issues have been noticed when running tier1/2/3 tests (1) there is a error at ln#Inflater.c#243, the "input" is being released instead of "output" http://cr.openjdk.java.net/~sherman/6341887.David.Lloyd/webrev.00/src/java.base/share/native/libzip/Inflater.c.sdiff.html which triggered crash for some tests. fixed. (2) sun/nio/ch/TestMaxCachedBufferSize.java failed "because of" the "defaultBuf" uses direct ByteBuffer. This is probably the issue of the test but I simply update the "defaultBuf" to be the heap buffer/0, instead of touch the failed test case. I don't have problem if you prefer to "fix" the test and keep the "defaultBuf" as direct buffer instead. // static final ByteBuffer defaultBuf = ByteBuffer.allocateDirect(0); static final ByteBuffer defaultBuf = ByteBuffer.allocate(0); (3) I also updated test/jdk/java/util/zip/DeInflate.java with more tests for the new APIs. More tests might be desired though. The latest webrev is at http://cr.openjdk.java.net/~sherman/6341887.David.Lloyd/webrev/ Thanks, Sherman From xu.y.yin at oracle.com Wed Apr 11 06:33:35 2018 From: xu.y.yin at oracle.com (Chris Yin) Date: Wed, 11 Apr 2018 14:33:35 +0800 Subject: RFR 8197418: Move java/util/RandomAccess/ tests into OpenJDK Message-ID: <19AD7051-2394-4BD6-AA86-53FE1CDCCED9@oracle.com> Please review the change to move java/util/RandomAccess/Basic.java test into OpenJDK, it increases code coverage of open jdk_util test group per JCov run, the main improvement is on java.util.Collections with %method up 1% and %block up 2%, thanks bug: https://bugs.openjdk.java.net/browse/JDK-8197418 webrev: http://cr.openjdk.java.net/~xyin/8197418/webrev.00/ Regards, Chris From alexey.ivanov at oracle.com Wed Apr 11 10:01:38 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 11 Apr 2018 11:01:38 +0100 Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations In-Reply-To: <34917a6d-6610-120d-2e8f-b7c54678377b@oracle.com> References: <9bae15f406ed4e029233415e6a8032b8@sap.com> <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com> <35e12d6d6eb24d88aadaf10e0229dd48@sap.com> <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com> <5146b9330edd44b483780587aca1757c@sap.com> <99420e261ef347578bb8099a48d6b7ec@sap.com> <5693830fbf6747d9a51e9cf374f63e18@sap.com> <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com> <3520f157a7d14a118a584fdeb226381e@sap.com> <34917a6d-6610-120d-2e8f-b7c54678377b@oracle.com> Message-ID: <84e8c6ec-727b-33c4-f842-d2da18ef99b8@oracle.com> I guess we also need to get an approval from core-libs (cc'd) as libzip and libjimage are modified. Regards, Alexey On 11/04/2018 10:56, Alexey Ivanov wrote: > The change looks good to me. > > On 11/04/2018 10:20, Baesken, Matthias wrote: >>> Was main() exported via map files? >> Seems main was exported , I can find it in jdk10? in? e.g.? : >> >> make/mapfiles/launchers/mapfile-sparcv9 >> make/mapfiles/launchers/mapfile-x86_64 > > Thank you for confirming it. > Then JNIEXPORT is better left untouched to keep main() exported. > > > Regards, > Alexey > >> Best regards, Matthias >> >> >>> -----Original Message----- >>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >>> Sent: Mittwoch, 11. April 2018 11:11 >>> To: Baesken, Matthias ; Magnus Ihse Bursie >>> >>> Cc: build-dev ; Doerr, Martin >>> >>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>> function >>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at >>> some places in function declarations/implementations >>> >>> >>> On 11/04/2018 08:44, Baesken, Matthias wrote: >>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it? >>>> Hi? Alexey, yes that's true . >>>> >>>>> Please remove JNIEXPORT from main(): >>>>> src/java.base/share/native/launcher/main.c >>>>> src/jdk.pack/share/native/unpack200/main.cpp >>>> I would? prefer to keep it for now . >>>> I notice? some? comments? in our SAPJVM code base? about needing >>> JNIEXPORT for? main? for Solaris? (we were running? in SAPJVM without >>> mapfiles in the past already). >>>> Maybe? that?s related to >>>> >>>> src/java.base/unix/native/libjli/java_md_solinux.c >>>> >>>> where main? is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT, >>>> "main"); >>>> but I am not sure about this. >>>> So I better keep? the JNIEXPORT? for the main functions, could be >>> removed in another? cleanup? if really needed. >>> >>> OK. Let them stay then. >>> Was main() exported via map files? >>> >>> >>> The change looks good to me. >>> >>> Regards, >>> Alexey >>> >>>>> You can reference both yourself and me as >>>>> Contributed-by: mbaesken, aivanov >>>>> when pushing the changeset if you don't mind. >>>>> >>>> Sure . >>>> >>>> Best regards, Matthias >>>> >>>> >>>>> -----Original Message----- >>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >>>>> Sent: Dienstag, 10. April 2018 21:34 >>>>> To: Baesken, Matthias ; Magnus Ihse >>> Bursie >>>>> >>>>> Cc: build-dev ; Doerr, Martin >>>>> >>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>> function >>>>> declarations/implementations - was : RE: missing JNIEXPORT / >>>>> JNICALL at >>>>> some places in function declarations/implementations >>>>> >>>>> Hi Matthias, >>>>> >>>>> On 10/04/2018 11:14, Baesken, Matthias wrote: >>>>>> Hello,? I? had to? do another small adjustment to make >>>>>> jimage.hpp/cpp >>> match. Please review : >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ >>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it? >>>>> >>>>> I've successfully built 32 bit Windows with your patch. >>>>> >>>>> >>>>> Please remove JNIEXPORT from main(): >>>>> src/java.base/share/native/launcher/main.c >>>>> src/jdk.pack/share/native/unpack200/main.cpp >>>>> >>>>>> With the latest webrev I could finally build jdk/jdk successfully >>>>>> on both >>> win32bit and win64 bit. >>>>>> Thanks again? to Alexey? to provide? the?? incorporated patch . >>>>> You can reference both yourself and me as >>>>> Contributed-by: mbaesken, aivanov >>>>> when pushing the changeset if you don't mind. >>>>> >>>>> >>>>> Regards, >>>>> Alexey >>>>> >>>>>> Best regards, Matthias >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >>>>>>> Sent: Montag, 9. April 2018 17:14 >>>>>>> To: Baesken, Matthias ; Magnus Ihse >>>>> Bursie >>>>>>> >>>>>>> Cc: build-dev ; Doerr, Martin >>>>>>> >>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>>>> function >>>>>>> declarations/implementations - was : RE: missing JNIEXPORT / >>>>>>> JNICALL >>> at >>>>>>> some places in function declarations/implementations >>>>>>> >>>>>>> Hi Matthias, >>>>>>> >>>>>>> On 09/04/2018 15:38, Baesken, Matthias wrote: >>>>>>>> Hi? Alexey,??? thanks? for the diff provided by you, and? for? the >>>>> explanations >>>>>>> . >>>>>>>> I created? a second? webrev : >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/ >>>>>>>> >>>>>>>> -?? it? adds? the diff? provided by you??? (hope that?s fine >>>>>>>> with you) >>>>>>> Yes, that's fine with me. >>>>>>> There could be only one author ;) >>>>>>> >>>>>>>> -??? changes? 2 launchers >>>>>>>> src/java.base/share/native/launcher/main.c >>>>> and >>>>>>> src/jdk.pack/share/native/unpack200/main.cpp where we face >>> similar >>>>>>> issues after mapfile removal for exes >>>>>>> >>>>>>> I'd rather remove both JNIEXPORT and JNICALL from main(). >>>>>>> It wasn't exported, and it shouldn't be. >>>>>>> >>>>>>> Regards, >>>>>>> Alexey >>>>>>> >>>>>>>> Best regards , Matthias > From david.lloyd at redhat.com Wed Apr 11 14:13:40 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 11 Apr 2018 09:13:40 -0500 Subject: [JDK-6341887] RFR: Patch V3: java.util.zip: Add ByteBuffer methods to Inflater/Deflater In-Reply-To: <5ACD85AD.4010009@oracle.com> References: <5AB53E95.9080308@oracle.com> <10728b43-110c-5dc3-1fdb-2e0241e3a0ff@oracle.com> <5ABC6DCF.10504@oracle.com> <6a2c6a54-9174-5815-80c1-35029931e0f2@oracle.com> <5ABE6B4A.1010701@oracle.com> <5ABE6E64.1060806@oracle.com> <5ACD85AD.4010009@oracle.com> Message-ID: That's great news, thanks! I'll pull down your updates just so my local copy does not get out of date in the meantime. On Tue, Apr 10, 2018 at 10:49 PM, Xueming Shen wrote: > Hi David, > > The CSR has been approved > https://bugs.openjdk.java.net/browse/JDK-8200527 > > API docs have been updated slightly based on the review suggestion. > > (1) added some words in the class spec for both Inflater and Deflater. > > *

> * This class deflates sequences of bytes into ZLIB compressed data format. > * The input byte sequence is provided in either byte array or byte buffer, > * via one of the {@code setInput()} methods. The output byte sequence is > * written to the output byte array or byte buffer passed to the > * {@code deflate()} methods. > *

> > *

> * This class inflates sequences of ZLIB compressed bytes. The input byte > * sequence is provided in either byte array or byte buffer, via one of the > * {@code setInput()} methods. The output byte sequence is written to the > * output byte array or byte buffer passed to the {@code deflate()} methods. > *

> > > (2) adjusted the workding a little for those setInput() methods > > *

> * One of the {@code setInput()} methods should be called whenever > * {@code needsInput()} returns true indicating that more input data > * is required. > *

> > > Two issues have been noticed when running tier1/2/3 tests > > (1) there is a error at ln#Inflater.c#243, the "input" is being released > instead of "output" > > http://cr.openjdk.java.net/~sherman/6341887.David.Lloyd/webrev.00/src/java.base/share/native/libzip/Inflater.c.sdiff.html > > which triggered crash for some tests. fixed. > > (2) sun/nio/ch/TestMaxCachedBufferSize.java failed "because of" the > "defaultBuf" > uses direct ByteBuffer. This is probably the issue of the test but I > simply update > the "defaultBuf" to be the heap buffer/0, instead of touch the failed > test case. > I don't have problem if you prefer to "fix" the test and keep the > "defaultBuf" as > direct buffer instead. > > // static final ByteBuffer defaultBuf = ByteBuffer.allocateDirect(0); > static final ByteBuffer defaultBuf = ByteBuffer.allocate(0); > > (3) I also updated test/jdk/java/util/zip/DeInflate.java with more tests for > the new APIs. > More tests might be desired though. > > The latest webrev is at > > http://cr.openjdk.java.net/~sherman/6341887.David.Lloyd/webrev/ > > Thanks, > Sherman > -- - DML From kirk.pepperdine at gmail.com Wed Apr 11 14:38:11 2018 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Wed, 11 Apr 2018 16:38:11 +0200 Subject: stripIndent() behavior In-Reply-To: References: Message-ID: <5B984768-E589-44E1-98CF-E64E2DC3D295@gmail.com> Hi, Mind if I bike shed on this one since everyone else it? A tab is white space of undefined length. Traditionally, tabs are the responsibility of the device (move forward software) to implement. This is why you *set* tabs. As such? it seems very reasonable that people don?t expect nor shouldn?t expect tabs to behave the same on all different devices. Meaning, if you want consistent behavior, a tab is not the signal you want to be sending. If we want the indent in our code to be the same all over then the correct signal is a space. That (for fixed width fonts) offers a uniformly sized white space. Note there is no tab/anti-tab rhetoric in here. Tabs are useful, so are spaces. You just need to know what they are so that you can know when it is appropriate to use one of the other. Kind regards, Kirk Pepperdine > On Apr 10, 2018, at 11:18 PM, Kevin Bourrillion wrote: > > On Tue, Apr 10, 2018 at 1:50 PM, Brian Goetz wrote: >> >> >> 3. If the input contains *any* tab characters at all (except any that are >>> part of the trailing whitespace), then this method cannot know that it >>> isn't jumbling the end result, and maybe it should just throw. >>> >> I think there's a middle ground, where it strips any common whitespace >> prefix. So if every line starts with tab-tab-space-space, it can safely >> strip this. > > > My point is that this is *not* safe, if by "safe" we mean "you will see the > same relative indentation you saw in the source". *Any* tab has the > potential to suddenly be worth a different number of spaces, once some > prefix of any kind has been removed. > > I would *like* to not worry about this, but we have to accept that the > programmers who will be hurt most will be the most novice. > > > 5. If we do end up in a world where we have to call this for almost every >>> one of our tens of thousands of multi-line RSLs... is it strange that I >>> feel like I would prefer it was static? It seems like it would look a lot >>> more normal that way visually. Ugh... >>> >> I think this is likely to vary subjectively a lot. Some people like that >> the instance method is mostly out of the way; others like the up-front >> shouting of the static method. >> > > Is it just potayto, potahto, or does one of the snippets above appear a lot > more consistent with how Java code has always looked? > > > On top of *that*, I have no idea what "right markers" are good for, nor >>> what customizing the marker choice is good for (other than creating more >>> needless variation between different pieces of code). >>> >>> >> String asciiArtFTW = >> ````````` >> ` BOO ` >> `````````.trimMarkers("`", "`"); >> >> > Ha, well, I did say "good" for :-) > > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com From paul.sandoz at oracle.com Wed Apr 11 18:10:03 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 11 Apr 2018 11:10:03 -0700 Subject: RFR 8197418: Move java/util/RandomAccess/ tests into OpenJDK In-Reply-To: <19AD7051-2394-4BD6-AA86-53FE1CDCCED9@oracle.com> References: <19AD7051-2394-4BD6-AA86-53FE1CDCCED9@oracle.com> Message-ID: Hi Chris, +1, and thanks for sharing code coverage results. Paul. > On Apr 10, 2018, at 11:33 PM, Chris Yin wrote: > > Please review the change to move java/util/RandomAccess/Basic.java test into OpenJDK, it increases code coverage of open jdk_util test group per JCov run, the main improvement is on java.util.Collections with %method up 1% and %block up 2%, thanks > > bug: https://bugs.openjdk.java.net/browse/JDK-8197418 > webrev: http://cr.openjdk.java.net/~xyin/8197418/webrev.00/ > > Regards, > Chris From emcmanus at google.com Wed Apr 11 19:00:05 2018 From: emcmanus at google.com (=?UTF-8?Q?=C3=89amonn_McManus?=) Date: Wed, 11 Apr 2018 19:00:05 +0000 Subject: stripIndent() behavior In-Reply-To: <2f91d5f3-18ff-fe8d-d827-3537798c7d06@oracle.com> References: <2f91d5f3-18ff-fe8d-d827-3537798c7d06@oracle.com> Message-ID: OK, well I think we do agree that at least stripIndent should be changed to remove the longest exact whitespace prefix common to all lines? So if you give it one line starting with 8 spaces and another starting with a tab it will return the string unchanged. The current behaviour just counts whitespace characters, so in that example it would strip the tab from the line that has it, and the first of the 8 spaces from the line that has them. My point about novice users is that not all users are inconvenienced alike. Users who have consciously configured their editing environment to use tabs presumably know what tabs are, and should quickly be able to figure out how to avoid them in RSLs or what method to call to get rid of them. But users who are new to the language, and perhaps to programming, may very well not know that there is such a thing as a tab character. Up until now they didn't have to care because they could unknowingly mix spaces and tabs without it mattering. But now I feel we are setting a trap for them where they will stare in frustration at two obviously identical lines that are somehow behaving differently from each other. As an experiment I put myself in the position of a novice user, by trying out a number of popular editors on the Mac in their default configurations. I found that NetBeans and IntelliJ did the right thing: by default they never write a tab. But with Eclipse, Emacs, Vim, and TextMate I found it quite easy to create mixed indentation. I also scanned the source of about 1,000 public open-source projects that are used within Google, and I found that 38% of them contained at least one file with inconsistent indentation (spaces before tabs, or some lines indented with spaces and others with tabs). And those would be projects presumably from relatively experienced developers. On Tue, 10 Apr 2018 at 15:27, Brian Goetz wrote: > I think this is "throwing" the baby out with the bathwater. It is > punishing those who can use tabs responsibly for the sins of those who > cannot. > You have to commit three sins before you have a problem: > - using tabs at all > - using tabs inconsistently across the lines of a single expression; > - using tabs after you've already used spaces on a line. > While I am sure that there are people who do so, it just seems > unreasonable to me to throw in the presence of tabs because someone, > somewhere, might commit these three sins together and *be confused by > the result*. (So, no, it's not the only option.) > Note that IDEs can also highlight code that would be inappropriately > mangled as a result, so people learn not to commit all three of the sins > listed. > On 4/10/2018 5:39 PM, ?amonn McManus wrote: > >>> 3. If the input contains *any* tab characters at all (except any that > > are > >>> part of the trailing whitespace), then this method cannot know that it > >>> isn't jumbling the end result, and maybe it should just throw. > >> I think there's a middle ground, where it strips any common whitespace > >> prefix. So if every line starts with tab-tab-space-space, it can safely > >> strip this. > > I'm afraid that's not true. In practice if you are using tabs at all it is > > very easy in many editors to end up with a mix of spaces and tabs. So you > > could easy have (with 8-space tabs) one line that has 3 tabs at the start, > > and another that has 2 tabs and 8 spaces. For example with Emacs you can > > get this just by hitting delete after a tab and then hitting space. You > > would nevertheless want stripIndent to remove the indentation from both > > lines, since they look identical. > > > > The situation is made worse by the fact that there are two common > > conventions for tab width, 4 or 8. > > > > I think the only way to avoid these problems is for stripIndent to throw if > > its argument has any tabs, or at least any tabs in leading whitespace, and > > provide a separate method `detab` whose argument says what the width of a > > tab stop is. (Just to be sure: this method should arrange for tab stops to > > be at positions 4N or 8N, where the first column is column 0. So a tab can > > expand into 1 to 4 spaces, or 1 to 8 spaces.) > > > > Then users operating in tab-free codebases can just write .stripIndent(), > > and users in tab-infected codebases can write .detab(4).stripIndent(). > > > > The alternative is to expose novice users to many hours of exasperation. > > Tabs are generally invisible, so you can imagine someone trying to figure > > out why two lines that look exactly the same ended up treated differently. > > Users may not even know there is such a thing as a tab character. (If > > stripIndent throws, it should have a helpful message that suggests calling > > detab(N) and that the value of n should probably be 4 or 8.) > > > >> String asciiArtFTW = > >> ````````` > >> ` BOO ` > >> `````````.trimMarkers("`", "`"); > > I'm not sure I get that. It doesn't correspond to anything I've ever wanted > > to do, even in languages that already have multiline strings. At least, > > could we have an overload that just takes the starting marker, for the > > overwhelmingly commoner case where you only want to strip at the start? > > > > On Tue, 10 Apr 2018 at 13:50, Brian Goetz wrote: > > > > > > > >>> (now stripIndent) > >>> > >>> I've accumulated a few questions/comments on this. > >>> > >>> 1. When choosing the amount to trim, it ought to ignore blank lines and > >>> only-whitespace lines, right? > >> Seems right. > >>> 2. Is it really appropriate to automatically remove trailing whitespace? > >> I'm not sure about this either. The reason that RSLs will have "extra" > >> whitespace that needs to be stripped is that we want to indent the RSL > >> snippet relative to the Java code (and as you point out, the IDE may do > >> that automatically for us.) But if there's trailing whitespace, its > >> because the user put it there, and who is it hurting? It might be > >> significant. > >>> 3. If the input contains *any* tab characters at all (except any that > > are > >>> part of the trailing whitespace), then this method cannot know that it > >>> isn't jumbling the end result, and maybe it should just throw. > >> I think there's a middle ground, where it strips any common whitespace > >> prefix. So if every line starts with tab-tab-space-space, it can safely > >> strip this. > >>> 5. If we do end up in a world where we have to call this for almost > > every > >>> one of our tens of thousands of multi-line RSLs... is it strange that I > >>> feel like I would prefer it was static? It seems like it would look a > > lot > >>> more normal that way visually. Ugh... > >> I think this is likely to vary subjectively a lot. Some people like > >> that the instance method is mostly out of the way; others like the > >> up-front shouting of the static method. > >> The reason we can't have both is then we can't resolve the method > >> reference String::strip as a Function, which seems a > >> useful thing to do. > >>> On top of *that*, I have no idea what "right markers" are good for, nor > >>> what customizing the marker choice is good for (other than creating more > >>> needless variation between different pieces of code). > >>> > >> String asciiArtFTW = > >> ````````` > >> ` BOO ` > >> `````````.trimMarkers("`", "`"); From paul.sandoz at oracle.com Wed Apr 11 19:09:52 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 11 Apr 2018 12:09:52 -0700 Subject: RFR: 8184692: add Pattern.asMatchPredicate In-Reply-To: References: <74681017-e7fe-47e8-89ef-d804c9e5e77b@default> <6AF1056A-D9AB-4C8C-9708-96CBCF40B2CB@oracle.com> <6e08e8d1-4052-40f9-ac30-514f3a83ef97@default> <3D98152E-5456-473B-9613-E0D5EDEBBC2C@oracle.com> Message-ID: <0710B763-B6B9-442F-AD6C-F77FE3824DFB@oracle.com> HI, Hopefully this is the last update :-) To align with asPredicate and Roger?s prior guidance on that method i think you can just say this: Creates a predicate that tests if this pattern matches a given input string. which is similar to the language of Pattern.matches. No need for another webrev if this change is acceptable. Paul. > On Apr 9, 2018, at 7:53 PM, Vivek Theeyarath wrote: > > Thanks Paul / Roger for the inputs. > I have updated the javadoc based on the inputs. http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.03 . Please review. > > Regards > Vivek > -----Original Message----- > From: Paul Sandoz > Sent: Monday, April 09, 2018 9:25 PM > To: Roger Riggs > Cc: Core-Libs-Dev > Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate > > > >> On Apr 9, 2018, at 8:41 AM, Roger Riggs wrote: >> >> Hi Vivek, >> >> As with Pattern.asPredicate the first sentence can be improved. >> >> Creates a predicate that tests if this pattern matches the entire region. >> > > The region of what? region is clear from the context of a Matcher, but less so from the context of Pattern. > > Paul. > >> 5833: As with the original issue, perhaps adding the word 'whole' or >> 'entire' will make it clearer that the pattern must match then entire input string. >> > >> 5827: Split into two sentences, the second one starting "For example," >> >> 5840: add a blank line between methods >> >> Regards, Roger >> >> >> On 4/9/18 5:05 AM, Vivek Theeyarath wrote: >>> Hi, >>> Please find the updated webrev after incorporating Paul's comments. >>> http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.02/ >>> >>> Also, I have created a csr for this issue https://bugs.openjdk.java.net/browse/JDK-8201308 . >>> >>> Regards >>> Vivek >>> -----Original Message----- >>> From: Paul Sandoz >>> Sent: Friday, April 06, 2018 6:55 AM >>> To: Vivek Theeyarath >>> Cc: Core-Libs-Dev >>> Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate >>> >>> >>> >>>> On Apr 4, 2018, at 10:47 AM, Vivek Theeyarath wrote: >>>> >>>> Hi All, >>>> >>>> Please review. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8184692 >>>> >>>> Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.00/ >>>> >>> Like with your other patch, alignment to ~80 chars would be good, as that is mostly consistent with other code in the same source file. >>> >>> Let?s not use the word ?find" here, so as not to confuse with matcher(s).find(). >>> >>> 5833 * @return The predicate which can be used for finding if an input string matches this pattern. >>> >>> I suggest: >>> >>> @return The predicate which can be used for matching an input string >>> against this pattern >>> >>> You could also add a @see Matcher#matches >>> >>> Paul. >>> >>>> >>>> The related jtreg test was run and the test passed . >>>> >>>> >>>> >>>> Regards >>>> >>>> Vivek >> > From kumar.x.srinivasan at oracle.com Wed Apr 11 20:43:42 2018 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 11 Apr 2018 13:43:42 -0700 Subject: RFR: 8198793:Add launcher support for preview features Message-ID: <5ACE737E.2050500@oracle.com> Hello, Could I get a review to update the launcher help message. https://bugs.openjdk.java.net/browse/JDK-8198793 diff --git a/src/java.base/share/classes/sun/launcher/resources/launcher.properties b/src/java.base/share/classes/sun/launcher/resources/launcher.properties --- a/src/java.base/share/classes/sun/launcher/resources/launcher.properties +++ b/src/java.base/share/classes/sun/launcher/resources/launcher.properties @@ -113,6 +113,8 @@ \ one or more argument files containing options\n\ \ -disable- at files\n\ \ prevent further argument file expansion\n\ +\ --enable-preview\n\ +\ allow classes to depend on preview features of this release \To specify an argument for a long option, you can use --= or\n\ \-- .\n Thanks Kumar From sundararajan.athijegannathan at oracle.com Wed Apr 11 23:16:41 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 12 Apr 2018 04:46:41 +0530 Subject: RFR: 8198793:Add launcher support for preview features In-Reply-To: <5ACE737E.2050500@oracle.com> References: <5ACE737E.2050500@oracle.com> Message-ID: <5ACE9759.2030501@oracle.com> Looks good. -Sundar On 12/04/18, 2:13 AM, Kumar Srinivasan wrote: > Hello, > > Could I get a review to update the launcher help message. > > https://bugs.openjdk.java.net/browse/JDK-8198793 > > diff --git > a/src/java.base/share/classes/sun/launcher/resources/launcher.properties > b/src/java.base/share/classes/sun/launcher/resources/launcher.properties > --- > a/src/java.base/share/classes/sun/launcher/resources/launcher.properties > +++ > b/src/java.base/share/classes/sun/launcher/resources/launcher.properties > @@ -113,6 +113,8 @@ > \ one or more argument files containing options\n\ > \ -disable- at files\n\ > \ prevent further argument file expansion\n\ > +\ --enable-preview\n\ > +\ allow classes to depend on preview features of > this release > \To specify an argument for a long option, you can use > --= or\n\ > \-- .\n > > > Thanks > Kumar > From xu.y.yin at oracle.com Thu Apr 12 01:19:51 2018 From: xu.y.yin at oracle.com (Chris Yin) Date: Thu, 12 Apr 2018 09:19:51 +0800 Subject: RFR 8197418: Move java/util/RandomAccess/ tests into OpenJDK In-Reply-To: References: <19AD7051-2394-4BD6-AA86-53FE1CDCCED9@oracle.com> Message-ID: <3F7B4A5B-4E7B-45BF-964E-4B890E1EB7EB@oracle.com> Thank you, Paul Regards, Chris > On 12 Apr 2018, at 2:10 AM, Paul Sandoz wrote: > > Hi Chris, > > +1, and thanks for sharing code coverage results. > > Paul. > > >> On Apr 10, 2018, at 11:33 PM, Chris Yin wrote: >> >> Please review the change to move java/util/RandomAccess/Basic.java test into OpenJDK, it increases code coverage of open jdk_util test group per JCov run, the main improvement is on java.util.Collections with %method up 1% and %block up 2%, thanks >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8197418 >> webrev: http://cr.openjdk.java.net/~xyin/8197418/webrev.00/ >> >> Regards, >> Chris > From huaming.li at oracle.com Thu Apr 12 02:47:22 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 12 Apr 2018 10:47:22 +0800 Subject: RFR of JDK-8078221, TEST_BUG: java/rmi/Naming/DefaultRegistryPort.java fails intermittently Message-ID: <1f13aa5c-58b8-de19-5add-1e38db3ce419@oracle.com> would you please review the following patch? bug: https://bugs.openjdk.java.net/browse/JDK-8078221 webrev: http://cr.openjdk.java.net/~mli/8078221/webrev.00/ Thank you -Hamlin From raffaello.giulietti at gmail.com Thu Apr 12 08:12:36 2018 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Thu, 12 Apr 2018 10:12:36 +0200 Subject: Clean-room implementation of Double::toString(double) and Float::toString(float) In-Reply-To: <3BD60996-BEC9-4179-91F8-39E002B33594@oracle.com> References: <5c8944fa-4941-79b4-9320-a04ecb93b27a@gmail.com> <8FC2F9AF-7B48-45FD-B65E-405122F1E21D@oracle.com> <9ffa5039-82b6-6f0b-479b-307361d8ba7a@gmail.com> <3BD60996-BEC9-4179-91F8-39E002B33594@oracle.com> Message-ID: <1806ffc6-fd62-0e15-77bb-4b53a28c9e36@gmail.com> Hi, my code is now ready to be uploaded to the OpenJDK reps. Currently it resides on GitHub and is under the "GPLv2 + Classpath Exception" license, with myself as the copyright holder. I asked Oracle about how the copyright notice should be adapted to meet the OCA requirements but, as of today, I got no answer. Is there any official reference about the copyright notice on OpenJDK contributions? Greetings Raffaello On 2018-03-31 00:17, Brian Burkhalter wrote: > Hi Raffaello, > > On Mar 30, 2018, at 2:57 PM, raffaello.giulietti at gmail.com > wrote: > >>>> [?] >>>> >>>> The new code also has a better specification than the current one, while >>>> being mostly compatible. Indeed, the current specification leaves room >>>> for interpretation and thus cannot ensure that an implementation >>>> produces consistent and unique results from one release to the next. The >>>> newer spec ensures a unique result. >>> >>> Any specification change would need to go through the Compatibility and >>> Specification Review process. [3] >>> >> >> OK, as you will see, as soon as the code will be uploaded, the only >> thing that formally affects output is the "1.0E23" versus "9.99....E22" >> issue. Everything else is worded in such a way to remain compatible but >> is simply a little bit more rigorous. > > Sounds good. > >> My wording was misleading: I already got the confirmation that my OCA >> application has been accepted, so I'm formally ready to contribute. > > That?s good as it gives more time. > >>> Per the JDK 11 schedule [5] there could well be sufficient time to run >>> this submission through the review processes. I suggest, once your OCA >>> has been processed, to proceed by posting your proposed changes for >>> review on this mailing list. Note that in general attachments are >>> scrubbed, so the patch would need either to be included inline or >>> published as a webrev [6]. >>> >> >> OK, I'll take a look on how the mechanics works. >> >> I'm usually on Windows. Are there technical issues with it as far as >> Webrev is concerned? I mean, I could setup a Linux VM in VirtualBox if >> this simplifies my life, but I'd prefer continuing my main work in Win. > > As seen in Jon?s posting there are some attachment types which will > work. As to webrev, I think it should work on Windows at least in cygwin > but I?ve not used it there myself. If it?s just a matter of creating a > webrev I could do that on your behalf based on your supplied patch. > > Thanks, > > Brian From bhamaram at in.ibm.com Thu Apr 12 09:41:30 2018 From: bhamaram at in.ibm.com (Bhaktavatsal R Maram) Date: Thu, 12 Apr 2018 09:41:30 +0000 Subject: Missing many locales support on AIX platform Message-ID: Hi, On AIX platforms, Java is not starting on many locales. Java initialization fails with java.lang.IllegalArgumentException bash-4.4$ LANG=Ja_JP java -version Error occurred during initialization of VM java.lang.IllegalArgumentException: Null charset name at java.nio.charset.Charset.lookup(java.base/Charset.java:455) at java.nio.charset.Charset.defaultCharset(java.base/Charset.java:608) at java.lang.StringCoding.decode(java.base/StringCoding.java:314) at java.lang.String.(java.base/String.java:591) at java.lang.String.(java.base/String.java:613) at java.lang.System.initProperties(java.base/Native Method) at java.lang.System.initPhase1(java.base/System.java:1908) >From our analysis, following are locales that are impacted with this issue. Ar_AA.IBM-1046 ar_AA.ISO8859-6 ca_ES.IBM-1252 at euro Iw_IL.IBM-856 iw_IL.ISO8859-8 Et_EE.IBM-922 at euro Ja_JP.IBM-932 Ja_JP.IBM-943 ja_JP.IBM-eucJP ko_KR.IBM-eucKR Lt_LT.IBM-921 at euro th_TH.TIS-620 Uk_UA.IBM-1124 Vi_VN.IBM-1129 Zh_CN.GB18030 zh_CN.IBM-eucCN Zh_HK.BIG5-HKSCS Zh_TW.big5 The default charset for these locales are not available in the java.base module and hence java cannot be used with those locales. In the current fix, am fixing the issue for following locales. Ja_JP.IBM-932 Ja_JP.IBM-943 ko_KR.IBM-eucKR th_TH.TIS-620 Uk_UA.IBM-1124 Zh_CN.GB18030 Zh_HK.BIG5-HKSCS Zh_TW.big5 I've attached fix with this mail. I will continue working on other locales and provide the fix. In the mean time, I kindly request you to open a bug and review the fix for the above locales. Thanks, Bhaktavatsal Reddy From mandy.chung at oracle.com Thu Apr 12 09:43:52 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 12 Apr 2018 17:43:52 +0800 Subject: RFR: 8198793:Add launcher support for preview features In-Reply-To: <5ACE737E.2050500@oracle.com> References: <5ACE737E.2050500@oracle.com> Message-ID: <62427d49-f1db-d36f-cd9d-d5e178e1513f@oracle.com> On 4/12/18 4:43 AM, Kumar Srinivasan wrote: > Hello, > > Could I get a review to update the launcher help message. > > https://bugs.openjdk.java.net/browse/JDK-8198793 > > diff --git > a/src/java.base/share/classes/sun/launcher/resources/launcher.properties > b/src/java.base/share/classes/sun/launcher/resources/launcher.properties > --- > a/src/java.base/share/classes/sun/launcher/resources/launcher.properties > +++ > b/src/java.base/share/classes/sun/launcher/resources/launcher.properties > @@ -113,6 +113,8 @@ > ?\????????????????? one or more argument files containing options\n\ > ?\??? -disable- at files\n\ > ?\????????????????? prevent further argument file expansion\n\ > +\??? --enable-preview\n\ > +\????????????????? allow classes to depend on preview features of > this release > ?\To specify an argument for a long option, you can use > --= or\n\ > ?\-- .\n I suggest to make the help message direct e.g. ??? enable the preview VM features of this release Mandy From bhamaram at in.ibm.com Thu Apr 12 09:45:28 2018 From: bhamaram at in.ibm.com (Bhaktavatsal R Maram) Date: Thu, 12 Apr 2018 09:45:28 +0000 Subject: Missing many locales support on AIX platform In-Reply-To: References: Message-ID: Patch I attached to previous mail is not seen. So, pasting patch here. Hope, it is fine. # HG changeset patch # User bhamaram # Date 1523510846 -19800 # Node ID 6134bbe9861111f8cc42b055081f2c48e91039a8 # Parent 0c3e252cea44f06aef570ef464950ab97c669970 java.lang.IllegalArgumentException from java -version on AIX with different locales diff -r 0c3e252cea44 -r 6134bbe98611 make/data/charsetmapping/charsets --- a/make/data/charsetmapping/charsets Thu Apr 12 10:19:31 2018 +0800 +++ b/make/data/charsetmapping/charsets Thu Apr 12 10:57:26 2018 +0530 @@ -933,11 +933,16 @@ charset x-IBM942C IBM942C package sun.nio.cs.ext - type source + type template alias cp942C # JDK historical alias ibm942C alias ibm-942C alias 942C + alias cp932 + alias ibm932 + alias ibm-932 + alias 932 + alias x-ibm932 charset x-IBM943 IBM943 package sun.nio.cs.ext diff -r 0c3e252cea44 -r 6134bbe98611 make/data/charsetmapping/stdcs-aix --- a/make/data/charsetmapping/stdcs-aix Thu Apr 12 10:19:31 2018 +0800 +++ b/make/data/charsetmapping/stdcs-aix Thu Apr 12 10:57:26 2018 +0530 @@ -1,6 +1,16 @@ # # generate these charsets into sun.nio.cs # +Big5 +Big5_HKSCS EUC_CN EUC_KR GBK +GB18030 +IBM942 +IBM942C +IBM943 +IBM950 +IBM970 +IBM1124 +TIS_620 diff -r 0c3e252cea44 -r 6134bbe98611 src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java --- a/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java Thu Apr 12 10:19:31 2018 +0800 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,93 +0,0 @@ -/* - * Copyright (c) 2003, 2004, 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. - */ - -package sun.nio.cs.ext; - -import java.nio.charset.Charset; -import java.nio.charset.CharsetDecoder; -import java.nio.charset.CharsetEncoder; -import java.util.Arrays; -import sun.nio.cs.DoubleByte; -import sun.nio.cs.HistoricallyNamedCharset; -import static sun.nio.cs.CharsetMapping.*; - -public class IBM942C extends Charset implements HistoricallyNamedCharset -{ - public IBM942C() { - super("x-IBM942C", ExtendedCharsets.aliasesFor("x-IBM942C")); - } - - public String historicalName() { - return "Cp942C"; - } - - public boolean contains(Charset cs) { - return ((cs.name().equals("US-ASCII")) - || (cs instanceof IBM942C)); - } - - public CharsetDecoder newDecoder() { - return new DoubleByte.Decoder(this, - IBM942.b2c, - b2cSB, - 0x40, - 0xfc); - } - - public CharsetEncoder newEncoder() { - return new DoubleByte.Encoder(this, c2b, c2bIndex); - } - - final static char[] b2cSB; - final static char[] c2b; - final static char[] c2bIndex; - - static { - IBM942.initb2c(); - - // the mappings need udpate are - // u+001a <-> 0x1a - // u+001c <-> 0x1c - // u+005c <-> 0x5c - // u+007e <-> 0x7e - // u+007f <-> 0x7f - - b2cSB = Arrays.copyOf(IBM942.b2cSB, IBM942.b2cSB.length); - b2cSB[0x1a] = 0x1a; - b2cSB[0x1c] = 0x1c; - b2cSB[0x5c] = 0x5c; - b2cSB[0x7e] = 0x7e; - b2cSB[0x7f] = 0x7f; - - IBM942.initc2b(); - c2b = Arrays.copyOf(IBM942.c2b, IBM942.c2b.length); - c2bIndex = Arrays.copyOf(IBM942.c2bIndex, IBM942.c2bIndex.length); - c2b[c2bIndex[0] + 0x1a] = 0x1a; - c2b[c2bIndex[0] + 0x1c] = 0x1c; - c2b[c2bIndex[0] + 0x5c] = 0x5c; - c2b[c2bIndex[0] + 0x7e] = 0x7e; - c2b[c2bIndex[0] + 0x7f] = 0x7f; - } -} diff -r 0c3e252cea44 -r 6134bbe98611 src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java.template --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java.template Thu Apr 12 10:57:26 2018 +0530 @@ -0,0 +1,93 @@ +/* + * Copyright (c) 2003, 2004, 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. + */ + +package $PACKAGE$; + +import java.nio.charset.Charset; +import java.nio.charset.CharsetDecoder; +import java.nio.charset.CharsetEncoder; +import java.util.Arrays; +import sun.nio.cs.DoubleByte; +import sun.nio.cs.HistoricallyNamedCharset; +import static sun.nio.cs.CharsetMapping.*; + +public class IBM942C extends Charset implements HistoricallyNamedCharset +{ + public IBM942C() { + super("x-IBM942C", $ALIASES$); + } + + public String historicalName() { + return "Cp942C"; + } + + public boolean contains(Charset cs) { + return ((cs.name().equals("US-ASCII")) + || (cs instanceof IBM942C)); + } + + public CharsetDecoder newDecoder() { + return new DoubleByte.Decoder(this, + IBM942.b2c, + b2cSB, + 0x40, + 0xfc); + } + + public CharsetEncoder newEncoder() { + return new DoubleByte.Encoder(this, c2b, c2bIndex); + } + + final static char[] b2cSB; + final static char[] c2b; + final static char[] c2bIndex; + + static { + IBM942.initb2c(); + + // the mappings need udpate are + // u+001a <-> 0x1a + // u+001c <-> 0x1c + // u+005c <-> 0x5c + // u+007e <-> 0x7e + // u+007f <-> 0x7f + + b2cSB = Arrays.copyOf(IBM942.b2cSB, IBM942.b2cSB.length); + b2cSB[0x1a] = 0x1a; + b2cSB[0x1c] = 0x1c; + b2cSB[0x5c] = 0x5c; + b2cSB[0x7e] = 0x7e; + b2cSB[0x7f] = 0x7f; + + IBM942.initc2b(); + c2b = Arrays.copyOf(IBM942.c2b, IBM942.c2b.length); + c2bIndex = Arrays.copyOf(IBM942.c2bIndex, IBM942.c2bIndex.length); + c2b[c2bIndex[0] + 0x1a] = 0x1a; + c2b[c2bIndex[0] + 0x1c] = 0x1c; + c2b[c2bIndex[0] + 0x5c] = 0x5c; + c2b[c2bIndex[0] + 0x7e] = 0x7e; + c2b[c2bIndex[0] + 0x7f] = 0x7f; + } +} Thanks, Bhaktavatsal Reddy -----"core-libs-dev" wrote: ----- To: core-libs-dev at openjdk.java.net From: "Bhaktavatsal R Maram" Sent by: "core-libs-dev" Date: 04/12/2018 03:12PM Subject: Missing many locales support on AIX platform Hi, On AIX platforms, Java is not starting on many locales. Java initialization fails with java.lang.IllegalArgumentException bash-4.4$ LANG=Ja_JP java -version Error occurred during initialization of VM java.lang.IllegalArgumentException: Null charset name at java.nio.charset.Charset.lookup(java.base/Charset.java:455) at java.nio.charset.Charset.defaultCharset(java.base/Charset.java:608) at java.lang.StringCoding.decode(java.base/StringCoding.java:314) at java.lang.String.(java.base/String.java:591) at java.lang.String.(java.base/String.java:613) at java.lang.System.initProperties(java.base/Native Method) at java.lang.System.initPhase1(java.base/System.java:1908) >From our analysis, following are locales that are impacted with this issue. Ar_AA.IBM-1046 ar_AA.ISO8859-6 ca_ES.IBM-1252 at euro Iw_IL.IBM-856 iw_IL.ISO8859-8 Et_EE.IBM-922 at euro Ja_JP.IBM-932 Ja_JP.IBM-943 ja_JP.IBM-eucJP ko_KR.IBM-eucKR Lt_LT.IBM-921 at euro th_TH.TIS-620 Uk_UA.IBM-1124 Vi_VN.IBM-1129 Zh_CN.GB18030 zh_CN.IBM-eucCN Zh_HK.BIG5-HKSCS Zh_TW.big5 The default charset for these locales are not available in the java.base module and hence java cannot be used with those locales. In the current fix, am fixing the issue for following locales. Ja_JP.IBM-932 Ja_JP.IBM-943 ko_KR.IBM-eucKR th_TH.TIS-620 Uk_UA.IBM-1124 Zh_CN.GB18030 Zh_HK.BIG5-HKSCS Zh_TW.big5 I've attached fix with this mail. I will continue working on other locales and provide the fix. In the mean time, I kindly request you to open a bug and review the fix for the above locales. Thanks, Bhaktavatsal Reddy From mandy.chung at oracle.com Thu Apr 12 10:24:33 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 12 Apr 2018 18:24:33 +0800 Subject: RFR [10] 8194554: filterArguments runs multiple filters in the wrong order In-Reply-To: References: Message-ID: <3c7e1830-4419-318b-eff3-df56bfe68912@oracle.com> I was on vacation last week.? Paul - thanks for submitting CSR for JDK-8194554 for the resulting behavioral change. This backport looks good to me. Thanks Mandy On 4/5/18 11:33 PM, Aleksey Shipilev wrote: > Hi, > > Please review this jdk10 backport. > > Original JDK 11 bug: > https://bugs.openjdk.java.net/browse/JDK-8194554 > > Original JDK 11 fix: > http://hg.openjdk.java.net/jdk/jdk/rev/050352ed64d5 > > Please note the discussion in JBS comments about the issue. It seems to include the more verbose > specification text, and Rob says it makes the patch not directly backportable. Therefore, requesting > to backport without the Javadoc change. I just dropped that single line from the original changeset: > > > 8194554: filterArguments runs multiple filters in the wrong order > Reviewed-by: psandoz, jrose > > diff -r b09e56145e11 -r ab2dc3096cdb src/java.base/share/classes/java/lang/invoke/MethodHandles.java > --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Thu Mar 08 04:23:31 2018 +0000 > +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Wed Jan 17 15:17:50 2018 -0800 > @@ -3836,11 +3836,12 @@ > MethodHandle filterArguments(MethodHandle target, int pos, MethodHandle... filters) { > filterArgumentsCheckArity(target, pos, filters); > MethodHandle adapter = target; > - int curPos = pos-1; // pre-incremented > - for (MethodHandle filter : filters) { > - curPos += 1; > + // process filters in reverse order so that the invocation of > + // the resulting adapter will invoke the filters in left-to-right order > + for (int i = filters.length - 1; i >= 0; --i) { > + MethodHandle filter = filters[i]; > if (filter == null) continue; // ignore null elements of filters > - adapter = filterArgument(adapter, curPos, filter); > + adapter = filterArgument(adapter, pos + i, filter); > } > return adapter; > } > diff -r b09e56145e11 -r ab2dc3096cdb test/jdk/java/lang/invoke/FilterArgumentsTest.java > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/test/jdk/java/lang/invoke/FilterArgumentsTest.java Wed Jan 17 15:17:50 2018 -0800 > @@ -0,0 +1,132 @@ > +/* > + * Copyright (c) 2018, 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. > + * > + * 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. > + */ > + > +/* > + * @test > + * @bug 8194554 > + * @run testng/othervm test.java.lang.invoke.FilterArgumentsTest > + */ > + > +package test.java.lang.invoke; > + > +import java.lang.invoke.MethodHandle; > +import java.lang.invoke.MethodHandles; > +import java.util.ArrayList; > +import java.util.List; > + > +import static java.lang.invoke.MethodHandles.*; > +import static java.lang.invoke.MethodType.methodType; > + > +import org.testng.annotations.*; > +import static org.testng.Assert.*; > + > +public class FilterArgumentsTest { > + > + @Test > + public static void testFilterA_B_C() throws Throwable { > + FilterTest test = new FilterTest( > + filterArguments(MH_TEST, 0, MH_FILTER_A, MH_FILTER_B, MH_FILTER_C)); > + test.run(List.of("A", "B", "C")); > + } > + > + @Test > + public static void testFilterA_B() throws Throwable { > + FilterTest test = new FilterTest( > + filterArguments(MH_TEST, 0, MH_FILTER_A, MH_FILTER_B)); > + test.run(List.of("A", "B")); > + } > + > + @Test > + public static void testFilterB_C() throws Throwable { > + FilterTest test = new FilterTest( > + filterArguments(MH_TEST, 1, MH_FILTER_B, MH_FILTER_C)); > + test.run(List.of("B", "C")); > + } > + > + @Test > + public static void testFilterB() throws Throwable { > + FilterTest test = new FilterTest(filterArguments(MH_TEST, 1, MH_FILTER_B)); > + test.run(List.of("B")); > + } > + > + @Test > + public static void testFilterC() throws Throwable { > + FilterTest test = new FilterTest(filterArguments(MH_TEST, 2, MH_FILTER_C)); > + test.run(List.of("C")); > + } > + > + static class FilterTest { > + static List filters = new ArrayList<>(); > + > + final MethodHandle mh; > + FilterTest(MethodHandle mh) { > + this.mh = mh; > + } > + > + void run(List expected) throws Throwable { > + filters.clear(); > + assertEquals("x-0-z", (String)mh.invokeExact("x", 0, 'z')); > + assertEquals(expected, filters); > + } > + > + static String filterA(String s) { > + filters.add("A"); > + return s; > + } > + > + static int filterB(int value) { > + filters.add("B"); > + return value; > + } > + > + static char filterC(char c) { > + filters.add("C"); > + return c; > + } > + > + static String test(String s, int i, char c) { > + return s + "-" + i + "-" + c; > + } > + } > + > + static final MethodHandle MH_TEST; > + static final MethodHandle MH_FILTER_A; > + static final MethodHandle MH_FILTER_B; > + static final MethodHandle MH_FILTER_C; > + static final Lookup LOOKUP = MethodHandles.lookup(); > + > + static { > + try { > + MH_TEST = LOOKUP.findStatic(FilterTest.class, "test", > + methodType(String.class, String.class, int.class, char.class)); > + MH_FILTER_A = LOOKUP.findStatic(FilterTest.class, "filterA", > + methodType(String.class, String.class)); > + MH_FILTER_B = LOOKUP.findStatic(FilterTest.class, "filterB", > + methodType(int.class, int.class)); > + MH_FILTER_C = LOOKUP.findStatic(FilterTest.class, "filterC", > + methodType(char.class, char.class)); > + } catch (Exception e) { > + throw new RuntimeException(e); > + } > + } > +} > > > Thanks, > -Aleksey From Alan.Bateman at oracle.com Thu Apr 12 10:53:42 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Apr 2018 11:53:42 +0100 Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations In-Reply-To: <9bae15f406ed4e029233415e6a8032b8@sap.com> References: <9bae15f406ed4e029233415e6a8032b8@sap.com> Message-ID: <81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com> Adding core-libs-dev as this is change code in libjava, libzip, libjimage, ... Can you confirm that this is the up to date webrev: ?? http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ As I read it, this changes the calling convention of these functions on 32-bit Windows but it will have no impact on 64-bit Windows (as __stdcall is ignored) or other platforms, is that correct? -Alan On 06/04/2018 14:20, Baesken, Matthias wrote: > Hello, I just noticed 2 additonal issues regarding mapfile-removal : > > > 1. The follow up change that removed mapfiles for exes as well leads on Win32 bit to this link error : > > Creating library C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and object C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp > LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup > C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe : fatal error LNK1120: 1 unresolved externals > > > Looks like we cannot have JNICALL in main.c : > > diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c > --- a/src/java.base/share/native/launcher/main.c Thu Apr 05 14:39:04 2018 -0700 > +++ b/src/java.base/share/native/launcher/main.c Fri Apr 06 15:16:40 2018 +0200 > @@ -93,7 +93,7 @@ > __initenv = _environ; > > #else /* JAVAW */ > -JNIEXPORT int JNICALL > +JNIEXPORT int > main(int argc, char **argv) > { > int margc; > > > > 1. Zip-library has runtime issues when symbols are resolved in src/hotspot/share/classfile/classLoader.cpp. > > I added the declaration of the missing symbol, this seems to fix it . > > > diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h > --- a/src/java.base/share/native/libzip/zip_util.h Thu Apr 05 14:39:04 2018 -0700 > +++ b/src/java.base/share/native/libzip/zip_util.h Fri Apr 06 15:16:40 2018 +0200 > @@ -284,4 +284,7 @@ > JNIEXPORT jboolean JNICALL > ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen, char **pmsg); > > +JNIEXPORT jint JNICALL > +ZIP_CRC32(jint crc, const jbyte *buf, jint len); > + > > > Should I prepare another bug, or add this to the existing one and post a second webrev ? > > Best regards, Matthias > > > From: Baesken, Matthias > Sent: Freitag, 6. April 2018 09:54 > To: 'Magnus Ihse Bursie' > Cc: build-dev at openjdk.java.net; Doerr, Martin > Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations > > Hello, please review : > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8201226 > > change : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/ > > mostly I added JNIEXPORT / JNICALL at some places where the win32bit build missed it . > > A difference is src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h > Where I removed a few declarations (one decl with one without JNIEXPORT / JNICALL ? looked a bit strange ) . > > Best regards , Matthias > > > From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] > Sent: Donnerstag, 5. April 2018 17:45 > To: Baesken, Matthias > > Cc: build-dev at openjdk.java.net; Doerr, Martin > > Subject: Re: missing JNIEXPORT / JNICALL at some places in function declarations/implementations > > That's most likely a result of the new JNIEXPORT I added as part of the mapfile removal. > > I tried to match header file and C file, but I can certainly have missed cases. If I didn't get any warnings, it was hard to know what I missed. > > Please do submit your patch. > > I'm a bit surprised 32-bit Window is still buildable. :) > > /Magnus > > 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias >: > Hello, we noticed that at a number of places in the coding , the JNIEXPORT and/or JNICALL modifiers do not match when one compares the declaration and > The implementation of functions. > While this is ok on most platforms, it seems to fail on Windows 32 bit and leads to errors like this one : > > e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageConvKernelConvert.c(87) : error C2373: 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type modifiers > e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\mlib_image_proto.h(2630) : see declaration of 'j2d_mlib_ImageConvKernelConvert' > > (there are quite a few of these e.g. in mlib / splashscreen etc.) > > > Another example is this one : > > diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp > --- a/src/java.base/share/native/libjimage/jimage.hpp Thu Apr 05 09:55:16 2018 +0200 > +++ b/src/java.base/share/native/libjimage/jimage.hpp Thu Apr 05 17:07:40 2018 +0200 > @@ -126,7 +126,7 @@ > * JImageLocationRef location = (*JImageFindResource)(image, > * "java.base", "9.0", "java/lang/String.class", &size); > */ > -extern "C" JNIEXPORT JImageLocationRef JIMAGE_FindResource(JImageFile* jimage, > +extern "C" JNIEXPORT JImageLocationRef JNICALL JIMAGE_FindResource(JImageFile* jimage, > const char* module_name, const char* version, const char* name, > jlong* size); > > > Is there some generic way to get the same declarations / impementations in the code ? > > Or should I just add a patch with my findings ? > > Best regards, Matthias > From matthias.baesken at sap.com Thu Apr 12 11:04:53 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 12 Apr 2018 11:04:53 +0000 Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations In-Reply-To: <81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com> References: <9bae15f406ed4e029233415e6a8032b8@sap.com> <81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com> Message-ID: <7c5e68c2a023490e96ce6452fbda1700@sap.com> Hi Alan , this is the up to date webrev . However we want to add Alexey Ivanov as additional author . > > As I read it, this changes the calling convention of these functions on > 32-bit Windows but it will have no impact on 64-bit Windows (as > __stdcall is ignored) or other platforms, is that correct? > The change adds JNIEXPORT at some places where it is ben forgotten , for example : http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp.c.udiff.html This might have potential impact on other platforms (fixes the mismatches) . Best regards, Matthias > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > Sent: Donnerstag, 12. April 2018 12:54 > To: Baesken, Matthias ; Magnus Ihse Bursie > > Cc: build-dev at openjdk.java.net; Doerr, Martin ; > core-libs-dev at openjdk.java.net > Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function > declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at > some places in function declarations/implementations > > Adding core-libs-dev as this is change code in libjava, libzip, > libjimage, ... > > Can you confirm that this is the up to date webrev: > ?? http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ > > As I read it, this changes the calling convention of these functions on > 32-bit Windows but it will have no impact on 64-bit Windows (as > __stdcall is ignored) or other platforms, is that correct? > > -Alan > > > On 06/04/2018 14:20, Baesken, Matthias wrote: > > Hello, I just noticed 2 additonal issues regarding mapfile-removal : > > > > > > 1. The follow up change that removed mapfiles for exes as well > leads on Win32 bit to this link error : > > > > Creating library > C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and object > C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp > > LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main > referenced in function ___tmainCRTStartup > > C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe : > fatal error LNK1120: 1 unresolved externals > > > > > > Looks like we cannot have JNICALL in main.c : > > > > diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c > > --- a/src/java.base/share/native/launcher/main.c Thu Apr 05 14:39:04 > 2018 -0700 > > +++ b/src/java.base/share/native/launcher/main.c Fri Apr 06 15:16:40 > 2018 +0200 > > @@ -93,7 +93,7 @@ > > __initenv = _environ; > > > > #else /* JAVAW */ > > -JNIEXPORT int JNICALL > > +JNIEXPORT int > > main(int argc, char **argv) > > { > > int margc; > > > > > > > > 1. Zip-library has runtime issues when symbols are resolved in > src/hotspot/share/classfile/classLoader.cpp. > > > > I added the declaration of the missing symbol, this seems to fix it . > > > > > > diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h > > --- a/src/java.base/share/native/libzip/zip_util.h Thu Apr 05 14:39:04 > 2018 -0700 > > +++ b/src/java.base/share/native/libzip/zip_util.h Fri Apr 06 15:16:40 > 2018 +0200 > > @@ -284,4 +284,7 @@ > > JNIEXPORT jboolean JNICALL > > ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen, char > **pmsg); > > > > +JNIEXPORT jint JNICALL > > +ZIP_CRC32(jint crc, const jbyte *buf, jint len); > > + > > > > > > Should I prepare another bug, or add this to the existing one and post a > second webrev ? > > > > Best regards, Matthias > > > > > > From: Baesken, Matthias > > Sent: Freitag, 6. April 2018 09:54 > > To: 'Magnus Ihse Bursie' > > Cc: build-dev at openjdk.java.net; Doerr, Martin > > Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in > function declarations/implementations - was : RE: missing JNIEXPORT / > JNICALL at some places in function declarations/implementations > > > > Hello, please review : > > > > Bug : > > > > https://bugs.openjdk.java.net/browse/JDK-8201226 > > > > change : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/ > > > > mostly I added JNIEXPORT / JNICALL at some places where the win32bit > build missed it . > > > > A difference is > src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h > > Where I removed a few declarations (one decl with one without > JNIEXPORT / JNICALL ? looked a bit strange ) . > > > > Best regards , Matthias > > > > > > From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] > > Sent: Donnerstag, 5. April 2018 17:45 > > To: Baesken, Matthias > > > > Cc: build-dev at openjdk.java.net; > Doerr, Martin > > > Subject: Re: missing JNIEXPORT / JNICALL at some places in function > declarations/implementations > > > > That's most likely a result of the new JNIEXPORT I added as part of the > mapfile removal. > > > > I tried to match header file and C file, but I can certainly have missed cases. > If I didn't get any warnings, it was hard to know what I missed. > > > > Please do submit your patch. > > > > I'm a bit surprised 32-bit Window is still buildable. :) > > > > /Magnus > > > > 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias > >: > > Hello, we noticed that at a number of places in the coding , the > JNIEXPORT and/or JNICALL modifiers do not match when one compares > the declaration and > > The implementation of functions. > > While this is ok on most platforms, it seems to fail on Windows 32 bit and > leads to errors like this one : > > > > > e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/ml > ib_ImageConvKernelConvert.c(87) : error C2373: > 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type modifiers > > > e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\ml > ib_image_proto.h(2630) : see declaration of > 'j2d_mlib_ImageConvKernelConvert' > > > > (there are quite a few of these e.g. in mlib / splashscreen etc.) > > > > > > Another example is this one : > > > > diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp > > --- a/src/java.base/share/native/libjimage/jimage.hpp Thu Apr 05 09:55:16 > 2018 +0200 > > +++ b/src/java.base/share/native/libjimage/jimage.hpp Thu Apr 05 > 17:07:40 2018 +0200 > > @@ -126,7 +126,7 @@ > > * JImageLocationRef location = (*JImageFindResource)(image, > > * "java.base", "9.0", "java/lang/String.class", &size); > > */ > > -extern "C" JNIEXPORT JImageLocationRef > JIMAGE_FindResource(JImageFile* jimage, > > +extern "C" JNIEXPORT JImageLocationRef JNICALL > JIMAGE_FindResource(JImageFile* jimage, > > const char* module_name, const char* version, const char* name, > > jlong* size); > > > > > > Is there some generic way to get the same declarations / impementations > in the code ? > > > > Or should I just add a patch with my findings ? > > > > Best regards, Matthias > > From alexey.ivanov at oracle.com Thu Apr 12 12:25:34 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 12 Apr 2018 13:25:34 +0100 Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations In-Reply-To: <3214002b-0892-0ab7-7bca-958483e89108@oracle.com> References: <9bae15f406ed4e029233415e6a8032b8@sap.com> <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com> <35e12d6d6eb24d88aadaf10e0229dd48@sap.com> <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com> <5146b9330edd44b483780587aca1757c@sap.com> <99420e261ef347578bb8099a48d6b7ec@sap.com> <5693830fbf6747d9a51e9cf374f63e18@sap.com> <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com> <3520f157a7d14a118a584fdeb226381e@sap.com> <3214002b-0892-0ab7-7bca-958483e89108@oracle.com> Message-ID: Hi Matthias, On 12/04/2018 11:12, Alexey Ivanov wrote: > Hi Matthias, > > On 12/04/2018 08:49, Baesken, Matthias wrote: >> Hi,? could? someone please? sponsor? the change? now ? > > According to OpenJDK Census page [1], you have committer rights to JDK > project. > >> And? could someone please check? what happened? to the submit-repo ? >> Yesterday I pushed to? the submit repo? to?? check my? change ,? but? >> no? response?? so far . >> Maybe? the submit repo? is not working currently? ,? not sure about it . > > I can your push to submit repo on 10 Apr 2018 08:38:56 +0200. > However, I'm not sure where the build and test job is run. I couldn't > find it. > > Anyway, I've just submitted a build job with your changeset and am > running 32 bit Windows build. The build job is successful: no failures found. My local 32 bit Windows build is also fine. I successfully ran SwingSet2 and Java2Demo with it. I guess we're waiting for approval from core-libs. Regards, Alexey > > > Regards, > Alexey > > [1] http://openjdk.java.net/census#mbaesken > >> >> Best regards , Matthias >> From vivek.theeyarath at oracle.com Thu Apr 12 12:49:15 2018 From: vivek.theeyarath at oracle.com (Vivek Theeyarath) Date: Thu, 12 Apr 2018 05:49:15 -0700 (PDT) Subject: RFR: 8184692: add Pattern.asMatchPredicate In-Reply-To: <0710B763-B6B9-442F-AD6C-F77FE3824DFB@oracle.com> References: <74681017-e7fe-47e8-89ef-d804c9e5e77b@default> <6AF1056A-D9AB-4C8C-9708-96CBCF40B2CB@oracle.com> <6e08e8d1-4052-40f9-ac30-514f3a83ef97@default> <3D98152E-5456-473B-9613-E0D5EDEBBC2C@oracle.com> <0710B763-B6B9-442F-AD6C-F77FE3824DFB@oracle.com> Message-ID: <6470b5b7-0c10-4d99-950e-4ca27a31fa83@default> Hi, I have updated the doc as per the suggestion. Have finalized the csr too. Regards Vivek -----Original Message----- From: Paul Sandoz Sent: Thursday, April 12, 2018 12:40 AM To: Vivek Theeyarath Cc: Roger Riggs ; Core-Libs-Dev Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate HI, Hopefully this is the last update :-) To align with asPredicate and Roger?s prior guidance on that method i think you can just say this: Creates a predicate that tests if this pattern matches a given input string. which is similar to the language of Pattern.matches. No need for another webrev if this change is acceptable. Paul. > On Apr 9, 2018, at 7:53 PM, Vivek Theeyarath wrote: > > Thanks Paul / Roger for the inputs. > I have updated the javadoc based on the inputs. http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.03 . Please review. > > Regards > Vivek > -----Original Message----- > From: Paul Sandoz > Sent: Monday, April 09, 2018 9:25 PM > To: Roger Riggs > Cc: Core-Libs-Dev > Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate > > > >> On Apr 9, 2018, at 8:41 AM, Roger Riggs wrote: >> >> Hi Vivek, >> >> As with Pattern.asPredicate the first sentence can be improved. >> >> Creates a predicate that tests if this pattern matches the entire region. >> > > The region of what? region is clear from the context of a Matcher, but less so from the context of Pattern. > > Paul. > >> 5833: As with the original issue, perhaps adding the word 'whole' or >> 'entire' will make it clearer that the pattern must match then entire input string. >> > >> 5827: Split into two sentences, the second one starting "For example," >> >> 5840: add a blank line between methods >> >> Regards, Roger >> >> >> On 4/9/18 5:05 AM, Vivek Theeyarath wrote: >>> Hi, >>> Please find the updated webrev after incorporating Paul's comments. >>> http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.02/ >>> >>> Also, I have created a csr for this issue https://bugs.openjdk.java.net/browse/JDK-8201308 . >>> >>> Regards >>> Vivek >>> -----Original Message----- >>> From: Paul Sandoz >>> Sent: Friday, April 06, 2018 6:55 AM >>> To: Vivek Theeyarath >>> Cc: Core-Libs-Dev >>> Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate >>> >>> >>> >>>> On Apr 4, 2018, at 10:47 AM, Vivek Theeyarath wrote: >>>> >>>> Hi All, >>>> >>>> Please review. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8184692 >>>> >>>> Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.00/ >>>> >>> Like with your other patch, alignment to ~80 chars would be good, as that is mostly consistent with other code in the same source file. >>> >>> Let?s not use the word ?find" here, so as not to confuse with matcher(s).find(). >>> >>> 5833 * @return The predicate which can be used for finding if an input string matches this pattern. >>> >>> I suggest: >>> >>> @return The predicate which can be used for matching an input >>> string against this pattern >>> >>> You could also add a @see Matcher#matches >>> >>> Paul. >>> >>>> >>>> The related jtreg test was run and the test passed . >>>> >>>> >>>> >>>> Regards >>>> >>>> Vivek >> > From matthias.baesken at sap.com Thu Apr 12 13:07:48 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 12 Apr 2018 13:07:48 +0000 Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations In-Reply-To: <4976D5AA-732B-4C95-B669-05E3DCD245C3@oracle.com> References: <9bae15f406ed4e029233415e6a8032b8@sap.com> <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com> <35e12d6d6eb24d88aadaf10e0229dd48@sap.com> <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com> <5146b9330edd44b483780587aca1757c@sap.com> <99420e261ef347578bb8099a48d6b7ec@sap.com> <5693830fbf6747d9a51e9cf374f63e18@sap.com> <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com> <3520f157a7d14a118a584fdeb226381e@sap.com> <4976D5AA-732B-4C95-B669-05E3DCD245C3@oracle.com> Message-ID: <4007f78bf6c44e0e9a6b96671493b22c@sap.com> > Your submit job ran without failures, we were doing maintenance on the jdk- > submit repo yesterday and had turned off notifications. Sorry for the > inconvenience. Hi Christian , Thanks for the information about the submit job success. Is there a way to check (e.g. webpage) that a submit job has "arrived" and is queued for build/test ? Would have been helpful in this situation . Best regards, Matthias > -----Original Message----- > From: Christian Tornqvist [mailto:christian.tornqvist at oracle.com] > Sent: Donnerstag, 12. April 2018 14:58 > To: Baesken, Matthias > Cc: Alexey Ivanov ; Magnus Ihse Bursie > ; build-dev dev at openjdk.java.net>; Doerr, Martin > Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function > declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at > some places in function declarations/implementations > > Hi Matthias, > > > > On Apr 12, 2018, at 3:49 35AM, Baesken, Matthias > wrote: > > > > Hi, could someone please sponsor the change now ? > > > > And could someone please check what happened to the submit-repo ? > > Yesterday I pushed to the submit repo to check my change , but no > response so far . > > Maybe the submit repo is not working currently , not sure about it . > > Your submit job ran without failures, we were doing maintenance on the jdk- > submit repo yesterday and had turned off notifications. Sorry for the > inconvenience. > > Thanks, > Christian > > > > > > Best regards , Matthias > > > > > > > > > >> -----Original Message----- > >> From: Baesken, Matthias > >> Sent: Mittwoch, 11. April 2018 11:20 > >> To: 'Alexey Ivanov' ; Magnus Ihse Bursie > >> > >> Cc: build-dev ; Doerr, Martin > >> > >> Subject: RE: 8201226 missing JNIEXPORT / JNICALL at some places in > function > >> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at > >> some places in function declarations/implementations > >> > >>> > >>> Was main() exported via map files? > >>> > >> > >> Seems main was exported , I can find it in jdk10 in e.g. : > >> > >> make/mapfiles/launchers/mapfile-sparcv9 > >> make/mapfiles/launchers/mapfile-x86_64 > >> > >> > >> Best regards, Matthias > >> > >> > >>> -----Original Message----- > >>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] > >>> Sent: Mittwoch, 11. April 2018 11:11 > >>> To: Baesken, Matthias ; Magnus Ihse > Bursie > >>> > >>> Cc: build-dev ; Doerr, Martin > >>> > >>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in > >> function > >>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at > >>> some places in function declarations/implementations > >>> > >>> > >>> On 11/04/2018 08:44, Baesken, Matthias wrote: > >>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it? > >>>> Hi Alexey, yes that's true . > >>>> > >>>>> Please remove JNIEXPORT from main(): > >>>>> src/java.base/share/native/launcher/main.c > >>>>> src/jdk.pack/share/native/unpack200/main.cpp > >>>> I would prefer to keep it for now . > >>>> I notice some comments in our SAPJVM code base about needing > >>> JNIEXPORT for main for Solaris (we were running in SAPJVM without > >>> mapfiles in the past already). > >>>> Maybe that?s related to > >>>> > >>>> src/java.base/unix/native/libjli/java_md_solinux.c > >>>> > >>>> where main is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT, > "main"); > >>>> but I am not sure about this. > >>>> So I better keep the JNIEXPORT for the main functions, could be > >>> removed in another cleanup if really needed. > >>> > >>> OK. Let them stay then. > >>> Was main() exported via map files? > >>> > >>> > >>> The change looks good to me. > >>> > >>> Regards, > >>> Alexey > >>> > >>>> > >>>>> You can reference both yourself and me as > >>>>> Contributed-by: mbaesken, aivanov > >>>>> when pushing the changeset if you don't mind. > >>>>> > >>>> Sure . > >>>> > >>>> Best regards, Matthias > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] > >>>>> Sent: Dienstag, 10. April 2018 21:34 > >>>>> To: Baesken, Matthias ; Magnus Ihse > >>> Bursie > >>>>> > >>>>> Cc: build-dev ; Doerr, Martin > >>>>> > >>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in > >>> function > >>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL > >> at > >>>>> some places in function declarations/implementations > >>>>> > >>>>> Hi Matthias, > >>>>> > >>>>> On 10/04/2018 11:14, Baesken, Matthias wrote: > >>>>>> Hello, I had to do another small adjustment to make > jimage.hpp/cpp > >>> match. Please review : > >>>>>> > >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ > >>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it? > >>>>> > >>>>> I've successfully built 32 bit Windows with your patch. > >>>>> > >>>>> > >>>>> Please remove JNIEXPORT from main(): > >>>>> src/java.base/share/native/launcher/main.c > >>>>> src/jdk.pack/share/native/unpack200/main.cpp > >>>>> > >>>>>> With the latest webrev I could finally build jdk/jdk successfully on > both > >>> win32bit and win64 bit. > >>>>>> > >>>>>> Thanks again to Alexey to provide the incorporated patch . > >>>>> You can reference both yourself and me as > >>>>> Contributed-by: mbaesken, aivanov > >>>>> when pushing the changeset if you don't mind. > >>>>> > >>>>> > >>>>> Regards, > >>>>> Alexey > >>>>> > >>>>>> > >>>>>> Best regards, Matthias > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] > >>>>>>> Sent: Montag, 9. April 2018 17:14 > >>>>>>> To: Baesken, Matthias ; Magnus > Ihse > >>>>> Bursie > >>>>>>> > >>>>>>> Cc: build-dev ; Doerr, Martin > >>>>>>> > >>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in > >>>>> function > >>>>>>> declarations/implementations - was : RE: missing JNIEXPORT / > >> JNICALL > >>> at > >>>>>>> some places in function declarations/implementations > >>>>>>> > >>>>>>> Hi Matthias, > >>>>>>> > >>>>>>> On 09/04/2018 15:38, Baesken, Matthias wrote: > >>>>>>>> Hi Alexey, thanks for the diff provided by you, and for the > >>>>> explanations > >>>>>>> . > >>>>>>>> I created a second webrev : > >>>>>>>> > >>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/ > >>>>>>>> > >>>>>>>> - it adds the diff provided by you (hope that?s fine with you) > >>>>>>> Yes, that's fine with me. > >>>>>>> There could be only one author ;) > >>>>>>> > >>>>>>>> - changes 2 launchers > >> src/java.base/share/native/launcher/main.c > >>>>> and > >>>>>>> src/jdk.pack/share/native/unpack200/main.cpp where we face > >>> similar > >>>>>>> issues after mapfile removal for exes > >>>>>>> > >>>>>>> I'd rather remove both JNIEXPORT and JNICALL from main(). > >>>>>>> It wasn't exported, and it shouldn't be. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Alexey > >>>>>>> > >>>>>>>> Best regards , Matthias > > From christian.tornqvist at oracle.com Thu Apr 12 13:12:10 2018 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 12 Apr 2018 09:12:10 -0400 Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations In-Reply-To: <4007f78bf6c44e0e9a6b96671493b22c@sap.com> References: <9bae15f406ed4e029233415e6a8032b8@sap.com> <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com> <35e12d6d6eb24d88aadaf10e0229dd48@sap.com> <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com> <5146b9330edd44b483780587aca1757c@sap.com> <99420e261ef347578bb8099a48d6b7ec@sap.com> <5693830fbf6747d9a51e9cf374f63e18@sap.com> <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com> <3520f157a7d14a118a584fdeb226381e@sap.com> <4976D5AA-732B-4C95-B669-05E3DCD245C3@oracle.com> <4007f78bf6c44e0e9a6b96671493b22c@sap.com> Message-ID: > On Apr 12, 2018, at 9:07 48AM, Baesken, Matthias wrote: > >> Your submit job ran without failures, we were doing maintenance on the jdk- >> submit repo yesterday and had turned off notifications. Sorry for the >> inconvenience. > > Hi Christian , Thanks for the information about the submit job success. > > Is there a way to check (e.g. webpage) that a submit job has "arrived" and is queued for build/test ? Unfortunately that webpage is only available internally at this point, we could look into sending an email notification that the job has been started if that would help? Thanks, Christian > Would have been helpful in this situation . > > Best regards, Matthias > > >> -----Original Message----- >> From: Christian Tornqvist [mailto:christian.tornqvist at oracle.com] >> Sent: Donnerstag, 12. April 2018 14:58 >> To: Baesken, Matthias >> Cc: Alexey Ivanov ; Magnus Ihse Bursie >> ; build-dev > dev at openjdk.java.net>; Doerr, Martin >> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function >> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at >> some places in function declarations/implementations >> >> Hi Matthias, >> >> >>> On Apr 12, 2018, at 3:49 35AM, Baesken, Matthias >> wrote: >>> >>> Hi, could someone please sponsor the change now ? >>> >>> And could someone please check what happened to the submit-repo ? >>> Yesterday I pushed to the submit repo to check my change , but no >> response so far . >>> Maybe the submit repo is not working currently , not sure about it . >> >> Your submit job ran without failures, we were doing maintenance on the jdk- >> submit repo yesterday and had turned off notifications. Sorry for the >> inconvenience. >> >> Thanks, >> Christian >>> >>> >>> Best regards , Matthias >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Baesken, Matthias >>>> Sent: Mittwoch, 11. April 2018 11:20 >>>> To: 'Alexey Ivanov' ; Magnus Ihse Bursie >>>> >>>> Cc: build-dev ; Doerr, Martin >>>> >>>> Subject: RE: 8201226 missing JNIEXPORT / JNICALL at some places in >> function >>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at >>>> some places in function declarations/implementations >>>> >>>>> >>>>> Was main() exported via map files? >>>>> >>>> >>>> Seems main was exported , I can find it in jdk10 in e.g. : >>>> >>>> make/mapfiles/launchers/mapfile-sparcv9 >>>> make/mapfiles/launchers/mapfile-x86_64 >>>> >>>> >>>> Best regards, Matthias >>>> >>>> >>>>> -----Original Message----- >>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >>>>> Sent: Mittwoch, 11. April 2018 11:11 >>>>> To: Baesken, Matthias ; Magnus Ihse >> Bursie >>>>> >>>>> Cc: build-dev ; Doerr, Martin >>>>> >>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>>> function >>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at >>>>> some places in function declarations/implementations >>>>> >>>>> >>>>> On 11/04/2018 08:44, Baesken, Matthias wrote: >>>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it? >>>>>> Hi Alexey, yes that's true . >>>>>> >>>>>>> Please remove JNIEXPORT from main(): >>>>>>> src/java.base/share/native/launcher/main.c >>>>>>> src/jdk.pack/share/native/unpack200/main.cpp >>>>>> I would prefer to keep it for now . >>>>>> I notice some comments in our SAPJVM code base about needing >>>>> JNIEXPORT for main for Solaris (we were running in SAPJVM without >>>>> mapfiles in the past already). >>>>>> Maybe that?s related to >>>>>> >>>>>> src/java.base/unix/native/libjli/java_md_solinux.c >>>>>> >>>>>> where main is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT, >> "main"); >>>>>> but I am not sure about this. >>>>>> So I better keep the JNIEXPORT for the main functions, could be >>>>> removed in another cleanup if really needed. >>>>> >>>>> OK. Let them stay then. >>>>> Was main() exported via map files? >>>>> >>>>> >>>>> The change looks good to me. >>>>> >>>>> Regards, >>>>> Alexey >>>>> >>>>>> >>>>>>> You can reference both yourself and me as >>>>>>> Contributed-by: mbaesken, aivanov >>>>>>> when pushing the changeset if you don't mind. >>>>>>> >>>>>> Sure . >>>>>> >>>>>> Best regards, Matthias >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >>>>>>> Sent: Dienstag, 10. April 2018 21:34 >>>>>>> To: Baesken, Matthias ; Magnus Ihse >>>>> Bursie >>>>>>> >>>>>>> Cc: build-dev ; Doerr, Martin >>>>>>> >>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>>>> function >>>>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL >>>> at >>>>>>> some places in function declarations/implementations >>>>>>> >>>>>>> Hi Matthias, >>>>>>> >>>>>>> On 10/04/2018 11:14, Baesken, Matthias wrote: >>>>>>>> Hello, I had to do another small adjustment to make >> jimage.hpp/cpp >>>>> match. Please review : >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ >>>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it? >>>>>>> >>>>>>> I've successfully built 32 bit Windows with your patch. >>>>>>> >>>>>>> >>>>>>> Please remove JNIEXPORT from main(): >>>>>>> src/java.base/share/native/launcher/main.c >>>>>>> src/jdk.pack/share/native/unpack200/main.cpp >>>>>>> >>>>>>>> With the latest webrev I could finally build jdk/jdk successfully on >> both >>>>> win32bit and win64 bit. >>>>>>>> >>>>>>>> Thanks again to Alexey to provide the incorporated patch . >>>>>>> You can reference both yourself and me as >>>>>>> Contributed-by: mbaesken, aivanov >>>>>>> when pushing the changeset if you don't mind. >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Alexey >>>>>>> >>>>>>>> >>>>>>>> Best regards, Matthias >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >>>>>>>>> Sent: Montag, 9. April 2018 17:14 >>>>>>>>> To: Baesken, Matthias ; Magnus >> Ihse >>>>>>> Bursie >>>>>>>>> >>>>>>>>> Cc: build-dev ; Doerr, Martin >>>>>>>>> >>>>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>>>>>> function >>>>>>>>> declarations/implementations - was : RE: missing JNIEXPORT / >>>> JNICALL >>>>> at >>>>>>>>> some places in function declarations/implementations >>>>>>>>> >>>>>>>>> Hi Matthias, >>>>>>>>> >>>>>>>>> On 09/04/2018 15:38, Baesken, Matthias wrote: >>>>>>>>>> Hi Alexey, thanks for the diff provided by you, and for the >>>>>>> explanations >>>>>>>>> . >>>>>>>>>> I created a second webrev : >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/ >>>>>>>>>> >>>>>>>>>> - it adds the diff provided by you (hope that?s fine with you) >>>>>>>>> Yes, that's fine with me. >>>>>>>>> There could be only one author ;) >>>>>>>>> >>>>>>>>>> - changes 2 launchers >>>> src/java.base/share/native/launcher/main.c >>>>>>> and >>>>>>>>> src/jdk.pack/share/native/unpack200/main.cpp where we face >>>>> similar >>>>>>>>> issues after mapfile removal for exes >>>>>>>>> >>>>>>>>> I'd rather remove both JNIEXPORT and JNICALL from main(). >>>>>>>>> It wasn't exported, and it shouldn't be. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Alexey >>>>>>>>> >>>>>>>>>> Best regards , Matthias >>> > From roger.riggs at oracle.com Thu Apr 12 14:13:10 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 12 Apr 2018 10:13:10 -0400 Subject: RFR: 8184692: add Pattern.asMatchPredicate In-Reply-To: <6470b5b7-0c10-4d99-950e-4ca27a31fa83@default> References: <74681017-e7fe-47e8-89ef-d804c9e5e77b@default> <6AF1056A-D9AB-4C8C-9708-96CBCF40B2CB@oracle.com> <6e08e8d1-4052-40f9-ac30-514f3a83ef97@default> <3D98152E-5456-473B-9613-E0D5EDEBBC2C@oracle.com> <0710B763-B6B9-442F-AD6C-F77FE3824DFB@oracle.com> <6470b5b7-0c10-4d99-950e-4ca27a31fa83@default> Message-ID: Hi Vivek, ok, Generally, I like to see an updated webrev so that an old non-final webrev isn't left around to be a source of questions. Its easy enough to create a simple script to create the webrev and copy it to cr.openjdk... Continued javadoc @xxx lines should be indented to improve readability of the source. 5845 * against this pattern. Thanks, Roger On 4/12/18 8:49 AM, Vivek Theeyarath wrote: > Hi, > I have updated the doc as per the suggestion. Have finalized the csr too. > > Regards > Vivek > -----Original Message----- > From: Paul Sandoz > Sent: Thursday, April 12, 2018 12:40 AM > To: Vivek Theeyarath > Cc: Roger Riggs ; Core-Libs-Dev > Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate > > HI, > > Hopefully this is the last update :-) > > To align with asPredicate and Roger?s prior guidance on that method i think you can just say this: > > Creates a predicate that tests if this pattern matches a given input string. > > which is similar to the language of Pattern.matches. > > No need for another webrev if this change is acceptable. > > Paul. > >> On Apr 9, 2018, at 7:53 PM, Vivek Theeyarath wrote: >> >> Thanks Paul / Roger for the inputs. >> I have updated the javadoc based on the inputs. http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.03 . Please review. >> >> Regards >> Vivek >> -----Original Message----- >> From: Paul Sandoz >> Sent: Monday, April 09, 2018 9:25 PM >> To: Roger Riggs >> Cc: Core-Libs-Dev >> Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate >> >> >> >>> On Apr 9, 2018, at 8:41 AM, Roger Riggs wrote: >>> >>> Hi Vivek, >>> >>> As with Pattern.asPredicate the first sentence can be improved. >>> >>> Creates a predicate that tests if this pattern matches the entire region. >>> >> The region of what? region is clear from the context of a Matcher, but less so from the context of Pattern. >> >> Paul. >> >>> 5833: As with the original issue, perhaps adding the word 'whole' or >>> 'entire' will make it clearer that the pattern must match then entire input string. >>> >>> 5827: Split into two sentences, the second one starting "For example," >>> >>> 5840: add a blank line between methods >>> >>> Regards, Roger >>> >>> >>> On 4/9/18 5:05 AM, Vivek Theeyarath wrote: >>>> Hi, >>>> Please find the updated webrev after incorporating Paul's comments. >>>> http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.02/ >>>> >>>> Also, I have created a csr for this issue https://bugs.openjdk.java.net/browse/JDK-8201308 . >>>> >>>> Regards >>>> Vivek >>>> -----Original Message----- >>>> From: Paul Sandoz >>>> Sent: Friday, April 06, 2018 6:55 AM >>>> To: Vivek Theeyarath >>>> Cc: Core-Libs-Dev >>>> Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate >>>> >>>> >>>> >>>>> On Apr 4, 2018, at 10:47 AM, Vivek Theeyarath wrote: >>>>> >>>>> Hi All, >>>>> >>>>> Please review. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8184692 >>>>> >>>>> Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.00/ >>>>> >>>> Like with your other patch, alignment to ~80 chars would be good, as that is mostly consistent with other code in the same source file. >>>> >>>> Let?s not use the word ?find" here, so as not to confuse with matcher(s).find(). >>>> >>>> 5833 * @return The predicate which can be used for finding if an input string matches this pattern. >>>> >>>> I suggest: >>>> >>>> @return The predicate which can be used for matching an input >>>> string against this pattern >>>> >>>> You could also add a @see Matcher#matches >>>> >>>> Paul. >>>> >>>>> The related jtreg test was run and the test passed . >>>>> >>>>> >>>>> >>>>> Regards >>>>> >>>>> Vivek From iris.clark at oracle.com Thu Apr 12 15:54:21 2018 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 12 Apr 2018 08:54:21 -0700 (PDT) Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations In-Reply-To: References: <9bae15f406ed4e029233415e6a8032b8@sap.com> <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com> <35e12d6d6eb24d88aadaf10e0229dd48@sap.com> <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com> <5146b9330edd44b483780587aca1757c@sap.com> <99420e261ef347578bb8099a48d6b7ec@sap.com> <5693830fbf6747d9a51e9cf374f63e18@sap.com> <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com> <3520f157a7d14a118a584fdeb226381e@sap.com> <4976D5AA-732B-4C95-B669-05E3DCD245C3@oracle.com> <4007f78bf6c44e0e9a6b96671493b22c@sap.com> Message-ID: Hi. I believe that the internal page Christian references is for the test system. If you want to know whether the push arrived in the repository, you could subscribe to jdk-submit-changes at openjdk.java.net. The archive of recent push notifications is public: http://mail.openjdk.java.net/pipermail/jdk-submit-changes/2018-April/thread.html I wonder if the test system could be enhanced to send a brief notification when a job is queued? Thanks, Iris -----Original Message----- From: Christian Tornqvist Sent: Thursday, April 12, 2018 6:12 AM To: Baesken, Matthias Cc: core-libs-dev at openjdk.java.net; Alexey Ivanov ; Doerr, Martin ; build-dev Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations > On Apr 12, 2018, at 9:07 48AM, Baesken, Matthias wrote: > >> Your submit job ran without failures, we were doing maintenance on >> the jdk- submit repo yesterday and had turned off notifications. >> Sorry for the inconvenience. > > Hi Christian , Thanks for the information about the submit job success. > > Is there a way to check (e.g. webpage) that a submit job has "arrived" and is queued for build/test ? Unfortunately that webpage is only available internally at this point, we could look into sending an email notification that the job has been started if that would help? Thanks, Christian > Would have been helpful in this situation . > > Best regards, Matthias > > >> -----Original Message----- >> From: Christian Tornqvist [mailto:christian.tornqvist at oracle.com] >> Sent: Donnerstag, 12. April 2018 14:58 >> To: Baesken, Matthias >> Cc: Alexey Ivanov ; Magnus Ihse Bursie >> ; build-dev > dev at openjdk.java.net>; Doerr, Martin >> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >> function declarations/implementations - was : RE: missing JNIEXPORT / >> JNICALL at some places in function declarations/implementations >> >> Hi Matthias, >> >> >>> On Apr 12, 2018, at 3:49 35AM, Baesken, Matthias >> wrote: >>> >>> Hi, could someone please sponsor the change now ? >>> >>> And could someone please check what happened to the submit-repo ? >>> Yesterday I pushed to the submit repo to check my change , but no >> response so far . >>> Maybe the submit repo is not working currently , not sure about it . >> >> Your submit job ran without failures, we were doing maintenance on >> the jdk- submit repo yesterday and had turned off notifications. >> Sorry for the inconvenience. >> >> Thanks, >> Christian >>> >>> >>> Best regards , Matthias >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Baesken, Matthias >>>> Sent: Mittwoch, 11. April 2018 11:20 >>>> To: 'Alexey Ivanov' ; Magnus Ihse Bursie >>>> >>>> Cc: build-dev ; Doerr, Martin >>>> >>>> Subject: RE: 8201226 missing JNIEXPORT / JNICALL at some places in >> function >>>> declarations/implementations - was : RE: missing JNIEXPORT / >>>> JNICALL at some places in function declarations/implementations >>>> >>>>> >>>>> Was main() exported via map files? >>>>> >>>> >>>> Seems main was exported , I can find it in jdk10 in e.g. : >>>> >>>> make/mapfiles/launchers/mapfile-sparcv9 >>>> make/mapfiles/launchers/mapfile-x86_64 >>>> >>>> >>>> Best regards, Matthias >>>> >>>> >>>>> -----Original Message----- >>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >>>>> Sent: Mittwoch, 11. April 2018 11:11 >>>>> To: Baesken, Matthias ; Magnus Ihse >> Bursie >>>>> >>>>> Cc: build-dev ; Doerr, Martin >>>>> >>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>>> function >>>>> declarations/implementations - was : RE: missing JNIEXPORT / >>>>> JNICALL at some places in function declarations/implementations >>>>> >>>>> >>>>> On 11/04/2018 08:44, Baesken, Matthias wrote: >>>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it? >>>>>> Hi Alexey, yes that's true . >>>>>> >>>>>>> Please remove JNIEXPORT from main(): >>>>>>> src/java.base/share/native/launcher/main.c >>>>>>> src/jdk.pack/share/native/unpack200/main.cpp >>>>>> I would prefer to keep it for now . >>>>>> I notice some comments in our SAPJVM code base about needing >>>>> JNIEXPORT for main for Solaris (we were running in SAPJVM >>>>> without mapfiles in the past already). >>>>>> Maybe that?s related to >>>>>> >>>>>> src/java.base/unix/native/libjli/java_md_solinux.c >>>>>> >>>>>> where main is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT, >> "main"); >>>>>> but I am not sure about this. >>>>>> So I better keep the JNIEXPORT for the main functions, could be >>>>> removed in another cleanup if really needed. >>>>> >>>>> OK. Let them stay then. >>>>> Was main() exported via map files? >>>>> >>>>> >>>>> The change looks good to me. >>>>> >>>>> Regards, >>>>> Alexey >>>>> >>>>>> >>>>>>> You can reference both yourself and me as >>>>>>> Contributed-by: mbaesken, aivanov when pushing the changeset if >>>>>>> you don't mind. >>>>>>> >>>>>> Sure . >>>>>> >>>>>> Best regards, Matthias >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >>>>>>> Sent: Dienstag, 10. April 2018 21:34 >>>>>>> To: Baesken, Matthias ; Magnus Ihse >>>>> Bursie >>>>>>> >>>>>>> Cc: build-dev ; Doerr, Martin >>>>>>> >>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places >>>>>>> in >>>>> function >>>>>>> declarations/implementations - was : RE: missing JNIEXPORT / >>>>>>> JNICALL >>>> at >>>>>>> some places in function declarations/implementations >>>>>>> >>>>>>> Hi Matthias, >>>>>>> >>>>>>> On 10/04/2018 11:14, Baesken, Matthias wrote: >>>>>>>> Hello, I had to do another small adjustment to make >> jimage.hpp/cpp >>>>> match. Please review : >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ >>>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it? >>>>>>> >>>>>>> I've successfully built 32 bit Windows with your patch. >>>>>>> >>>>>>> >>>>>>> Please remove JNIEXPORT from main(): >>>>>>> src/java.base/share/native/launcher/main.c >>>>>>> src/jdk.pack/share/native/unpack200/main.cpp >>>>>>> >>>>>>>> With the latest webrev I could finally build jdk/jdk >>>>>>>> successfully on >> both >>>>> win32bit and win64 bit. >>>>>>>> >>>>>>>> Thanks again to Alexey to provide the incorporated patch . >>>>>>> You can reference both yourself and me as >>>>>>> Contributed-by: mbaesken, aivanov when pushing the changeset if >>>>>>> you don't mind. >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Alexey >>>>>>> >>>>>>>> >>>>>>>> Best regards, Matthias >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >>>>>>>>> Sent: Montag, 9. April 2018 17:14 >>>>>>>>> To: Baesken, Matthias ; Magnus >> Ihse >>>>>>> Bursie >>>>>>>>> >>>>>>>>> Cc: build-dev ; Doerr, Martin >>>>>>>>> >>>>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some >>>>>>>>> places in >>>>>>> function >>>>>>>>> declarations/implementations - was : RE: missing JNIEXPORT / >>>> JNICALL >>>>> at >>>>>>>>> some places in function declarations/implementations >>>>>>>>> >>>>>>>>> Hi Matthias, >>>>>>>>> >>>>>>>>> On 09/04/2018 15:38, Baesken, Matthias wrote: >>>>>>>>>> Hi Alexey, thanks for the diff provided by you, and for the >>>>>>> explanations >>>>>>>>> . >>>>>>>>>> I created a second webrev : >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/ >>>>>>>>>> >>>>>>>>>> - it adds the diff provided by you (hope that?s fine with you) >>>>>>>>> Yes, that's fine with me. >>>>>>>>> There could be only one author ;) >>>>>>>>> >>>>>>>>>> - changes 2 launchers >>>> src/java.base/share/native/launcher/main.c >>>>>>> and >>>>>>>>> src/jdk.pack/share/native/unpack200/main.cpp where we face >>>>> similar >>>>>>>>> issues after mapfile removal for exes >>>>>>>>> >>>>>>>>> I'd rather remove both JNIEXPORT and JNICALL from main(). >>>>>>>>> It wasn't exported, and it shouldn't be. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Alexey >>>>>>>>> >>>>>>>>>> Best regards , Matthias >>> > From paul.sandoz at oracle.com Thu Apr 12 16:28:15 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 12 Apr 2018 09:28:15 -0700 Subject: RFR: 8184692: add Pattern.asMatchPredicate In-Reply-To: <6470b5b7-0c10-4d99-950e-4ca27a31fa83@default> References: <74681017-e7fe-47e8-89ef-d804c9e5e77b@default> <6AF1056A-D9AB-4C8C-9708-96CBCF40B2CB@oracle.com> <6e08e8d1-4052-40f9-ac30-514f3a83ef97@default> <3D98152E-5456-473B-9613-E0D5EDEBBC2C@oracle.com> <0710B763-B6B9-442F-AD6C-F77FE3824DFB@oracle.com> <6470b5b7-0c10-4d99-950e-4ca27a31fa83@default> Message-ID: <3AF75E84-7018-4E1B-86A2-B86FD12E67A3@oracle.com> Ok, thanks. When the CSR is approved please directly send me an exported changeset and i will push for you. Paul. > On Apr 12, 2018, at 5:49 AM, Vivek Theeyarath wrote: > > Hi, > I have updated the doc as per the suggestion. Have finalized the csr too. > > Regards > Vivek > -----Original Message----- > From: Paul Sandoz > Sent: Thursday, April 12, 2018 12:40 AM > To: Vivek Theeyarath > Cc: Roger Riggs ; Core-Libs-Dev > Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate > > HI, > > Hopefully this is the last update :-) > > To align with asPredicate and Roger?s prior guidance on that method i think you can just say this: > > Creates a predicate that tests if this pattern matches a given input string. > > which is similar to the language of Pattern.matches. > > No need for another webrev if this change is acceptable. > > Paul. From christian.tornqvist at oracle.com Thu Apr 12 17:04:06 2018 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 12 Apr 2018 13:04:06 -0400 Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations In-Reply-To: References: <9bae15f406ed4e029233415e6a8032b8@sap.com> <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com> <35e12d6d6eb24d88aadaf10e0229dd48@sap.com> <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com> <5146b9330edd44b483780587aca1757c@sap.com> <99420e261ef347578bb8099a48d6b7ec@sap.com> <5693830fbf6747d9a51e9cf374f63e18@sap.com> <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com> <3520f157a7d14a118a584fdeb226381e@sap.com> <4976D5AA-732B-4C95-B669-05E3DCD245C3@oracle.com> <4007f78bf6c44e0e9a6b96671493b22c@sap.com> Message-ID: <4E4491FC-5E55-4880-A120-888356D15610@oracle.com> > On Apr 12, 2018, at 11:54 21AM, Iris Clark wrote: > > Hi. > > I believe that the internal page Christian references is for the test system. > > If you want to know whether the push arrived in the repository, you could subscribe to jdk-submit-changes at openjdk.java.net. The archive of recent push notifications is public: > > http://mail.openjdk.java.net/pipermail/jdk-submit-changes/2018-April/thread.html > > I wonder if the test system could be enhanced to send a brief notification when a job is queued? I?ve opened an enhancement for adding a notification once the job has been handed off to our build and test farm. Thanks, Christian > > Thanks, > Iris > > -----Original Message----- > From: Christian Tornqvist > Sent: Thursday, April 12, 2018 6:12 AM > To: Baesken, Matthias > Cc: core-libs-dev at openjdk.java.net; Alexey Ivanov ; Doerr, Martin ; build-dev > Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations > > > >> On Apr 12, 2018, at 9:07 48AM, Baesken, Matthias wrote: >> >>> Your submit job ran without failures, we were doing maintenance on >>> the jdk- submit repo yesterday and had turned off notifications. >>> Sorry for the inconvenience. >> >> Hi Christian , Thanks for the information about the submit job success. >> >> Is there a way to check (e.g. webpage) that a submit job has "arrived" and is queued for build/test ? > > Unfortunately that webpage is only available internally at this point, we could look into sending an email notification that the job has been started if that would help? > > Thanks, > Christian > >> Would have been helpful in this situation . >> >> Best regards, Matthias >> >> >>> -----Original Message----- >>> From: Christian Tornqvist [mailto:christian.tornqvist at oracle.com] >>> Sent: Donnerstag, 12. April 2018 14:58 >>> To: Baesken, Matthias >>> Cc: Alexey Ivanov ; Magnus Ihse Bursie >>> ; build-dev >> dev at openjdk.java.net>; Doerr, Martin >>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>> function declarations/implementations - was : RE: missing JNIEXPORT / >>> JNICALL at some places in function declarations/implementations >>> >>> Hi Matthias, >>> >>> >>>> On Apr 12, 2018, at 3:49 35AM, Baesken, Matthias >>> wrote: >>>> >>>> Hi, could someone please sponsor the change now ? >>>> >>>> And could someone please check what happened to the submit-repo ? >>>> Yesterday I pushed to the submit repo to check my change , but no >>> response so far . >>>> Maybe the submit repo is not working currently , not sure about it . >>> >>> Your submit job ran without failures, we were doing maintenance on >>> the jdk- submit repo yesterday and had turned off notifications. >>> Sorry for the inconvenience. >>> >>> Thanks, >>> Christian >>>> >>>> >>>> Best regards , Matthias >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Baesken, Matthias >>>>> Sent: Mittwoch, 11. April 2018 11:20 >>>>> To: 'Alexey Ivanov' ; Magnus Ihse Bursie >>>>> >>>>> Cc: build-dev ; Doerr, Martin >>>>> >>>>> Subject: RE: 8201226 missing JNIEXPORT / JNICALL at some places in >>> function >>>>> declarations/implementations - was : RE: missing JNIEXPORT / >>>>> JNICALL at some places in function declarations/implementations >>>>> >>>>>> >>>>>> Was main() exported via map files? >>>>>> >>>>> >>>>> Seems main was exported , I can find it in jdk10 in e.g. : >>>>> >>>>> make/mapfiles/launchers/mapfile-sparcv9 >>>>> make/mapfiles/launchers/mapfile-x86_64 >>>>> >>>>> >>>>> Best regards, Matthias >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >>>>>> Sent: Mittwoch, 11. April 2018 11:11 >>>>>> To: Baesken, Matthias ; Magnus Ihse >>> Bursie >>>>>> >>>>>> Cc: build-dev ; Doerr, Martin >>>>>> >>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>>>> function >>>>>> declarations/implementations - was : RE: missing JNIEXPORT / >>>>>> JNICALL at some places in function declarations/implementations >>>>>> >>>>>> >>>>>> On 11/04/2018 08:44, Baesken, Matthias wrote: >>>>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it? >>>>>>> Hi Alexey, yes that's true . >>>>>>> >>>>>>>> Please remove JNIEXPORT from main(): >>>>>>>> src/java.base/share/native/launcher/main.c >>>>>>>> src/jdk.pack/share/native/unpack200/main.cpp >>>>>>> I would prefer to keep it for now . >>>>>>> I notice some comments in our SAPJVM code base about needing >>>>>> JNIEXPORT for main for Solaris (we were running in SAPJVM >>>>>> without mapfiles in the past already). >>>>>>> Maybe that?s related to >>>>>>> >>>>>>> src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>> >>>>>>> where main is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT, >>> "main"); >>>>>>> but I am not sure about this. >>>>>>> So I better keep the JNIEXPORT for the main functions, could be >>>>>> removed in another cleanup if really needed. >>>>>> >>>>>> OK. Let them stay then. >>>>>> Was main() exported via map files? >>>>>> >>>>>> >>>>>> The change looks good to me. >>>>>> >>>>>> Regards, >>>>>> Alexey >>>>>> >>>>>>> >>>>>>>> You can reference both yourself and me as >>>>>>>> Contributed-by: mbaesken, aivanov when pushing the changeset if >>>>>>>> you don't mind. >>>>>>>> >>>>>>> Sure . >>>>>>> >>>>>>> Best regards, Matthias >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >>>>>>>> Sent: Dienstag, 10. April 2018 21:34 >>>>>>>> To: Baesken, Matthias ; Magnus Ihse >>>>>> Bursie >>>>>>>> >>>>>>>> Cc: build-dev ; Doerr, Martin >>>>>>>> >>>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places >>>>>>>> in >>>>>> function >>>>>>>> declarations/implementations - was : RE: missing JNIEXPORT / >>>>>>>> JNICALL >>>>> at >>>>>>>> some places in function declarations/implementations >>>>>>>> >>>>>>>> Hi Matthias, >>>>>>>> >>>>>>>> On 10/04/2018 11:14, Baesken, Matthias wrote: >>>>>>>>> Hello, I had to do another small adjustment to make >>> jimage.hpp/cpp >>>>>> match. Please review : >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ >>>>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it? >>>>>>>> >>>>>>>> I've successfully built 32 bit Windows with your patch. >>>>>>>> >>>>>>>> >>>>>>>> Please remove JNIEXPORT from main(): >>>>>>>> src/java.base/share/native/launcher/main.c >>>>>>>> src/jdk.pack/share/native/unpack200/main.cpp >>>>>>>> >>>>>>>>> With the latest webrev I could finally build jdk/jdk >>>>>>>>> successfully on >>> both >>>>>> win32bit and win64 bit. >>>>>>>>> >>>>>>>>> Thanks again to Alexey to provide the incorporated patch . >>>>>>>> You can reference both yourself and me as >>>>>>>> Contributed-by: mbaesken, aivanov when pushing the changeset if >>>>>>>> you don't mind. >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Alexey >>>>>>>> >>>>>>>>> >>>>>>>>> Best regards, Matthias >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >>>>>>>>>> Sent: Montag, 9. April 2018 17:14 >>>>>>>>>> To: Baesken, Matthias ; Magnus >>> Ihse >>>>>>>> Bursie >>>>>>>>>> >>>>>>>>>> Cc: build-dev ; Doerr, Martin >>>>>>>>>> >>>>>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some >>>>>>>>>> places in >>>>>>>> function >>>>>>>>>> declarations/implementations - was : RE: missing JNIEXPORT / >>>>> JNICALL >>>>>> at >>>>>>>>>> some places in function declarations/implementations >>>>>>>>>> >>>>>>>>>> Hi Matthias, >>>>>>>>>> >>>>>>>>>> On 09/04/2018 15:38, Baesken, Matthias wrote: >>>>>>>>>>> Hi Alexey, thanks for the diff provided by you, and for the >>>>>>>> explanations >>>>>>>>>> . >>>>>>>>>>> I created a second webrev : >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/ >>>>>>>>>>> >>>>>>>>>>> - it adds the diff provided by you (hope that?s fine with you) >>>>>>>>>> Yes, that's fine with me. >>>>>>>>>> There could be only one author ;) >>>>>>>>>> >>>>>>>>>>> - changes 2 launchers >>>>> src/java.base/share/native/launcher/main.c >>>>>>>> and >>>>>>>>>> src/jdk.pack/share/native/unpack200/main.cpp where we face >>>>>> similar >>>>>>>>>> issues after mapfile removal for exes >>>>>>>>>> >>>>>>>>>> I'd rather remove both JNIEXPORT and JNICALL from main(). >>>>>>>>>> It wasn't exported, and it shouldn't be. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Alexey >>>>>>>>>> >>>>>>>>>>> Best regards , Matthias >>>> >> > From shade at redhat.com Thu Apr 12 17:06:23 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 12 Apr 2018 19:06:23 +0200 Subject: RFR [10] 8194554: filterArguments runs multiple filters in the wrong order In-Reply-To: <3c7e1830-4419-318b-eff3-df56bfe68912@oracle.com> References: <3c7e1830-4419-318b-eff3-df56bfe68912@oracle.com> Message-ID: Thanks Mandy! I added the comments to the JBS issue, hoping that would be enough to get the backport moving. -Aleksey On 04/12/2018 12:24 PM, mandy chung wrote: > I was on vacation last week.? Paul - thanks for submitting CSR for JDK-8194554 for the resulting > behavioral change. > > This backport looks good to me. > > Thanks > Mandy > > On 4/5/18 11:33 PM, Aleksey Shipilev wrote: >> Hi, >> >> Please review this jdk10 backport. >> >> Original JDK 11 bug: >> https://bugs.openjdk.java.net/browse/JDK-8194554 >> >> Original JDK 11 fix: >> http://hg.openjdk.java.net/jdk/jdk/rev/050352ed64d5 >> >> Please note the discussion in JBS comments about the issue. It seems to include the more verbose >> specification text, and Rob says it makes the patch not directly backportable. Therefore, requesting >> to backport without the Javadoc change. I just dropped that single line from the original changeset: >> >> >> 8194554: filterArguments runs multiple filters in the wrong order >> Reviewed-by: psandoz, jrose >> >> diff -r b09e56145e11 -r ab2dc3096cdb src/java.base/share/classes/java/lang/invoke/MethodHandles.java >> --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Thu Mar 08 04:23:31 2018 +0000 >> +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Wed Jan 17 15:17:50 2018 -0800 >> @@ -3836,11 +3836,12 @@ >> MethodHandle filterArguments(MethodHandle target, int pos, MethodHandle... filters) { >> filterArgumentsCheckArity(target, pos, filters); >> MethodHandle adapter = target; >> - int curPos = pos-1; // pre-incremented >> - for (MethodHandle filter : filters) { >> - curPos += 1; >> + // process filters in reverse order so that the invocation of >> + // the resulting adapter will invoke the filters in left-to-right order >> + for (int i = filters.length - 1; i >= 0; --i) { >> + MethodHandle filter = filters[i]; >> if (filter == null) continue; // ignore null elements of filters >> - adapter = filterArgument(adapter, curPos, filter); >> + adapter = filterArgument(adapter, pos + i, filter); >> } >> return adapter; >> } >> diff -r b09e56145e11 -r ab2dc3096cdb test/jdk/java/lang/invoke/FilterArgumentsTest.java >> --- /dev/null Thu Jan 01 00:00:00 1970 +0000 >> +++ b/test/jdk/java/lang/invoke/FilterArgumentsTest.java Wed Jan 17 15:17:50 2018 -0800 >> @@ -0,0 +1,132 @@ >> +/* >> + * Copyright (c) 2018, 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. >> + * >> + * 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. >> + */ >> + >> +/* >> + * @test >> + * @bug 8194554 >> + * @run testng/othervm test.java.lang.invoke.FilterArgumentsTest >> + */ >> + >> +package test.java.lang.invoke; >> + >> +import java.lang.invoke.MethodHandle; >> +import java.lang.invoke.MethodHandles; >> +import java.util.ArrayList; >> +import java.util.List; >> + >> +import static java.lang.invoke.MethodHandles.*; >> +import static java.lang.invoke.MethodType.methodType; >> + >> +import org.testng.annotations.*; >> +import static org.testng.Assert.*; >> + >> +public class FilterArgumentsTest { >> + >> + @Test >> + public static void testFilterA_B_C() throws Throwable { >> + FilterTest test = new FilterTest( >> + filterArguments(MH_TEST, 0, MH_FILTER_A, MH_FILTER_B, MH_FILTER_C)); >> + test.run(List.of("A", "B", "C")); >> + } >> + >> + @Test >> + public static void testFilterA_B() throws Throwable { >> + FilterTest test = new FilterTest( >> + filterArguments(MH_TEST, 0, MH_FILTER_A, MH_FILTER_B)); >> + test.run(List.of("A", "B")); >> + } >> + >> + @Test >> + public static void testFilterB_C() throws Throwable { >> + FilterTest test = new FilterTest( >> + filterArguments(MH_TEST, 1, MH_FILTER_B, MH_FILTER_C)); >> + test.run(List.of("B", "C")); >> + } >> + >> + @Test >> + public static void testFilterB() throws Throwable { >> + FilterTest test = new FilterTest(filterArguments(MH_TEST, 1, MH_FILTER_B)); >> + test.run(List.of("B")); >> + } >> + >> + @Test >> + public static void testFilterC() throws Throwable { >> + FilterTest test = new FilterTest(filterArguments(MH_TEST, 2, MH_FILTER_C)); >> + test.run(List.of("C")); >> + } >> + >> + static class FilterTest { >> + static List filters = new ArrayList<>(); >> + >> + final MethodHandle mh; >> + FilterTest(MethodHandle mh) { >> + this.mh = mh; >> + } >> + >> + void run(List expected) throws Throwable { >> + filters.clear(); >> + assertEquals("x-0-z", (String)mh.invokeExact("x", 0, 'z')); >> + assertEquals(expected, filters); >> + } >> + >> + static String filterA(String s) { >> + filters.add("A"); >> + return s; >> + } >> + >> + static int filterB(int value) { >> + filters.add("B"); >> + return value; >> + } >> + >> + static char filterC(char c) { >> + filters.add("C"); >> + return c; >> + } >> + >> + static String test(String s, int i, char c) { >> + return s + "-" + i + "-" + c; >> + } >> + } >> + >> + static final MethodHandle MH_TEST; >> + static final MethodHandle MH_FILTER_A; >> + static final MethodHandle MH_FILTER_B; >> + static final MethodHandle MH_FILTER_C; >> + static final Lookup LOOKUP = MethodHandles.lookup(); >> + >> + static { >> + try { >> + MH_TEST = LOOKUP.findStatic(FilterTest.class, "test", >> + methodType(String.class, String.class, int.class, char.class)); >> + MH_FILTER_A = LOOKUP.findStatic(FilterTest.class, "filterA", >> + methodType(String.class, String.class)); >> + MH_FILTER_B = LOOKUP.findStatic(FilterTest.class, "filterB", >> + methodType(int.class, int.class)); >> + MH_FILTER_C = LOOKUP.findStatic(FilterTest.class, "filterC", >> + methodType(char.class, char.class)); >> + } catch (Exception e) { >> + throw new RuntimeException(e); >> + } >> + } >> +} >> >> >> Thanks, >> -Aleksey > From alexandr.miloslavskiy at gmail.com Thu Apr 12 17:38:32 2018 From: alexandr.miloslavskiy at gmail.com (Alexander Miloslavskiy) Date: Thu, 12 Apr 2018 20:38:32 +0300 Subject: 8194734 : Handle to jimage file inherited into child processes (win) In-Reply-To: References: <3efdeaaa-7cb7-15b7-05fe-7409997e44ba@gmail.com> Message-ID: I still need someone to get this patch applied. Please? At this moment, it seems that patch is validated: > Martin Buchholz > But regardless of that, we should try to set the CLOEXEC bit on all > our file descriptor > Alan Bateman > The update to osSupport_Windows.cpp looks okay. From paul.sandoz at oracle.com Thu Apr 12 17:43:36 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 12 Apr 2018 10:43:36 -0700 Subject: RFR [10] 8194554: filterArguments runs multiple filters in the wrong order In-Reply-To: References: <3c7e1830-4419-318b-eff3-df56bfe68912@oracle.com> Message-ID: <73BA92B0-69AA-4619-A445-1AAE7933A8E6@oracle.com> Hi Aleksey, Sorry to be the bearer of more bureaucratic news i just found out we require a CSR for 10 as well? which means you need to explicitly create a back port issue for 10 and hook the CSR for 10 to that (there may be some small consolation that the CSR for 11 can be mostly copied verbatim). Paul. > On Apr 12, 2018, at 10:06 AM, Aleksey Shipilev wrote: > > Thanks Mandy! > > I added the comments to the JBS issue, hoping that would be enough to get the backport moving. > > -Aleksey > > On 04/12/2018 12:24 PM, mandy chung wrote: >> I was on vacation last week. Paul - thanks for submitting CSR for JDK-8194554 for the resulting >> behavioral change. >> >> This backport looks good to me. >> >> Thanks >> Mandy >> >> On 4/5/18 11:33 PM, Aleksey Shipilev wrote: >>> Hi, >>> >>> Please review this jdk10 backport. >>> >>> Original JDK 11 bug: >>> https://bugs.openjdk.java.net/browse/JDK-8194554 >>> >>> Original JDK 11 fix: >>> http://hg.openjdk.java.net/jdk/jdk/rev/050352ed64d5 >>> >>> Please note the discussion in JBS comments about the issue. It seems to include the more verbose >>> specification text, and Rob says it makes the patch not directly backportable. Therefore, requesting >>> to backport without the Javadoc change. I just dropped that single line from the original changeset: >>> >>> >>> 8194554: filterArguments runs multiple filters in the wrong order >>> Reviewed-by: psandoz, jrose >>> >>> diff -r b09e56145e11 -r ab2dc3096cdb src/java.base/share/classes/java/lang/invoke/MethodHandles.java >>> --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Thu Mar 08 04:23:31 2018 +0000 >>> +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Wed Jan 17 15:17:50 2018 -0800 >>> @@ -3836,11 +3836,12 @@ >>> MethodHandle filterArguments(MethodHandle target, int pos, MethodHandle... filters) { >>> filterArgumentsCheckArity(target, pos, filters); >>> MethodHandle adapter = target; >>> - int curPos = pos-1; // pre-incremented >>> - for (MethodHandle filter : filters) { >>> - curPos += 1; >>> + // process filters in reverse order so that the invocation of >>> + // the resulting adapter will invoke the filters in left-to-right order >>> + for (int i = filters.length - 1; i >= 0; --i) { >>> + MethodHandle filter = filters[i]; >>> if (filter == null) continue; // ignore null elements of filters >>> - adapter = filterArgument(adapter, curPos, filter); >>> + adapter = filterArgument(adapter, pos + i, filter); >>> } >>> return adapter; >>> } >>> diff -r b09e56145e11 -r ab2dc3096cdb test/jdk/java/lang/invoke/FilterArgumentsTest.java >>> --- /dev/null Thu Jan 01 00:00:00 1970 +0000 >>> +++ b/test/jdk/java/lang/invoke/FilterArgumentsTest.java Wed Jan 17 15:17:50 2018 -0800 >>> @@ -0,0 +1,132 @@ >>> +/* >>> + * Copyright (c) 2018, 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. >>> + * >>> + * 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. >>> + */ >>> + >>> +/* >>> + * @test >>> + * @bug 8194554 >>> + * @run testng/othervm test.java.lang.invoke.FilterArgumentsTest >>> + */ >>> + >>> +package test.java.lang.invoke; >>> + >>> +import java.lang.invoke.MethodHandle; >>> +import java.lang.invoke.MethodHandles; >>> +import java.util.ArrayList; >>> +import java.util.List; >>> + >>> +import static java.lang.invoke.MethodHandles.*; >>> +import static java.lang.invoke.MethodType.methodType; >>> + >>> +import org.testng.annotations.*; >>> +import static org.testng.Assert.*; >>> + >>> +public class FilterArgumentsTest { >>> + >>> + @Test >>> + public static void testFilterA_B_C() throws Throwable { >>> + FilterTest test = new FilterTest( >>> + filterArguments(MH_TEST, 0, MH_FILTER_A, MH_FILTER_B, MH_FILTER_C)); >>> + test.run(List.of("A", "B", "C")); >>> + } >>> + >>> + @Test >>> + public static void testFilterA_B() throws Throwable { >>> + FilterTest test = new FilterTest( >>> + filterArguments(MH_TEST, 0, MH_FILTER_A, MH_FILTER_B)); >>> + test.run(List.of("A", "B")); >>> + } >>> + >>> + @Test >>> + public static void testFilterB_C() throws Throwable { >>> + FilterTest test = new FilterTest( >>> + filterArguments(MH_TEST, 1, MH_FILTER_B, MH_FILTER_C)); >>> + test.run(List.of("B", "C")); >>> + } >>> + >>> + @Test >>> + public static void testFilterB() throws Throwable { >>> + FilterTest test = new FilterTest(filterArguments(MH_TEST, 1, MH_FILTER_B)); >>> + test.run(List.of("B")); >>> + } >>> + >>> + @Test >>> + public static void testFilterC() throws Throwable { >>> + FilterTest test = new FilterTest(filterArguments(MH_TEST, 2, MH_FILTER_C)); >>> + test.run(List.of("C")); >>> + } >>> + >>> + static class FilterTest { >>> + static List filters = new ArrayList<>(); >>> + >>> + final MethodHandle mh; >>> + FilterTest(MethodHandle mh) { >>> + this.mh = mh; >>> + } >>> + >>> + void run(List expected) throws Throwable { >>> + filters.clear(); >>> + assertEquals("x-0-z", (String)mh.invokeExact("x", 0, 'z')); >>> + assertEquals(expected, filters); >>> + } >>> + >>> + static String filterA(String s) { >>> + filters.add("A"); >>> + return s; >>> + } >>> + >>> + static int filterB(int value) { >>> + filters.add("B"); >>> + return value; >>> + } >>> + >>> + static char filterC(char c) { >>> + filters.add("C"); >>> + return c; >>> + } >>> + >>> + static String test(String s, int i, char c) { >>> + return s + "-" + i + "-" + c; >>> + } >>> + } >>> + >>> + static final MethodHandle MH_TEST; >>> + static final MethodHandle MH_FILTER_A; >>> + static final MethodHandle MH_FILTER_B; >>> + static final MethodHandle MH_FILTER_C; >>> + static final Lookup LOOKUP = MethodHandles.lookup(); >>> + >>> + static { >>> + try { >>> + MH_TEST = LOOKUP.findStatic(FilterTest.class, "test", >>> + methodType(String.class, String.class, int.class, char.class)); >>> + MH_FILTER_A = LOOKUP.findStatic(FilterTest.class, "filterA", >>> + methodType(String.class, String.class)); >>> + MH_FILTER_B = LOOKUP.findStatic(FilterTest.class, "filterB", >>> + methodType(int.class, int.class)); >>> + MH_FILTER_C = LOOKUP.findStatic(FilterTest.class, "filterC", >>> + methodType(char.class, char.class)); >>> + } catch (Exception e) { >>> + throw new RuntimeException(e); >>> + } >>> + } >>> +} >>> >>> >>> Thanks, >>> -Aleksey >> > From shade at redhat.com Thu Apr 12 18:11:27 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 12 Apr 2018 20:11:27 +0200 Subject: RFR [10] 8194554: filterArguments runs multiple filters in the wrong order In-Reply-To: <73BA92B0-69AA-4619-A445-1AAE7933A8E6@oracle.com> References: <3c7e1830-4419-318b-eff3-df56bfe68912@oracle.com> <73BA92B0-69AA-4619-A445-1AAE7933A8E6@oracle.com> Message-ID: On 04/12/2018 07:43 PM, Paul Sandoz wrote: > Sorry to be the bearer of more bureaucratic news i just found out we require a CSR for 10 as > well? which means you need to explicitly create a back port issue for 10 and hook the CSR for 10 > to that (there may be some small consolation that the CSR for 11 can be mostly copied verbatim). So I created the backport: https://bugs.openjdk.java.net/browse/JDK-8201502 ...but I cannot create the CSR. "New Issue" -> "CSR" says "CSRs cannot be created manually, instead use the Create CSR operation on the Issue View page". But there is no "Create CSR" to be found anywhere. -Aleksey From joe.darcy at oracle.com Thu Apr 12 18:15:46 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 12 Apr 2018 11:15:46 -0700 Subject: RFR [10] 8194554: filterArguments runs multiple filters in the wrong order In-Reply-To: References: <3c7e1830-4419-318b-eff3-df56bfe68912@oracle.com> <73BA92B0-69AA-4619-A445-1AAE7933A8E6@oracle.com> Message-ID: <8c90befe-4d9a-b4bb-ab51-c4a313bf2520@oracle.com> On 4/12/2018 11:11 AM, Aleksey Shipilev wrote: > On 04/12/2018 07:43 PM, Paul Sandoz wrote: >> Sorry to be the bearer of more bureaucratic news i just found out we require a CSR for 10 as >> well? which means you need to explicitly create a back port issue for 10 and hook the CSR for 10 >> to that (there may be some small consolation that the CSR for 11 can be mostly copied verbatim). > So I created the backport: > https://bugs.openjdk.java.net/browse/JDK-8201502 > > ...but I cannot create the CSR. "New Issue" -> "CSR" says "CSRs cannot be created manually, instead > use the Create CSR operation on the Issue View page". But there is no "Create CSR" to be found anywhere. Hello, CSR hat on, that is the proper procedure, but a bug fix to allow the creation of CSRs for backport isn't in production yet. I'm checking with the JBS team. Sorry for the delay, -Joe From Alan.Bateman at oracle.com Thu Apr 12 18:15:47 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Apr 2018 19:15:47 +0100 Subject: 8194734 : Handle to jimage file inherited into child processes (win) In-Reply-To: References: <3efdeaaa-7cb7-15b7-05fe-7409997e44ba@gmail.com> Message-ID: On 12/04/2018 18:38, Alexander Miloslavskiy wrote: > I still need someone to get this patch applied. Please? > > At this moment, it seems that patch is validated: > > > Martin Buchholz > > But regardless of that, we should try to set the CLOEXEC bit on all > > our file descriptor > > > Alan Bateman > > The update to osSupport_Windows.cpp looks okay. > I'm happy to take the Windows change and get that in. I'm still puzzled by the Unix change. I completely agree with Martin about CLOSEXEC but there is something fishy here that we need to get a handle on. When we fork then we close >= 3 in the child so there shouldn't be any magic with fd 3. -Alan From bhamaram at in.ibm.com Thu Apr 12 18:17:55 2018 From: bhamaram at in.ibm.com (Bhaktavatsal R Maram) Date: Thu, 12 Apr 2018 18:17:55 +0000 Subject: Missing many locales support on AIX platform In-Reply-To: References: , Message-ID: Please review this patch for this issue. I have added IBM-943C as well to standard charset along with IBM-943. # HG changeset patch # User bhamaram # Date 1523510846 -19800 # Thu Apr 12 10:57:26 2018 +0530 # Node ID a76dd37b1c6b47e7ac99f279c4ba76832dd9736f # Parent 129d60b5dac71872f3317d94c724304100bc2048 java.lang.IllegalArgumentException from java -version on AIX with different locales diff -r 129d60b5dac7 -r a76dd37b1c6b make/data/charsetmapping/charsets --- a/make/data/charsetmapping/charsets Thu Apr 12 09:03:46 2018 -0400 +++ b/make/data/charsetmapping/charsets Thu Apr 12 10:57:26 2018 +0530 @@ -933,11 +933,16 @@ charset x-IBM942C IBM942C package sun.nio.cs.ext - type source + type template alias cp942C # JDK historical alias ibm942C alias ibm-942C alias 942C + alias cp932 + alias ibm932 + alias ibm-932 + alias 932 + alias x-ibm932 charset x-IBM943 IBM943 package sun.nio.cs.ext diff -r 129d60b5dac7 -r a76dd37b1c6b make/data/charsetmapping/stdcs-aix --- a/make/data/charsetmapping/stdcs-aix Thu Apr 12 09:03:46 2018 -0400 +++ b/make/data/charsetmapping/stdcs-aix Thu Apr 12 10:57:26 2018 +0530 @@ -1,6 +1,16 @@ # # generate these charsets into sun.nio.cs # +Big5 +Big5_HKSCS EUC_CN EUC_KR GBK +GB18030 +IBM942 +IBM942C +IBM943 +IBM950 +IBM970 +IBM1124 +TIS_620 diff -r 129d60b5dac7 -r a76dd37b1c6b src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java --- a/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java Thu Apr 12 09:03:46 2018 -0400 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,93 +0,0 @@ -/* - * Copyright (c) 2003, 2004, 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. - */ - -package sun.nio.cs.ext; - -import java.nio.charset.Charset; -import java.nio.charset.CharsetDecoder; -import java.nio.charset.CharsetEncoder; -import java.util.Arrays; -import sun.nio.cs.DoubleByte; -import sun.nio.cs.HistoricallyNamedCharset; -import static sun.nio.cs.CharsetMapping.*; - -public class IBM942C extends Charset implements HistoricallyNamedCharset -{ - public IBM942C() { - super("x-IBM942C", ExtendedCharsets.aliasesFor("x-IBM942C")); - } - - public String historicalName() { - return "Cp942C"; - } - - public boolean contains(Charset cs) { - return ((cs.name().equals("US-ASCII")) - || (cs instanceof IBM942C)); - } - - public CharsetDecoder newDecoder() { - return new DoubleByte.Decoder(this, - IBM942.b2c, - b2cSB, - 0x40, - 0xfc); - } - - public CharsetEncoder newEncoder() { - return new DoubleByte.Encoder(this, c2b, c2bIndex); - } - - final static char[] b2cSB; - final static char[] c2b; - final static char[] c2bIndex; - - static { - IBM942.initb2c(); - - // the mappings need udpate are - // u+001a <-> 0x1a - // u+001c <-> 0x1c - // u+005c <-> 0x5c - // u+007e <-> 0x7e - // u+007f <-> 0x7f - - b2cSB = Arrays.copyOf(IBM942.b2cSB, IBM942.b2cSB.length); - b2cSB[0x1a] = 0x1a; - b2cSB[0x1c] = 0x1c; - b2cSB[0x5c] = 0x5c; - b2cSB[0x7e] = 0x7e; - b2cSB[0x7f] = 0x7f; - - IBM942.initc2b(); - c2b = Arrays.copyOf(IBM942.c2b, IBM942.c2b.length); - c2bIndex = Arrays.copyOf(IBM942.c2bIndex, IBM942.c2bIndex.length); - c2b[c2bIndex[0] + 0x1a] = 0x1a; - c2b[c2bIndex[0] + 0x1c] = 0x1c; - c2b[c2bIndex[0] + 0x5c] = 0x5c; - c2b[c2bIndex[0] + 0x7e] = 0x7e; - c2b[c2bIndex[0] + 0x7f] = 0x7f; - } -} diff -r 129d60b5dac7 -r a76dd37b1c6b src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java.template --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java.template Thu Apr 12 10:57:26 2018 +0530 @@ -0,0 +1,93 @@ +/* + * Copyright (c) 2003, 2004, 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. + */ + +package $PACKAGE$; + +import java.nio.charset.Charset; +import java.nio.charset.CharsetDecoder; +import java.nio.charset.CharsetEncoder; +import java.util.Arrays; +import sun.nio.cs.DoubleByte; +import sun.nio.cs.HistoricallyNamedCharset; +import static sun.nio.cs.CharsetMapping.*; + +public class IBM942C extends Charset implements HistoricallyNamedCharset +{ + public IBM942C() { + super("x-IBM942C", $ALIASES$); + } + + public String historicalName() { + return "Cp942C"; + } + + public boolean contains(Charset cs) { + return ((cs.name().equals("US-ASCII")) + || (cs instanceof IBM942C)); + } + + public CharsetDecoder newDecoder() { + return new DoubleByte.Decoder(this, + IBM942.b2c, + b2cSB, + 0x40, + 0xfc); + } + + public CharsetEncoder newEncoder() { + return new DoubleByte.Encoder(this, c2b, c2bIndex); + } + + final static char[] b2cSB; + final static char[] c2b; + final static char[] c2bIndex; + + static { + IBM942.initb2c(); + + // the mappings need udpate are + // u+001a <-> 0x1a + // u+001c <-> 0x1c + // u+005c <-> 0x5c + // u+007e <-> 0x7e + // u+007f <-> 0x7f + + b2cSB = Arrays.copyOf(IBM942.b2cSB, IBM942.b2cSB.length); + b2cSB[0x1a] = 0x1a; + b2cSB[0x1c] = 0x1c; + b2cSB[0x5c] = 0x5c; + b2cSB[0x7e] = 0x7e; + b2cSB[0x7f] = 0x7f; + + IBM942.initc2b(); + c2b = Arrays.copyOf(IBM942.c2b, IBM942.c2b.length); + c2bIndex = Arrays.copyOf(IBM942.c2bIndex, IBM942.c2bIndex.length); + c2b[c2bIndex[0] + 0x1a] = 0x1a; + c2b[c2bIndex[0] + 0x1c] = 0x1c; + c2b[c2bIndex[0] + 0x5c] = 0x5c; + c2b[c2bIndex[0] + 0x7e] = 0x7e; + c2b[c2bIndex[0] + 0x7f] = 0x7f; + } +} # HG changeset patch # User bhamaram # Date 1523555765 -19800 # Thu Apr 12 23:26:05 2018 +0530 # Node ID 99542925f31823e5f337a0890499c2647b803629 # Parent a76dd37b1c6b47e7ac99f279c4ba76832dd9736f include IBM-943C to standard charset diff -r a76dd37b1c6b -r 99542925f318 make/data/charsetmapping/charsets --- a/make/data/charsetmapping/charsets Thu Apr 12 10:57:26 2018 +0530 +++ b/make/data/charsetmapping/charsets Thu Apr 12 23:26:05 2018 +0530 @@ -957,7 +957,7 @@ charset x-IBM943C IBM943C package sun.nio.cs.ext - type source + type template alias cp943C # JDK historical alias ibm943C alias ibm-943C diff -r a76dd37b1c6b -r 99542925f318 make/data/charsetmapping/stdcs-aix --- a/make/data/charsetmapping/stdcs-aix Thu Apr 12 10:57:26 2018 +0530 +++ b/make/data/charsetmapping/stdcs-aix Thu Apr 12 23:26:05 2018 +0530 @@ -2,6 +2,7 @@ # generate these charsets into sun.nio.cs # Big5 +Big5_Solaris Big5_HKSCS EUC_CN EUC_KR @@ -10,6 +11,7 @@ IBM942 IBM942C IBM943 +IBM943C IBM950 IBM970 IBM1124 diff -r a76dd37b1c6b -r 99542925f318 src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM943C.java --- a/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM943C.java Thu Apr 12 10:57:26 2018 +0530 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,85 +0,0 @@ -/* - * Copyright (c) 2003, 2004, 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. - */ - -package sun.nio.cs.ext; - -import java.nio.charset.Charset; -import java.nio.charset.CharsetDecoder; -import java.nio.charset.CharsetEncoder; -import java.util.Arrays; -import sun.nio.cs.DoubleByte; -import sun.nio.cs.HistoricallyNamedCharset; - -public class IBM943C extends Charset implements HistoricallyNamedCharset -{ - - public IBM943C() { - super("x-IBM943C", ExtendedCharsets.aliasesFor("x-IBM943C")); - } - - public String historicalName() { - return "Cp943C"; - } - - public boolean contains(Charset cs) { - return ((cs.name().equals("US-ASCII")) - || (cs instanceof IBM943C)); - } - - public CharsetDecoder newDecoder() { - return new DoubleByte.Decoder(this, - IBM943.b2c, - b2cSB, - 0x40, - 0xfc); - } - - public CharsetEncoder newEncoder() { - return new DoubleByte.Encoder(this, c2b, c2bIndex); - } - - final static char[] b2cSB; - final static char[] c2b; - final static char[] c2bIndex; - - static { - IBM943.initb2c(); - b2cSB = new char[0x100]; - for (int i = 0; i < 0x80; i++) { - b2cSB[i] = (char)i; - } - for (int i = 0x80; i < 0x100; i++) { - b2cSB[i] = IBM943.b2cSB[i]; - } - - IBM943.initc2b(); - c2b = Arrays.copyOf(IBM943.c2b, IBM943.c2b.length); - c2bIndex = Arrays.copyOf(IBM943.c2bIndex, IBM943.c2bIndex.length); - for (char c = '\0'; c < '\u0080'; ++c) { - int index = c2bIndex[c >> 8]; - c2b[index + (c & 0xff)] = c; - } - } -} diff -r a76dd37b1c6b -r 99542925f318 src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM943C.java.template --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM943C.java.template Thu Apr 12 23:26:05 2018 +0530 @@ -0,0 +1,85 @@ +/* + * Copyright (c) 2003, 2004, 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. + */ + +package $PACKAGE$; + +import java.nio.charset.Charset; +import java.nio.charset.CharsetDecoder; +import java.nio.charset.CharsetEncoder; +import java.util.Arrays; +import sun.nio.cs.DoubleByte; +import sun.nio.cs.HistoricallyNamedCharset; + +public class IBM943C extends Charset implements HistoricallyNamedCharset +{ + + public IBM943C() { + super("x-IBM943C", $ALIASES$); + } + + public String historicalName() { + return "Cp943C"; + } + + public boolean contains(Charset cs) { + return ((cs.name().equals("US-ASCII")) + || (cs instanceof IBM943C)); + } + + public CharsetDecoder newDecoder() { + return new DoubleByte.Decoder(this, + IBM943.b2c, + b2cSB, + 0x40, + 0xfc); + } + + public CharsetEncoder newEncoder() { + return new DoubleByte.Encoder(this, c2b, c2bIndex); + } + + final static char[] b2cSB; + final static char[] c2b; + final static char[] c2bIndex; + + static { + IBM943.initb2c(); + b2cSB = new char[0x100]; + for (int i = 0; i < 0x80; i++) { + b2cSB[i] = (char)i; + } + for (int i = 0x80; i < 0x100; i++) { + b2cSB[i] = IBM943.b2cSB[i]; + } + + IBM943.initc2b(); + c2b = Arrays.copyOf(IBM943.c2b, IBM943.c2b.length); + c2bIndex = Arrays.copyOf(IBM943.c2bIndex, IBM943.c2bIndex.length); + for (char c = '\0'; c < '\u0080'; ++c) { + int index = c2bIndex[c >> 8]; + c2b[index + (c & 0xff)] = c; + } + } +} Thanks, Bhaktavatsal Reddy -----"core-libs-dev" wrote: ----- To: core-libs-dev at openjdk.java.net From: "Bhaktavatsal R Maram" Sent by: "core-libs-dev" Date: 04/12/2018 03:16PM Subject: Re: Missing many locales support on AIX platform Patch I attached to previous mail is not seen. So, pasting patch here. Hope, it is fine. # HG changeset patch # User bhamaram # Date 1523510846 -19800 # Node ID 6134bbe9861111f8cc42b055081f2c48e91039a8 # Parent 0c3e252cea44f06aef570ef464950ab97c669970 java.lang.IllegalArgumentException from java -version on AIX with different locales diff -r 0c3e252cea44 -r 6134bbe98611 make/data/charsetmapping/charsets --- a/make/data/charsetmapping/charsets Thu Apr 12 10:19:31 2018 +0800 +++ b/make/data/charsetmapping/charsets Thu Apr 12 10:57:26 2018 +0530 @@ -933,11 +933,16 @@ charset x-IBM942C IBM942C package sun.nio.cs.ext - type source + type template alias cp942C # JDK historical alias ibm942C alias ibm-942C alias 942C + alias cp932 + alias ibm932 + alias ibm-932 + alias 932 + alias x-ibm932 charset x-IBM943 IBM943 package sun.nio.cs.ext diff -r 0c3e252cea44 -r 6134bbe98611 make/data/charsetmapping/stdcs-aix --- a/make/data/charsetmapping/stdcs-aix Thu Apr 12 10:19:31 2018 +0800 +++ b/make/data/charsetmapping/stdcs-aix Thu Apr 12 10:57:26 2018 +0530 @@ -1,6 +1,16 @@ # # generate these charsets into sun.nio.cs # +Big5 +Big5_HKSCS EUC_CN EUC_KR GBK +GB18030 +IBM942 +IBM942C +IBM943 +IBM950 +IBM970 +IBM1124 +TIS_620 diff -r 0c3e252cea44 -r 6134bbe98611 src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java --- a/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java Thu Apr 12 10:19:31 2018 +0800 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,93 +0,0 @@ -/* - * Copyright (c) 2003, 2004, 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. - */ - -package sun.nio.cs.ext; - -import java.nio.charset.Charset; -import java.nio.charset.CharsetDecoder; -import java.nio.charset.CharsetEncoder; -import java.util.Arrays; -import sun.nio.cs.DoubleByte; -import sun.nio.cs.HistoricallyNamedCharset; -import static sun.nio.cs.CharsetMapping.*; - -public class IBM942C extends Charset implements HistoricallyNamedCharset -{ - public IBM942C() { - super("x-IBM942C", ExtendedCharsets.aliasesFor("x-IBM942C")); - } - - public String historicalName() { - return "Cp942C"; - } - - public boolean contains(Charset cs) { - return ((cs.name().equals("US-ASCII")) - || (cs instanceof IBM942C)); - } - - public CharsetDecoder newDecoder() { - return new DoubleByte.Decoder(this, - IBM942.b2c, - b2cSB, - 0x40, - 0xfc); - } - - public CharsetEncoder newEncoder() { - return new DoubleByte.Encoder(this, c2b, c2bIndex); - } - - final static char[] b2cSB; - final static char[] c2b; - final static char[] c2bIndex; - - static { - IBM942.initb2c(); - - // the mappings need udpate are - // u+001a <-> 0x1a - // u+001c <-> 0x1c - // u+005c <-> 0x5c - // u+007e <-> 0x7e - // u+007f <-> 0x7f - - b2cSB = Arrays.copyOf(IBM942.b2cSB, IBM942.b2cSB.length); - b2cSB[0x1a] = 0x1a; - b2cSB[0x1c] = 0x1c; - b2cSB[0x5c] = 0x5c; - b2cSB[0x7e] = 0x7e; - b2cSB[0x7f] = 0x7f; - - IBM942.initc2b(); - c2b = Arrays.copyOf(IBM942.c2b, IBM942.c2b.length); - c2bIndex = Arrays.copyOf(IBM942.c2bIndex, IBM942.c2bIndex.length); - c2b[c2bIndex[0] + 0x1a] = 0x1a; - c2b[c2bIndex[0] + 0x1c] = 0x1c; - c2b[c2bIndex[0] + 0x5c] = 0x5c; - c2b[c2bIndex[0] + 0x7e] = 0x7e; - c2b[c2bIndex[0] + 0x7f] = 0x7f; - } -} diff -r 0c3e252cea44 -r 6134bbe98611 src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java.template --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java.template Thu Apr 12 10:57:26 2018 +0530 @@ -0,0 +1,93 @@ +/* + * Copyright (c) 2003, 2004, 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. + */ + +package $PACKAGE$; + +import java.nio.charset.Charset; +import java.nio.charset.CharsetDecoder; +import java.nio.charset.CharsetEncoder; +import java.util.Arrays; +import sun.nio.cs.DoubleByte; +import sun.nio.cs.HistoricallyNamedCharset; +import static sun.nio.cs.CharsetMapping.*; + +public class IBM942C extends Charset implements HistoricallyNamedCharset +{ + public IBM942C() { + super("x-IBM942C", $ALIASES$); + } + + public String historicalName() { + return "Cp942C"; + } + + public boolean contains(Charset cs) { + return ((cs.name().equals("US-ASCII")) + || (cs instanceof IBM942C)); + } + + public CharsetDecoder newDecoder() { + return new DoubleByte.Decoder(this, + IBM942.b2c, + b2cSB, + 0x40, + 0xfc); + } + + public CharsetEncoder newEncoder() { + return new DoubleByte.Encoder(this, c2b, c2bIndex); + } + + final static char[] b2cSB; + final static char[] c2b; + final static char[] c2bIndex; + + static { + IBM942.initb2c(); + + // the mappings need udpate are + // u+001a <-> 0x1a + // u+001c <-> 0x1c + // u+005c <-> 0x5c + // u+007e <-> 0x7e + // u+007f <-> 0x7f + + b2cSB = Arrays.copyOf(IBM942.b2cSB, IBM942.b2cSB.length); + b2cSB[0x1a] = 0x1a; + b2cSB[0x1c] = 0x1c; + b2cSB[0x5c] = 0x5c; + b2cSB[0x7e] = 0x7e; + b2cSB[0x7f] = 0x7f; + + IBM942.initc2b(); + c2b = Arrays.copyOf(IBM942.c2b, IBM942.c2b.length); + c2bIndex = Arrays.copyOf(IBM942.c2bIndex, IBM942.c2bIndex.length); + c2b[c2bIndex[0] + 0x1a] = 0x1a; + c2b[c2bIndex[0] + 0x1c] = 0x1c; + c2b[c2bIndex[0] + 0x5c] = 0x5c; + c2b[c2bIndex[0] + 0x7e] = 0x7e; + c2b[c2bIndex[0] + 0x7f] = 0x7f; + } +} Thanks, Bhaktavatsal Reddy -----"core-libs-dev" wrote: ----- To: core-libs-dev at openjdk.java.net From: "Bhaktavatsal R Maram" Sent by: "core-libs-dev" Date: 04/12/2018 03:12PM Subject: Missing many locales support on AIX platform Hi, On AIX platforms, Java is not starting on many locales. Java initialization fails with java.lang.IllegalArgumentException bash-4.4$ LANG=Ja_JP java -version Error occurred during initialization of VM java.lang.IllegalArgumentException: Null charset name at java.nio.charset.Charset.lookup(java.base/Charset.java:455) at java.nio.charset.Charset.defaultCharset(java.base/Charset.java:608) at java.lang.StringCoding.decode(java.base/StringCoding.java:314) at java.lang.String.(java.base/String.java:591) at java.lang.String.(java.base/String.java:613) at java.lang.System.initProperties(java.base/Native Method) at java.lang.System.initPhase1(java.base/System.java:1908) >From our analysis, following are locales that are impacted with this issue. Ar_AA.IBM-1046 ar_AA.ISO8859-6 ca_ES.IBM-1252 at euro Iw_IL.IBM-856 iw_IL.ISO8859-8 Et_EE.IBM-922 at euro Ja_JP.IBM-932 Ja_JP.IBM-943 ja_JP.IBM-eucJP ko_KR.IBM-eucKR Lt_LT.IBM-921 at euro th_TH.TIS-620 Uk_UA.IBM-1124 Vi_VN.IBM-1129 Zh_CN.GB18030 zh_CN.IBM-eucCN Zh_HK.BIG5-HKSCS Zh_TW.big5 The default charset for these locales are not available in the java.base module and hence java cannot be used with those locales. In the current fix, am fixing the issue for following locales. Ja_JP.IBM-932 Ja_JP.IBM-943 ko_KR.IBM-eucKR th_TH.TIS-620 Uk_UA.IBM-1124 Zh_CN.GB18030 Zh_HK.BIG5-HKSCS Zh_TW.big5 I've attached fix with this mail. I will continue working on other locales and provide the fix. In the mean time, I kindly request you to open a bug and review the fix for the above locales. Thanks, Bhaktavatsal Reddy From alexandr.miloslavskiy at gmail.com Thu Apr 12 18:23:14 2018 From: alexandr.miloslavskiy at gmail.com (Alexander Miloslavskiy) Date: Thu, 12 Apr 2018 21:23:14 +0300 Subject: 8194734 : Handle to jimage file inherited into child processes (win) In-Reply-To: References: <3efdeaaa-7cb7-15b7-05fe-7409997e44ba@gmail.com> Message-ID: Please get Windows change applied. I'm mostly interested in this part, because bug is currently hidden on Unix. > I'm still puzzled by the Unix change. I completely agree with Martin > about CLOSEXEC but there is something fishy here that we need to get a > handle on. When we fork then we close >= 3 in the child so there > shouldn't be any magic with fd 3. From joe.darcy at oracle.com Thu Apr 12 18:23:12 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 12 Apr 2018 11:23:12 -0700 Subject: RFR [10] 8194554: filterArguments runs multiple filters in the wrong order In-Reply-To: <8c90befe-4d9a-b4bb-ab51-c4a313bf2520@oracle.com> References: <3c7e1830-4419-318b-eff3-df56bfe68912@oracle.com> <73BA92B0-69AA-4619-A445-1AAE7933A8E6@oracle.com> <8c90befe-4d9a-b4bb-ab51-c4a313bf2520@oracle.com> Message-ID: I've manually created a CSR for this issue and linked it in to the backport; HTH, -Joe On 4/12/2018 11:15 AM, joe darcy wrote: > On 4/12/2018 11:11 AM, Aleksey Shipilev wrote: >> On 04/12/2018 07:43 PM, Paul Sandoz wrote: >>> Sorry to be the bearer of more bureaucratic news i just found out we >>> require a CSR for 10 as >>> well? which means you need to explicitly create a back port issue >>> for 10 and hook the CSR for 10 >>> to that (there may be some small consolation that the CSR for 11 can >>> be mostly copied verbatim). >> So I created the backport: >> ?? https://bugs.openjdk.java.net/browse/JDK-8201502 >> >> ...but I cannot create the CSR. "New Issue" -> "CSR" says "CSRs >> cannot be created manually, instead >> use the Create CSR operation on the Issue View page". But there is no >> "Create CSR" to be found anywhere. > > Hello, > > CSR hat on, that is the proper procedure, but a bug fix to allow the > creation of CSRs for backport isn't in production yet. I'm checking > with the JBS team. > > Sorry for the delay, > > -Joe From shade at redhat.com Thu Apr 12 18:25:45 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 12 Apr 2018 20:25:45 +0200 Subject: RFR [10] 8194554: filterArguments runs multiple filters in the wrong order In-Reply-To: References: <3c7e1830-4419-318b-eff3-df56bfe68912@oracle.com> <73BA92B0-69AA-4619-A445-1AAE7933A8E6@oracle.com> <8c90befe-4d9a-b4bb-ab51-c4a313bf2520@oracle.com> Message-ID: <89664658-be21-2acf-b538-96fb85090f6b@redhat.com> On 04/12/2018 08:23 PM, joe darcy wrote: > I've manually created a CSR for this issue and linked it in to the backport; HTH, Thank you Joe! -Aleksey From alexandr.miloslavskiy at gmail.com Thu Apr 12 18:29:06 2018 From: alexandr.miloslavskiy at gmail.com (Alexander Miloslavskiy) Date: Thu, 12 Apr 2018 21:29:06 +0300 Subject: 8194734 : Handle to jimage file inherited into child processes (win) In-Reply-To: References: <3efdeaaa-7cb7-15b7-05fe-7409997e44ba@gmail.com> Message-ID: <218a902b-6512-fa45-082d-ac690c879852@gmail.com> > I'm still puzzled by the Unix change. I completely agree with Martin > about CLOSEXEC but there is something fishy here that we need to get a > handle on. When we fork then we close >= 3 in the child so there > shouldn't be any magic with fd 3. The current code closes >= 4. FD 3 is a special one that is intended to be error pipe back to parent. But after jimage was implemented, FD 3 is occupied by it instead. As far as I understand it, there's no need for hardcoded FD numbers at all. I can remove all magic from this code if someone promises me he'll get the patch applied (after review, of course!) Aside from removing magic from code, the future patch will also fix communicating errors back to parent, because with current code it obviously can't work. From xueming.shen at oracle.com Thu Apr 12 18:43:39 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 12 Apr 2018 11:43:39 -0700 Subject: RFR: JDK-8201443: NoSuchMethodException JarFile.open when jar file is used in classpath Message-ID: <5ACFA8DB.20306@oracle.com> Hi, Please help review the change for JDK-8201443 issue: https://bugs.openjdk.java.net/browse/JDK-8201443 webrev: http://cr.openjdk.java.net/~sherman/8201443/webrev (1) To use SharedSecret/JavaLangAccess/Class.getDeclaredPublicMethods to avoid NoSuchMethodExcetpion throwing. (2) Given the fact that our JarFile does not override ZipFile.close(), to add the fast check for JarFile to avoid unnecessary class/method check. (3) No new regression test provided. To use the existing unit tests for regression test. Manually verified the provided test/scenario is passed. Thanks, Sherman From Roger.Riggs at Oracle.com Thu Apr 12 19:25:24 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 12 Apr 2018 15:25:24 -0400 Subject: RFR: JDK-8201443: NoSuchMethodException JarFile.open when jar file is used in classpath In-Reply-To: <5ACFA8DB.20306@oracle.com> References: <5ACFA8DB.20306@oracle.com> Message-ID: Looks good,? Thanks Sherman On 4/12/2018 2:43 PM, Xueming Shen wrote: > Hi, > > Please help review the change for JDK-8201443 > > issue: https://bugs.openjdk.java.net/browse/JDK-8201443 > webrev: http://cr.openjdk.java.net/~sherman/8201443/webrev > > (1) To use SharedSecret/JavaLangAccess/Class.getDeclaredPublicMethods > to avoid > ???? NoSuchMethodExcetpion throwing. > (2) Given the fact that our JarFile does not override ZipFile.close(), > to add the fast > ???? check for JarFile to avoid unnecessary class/method check. > (3) No new regression test provided. To use the existing unit tests > for regression test. > ???? Manually verified the provided test/scenario is passed. > > Thanks, > Sherman > From claes.redestad at oracle.com Thu Apr 12 19:35:33 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 12 Apr 2018 21:35:33 +0200 Subject: RFR: JDK-8201443: NoSuchMethodException JarFile.open when jar file is used in classpath In-Reply-To: References: <5ACFA8DB.20306@oracle.com> Message-ID: +1 /Claes On 2018-04-12 21:25, Roger Riggs wrote: > Looks good,? Thanks Sherman > > On 4/12/2018 2:43 PM, Xueming Shen wrote: >> Hi, >> >> Please help review the change for JDK-8201443 >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8201443 >> webrev: http://cr.openjdk.java.net/~sherman/8201443/webrev >> >> (1) To use SharedSecret/JavaLangAccess/Class.getDeclaredPublicMethods >> to avoid >> ???? NoSuchMethodExcetpion throwing. >> (2) Given the fact that our JarFile does not override >> ZipFile.close(), to add the fast >> ???? check for JarFile to avoid unnecessary class/method check. >> (3) No new regression test provided. To use the existing unit tests >> for regression test. >> ???? Manually verified the provided test/scenario is passed. >> >> Thanks, >> Sherman >> > From Roger.Riggs at Oracle.com Thu Apr 12 19:41:05 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 12 Apr 2018 15:41:05 -0400 Subject: RFR of JDK-8078221, TEST_BUG: java/rmi/Naming/DefaultRegistryPort.java fails intermittently In-Reply-To: <1f13aa5c-58b8-de19-5add-1e38db3ce419@oracle.com> References: <1f13aa5c-58b8-de19-5add-1e38db3ce419@oracle.com> Message-ID: <0f6b716b-7ed0-cda0-03e9-685b43fd5187@Oracle.com> Hi Hamlin, Looks ok. Please improve the exception message at line 76: to make it clear that the retries were exhausted and not some other cause or exception. Thanks, Roger On 4/11/2018 10:47 PM, Hamlin Li wrote: > would you please review the following patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8078221 > > webrev: http://cr.openjdk.java.net/~mli/8078221/webrev.00/ > > > Thank you > > -Hamlin > From jonathan.gibbons at oracle.com Thu Apr 12 20:15:24 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 12 Apr 2018 13:15:24 -0700 Subject: RFR: 8201274: Launch Single-File Source-Code Programs Message-ID: <5ACFBE5C.1080508@oracle.com> Please review an initial implementation for the feature described in JEP 330: Launch Single-File Source-Code Programs. The work is described in the JEP and CSR, and falls into various parts: * The part to handle the new command-line options is in the native Java launcher code. * The part to invoke the compiler and subsequently execute the code found in the source file is in a new class in the jdk.compiler module. * There are some minor Makefile changes, to add support for a new resource file. There are no changes to javac itself. JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ -- Jon From magnus.ihse.bursie at oracle.com Thu Apr 12 20:17:03 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 Apr 2018 22:17:03 +0200 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5ACFBE5C.1080508@oracle.com> References: <5ACFBE5C.1080508@oracle.com> Message-ID: On 2018-04-12 22:15, Jonathan Gibbons wrote: > Please review an initial implementation for the feature described in > JEP 330: Launch Single-File Source-Code Programs. > > The work is described in the JEP and CSR, and falls into various parts: > > ?* The part to handle the new command-line options is in the native > ?? Java launcher code. > ?* The part to invoke the compiler and subsequently execute the code > ?? found in the source file is in a new class in the jdk.compiler module. > ?* There are some minor Makefile changes, to add support for a new > ?? resource file. > > There are no changes to javac itself. > > JEP: http://openjdk.java.net/jeps/330 > JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 > CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 > Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ Build changes look trivially fine. /Magnus > > -- Jon From philip.race at oracle.com Thu Apr 12 20:42:59 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 12 Apr 2018 13:42:59 -0700 Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations In-Reply-To: <7c5e68c2a023490e96ce6452fbda1700@sap.com> References: <9bae15f406ed4e029233415e6a8032b8@sap.com> <81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com> <7c5e68c2a023490e96ce6452fbda1700@sap.com> Message-ID: How can JNIEXPORT be different between 32 bit & 64 bit ? I'm sure you saw compilation errors but I don't get why it failed for 32 only. JNICALL (_stdcall) may be unnecessary on 64 bit Windows but that doesn't explain why the 32 bit compiler would complain about inconsistent application of __declspec(dllexport) - ie JNIEXPORT. Or is that part (adding JNIEXPORT) pure clean up and the compilation errors were all down to JNICALL ? I was a bit puzzled at the removals I saw here : http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h.udiff.html .. I needed to look at the whole file to realise that you were removing a duplicate declaration. -phil. On 04/12/2018 04:04 AM, Baesken, Matthias wrote: > Hi Alan , this is the up to date webrev . > However we want to add Alexey Ivanov as additional author . > >> As I read it, this changes the calling convention of these functions on >> 32-bit Windows but it will have no impact on 64-bit Windows (as >> __stdcall is ignored) or other platforms, is that correct? >> > The change adds JNIEXPORT at some places where it is ben forgotten , for example : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp.c.udiff.html > > This might have potential impact on other platforms (fixes the mismatches) . > > Best regards, Matthias > > > > >> -----Original Message----- >> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >> Sent: Donnerstag, 12. April 2018 12:54 >> To: Baesken, Matthias ; Magnus Ihse Bursie >> >> Cc: build-dev at openjdk.java.net; Doerr, Martin ; >> core-libs-dev at openjdk.java.net >> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function >> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at >> some places in function declarations/implementations >> >> Adding core-libs-dev as this is change code in libjava, libzip, >> libjimage, ... >> >> Can you confirm that this is the up to date webrev: >> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ >> >> As I read it, this changes the calling convention of these functions on >> 32-bit Windows but it will have no impact on 64-bit Windows (as >> __stdcall is ignored) or other platforms, is that correct? >> >> -Alan >> >> >> On 06/04/2018 14:20, Baesken, Matthias wrote: >>> Hello, I just noticed 2 additonal issues regarding mapfile-removal : >>> >>> >>> 1. The follow up change that removed mapfiles for exes as well >> leads on Win32 bit to this link error : >>> Creating library >> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and object >> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp >>> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main >> referenced in function ___tmainCRTStartup >>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe : >> fatal error LNK1120: 1 unresolved externals >>> >>> Looks like we cannot have JNICALL in main.c : >>> >>> diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c >>> --- a/src/java.base/share/native/launcher/main.c Thu Apr 05 14:39:04 >> 2018 -0700 >>> +++ b/src/java.base/share/native/launcher/main.c Fri Apr 06 15:16:40 >> 2018 +0200 >>> @@ -93,7 +93,7 @@ >>> __initenv = _environ; >>> >>> #else /* JAVAW */ >>> -JNIEXPORT int JNICALL >>> +JNIEXPORT int >>> main(int argc, char **argv) >>> { >>> int margc; >>> >>> >>> >>> 1. Zip-library has runtime issues when symbols are resolved in >> src/hotspot/share/classfile/classLoader.cpp. >>> I added the declaration of the missing symbol, this seems to fix it . >>> >>> >>> diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h >>> --- a/src/java.base/share/native/libzip/zip_util.h Thu Apr 05 14:39:04 >> 2018 -0700 >>> +++ b/src/java.base/share/native/libzip/zip_util.h Fri Apr 06 15:16:40 >> 2018 +0200 >>> @@ -284,4 +284,7 @@ >>> JNIEXPORT jboolean JNICALL >>> ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen, char >> **pmsg); >>> +JNIEXPORT jint JNICALL >>> +ZIP_CRC32(jint crc, const jbyte *buf, jint len); >>> + >>> >>> >>> Should I prepare another bug, or add this to the existing one and post a >> second webrev ? >>> Best regards, Matthias >>> >>> >>> From: Baesken, Matthias >>> Sent: Freitag, 6. April 2018 09:54 >>> To: 'Magnus Ihse Bursie' >>> Cc: build-dev at openjdk.java.net; Doerr, Martin >>> Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in >> function declarations/implementations - was : RE: missing JNIEXPORT / >> JNICALL at some places in function declarations/implementations >>> Hello, please review : >>> >>> Bug : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>> >>> change : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/ >>> >>> mostly I added JNIEXPORT / JNICALL at some places where the win32bit >> build missed it . >>> A difference is >> src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h >>> Where I removed a few declarations (one decl with one without >> JNIEXPORT / JNICALL ? looked a bit strange ) . >>> Best regards , Matthias >>> >>> >>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] >>> Sent: Donnerstag, 5. April 2018 17:45 >>> To: Baesken, Matthias >> > >>> Cc: build-dev at openjdk.java.net; >> Doerr, Martin > >>> Subject: Re: missing JNIEXPORT / JNICALL at some places in function >> declarations/implementations >>> That's most likely a result of the new JNIEXPORT I added as part of the >> mapfile removal. >>> I tried to match header file and C file, but I can certainly have missed cases. >> If I didn't get any warnings, it was hard to know what I missed. >>> Please do submit your patch. >>> >>> I'm a bit surprised 32-bit Window is still buildable. :) >>> >>> /Magnus >>> >>> 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias >> >: >>> Hello, we noticed that at a number of places in the coding , the >> JNIEXPORT and/or JNICALL modifiers do not match when one compares >> the declaration and >>> The implementation of functions. >>> While this is ok on most platforms, it seems to fail on Windows 32 bit and >> leads to errors like this one : >>> >> e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/ml >> ib_ImageConvKernelConvert.c(87) : error C2373: >> 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type modifiers >> e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\ml >> ib_image_proto.h(2630) : see declaration of >> 'j2d_mlib_ImageConvKernelConvert' >>> (there are quite a few of these e.g. in mlib / splashscreen etc.) >>> >>> >>> Another example is this one : >>> >>> diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp >>> --- a/src/java.base/share/native/libjimage/jimage.hpp Thu Apr 05 09:55:16 >> 2018 +0200 >>> +++ b/src/java.base/share/native/libjimage/jimage.hpp Thu Apr 05 >> 17:07:40 2018 +0200 >>> @@ -126,7 +126,7 @@ >>> * JImageLocationRef location = (*JImageFindResource)(image, >>> * "java.base", "9.0", "java/lang/String.class", &size); >>> */ >>> -extern "C" JNIEXPORT JImageLocationRef >> JIMAGE_FindResource(JImageFile* jimage, >>> +extern "C" JNIEXPORT JImageLocationRef JNICALL >> JIMAGE_FindResource(JImageFile* jimage, >>> const char* module_name, const char* version, const char* name, >>> jlong* size); >>> >>> >>> Is there some generic way to get the same declarations / impementations >> in the code ? >>> Or should I just add a patch with my findings ? >>> >>> Best regards, Matthias >>> From maurizio.cimadamore at oracle.com Thu Apr 12 20:46:54 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 12 Apr 2018 21:46:54 +0100 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5ACFBE5C.1080508@oracle.com> References: <5ACFBE5C.1080508@oracle.com> Message-ID: Looks great - some initial comments (I can't really comment on the launcher changes): * This logic is efficient: int magic = (in.read() << 8) + in.read(); boolean shebang = magic == (('#' << 8) + '!'); but convoluted to read; perhaps could be improved slightly by making '#' << 8) + '!' a static constant, and comparing against that. * I note that the reading logic in general could be simplified, e.g. using Files.lines(Path) - but I assume that you wrote the code as is for performance reasons (e.g. to avoid creating too many string objects) ? * I see that both the file manager and the class loader reasonably share the same context: a Map. I would make this more explicit, by having a Context class, whose state is the map, and then have the context provide two methods: getClassLoader() getFileManager() This way the sharing will be automatic, no need to extract one field from one place and pass it over to the other place. * Big whohoo for being able to use the enhanced diagnostic framework with a couple of tweaks on the makefile - I hope that would have been the case when I put in the support, but since we have never done it - wasn't 100% sure it would work ;-) Overall I like it quite a lot and I think you went for a really clean design - kudos! Maurizio On 12/04/18 21:15, Jonathan Gibbons wrote: > Please review an initial implementation for the feature described in > JEP 330: Launch Single-File Source-Code Programs. > > The work is described in the JEP and CSR, and falls into various parts: > > * The part to handle the new command-line options is in the native > Java launcher code. > * The part to invoke the compiler and subsequently execute the code > found in the source file is in a new class in the jdk.compiler module. > * There are some minor Makefile changes, to add support for a new > resource file. > > There are no changes to javac itself. > > JEP: http://openjdk.java.net/jeps/330 > JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 > CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 > Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ > > -- Jon From alexey.ivanov at oracle.com Thu Apr 12 21:53:10 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 12 Apr 2018 22:53:10 +0100 Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations In-Reply-To: References: <9bae15f406ed4e029233415e6a8032b8@sap.com> <81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com> <7c5e68c2a023490e96ce6452fbda1700@sap.com> Message-ID: <9fff2e7e-06ac-54c1-8f66-33bff34ea621@oracle.com> On 12/04/2018 21:42, Phil Race wrote: > How can JNIEXPORT be different between 32 bit & 64 bit ? > I'm sure you saw compilation errors but I don't get why it failed for > 32 only. > > JNICALL (_stdcall) may be unnecessary on 64 bit Windows but that doesn't > explain why the 32 bit compiler would complain about inconsistent > application > of __declspec(dllexport) - ie JNIEXPORT. > > Or is that part (adding JNIEXPORT) pure clean up and the compilation > errors were all down to JNICALL ? Adding missing JNIEXPORT is for cleanup only. The compiler complained about mismatched JNICALL / non-JNICALL declarations as the macro changes calling convention from the default __cdecl? to __stdcall on 32 bit Windows. Another issue is that __stdcall decorates the functions: prefixes with underscore and postfixes with @ + size of parameters. Because of the decorations, classLoader.cpp can't lookup the required functions by name from zip.dll and jimage.dll. The functions are exported but with different name. I hope this information adds more details to the picture. > I was a bit puzzled at the removals I saw here : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h.udiff.html > > > .. I needed to look at the whole file to realise that you were > removing a duplicate > declaration. That was tricky. I could have been mentioned in the review. Regards, Alexey > > -phil. > > On 04/12/2018 04:04 AM, Baesken, Matthias wrote: >> Hi? Alan , this is the up to date webrev . >> However we want to add?? Alexey?? Ivanov? as additional? author . >> >>> As I read it, this changes the calling convention of these functions on >>> 32-bit Windows but it will have no impact on 64-bit Windows (as >>> __stdcall is ignored) or other platforms, is that correct? >>> >> The? change adds? JNIEXPORT?? at some places? where it is? ben >> forgotten , for example : >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp.c.udiff.html >> >> >> This might have? potential? impact? on other platforms?? (fixes the >> mismatches) . >> >> Best regards, Matthias >> >> >> >> >>> -----Original Message----- >>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >>> Sent: Donnerstag, 12. April 2018 12:54 >>> To: Baesken, Matthias ; Magnus Ihse Bursie >>> >>> Cc: build-dev at openjdk.java.net; Doerr, Martin ; >>> core-libs-dev at openjdk.java.net >>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>> function >>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at >>> some places in function declarations/implementations >>> >>> Adding core-libs-dev as this is change code in libjava, libzip, >>> libjimage, ... >>> >>> Can you confirm that this is the up to date webrev: >>> ???? http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ >>> >>> As I read it, this changes the calling convention of these functions on >>> 32-bit Windows but it will have no impact on 64-bit Windows (as >>> __stdcall is ignored) or other platforms, is that correct? >>> >>> -Alan >>> >>> >>> On 06/04/2018 14:20, Baesken, Matthias wrote: >>>> Hello, I just noticed? 2? additonal issues? regarding >>>> mapfile-removal : >>>> >>>> >>>> ??? 1.? The?? follow up change? that removed?? mapfiles for exes? >>>> as well >>> leads on Win32 bit? to? this link error : >>>> ??? Creating library >>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and >>> object >>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp >>>> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main >>> referenced in function ___tmainCRTStartup >>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe : >>> fatal error LNK1120: 1 unresolved externals >>>> >>>> Looks like we? cannot have?? JNICALL?? in main.c?? : >>>> >>>> diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c >>>> --- a/src/java.base/share/native/launcher/main.c??????? Thu Apr 05 >>>> 14:39:04 >>> 2018 -0700 >>>> +++ b/src/java.base/share/native/launcher/main.c??????? Fri Apr 06 >>>> 15:16:40 >>> 2018 +0200 >>>> @@ -93,7 +93,7 @@ >>>> ?????? __initenv = _environ; >>>> >>>> #else /* JAVAW */ >>>> -JNIEXPORT int JNICALL >>>> +JNIEXPORT int >>>> main(int argc, char **argv) >>>> { >>>> ?????? int margc; >>>> >>>> >>>> >>>> ??? 1.? Zip-library? has runtime issues?? when? symbols? are >>>> resolved? in >>> src/hotspot/share/classfile/classLoader.cpp. >>>> I added? the declaration of the missing symbol, this seems to fix it . >>>> >>>> >>>> diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h >>>> --- a/src/java.base/share/native/libzip/zip_util.h????? Thu Apr 05 >>>> 14:39:04 >>> 2018 -0700 >>>> +++ b/src/java.base/share/native/libzip/zip_util.h????? Fri Apr 06 >>>> 15:16:40 >>> 2018 +0200 >>>> @@ -284,4 +284,7 @@ >>>> JNIEXPORT jboolean JNICALL >>>> ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong >>>> outLen, char >>> **pmsg); >>>> +JNIEXPORT jint JNICALL >>>> +ZIP_CRC32(jint crc, const jbyte *buf, jint len); >>>> + >>>> >>>> >>>> Should I? prepare? another? bug,? or? add this to the existing one >>>> and??? post a >>> second webrev ? >>>> Best regards, Matthias >>>> >>>> >>>> From: Baesken, Matthias >>>> Sent: Freitag, 6. April 2018 09:54 >>>> To: 'Magnus Ihse Bursie' >>>> Cc: build-dev at openjdk.java.net; Doerr, Martin >>>> Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in >>> function declarations/implementations - was : RE: missing JNIEXPORT / >>> JNICALL at some places in function declarations/implementations >>>> Hello, please review : >>>> >>>> Bug : >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>>> >>>> change : >>>> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/ >>>> >>>> mostly I added? JNIEXPORT / JNICALL at some places? where the win32bit >>> build missed it . >>>> A difference is >>> src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h >>>> Where I removed?? a few? declarations (one? decl?? with one without >>> JNIEXPORT / JNICALL ? looked a bit strange ) . >>>> Best regards , Matthias >>>> >>>> >>>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] >>>> Sent: Donnerstag, 5. April 2018 17:45 >>>> To: Baesken, Matthias >>> > >>>> Cc: build-dev at openjdk.java.net; >>> Doerr, Martin > >>>> Subject: Re: missing JNIEXPORT / JNICALL at some places in function >>> declarations/implementations >>>> That's most likely a result of the new JNIEXPORT I added as part of >>>> the >>> mapfile removal. >>>> I tried to match header file and C file, but I can certainly have >>>> missed cases. >>> If I didn't get any warnings, it was hard to know what I missed. >>>> Please do submit your patch. >>>> >>>> I'm a bit surprised 32-bit Window is still buildable. :) >>>> >>>> /Magnus >>>> >>>> 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias >>> >: >>>> Hello, we noticed? that? at a number of places in the coding? ,?? the >>> JNIEXPORT and/or?? JNICALL modifiers?? do not match? when one compares >>> the declaration and >>>> The implementation of functions. >>>> While this is ok on most platforms, it seems to fail on Windows 32 >>>> bit and >>> leads to errors like this one : >>>> >>> e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/ml >>> >>> ib_ImageConvKernelConvert.c(87) : error C2373: >>> 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type >>> modifiers >>> e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\ml >>> >>> ib_image_proto.h(2630) : see declaration of >>> 'j2d_mlib_ImageConvKernelConvert' >>>> (there are quite a few of these e.g. in mlib? / splashscreen etc.) >>>> >>>> >>>> Another example is this one : >>>> >>>> diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp >>>> --- a/src/java.base/share/native/libjimage/jimage.hpp? Thu Apr 05 >>>> 09:55:16 >>> 2018 +0200 >>>> +++ b/src/java.base/share/native/libjimage/jimage.hpp Thu Apr 05 >>> 17:07:40 2018 +0200 >>>> @@ -126,7 +126,7 @@ >>>> ??? *?? JImageLocationRef location = (*JImageFindResource)(image, >>>> ??? *??????????????????????????????? "java.base", "9.0", >>>> "java/lang/String.class", &size); >>>> ??? */ >>>> -extern "C" JNIEXPORT JImageLocationRef >>> JIMAGE_FindResource(JImageFile* jimage, >>>> +extern "C" JNIEXPORT JImageLocationRef JNICALL >>> JIMAGE_FindResource(JImageFile* jimage, >>>> ?????????? const char* module_name, const char* version, const >>>> char* name, >>>> ?????????? jlong* size); >>>> >>>> >>>> Is there some generic way to get? the? same? declarations / >>>> impementations >>> in the code? ? >>>> Or should I just add a patch with my findings ? >>>> >>>> Best regards, Matthias >>>> > From naoto.sato at oracle.com Fri Apr 13 00:34:18 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 12 Apr 2018 17:34:18 -0700 Subject: [11] RFR: 8201507: Generate alias entries in j.t.f.ZoneName from tzdb at build time Message-ID: Hi, Please review the fix to the subject issue. While fixing 8189784 [1], I noticed that not only CLDR zones but also tzdb link entries are also hard coded. So I further modified j.t.f.ZoneName to generate tzdb entries at the build time. The issue: https://bugs.openjdk.java.net/browse/JDK-8201507 Fix: http://cr.openjdk.java.net/~naoto/8201507/webrev.00/ Like the last time, including build-dev for makefile modification review. Naoto [1] http://mail.openjdk.java.net/pipermail/i18n-dev/2018-April/002492.html From huaming.li at oracle.com Fri Apr 13 01:04:38 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 13 Apr 2018 09:04:38 +0800 Subject: RFR of JDK-8078221, TEST_BUG: java/rmi/Naming/DefaultRegistryPort.java fails intermittently In-Reply-To: <0f6b716b-7ed0-cda0-03e9-685b43fd5187@Oracle.com> References: <1f13aa5c-58b8-de19-5add-1e38db3ce419@oracle.com> <0f6b716b-7ed0-cda0-03e9-685b43fd5187@Oracle.com> Message-ID: Hi Roger, Thank you for reviewing, will push the code after improve the exception message. -Hamlin On 13/04/2018 3:41 AM, Roger Riggs wrote: > Hi Hamlin, > > Looks ok. > > Please improve the exception message at line 76: to make it clear that > the retries were > exhausted and not some other cause or exception. > > Thanks, Roger > > > On 4/11/2018 10:47 PM, Hamlin Li wrote: >> would you please review the following patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8078221 >> >> webrev: http://cr.openjdk.java.net/~mli/8078221/webrev.00/ >> >> >> Thank you >> >> -Hamlin >> > From vivek.theeyarath at oracle.com Fri Apr 13 01:25:16 2018 From: vivek.theeyarath at oracle.com (Vivek Theeyarath) Date: Thu, 12 Apr 2018 18:25:16 -0700 (PDT) Subject: RFR: 8184692: add Pattern.asMatchPredicate In-Reply-To: References: <74681017-e7fe-47e8-89ef-d804c9e5e77b@default> <6AF1056A-D9AB-4C8C-9708-96CBCF40B2CB@oracle.com> <6e08e8d1-4052-40f9-ac30-514f3a83ef97@default> <3D98152E-5456-473B-9613-E0D5EDEBBC2C@oracle.com> <0710B763-B6B9-442F-AD6C-F77FE3824DFB@oracle.com> <6470b5b7-0c10-4d99-950e-4ca27a31fa83@default> Message-ID: <34ba5981-b313-4473-bcc3-cfa4db25904b@default> Hi Roger, ?????????????? Please find the updated webrev http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.04/ . I fixed the indentation with my earlier fix (asPredicate) too. Hope that is fine. ? Regards Vivek From: Roger Riggs Sent: Thursday, April 12, 2018 7:43 PM To: Vivek Theeyarath Cc: Core-Libs-Dev Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate ? Hi Vivek, ok,? Generally, I like to see an updated webrev so that an old non-final webrev isn't left around to be a source of questions. Its easy enough to create a simple script to create the webrev and copy it to cr.openjdk... Continued javadoc @xxx lines should be indented to improve readability of the source. 5845????? *?????????? against this pattern. Thanks, Roger On 4/12/18 8:49 AM, Vivek Theeyarath wrote: Hi, ? I have updated the doc as per the suggestion. Have finalized the csr too. ? Regards Vivek -----Original Message----- From: Paul Sandoz Sent: Thursday, April 12, 2018 12:40 AM To: Vivek Theeyarath HYPERLINK "mailto:vivek.theeyarath at oracle.com" Cc: Roger Riggs HYPERLINK "mailto:roger.riggs at oracle.com"; Core-Libs-Dev HYPERLINK "mailto:core-libs-dev at openjdk.java.net" Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate ? HI, ? Hopefully this is the last update :-) ? To align with asPredicate and Roger?s prior guidance on that method i think you can just say this: ? ? Creates a predicate that tests if this pattern matches a given input string. ? which is similar to the language of Pattern.matches. ? No need for another webrev if this change is acceptable. ? Paul. ? On Apr 9, 2018, at 7:53 PM, Vivek Theeyarath HYPERLINK "mailto:vivek.theeyarath at oracle.com" wrote: ? Thanks Paul / Roger for the inputs. I have updated the javadoc based on the inputs. http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.03 . Please review. ? Regards Vivek -----Original Message----- From: Paul Sandoz Sent: Monday, April 09, 2018 9:25 PM To: Roger Riggs HYPERLINK "mailto:roger.riggs at oracle.com" Cc: Core-Libs-Dev HYPERLINK "mailto:core-libs-dev at openjdk.java.net" Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate ? ? ? On Apr 9, 2018, at 8:41 AM, Roger Riggs HYPERLINK "mailto:Roger.Riggs at Oracle.com" wrote: ? Hi Vivek, ? As with Pattern.asPredicate the first sentence can be improved. ? Creates a predicate that tests if this pattern matches the entire region. ? ? The region of what? region is clear from the context of a Matcher, but less so from the context of Pattern. ? Paul. ? 5833: As with the original issue, perhaps adding the word 'whole' or 'entire' will make it clearer that the pattern must match then entire input string. ? ? 5827:? Split into two sentences, the second one starting? "For example," ? 5840: add a blank line between methods ? Regards, Roger ? ? On 4/9/18 5:05 AM, Vivek Theeyarath wrote: Hi, ?????? Please find the updated webrev after incorporating Paul's comments. http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.02/ ? Also, I have created a csr for this issue https://bugs.openjdk.java.net/browse/JDK-8201308 . ? Regards Vivek -----Original Message----- From: Paul Sandoz Sent: Friday, April 06, 2018 6:55 AM To: Vivek Theeyarath HYPERLINK "mailto:vivek.theeyarath at oracle.com" Cc: Core-Libs-Dev HYPERLINK "mailto:core-libs-dev at openjdk.java.net" Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate ? ? ? On Apr 4, 2018, at 10:47 AM, Vivek Theeyarath HYPERLINK "mailto:vivek.theeyarath at oracle.com" wrote: ? Hi All, ? ???????????? Please review. ? Bug: https://bugs.openjdk.java.net/browse/JDK-8184692 ? Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.00/ ? Like with your other patch, alignment to ~80 chars would be good, as that is mostly consistent with other code in the same source file. ? Let?s not use the word ?find" here, so as not to confuse with matcher(s).find(). ? 5833????? * @return? The predicate which can be used for finding if an input string matches this pattern. ? I suggest: ? @return? The predicate which can be used for matching an input string against this pattern ? You could also add a @see Matcher#matches ? Paul. ? ? The related jtreg test was run and the test passed . ? ? ? Regards ? Vivek ? ? ? ? From roger.riggs at oracle.com Fri Apr 13 02:42:09 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 12 Apr 2018 22:42:09 -0400 Subject: RFR: 8184692: add Pattern.asMatchPredicate In-Reply-To: <34ba5981-b313-4473-bcc3-cfa4db25904b@default> References: <74681017-e7fe-47e8-89ef-d804c9e5e77b@default> <6AF1056A-D9AB-4C8C-9708-96CBCF40B2CB@oracle.com> <6e08e8d1-4052-40f9-ac30-514f3a83ef97@default> <3D98152E-5456-473B-9613-E0D5EDEBBC2C@oracle.com> <0710B763-B6B9-442F-AD6C-F77FE3824DFB@oracle.com> <6470b5b7-0c10-4d99-950e-4ca27a31fa83@default> <34ba5981-b313-4473-bcc3-cfa4db25904b@default> Message-ID: <45e5de44-03f8-279a-e361-d9490b7baba7@oracle.com> Thanks Vivek, Looks good to me. On 4/12/18 9:25 PM, Vivek Theeyarath wrote: > > Hi Roger, > > Please find the updated webrev > http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.04/ > . I > fixed the indentation with my earlier fix (asPredicate) too. Hope that > is fine. > > Regards > > Vivek > > *From:*Roger Riggs > *Sent:* Thursday, April 12, 2018 7:43 PM > *To:* Vivek Theeyarath > *Cc:* Core-Libs-Dev > *Subject:* Re: RFR: 8184692: add Pattern.asMatchPredicate > > Hi Vivek, > > ok, > > Generally, I like to see an updated webrev so that an old non-final > webrev isn't left around to be a source of questions. > Its easy enough to create a simple script to create the webrev and > copy it to cr.openjdk... > > Continued javadoc @xxx lines should be indented to improve readability > of the source. > > 5845????? *?????????? against this pattern. > > > Thanks, Roger > > On 4/12/18 8:49 AM, Vivek Theeyarath wrote: > > Hi, > > ? I have updated the doc as per the suggestion. Have finalized the csr too. > > Regards > > Vivek > > -----Original Message----- > > From: Paul Sandoz > > Sent: Thursday, April 12, 2018 12:40 AM > > To: Vivek Theeyarath > > Cc: Roger Riggs ; Core-Libs-Dev > > > Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate > > HI, > > Hopefully this is the last update :-) > > To align with asPredicate and Roger?s prior guidance on that method i think you can just say this: > > ? Creates a predicate that tests if this pattern matches a given input string. > > which is similar to the language of Pattern.matches. > > No need for another webrev if this change is acceptable. > > Paul. > > On Apr 9, 2018, at 7:53 PM, Vivek Theeyarath wrote: > > Thanks Paul / Roger for the inputs. > > I have updated the javadoc based on the inputs.http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.03 > . Please review. > > Regards > > Vivek > > -----Original Message----- > > From: Paul Sandoz > > Sent: Monday, April 09, 2018 9:25 PM > > To: Roger Riggs > > Cc: Core-Libs-Dev > > > Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate > > On Apr 9, 2018, at 8:41 AM, Roger Riggs wrote: > > Hi Vivek, > > As with Pattern.asPredicate the first sentence can be improved. > > Creates a predicate that tests if this pattern matches the entire region. > > The region of what? region is clear from the context of a Matcher, but less so from the context of Pattern. > > Paul. > > 5833: As with the original issue, perhaps adding the word 'whole' or > > 'entire' will make it clearer that the pattern must match then entire input string. > > 5827:? Split into two sentences, the second one starting? "For example," > > 5840: add a blank line between methods > > Regards, Roger > > On 4/9/18 5:05 AM, Vivek Theeyarath wrote: > > Hi, > > ?????? Please find the updated webrev after incorporating Paul's comments. > > http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.02/ > > > Also, I have created a csr for this issuehttps://bugs.openjdk.java.net/browse/JDK-8201308 . > > Regards > > Vivek > > -----Original Message----- > > From: Paul Sandoz > > Sent: Friday, April 06, 2018 6:55 AM > > To: Vivek Theeyarath > > > Cc: Core-Libs-Dev > > > Subject: Re: RFR: 8184692: add Pattern.asMatchPredicate > > On Apr 4, 2018, at 10:47 AM, Vivek Theeyarath > wrote: > > Hi All, > > ???????????? Please review. > > Bug:https://bugs.openjdk.java.net/browse/JDK-8184692 > > Webrev :http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.00/ > > > Like with your other patch, alignment to ~80 chars would be good, as that is mostly consistent with other code in the same source file. > > Let?s not use the word ?find" here, so as not to confuse with matcher(s).find(). > > 5833????? * @return? The predicate which can be used for finding if an input string matches this pattern. > > I suggest: > > @return? The predicate which can be used for matching an input > > string against this pattern > > You could also add a @see Matcher#matches > > Paul. > > The related jtreg test was run and the test passed . > > Regards > > Vivek > From mandy.chung at oracle.com Fri Apr 13 05:20:14 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 13 Apr 2018 13:20:14 +0800 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5ACFBE5C.1080508@oracle.com> References: <5ACFBE5C.1080508@oracle.com> Message-ID: <87e3bc79-aa0c-3241-d8f5-8c77850f61db@oracle.com> On 4/13/18 4:15 AM, Jonathan Gibbons wrote: > Please review an initial implementation for the feature described in > JEP 330: Launch Single-File Source-Code Programs. > > The work is described in the JEP and CSR, and falls into various parts: > > ?* The part to handle the new command-line options is in the native > ?? Java launcher code. > ?* The part to invoke the compiler and subsequently execute the code > ?? found in the source file is in a new class in the jdk.compiler module. > ?* There are some minor Makefile changes, to add support for a new > ?? resource file. > > There are no changes to javac itself. > > JEP: http://openjdk.java.net/jeps/330 > JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 > CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 > Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ This looks quite good to me.? One small comment on the source launcher Main class: 122 } catch (InvocationTargetException e) { 123 // leave VM to handle the stacktrace, in the standard manner 124 throw e.getTargetException(); 125 } 387 } catch (InvocationTargetException e) { 388 // remove stack frames for source launcher 389 int invocationFrames = e.getStackTrace().length; 390 Throwable target = e.getTargetException(); 391 StackTraceElement[] targetTrace = target.getStackTrace(); 392 target.setStackTrace(Arrays.copyOfRange(targetTrace, 0, targetTrace.length - invocationFrames)); 393 throw e; 394 } This could simply throw target instead of the InvocationTargetException and then the main method can propagate the target, if thrown. Mandy From matthias.baesken at sap.com Fri Apr 13 05:48:23 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 13 Apr 2018 05:48:23 +0000 Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations In-Reply-To: <9fff2e7e-06ac-54c1-8f66-33bff34ea621@oracle.com> References: <9bae15f406ed4e029233415e6a8032b8@sap.com> <81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com> <7c5e68c2a023490e96ce6452fbda1700@sap.com> <9fff2e7e-06ac-54c1-8f66-33bff34ea621@oracle.com> Message-ID: Hi Phil/Alexey, thanks for adding the other lists . > Is this the current version of the change : http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ ? Yes. Best regards, Matthias > -----Original Message----- > From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] > Sent: Donnerstag, 12. April 2018 23:53 > To: Phil Race ; Baesken, Matthias > ; Alan Bateman ; > Magnus Ihse Bursie > Cc: build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Doerr, > Martin ; 2d-dev <2d-dev at openjdk.java.net>; > hotspot-dev > Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function > declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at > some places in function declarations/implementations > > > On 12/04/2018 21:42, Phil Race wrote: > > How can JNIEXPORT be different between 32 bit & 64 bit ? > > I'm sure you saw compilation errors but I don't get why it failed for > > 32 only. > > > > JNICALL (_stdcall) may be unnecessary on 64 bit Windows but that doesn't > > explain why the 32 bit compiler would complain about inconsistent > > application > > of __declspec(dllexport) - ie JNIEXPORT. > > > > Or is that part (adding JNIEXPORT) pure clean up and the compilation > > errors were all down to JNICALL ? > > Adding missing JNIEXPORT is for cleanup only. > > The compiler complained about mismatched JNICALL / non-JNICALL > declarations as the macro changes calling convention from the default > __cdecl? to __stdcall on 32 bit Windows. > > Another issue is that __stdcall decorates the functions: prefixes with > underscore and postfixes with @ + size of parameters. Because of the > decorations, classLoader.cpp can't lookup the required functions by name > from zip.dll and jimage.dll. The functions are exported but with > different name. > > I hope this information adds more details to the picture. > > > I was a bit puzzled at the removals I saw here : > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.deskto > p/share/native/libsplashscreen/splashscreen_impl.h.udiff.html > > > > > > .. I needed to look at the whole file to realise that you were > > removing a duplicate > > declaration. > > That was tricky. I could have been mentioned in the review. > > > Regards, > Alexey > > > > > -phil. > > > > On 04/12/2018 04:04 AM, Baesken, Matthias wrote: > >> Hi? Alan , this is the up to date webrev . > >> However we want to add?? Alexey?? Ivanov? as additional? author . > >> > >>> As I read it, this changes the calling convention of these functions on > >>> 32-bit Windows but it will have no impact on 64-bit Windows (as > >>> __stdcall is ignored) or other platforms, is that correct? > >>> > >> The? change adds? JNIEXPORT?? at some places? where it is? ben > >> forgotten , for example : > >> > >> > http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.deskto > p/share/native/libmlib_image/mlib_c_ImageLookUp.c.udiff.html > >> > >> > >> This might have? potential? impact? on other platforms?? (fixes the > >> mismatches) . > >> > >> Best regards, Matthias > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > >>> Sent: Donnerstag, 12. April 2018 12:54 > >>> To: Baesken, Matthias ; Magnus Ihse > Bursie > >>> > >>> Cc: build-dev at openjdk.java.net; Doerr, Martin > ; > >>> core-libs-dev at openjdk.java.net > >>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in > >>> function > >>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at > >>> some places in function declarations/implementations > >>> > >>> Adding core-libs-dev as this is change code in libjava, libzip, > >>> libjimage, ... > >>> > >>> Can you confirm that this is the up to date webrev: > >>> ???? http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ > >>> > >>> As I read it, this changes the calling convention of these functions on > >>> 32-bit Windows but it will have no impact on 64-bit Windows (as > >>> __stdcall is ignored) or other platforms, is that correct? > >>> > >>> -Alan > >>> > >>> > >>> On 06/04/2018 14:20, Baesken, Matthias wrote: > >>>> Hello, I just noticed? 2? additonal issues? regarding > >>>> mapfile-removal : > >>>> > >>>> > >>>> ??? 1.? The?? follow up change? that removed?? mapfiles for exes > >>>> as well > >>> leads on Win32 bit? to? this link error : > >>>> ??? Creating library > >>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and > >>> object > >>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp > >>>> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main > >>> referenced in function ___tmainCRTStartup > >>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe > : > >>> fatal error LNK1120: 1 unresolved externals > >>>> > >>>> Looks like we? cannot have?? JNICALL?? in main.c?? : > >>>> > >>>> diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c > >>>> --- a/src/java.base/share/native/launcher/main.c??????? Thu Apr 05 > >>>> 14:39:04 > >>> 2018 -0700 > >>>> +++ b/src/java.base/share/native/launcher/main.c??????? Fri Apr 06 > >>>> 15:16:40 > >>> 2018 +0200 > >>>> @@ -93,7 +93,7 @@ > >>>> ?????? __initenv = _environ; > >>>> > >>>> #else /* JAVAW */ > >>>> -JNIEXPORT int JNICALL > >>>> +JNIEXPORT int > >>>> main(int argc, char **argv) > >>>> { > >>>> ?????? int margc; > >>>> > >>>> > >>>> > >>>> ??? 1.? Zip-library? has runtime issues?? when? symbols? are > >>>> resolved? in > >>> src/hotspot/share/classfile/classLoader.cpp. > >>>> I added? the declaration of the missing symbol, this seems to fix it . > >>>> > >>>> > >>>> diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h > >>>> --- a/src/java.base/share/native/libzip/zip_util.h????? Thu Apr 05 > >>>> 14:39:04 > >>> 2018 -0700 > >>>> +++ b/src/java.base/share/native/libzip/zip_util.h????? Fri Apr 06 > >>>> 15:16:40 > >>> 2018 +0200 > >>>> @@ -284,4 +284,7 @@ > >>>> JNIEXPORT jboolean JNICALL > >>>> ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong > >>>> outLen, char > >>> **pmsg); > >>>> +JNIEXPORT jint JNICALL > >>>> +ZIP_CRC32(jint crc, const jbyte *buf, jint len); > >>>> + > >>>> > >>>> > >>>> Should I? prepare? another? bug,? or? add this to the existing one > >>>> and??? post a > >>> second webrev ? > >>>> Best regards, Matthias > >>>> > >>>> > >>>> From: Baesken, Matthias > >>>> Sent: Freitag, 6. April 2018 09:54 > >>>> To: 'Magnus Ihse Bursie' > >>>> Cc: build-dev at openjdk.java.net; Doerr, Martin > > >>>> Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in > >>> function declarations/implementations - was : RE: missing JNIEXPORT / > >>> JNICALL at some places in function declarations/implementations > >>>> Hello, please review : > >>>> > >>>> Bug : > >>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8201226 > >>>> > >>>> change : > >>>> > >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/ > >>>> > >>>> mostly I added? JNIEXPORT / JNICALL at some places? where the > win32bit > >>> build missed it . > >>>> A difference is > >>> src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h > >>>> Where I removed?? a few? declarations (one? decl?? with one without > >>> JNIEXPORT / JNICALL ? looked a bit strange ) . > >>>> Best regards , Matthias > >>>> > >>>> > >>>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] > >>>> Sent: Donnerstag, 5. April 2018 17:45 > >>>> To: Baesken, Matthias > >>> > > >>>> Cc: build-dev at openjdk.java.net; > >>> Doerr, Martin > > > >>>> Subject: Re: missing JNIEXPORT / JNICALL at some places in function > >>> declarations/implementations > >>>> That's most likely a result of the new JNIEXPORT I added as part of > >>>> the > >>> mapfile removal. > >>>> I tried to match header file and C file, but I can certainly have > >>>> missed cases. > >>> If I didn't get any warnings, it was hard to know what I missed. > >>>> Please do submit your patch. > >>>> > >>>> I'm a bit surprised 32-bit Window is still buildable. :) > >>>> > >>>> /Magnus > >>>> > >>>> 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias > >>> >: > >>>> Hello, we noticed? that? at a number of places in the coding? ,?? the > >>> JNIEXPORT and/or?? JNICALL modifiers?? do not match? when one > compares > >>> the declaration and > >>>> The implementation of functions. > >>>> While this is ok on most platforms, it seems to fail on Windows 32 > >>>> bit and > >>> leads to errors like this one : > >>>> > >>> > e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/ml > >>> > >>> ib_ImageConvKernelConvert.c(87) : error C2373: > >>> 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type > >>> modifiers > >>> > e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\ml > >>> > >>> ib_image_proto.h(2630) : see declaration of > >>> 'j2d_mlib_ImageConvKernelConvert' > >>>> (there are quite a few of these e.g. in mlib? / splashscreen etc.) > >>>> > >>>> > >>>> Another example is this one : > >>>> > >>>> diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp > >>>> --- a/src/java.base/share/native/libjimage/jimage.hpp? Thu Apr 05 > >>>> 09:55:16 > >>> 2018 +0200 > >>>> +++ b/src/java.base/share/native/libjimage/jimage.hpp Thu Apr 05 > >>> 17:07:40 2018 +0200 > >>>> @@ -126,7 +126,7 @@ > >>>> ??? *?? JImageLocationRef location = (*JImageFindResource)(image, > >>>> ??? *??????????????????????????????? "java.base", "9.0", > >>>> "java/lang/String.class", &size); > >>>> ??? */ > >>>> -extern "C" JNIEXPORT JImageLocationRef > >>> JIMAGE_FindResource(JImageFile* jimage, > >>>> +extern "C" JNIEXPORT JImageLocationRef JNICALL > >>> JIMAGE_FindResource(JImageFile* jimage, > >>>> ?????????? const char* module_name, const char* version, const > >>>> char* name, > >>>> ?????????? jlong* size); > >>>> > >>>> > >>>> Is there some generic way to get? the? same? declarations / > >>>> impementations > >>> in the code? ? > >>>> Or should I just add a patch with my findings ? > >>>> > >>>> Best regards, Matthias > >>>> > > From jan.lahoda at oracle.com Fri Apr 13 09:08:38 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 13 Apr 2018 11:08:38 +0200 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5ACFBE5C.1080508@oracle.com> References: <5ACFBE5C.1080508@oracle.com> Message-ID: <5AD07396.1050908@oracle.com> The javac part looks OK to me. A nit comment, in: launcher/Main.java/MemoryFileManager#createInMemoryClassFile, there is: return new FilterOutputStream(new ByteArrayOutputStream()) { ... It could I think be written as: return new ByteArrayOutputStream() { @Override public void close() throws IOException { super.close(); byte[] bytes = toByteArray(); map.put(className, bytes); } }; (I.e. without the cast to ByteArrayOutputStream.) Jan On 12.4.2018 22:15, Jonathan Gibbons wrote: > Please review an initial implementation for the feature described in > JEP 330: Launch Single-File Source-Code Programs. > > The work is described in the JEP and CSR, and falls into various parts: > > * The part to handle the new command-line options is in the native > Java launcher code. > * The part to invoke the compiler and subsequently execute the code > found in the source file is in a new class in the jdk.compiler module. > * There are some minor Makefile changes, to add support for a new > resource file. > > There are no changes to javac itself. > > JEP: http://openjdk.java.net/jeps/330 > JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 > CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 > Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ > > -- Jon From thomas.stuefe at gmail.com Fri Apr 13 09:31:44 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 13 Apr 2018 11:31:44 +0200 Subject: Clean-room implementation of Double::toString(double) and Float::toString(float) In-Reply-To: <3BD60996-BEC9-4179-91F8-39E002B33594@oracle.com> References: <5c8944fa-4941-79b4-9320-a04ecb93b27a@gmail.com> <8FC2F9AF-7B48-45FD-B65E-405122F1E21D@oracle.com> <9ffa5039-82b6-6f0b-479b-307361d8ba7a@gmail.com> <3BD60996-BEC9-4179-91F8-39E002B33594@oracle.com> Message-ID: On Sat, Mar 31, 2018 at 12:17 AM, Brian Burkhalter wrote: > Hi Raffaello, > > On Mar 30, 2018, at 2:57 PM, raffaello.giulietti at gmail.com wrote: > >>>> [?] >>>> >>>> The new code also has a better specification than the current one, while >>>> being mostly compatible. Indeed, the current specification leaves room >>>> for interpretation and thus cannot ensure that an implementation >>>> produces consistent and unique results from one release to the next. The >>>> newer spec ensures a unique result. >>> >>> Any specification change would need to go through the Compatibility and >>> Specification Review process. [3] >>> >> >> OK, as you will see, as soon as the code will be uploaded, the only >> thing that formally affects output is the "1.0E23" versus "9.99....E22" >> issue. Everything else is worded in such a way to remain compatible but >> is simply a little bit more rigorous. > > Sounds good. > >> My wording was misleading: I already got the confirmation that my OCA >> application has been accepted, so I'm formally ready to contribute. > > That?s good as it gives more time. > >>> Per the JDK 11 schedule [5] there could well be sufficient time to run >>> this submission through the review processes. I suggest, once your OCA >>> has been processed, to proceed by posting your proposed changes for >>> review on this mailing list. Note that in general attachments are >>> scrubbed, so the patch would need either to be included inline or >>> published as a webrev [6]. >>> >> >> OK, I'll take a look on how the mechanics works. >> >> I'm usually on Windows. Are there technical issues with it as far as >> Webrev is concerned? I mean, I could setup a Linux VM in VirtualBox if >> this simplifies my life, but I'd prefer continuing my main work in Win. > > As seen in Jon?s posting there are some attachment types which will work. As to webrev, I think it should work on Windows at least in cygwin but I?ve not used it there myself. If it?s just a matter of creating a webrev I could do that on your behalf based on your supplied patch. > Just to chime in here, producing webrevs on windows is easy: - in cygwin, install Korn shell (ksh) - and, of course, mercurial the rest is standard: - clone the code-tools/webrev repo: http://hg.openjdk.java.net/code-tools/webrev/ - run webrev: ksh /webrev.ksh -o Best Regards, Thomas > Thanks, > > Brian From bhamaram at in.ibm.com Fri Apr 13 09:35:21 2018 From: bhamaram at in.ibm.com (Bhaktavatsal R Maram) Date: Fri, 13 Apr 2018 09:35:21 +0000 Subject: Missing many locales support on AIX platform In-Reply-To: References: , , Message-ID: Given that patch is big, I am sending patch as attachment again after changing some mail settings. Hopefully, it will make to community this time. Thanks, Bhaktavatsal Reddy -----Bhaktavatsal R Maram/India/IBM wrote: ----- To: core-libs-dev at openjdk.java.net From: Bhaktavatsal R Maram/India/IBM Date: 04/12/2018 11:47PM Subject: Re: Missing many locales support on AIX platform Please review this patch for this issue. I have added IBM-943C as well to standard charset along with IBM-943. # HG changeset patch # User bhamaram # Date 1523510846 -19800 # Thu Apr 12 10:57:26 2018 +0530 # Node ID a76dd37b1c6b47e7ac99f279c4ba76832dd9736f # Parent 129d60b5dac71872f3317d94c724304100bc2048 java.lang.IllegalArgumentException from java -version on AIX with different locales diff -r 129d60b5dac7 -r a76dd37b1c6b make/data/charsetmapping/charsets --- a/make/data/charsetmapping/charsets Thu Apr 12 09:03:46 2018 -0400 +++ b/make/data/charsetmapping/charsets Thu Apr 12 10:57:26 2018 +0530 @@ -933,11 +933,16 @@ charset x-IBM942C IBM942C package sun.nio.cs.ext - type source + type template alias cp942C # JDK historical alias ibm942C alias ibm-942C alias 942C + alias cp932 + alias ibm932 + alias ibm-932 + alias 932 + alias x-ibm932 charset x-IBM943 IBM943 package sun.nio.cs.ext diff -r 129d60b5dac7 -r a76dd37b1c6b make/data/charsetmapping/stdcs-aix --- a/make/data/charsetmapping/stdcs-aix Thu Apr 12 09:03:46 2018 -0400 +++ b/make/data/charsetmapping/stdcs-aix Thu Apr 12 10:57:26 2018 +0530 @@ -1,6 +1,16 @@ # # generate these charsets into sun.nio.cs # +Big5 +Big5_HKSCS EUC_CN EUC_KR GBK +GB18030 +IBM942 +IBM942C +IBM943 +IBM950 +IBM970 +IBM1124 +TIS_620 diff -r 129d60b5dac7 -r a76dd37b1c6b src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java --- a/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java Thu Apr 12 09:03:46 2018 -0400 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,93 +0,0 @@ -/* - * Copyright (c) 2003, 2004, 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. - */ - -package sun.nio.cs.ext; - -import java.nio.charset.Charset; -import java.nio.charset.CharsetDecoder; -import java.nio.charset.CharsetEncoder; -import java.util.Arrays; -import sun.nio.cs.DoubleByte; -import sun.nio.cs.HistoricallyNamedCharset; -import static sun.nio.cs.CharsetMapping.*; - -public class IBM942C extends Charset implements HistoricallyNamedCharset -{ - public IBM942C() { - super("x-IBM942C", ExtendedCharsets.aliasesFor("x-IBM942C")); - } - - public String historicalName() { - return "Cp942C"; - } - - public boolean contains(Charset cs) { - return ((cs.name().equals("US-ASCII")) - || (cs instanceof IBM942C)); - } - - public CharsetDecoder newDecoder() { - return new DoubleByte.Decoder(this, - IBM942.b2c, - b2cSB, - 0x40, - 0xfc); - } - - public CharsetEncoder newEncoder() { - return new DoubleByte.Encoder(this, c2b, c2bIndex); - } - - final static char[] b2cSB; - final static char[] c2b; - final static char[] c2bIndex; - - static { - IBM942.initb2c(); - - // the mappings need udpate are - // u+001a <-> 0x1a - // u+001c <-> 0x1c - // u+005c <-> 0x5c - // u+007e <-> 0x7e - // u+007f <-> 0x7f - - b2cSB = Arrays.copyOf(IBM942.b2cSB, IBM942.b2cSB.length); - b2cSB[0x1a] = 0x1a; - b2cSB[0x1c] = 0x1c; - b2cSB[0x5c] = 0x5c; - b2cSB[0x7e] = 0x7e; - b2cSB[0x7f] = 0x7f; - - IBM942.initc2b(); - c2b = Arrays.copyOf(IBM942.c2b, IBM942.c2b.length); - c2bIndex = Arrays.copyOf(IBM942.c2bIndex, IBM942.c2bIndex.length); - c2b[c2bIndex[0] + 0x1a] = 0x1a; - c2b[c2bIndex[0] + 0x1c] = 0x1c; - c2b[c2bIndex[0] + 0x5c] = 0x5c; - c2b[c2bIndex[0] + 0x7e] = 0x7e; - c2b[c2bIndex[0] + 0x7f] = 0x7f; - } -} diff -r 129d60b5dac7 -r a76dd37b1c6b src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java.template --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java.template Thu Apr 12 10:57:26 2018 +0530 @@ -0,0 +1,93 @@ +/* + * Copyright (c) 2003, 2004, 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. + */ + +package $PACKAGE$; + +import java.nio.charset.Charset; +import java.nio.charset.CharsetDecoder; +import java.nio.charset.CharsetEncoder; +import java.util.Arrays; +import sun.nio.cs.DoubleByte; +import sun.nio.cs.HistoricallyNamedCharset; +import static sun.nio.cs.CharsetMapping.*; + +public class IBM942C extends Charset implements HistoricallyNamedCharset +{ + public IBM942C() { + super("x-IBM942C", $ALIASES$); + } + + public String historicalName() { + return "Cp942C"; + } + + public boolean contains(Charset cs) { + return ((cs.name().equals("US-ASCII")) + || (cs instanceof IBM942C)); + } + + public CharsetDecoder newDecoder() { + return new DoubleByte.Decoder(this, + IBM942.b2c, + b2cSB, + 0x40, + 0xfc); + } + + public CharsetEncoder newEncoder() { + return new DoubleByte.Encoder(this, c2b, c2bIndex); + } + + final static char[] b2cSB; + final static char[] c2b; + final static char[] c2bIndex; + + static { + IBM942.initb2c(); + + // the mappings need udpate are + // u+001a <-> 0x1a + // u+001c <-> 0x1c + // u+005c <-> 0x5c + // u+007e <-> 0x7e + // u+007f <-> 0x7f + + b2cSB = Arrays.copyOf(IBM942.b2cSB, IBM942.b2cSB.length); + b2cSB[0x1a] = 0x1a; + b2cSB[0x1c] = 0x1c; + b2cSB[0x5c] = 0x5c; + b2cSB[0x7e] = 0x7e; + b2cSB[0x7f] = 0x7f; + + IBM942.initc2b(); + c2b = Arrays.copyOf(IBM942.c2b, IBM942.c2b.length); + c2bIndex = Arrays.copyOf(IBM942.c2bIndex, IBM942.c2bIndex.length); + c2b[c2bIndex[0] + 0x1a] = 0x1a; + c2b[c2bIndex[0] + 0x1c] = 0x1c; + c2b[c2bIndex[0] + 0x5c] = 0x5c; + c2b[c2bIndex[0] + 0x7e] = 0x7e; + c2b[c2bIndex[0] + 0x7f] = 0x7f; + } +} # HG changeset patch # User bhamaram # Date 1523555765 -19800 # Thu Apr 12 23:26:05 2018 +0530 # Node ID 99542925f31823e5f337a0890499c2647b803629 # Parent a76dd37b1c6b47e7ac99f279c4ba76832dd9736f include IBM-943C to standard charset diff -r a76dd37b1c6b -r 99542925f318 make/data/charsetmapping/charsets --- a/make/data/charsetmapping/charsets Thu Apr 12 10:57:26 2018 +0530 +++ b/make/data/charsetmapping/charsets Thu Apr 12 23:26:05 2018 +0530 @@ -957,7 +957,7 @@ charset x-IBM943C IBM943C package sun.nio.cs.ext - type source + type template alias cp943C # JDK historical alias ibm943C alias ibm-943C diff -r a76dd37b1c6b -r 99542925f318 make/data/charsetmapping/stdcs-aix --- a/make/data/charsetmapping/stdcs-aix Thu Apr 12 10:57:26 2018 +0530 +++ b/make/data/charsetmapping/stdcs-aix Thu Apr 12 23:26:05 2018 +0530 @@ -2,6 +2,7 @@ # generate these charsets into sun.nio.cs # Big5 +Big5_Solaris Big5_HKSCS EUC_CN EUC_KR @@ -10,6 +11,7 @@ IBM942 IBM942C IBM943 +IBM943C IBM950 IBM970 IBM1124 diff -r a76dd37b1c6b -r 99542925f318 src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM943C.java --- a/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM943C.java Thu Apr 12 10:57:26 2018 +0530 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,85 +0,0 @@ -/* - * Copyright (c) 2003, 2004, 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. - */ - -package sun.nio.cs.ext; - -import java.nio.charset.Charset; -import java.nio.charset.CharsetDecoder; -import java.nio.charset.CharsetEncoder; -import java.util.Arrays; -import sun.nio.cs.DoubleByte; -import sun.nio.cs.HistoricallyNamedCharset; - -public class IBM943C extends Charset implements HistoricallyNamedCharset -{ - - public IBM943C() { - super("x-IBM943C", ExtendedCharsets.aliasesFor("x-IBM943C")); - } - - public String historicalName() { - return "Cp943C"; - } - - public boolean contains(Charset cs) { - return ((cs.name().equals("US-ASCII")) - || (cs instanceof IBM943C)); - } - - public CharsetDecoder newDecoder() { - return new DoubleByte.Decoder(this, - IBM943.b2c, - b2cSB, - 0x40, - 0xfc); - } - - public CharsetEncoder newEncoder() { - return new DoubleByte.Encoder(this, c2b, c2bIndex); - } - - final static char[] b2cSB; - final static char[] c2b; - final static char[] c2bIndex; - - static { - IBM943.initb2c(); - b2cSB = new char[0x100]; - for (int i = 0; i < 0x80; i++) { - b2cSB[i] = (char)i; - } - for (int i = 0x80; i < 0x100; i++) { - b2cSB[i] = IBM943.b2cSB[i]; - } - - IBM943.initc2b(); - c2b = Arrays.copyOf(IBM943.c2b, IBM943.c2b.length); - c2bIndex = Arrays.copyOf(IBM943.c2bIndex, IBM943.c2bIndex.length); - for (char c = '\0'; c < '\u0080'; ++c) { - int index = c2bIndex[c >> 8]; - c2b[index + (c & 0xff)] = c; - } - } -} diff -r a76dd37b1c6b -r 99542925f318 src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM943C.java.template --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM943C.java.template Thu Apr 12 23:26:05 2018 +0530 @@ -0,0 +1,85 @@ +/* + * Copyright (c) 2003, 2004, 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. + */ + +package $PACKAGE$; + +import java.nio.charset.Charset; +import java.nio.charset.CharsetDecoder; +import java.nio.charset.CharsetEncoder; +import java.util.Arrays; +import sun.nio.cs.DoubleByte; +import sun.nio.cs.HistoricallyNamedCharset; + +public class IBM943C extends Charset implements HistoricallyNamedCharset +{ + + public IBM943C() { + super("x-IBM943C", $ALIASES$); + } + + public String historicalName() { + return "Cp943C"; + } + + public boolean contains(Charset cs) { + return ((cs.name().equals("US-ASCII")) + || (cs instanceof IBM943C)); + } + + public CharsetDecoder newDecoder() { + return new DoubleByte.Decoder(this, + IBM943.b2c, + b2cSB, + 0x40, + 0xfc); + } + + public CharsetEncoder newEncoder() { + return new DoubleByte.Encoder(this, c2b, c2bIndex); + } + + final static char[] b2cSB; + final static char[] c2b; + final static char[] c2bIndex; + + static { + IBM943.initb2c(); + b2cSB = new char[0x100]; + for (int i = 0; i < 0x80; i++) { + b2cSB[i] = (char)i; + } + for (int i = 0x80; i < 0x100; i++) { + b2cSB[i] = IBM943.b2cSB[i]; + } + + IBM943.initc2b(); + c2b = Arrays.copyOf(IBM943.c2b, IBM943.c2b.length); + c2bIndex = Arrays.copyOf(IBM943.c2bIndex, IBM943.c2bIndex.length); + for (char c = '\0'; c < '\u0080'; ++c) { + int index = c2bIndex[c >> 8]; + c2b[index + (c & 0xff)] = c; + } + } +} Thanks, Bhaktavatsal Reddy -----"core-libs-dev" wrote: ----- To: core-libs-dev at openjdk.java.net From: "Bhaktavatsal R Maram" Sent by: "core-libs-dev" Date: 04/12/2018 03:16PM Subject: Re: Missing many locales support on AIX platform Patch I attached to previous mail is not seen. So, pasting patch here. Hope, it is fine. # HG changeset patch # User bhamaram # Date 1523510846 -19800 # Node ID 6134bbe9861111f8cc42b055081f2c48e91039a8 # Parent 0c3e252cea44f06aef570ef464950ab97c669970 java.lang.IllegalArgumentException from java -version on AIX with different locales diff -r 0c3e252cea44 -r 6134bbe98611 make/data/charsetmapping/charsets --- a/make/data/charsetmapping/charsets Thu Apr 12 10:19:31 2018 +0800 +++ b/make/data/charsetmapping/charsets Thu Apr 12 10:57:26 2018 +0530 @@ -933,11 +933,16 @@ charset x-IBM942C IBM942C package sun.nio.cs.ext - type source + type template alias cp942C # JDK historical alias ibm942C alias ibm-942C alias 942C + alias cp932 + alias ibm932 + alias ibm-932 + alias 932 + alias x-ibm932 charset x-IBM943 IBM943 package sun.nio.cs.ext diff -r 0c3e252cea44 -r 6134bbe98611 make/data/charsetmapping/stdcs-aix --- a/make/data/charsetmapping/stdcs-aix Thu Apr 12 10:19:31 2018 +0800 +++ b/make/data/charsetmapping/stdcs-aix Thu Apr 12 10:57:26 2018 +0530 @@ -1,6 +1,16 @@ # # generate these charsets into sun.nio.cs # +Big5 +Big5_HKSCS EUC_CN EUC_KR GBK +GB18030 +IBM942 +IBM942C +IBM943 +IBM950 +IBM970 +IBM1124 +TIS_620 diff -r 0c3e252cea44 -r 6134bbe98611 src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java --- a/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java Thu Apr 12 10:19:31 2018 +0800 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,93 +0,0 @@ -/* - * Copyright (c) 2003, 2004, 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. - */ - -package sun.nio.cs.ext; - -import java.nio.charset.Charset; -import java.nio.charset.CharsetDecoder; -import java.nio.charset.CharsetEncoder; -import java.util.Arrays; -import sun.nio.cs.DoubleByte; -import sun.nio.cs.HistoricallyNamedCharset; -import static sun.nio.cs.CharsetMapping.*; - -public class IBM942C extends Charset implements HistoricallyNamedCharset -{ - public IBM942C() { - super("x-IBM942C", ExtendedCharsets.aliasesFor("x-IBM942C")); - } - - public String historicalName() { - return "Cp942C"; - } - - public boolean contains(Charset cs) { - return ((cs.name().equals("US-ASCII")) - || (cs instanceof IBM942C)); - } - - public CharsetDecoder newDecoder() { - return new DoubleByte.Decoder(this, - IBM942.b2c, - b2cSB, - 0x40, - 0xfc); - } - - public CharsetEncoder newEncoder() { - return new DoubleByte.Encoder(this, c2b, c2bIndex); - } - - final static char[] b2cSB; - final static char[] c2b; - final static char[] c2bIndex; - - static { - IBM942.initb2c(); - - // the mappings need udpate are - // u+001a <-> 0x1a - // u+001c <-> 0x1c - // u+005c <-> 0x5c - // u+007e <-> 0x7e - // u+007f <-> 0x7f - - b2cSB = Arrays.copyOf(IBM942.b2cSB, IBM942.b2cSB.length); - b2cSB[0x1a] = 0x1a; - b2cSB[0x1c] = 0x1c; - b2cSB[0x5c] = 0x5c; - b2cSB[0x7e] = 0x7e; - b2cSB[0x7f] = 0x7f; - - IBM942.initc2b(); - c2b = Arrays.copyOf(IBM942.c2b, IBM942.c2b.length); - c2bIndex = Arrays.copyOf(IBM942.c2bIndex, IBM942.c2bIndex.length); - c2b[c2bIndex[0] + 0x1a] = 0x1a; - c2b[c2bIndex[0] + 0x1c] = 0x1c; - c2b[c2bIndex[0] + 0x5c] = 0x5c; - c2b[c2bIndex[0] + 0x7e] = 0x7e; - c2b[c2bIndex[0] + 0x7f] = 0x7f; - } -} diff -r 0c3e252cea44 -r 6134bbe98611 src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java.template --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java.template Thu Apr 12 10:57:26 2018 +0530 @@ -0,0 +1,93 @@ +/* + * Copyright (c) 2003, 2004, 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. + */ + +package $PACKAGE$; + +import java.nio.charset.Charset; +import java.nio.charset.CharsetDecoder; +import java.nio.charset.CharsetEncoder; +import java.util.Arrays; +import sun.nio.cs.DoubleByte; +import sun.nio.cs.HistoricallyNamedCharset; +import static sun.nio.cs.CharsetMapping.*; + +public class IBM942C extends Charset implements HistoricallyNamedCharset +{ + public IBM942C() { + super("x-IBM942C", $ALIASES$); + } + + public String historicalName() { + return "Cp942C"; + } + + public boolean contains(Charset cs) { + return ((cs.name().equals("US-ASCII")) + || (cs instanceof IBM942C)); + } + + public CharsetDecoder newDecoder() { + return new DoubleByte.Decoder(this, + IBM942.b2c, + b2cSB, + 0x40, + 0xfc); + } + + public CharsetEncoder newEncoder() { + return new DoubleByte.Encoder(this, c2b, c2bIndex); + } + + final static char[] b2cSB; + final static char[] c2b; + final static char[] c2bIndex; + + static { + IBM942.initb2c(); + + // the mappings need udpate are + // u+001a <-> 0x1a + // u+001c <-> 0x1c + // u+005c <-> 0x5c + // u+007e <-> 0x7e + // u+007f <-> 0x7f + + b2cSB = Arrays.copyOf(IBM942.b2cSB, IBM942.b2cSB.length); + b2cSB[0x1a] = 0x1a; + b2cSB[0x1c] = 0x1c; + b2cSB[0x5c] = 0x5c; + b2cSB[0x7e] = 0x7e; + b2cSB[0x7f] = 0x7f; + + IBM942.initc2b(); + c2b = Arrays.copyOf(IBM942.c2b, IBM942.c2b.length); + c2bIndex = Arrays.copyOf(IBM942.c2bIndex, IBM942.c2bIndex.length); + c2b[c2bIndex[0] + 0x1a] = 0x1a; + c2b[c2bIndex[0] + 0x1c] = 0x1c; + c2b[c2bIndex[0] + 0x5c] = 0x5c; + c2b[c2bIndex[0] + 0x7e] = 0x7e; + c2b[c2bIndex[0] + 0x7f] = 0x7f; + } +} Thanks, Bhaktavatsal Reddy -----"core-libs-dev" wrote: ----- To: core-libs-dev at openjdk.java.net From: "Bhaktavatsal R Maram" Sent by: "core-libs-dev" Date: 04/12/2018 03:12PM Subject: Missing many locales support on AIX platform Hi, On AIX platforms, Java is not starting on many locales. Java initialization fails with java.lang.IllegalArgumentException bash-4.4$ LANG=Ja_JP java -version Error occurred during initialization of VM java.lang.IllegalArgumentException: Null charset name at java.nio.charset.Charset.lookup(java.base/Charset.java:455) at java.nio.charset.Charset.defaultCharset(java.base/Charset.java:608) at java.lang.StringCoding.decode(java.base/StringCoding.java:314) at java.lang.String.(java.base/String.java:591) at java.lang.String.(java.base/String.java:613) at java.lang.System.initProperties(java.base/Native Method) at java.lang.System.initPhase1(java.base/System.java:1908) >From our analysis, following are locales that are impacted with this issue. Ar_AA.IBM-1046 ar_AA.ISO8859-6 ca_ES.IBM-1252 at euro Iw_IL.IBM-856 iw_IL.ISO8859-8 Et_EE.IBM-922 at euro Ja_JP.IBM-932 Ja_JP.IBM-943 ja_JP.IBM-eucJP ko_KR.IBM-eucKR Lt_LT.IBM-921 at euro th_TH.TIS-620 Uk_UA.IBM-1124 Vi_VN.IBM-1129 Zh_CN.GB18030 zh_CN.IBM-eucCN Zh_HK.BIG5-HKSCS Zh_TW.big5 The default charset for these locales are not available in the java.base module and hence java cannot be used with those locales. In the current fix, am fixing the issue for following locales. Ja_JP.IBM-932 Ja_JP.IBM-943 ko_KR.IBM-eucKR th_TH.TIS-620 Uk_UA.IBM-1124 Zh_CN.GB18030 Zh_HK.BIG5-HKSCS Zh_TW.big5 I've attached fix with this mail. I will continue working on other locales and provide the fix. In the mean time, I kindly request you to open a bug and review the fix for the above locales. Thanks, Bhaktavatsal Reddy -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patchv2.txt URL: From bhamaram at in.ibm.com Fri Apr 13 09:37:18 2018 From: bhamaram at in.ibm.com (Bhaktavatsal R Maram) Date: Fri, 13 Apr 2018 09:37:18 +0000 Subject: Missing many locales support on AIX platform In-Reply-To: References: , , , Message-ID: No luck! :( How can I attach patch? Any suggestions? Thanks, Bhaktavatsal Reddy -----Bhaktavatsal R Maram/India/IBM wrote: ----- To: core-libs-dev at openjdk.java.net From: Bhaktavatsal R Maram/India/IBM Date: 04/13/2018 03:05PM Subject: Re: Missing many locales support on AIX platform Given that patch is big, I am sending patch as attachment again after changing some mail settings. Hopefully, it will make to community this time. Thanks, Bhaktavatsal Reddy -----Bhaktavatsal R Maram/India/IBM wrote: ----- To: core-libs-dev at openjdk.java.net From: Bhaktavatsal R Maram/India/IBM Date: 04/12/2018 11:47PM Subject: Re: Missing many locales support on AIX platform Please review this patch for this issue. I have added IBM-943C as well to standard charset along with IBM-943. # HG changeset patch # User bhamaram # Date 1523510846 -19800 # Thu Apr 12 10:57:26 2018 +0530 # Node ID a76dd37b1c6b47e7ac99f279c4ba76832dd9736f # Parent 129d60b5dac71872f3317d94c724304100bc2048 java.lang.IllegalArgumentException from java -version on AIX with different locales diff -r 129d60b5dac7 -r a76dd37b1c6b make/data/charsetmapping/charsets --- a/make/data/charsetmapping/charsets Thu Apr 12 09:03:46 2018 -0400 +++ b/make/data/charsetmapping/charsets Thu Apr 12 10:57:26 2018 +0530 @@ -933,11 +933,16 @@ charset x-IBM942C IBM942C package sun.nio.cs.ext - type source + type template alias cp942C # JDK historical alias ibm942C alias ibm-942C alias 942C + alias cp932 + alias ibm932 + alias ibm-932 + alias 932 + alias x-ibm932 charset x-IBM943 IBM943 package sun.nio.cs.ext diff -r 129d60b5dac7 -r a76dd37b1c6b make/data/charsetmapping/stdcs-aix --- a/make/data/charsetmapping/stdcs-aix Thu Apr 12 09:03:46 2018 -0400 +++ b/make/data/charsetmapping/stdcs-aix Thu Apr 12 10:57:26 2018 +0530 @@ -1,6 +1,16 @@ # # generate these charsets into sun.nio.cs # +Big5 +Big5_HKSCS EUC_CN EUC_KR GBK +GB18030 +IBM942 +IBM942C +IBM943 +IBM950 +IBM970 +IBM1124 +TIS_620 diff -r 129d60b5dac7 -r a76dd37b1c6b src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java --- a/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java Thu Apr 12 09:03:46 2018 -0400 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,93 +0,0 @@ -/* - * Copyright (c) 2003, 2004, 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. - */ - -package sun.nio.cs.ext; - -import java.nio.charset.Charset; -import java.nio.charset.CharsetDecoder; -import java.nio.charset.CharsetEncoder; -import java.util.Arrays; -import sun.nio.cs.DoubleByte; -import sun.nio.cs.HistoricallyNamedCharset; -import static sun.nio.cs.CharsetMapping.*; - -public class IBM942C extends Charset implements HistoricallyNamedCharset -{ - public IBM942C() { - super("x-IBM942C", ExtendedCharsets.aliasesFor("x-IBM942C")); - } - - public String historicalName() { - return "Cp942C"; - } - - public boolean contains(Charset cs) { - return ((cs.name().equals("US-ASCII")) - || (cs instanceof IBM942C)); - } - - public CharsetDecoder newDecoder() { - return new DoubleByte.Decoder(this, - IBM942.b2c, - b2cSB, - 0x40, - 0xfc); - } - - public CharsetEncoder newEncoder() { - return new DoubleByte.Encoder(this, c2b, c2bIndex); - } - - final static char[] b2cSB; - final static char[] c2b; - final static char[] c2bIndex; - - static { - IBM942.initb2c(); - - // the mappings need udpate are - // u+001a <-> 0x1a - // u+001c <-> 0x1c - // u+005c <-> 0x5c - // u+007e <-> 0x7e - // u+007f <-> 0x7f - - b2cSB = Arrays.copyOf(IBM942.b2cSB, IBM942.b2cSB.length); - b2cSB[0x1a] = 0x1a; - b2cSB[0x1c] = 0x1c; - b2cSB[0x5c] = 0x5c; - b2cSB[0x7e] = 0x7e; - b2cSB[0x7f] = 0x7f; - - IBM942.initc2b(); - c2b = Arrays.copyOf(IBM942.c2b, IBM942.c2b.length); - c2bIndex = Arrays.copyOf(IBM942.c2bIndex, IBM942.c2bIndex.length); - c2b[c2bIndex[0] + 0x1a] = 0x1a; - c2b[c2bIndex[0] + 0x1c] = 0x1c; - c2b[c2bIndex[0] + 0x5c] = 0x5c; - c2b[c2bIndex[0] + 0x7e] = 0x7e; - c2b[c2bIndex[0] + 0x7f] = 0x7f; - } -} diff -r 129d60b5dac7 -r a76dd37b1c6b src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java.template --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java.template Thu Apr 12 10:57:26 2018 +0530 @@ -0,0 +1,93 @@ +/* + * Copyright (c) 2003, 2004, 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. + */ + +package $PACKAGE$; + +import java.nio.charset.Charset; +import java.nio.charset.CharsetDecoder; +import java.nio.charset.CharsetEncoder; +import java.util.Arrays; +import sun.nio.cs.DoubleByte; +import sun.nio.cs.HistoricallyNamedCharset; +import static sun.nio.cs.CharsetMapping.*; + +public class IBM942C extends Charset implements HistoricallyNamedCharset +{ + public IBM942C() { + super("x-IBM942C", $ALIASES$); + } + + public String historicalName() { + return "Cp942C"; + } + + public boolean contains(Charset cs) { + return ((cs.name().equals("US-ASCII")) + || (cs instanceof IBM942C)); + } + + public CharsetDecoder newDecoder() { + return new DoubleByte.Decoder(this, + IBM942.b2c, + b2cSB, + 0x40, + 0xfc); + } + + public CharsetEncoder newEncoder() { + return new DoubleByte.Encoder(this, c2b, c2bIndex); + } + + final static char[] b2cSB; + final static char[] c2b; + final static char[] c2bIndex; + + static { + IBM942.initb2c(); + + // the mappings need udpate are + // u+001a <-> 0x1a + // u+001c <-> 0x1c + // u+005c <-> 0x5c + // u+007e <-> 0x7e + // u+007f <-> 0x7f + + b2cSB = Arrays.copyOf(IBM942.b2cSB, IBM942.b2cSB.length); + b2cSB[0x1a] = 0x1a; + b2cSB[0x1c] = 0x1c; + b2cSB[0x5c] = 0x5c; + b2cSB[0x7e] = 0x7e; + b2cSB[0x7f] = 0x7f; + + IBM942.initc2b(); + c2b = Arrays.copyOf(IBM942.c2b, IBM942.c2b.length); + c2bIndex = Arrays.copyOf(IBM942.c2bIndex, IBM942.c2bIndex.length); + c2b[c2bIndex[0] + 0x1a] = 0x1a; + c2b[c2bIndex[0] + 0x1c] = 0x1c; + c2b[c2bIndex[0] + 0x5c] = 0x5c; + c2b[c2bIndex[0] + 0x7e] = 0x7e; + c2b[c2bIndex[0] + 0x7f] = 0x7f; + } +} # HG changeset patch # User bhamaram # Date 1523555765 -19800 # Thu Apr 12 23:26:05 2018 +0530 # Node ID 99542925f31823e5f337a0890499c2647b803629 # Parent a76dd37b1c6b47e7ac99f279c4ba76832dd9736f include IBM-943C to standard charset diff -r a76dd37b1c6b -r 99542925f318 make/data/charsetmapping/charsets --- a/make/data/charsetmapping/charsets Thu Apr 12 10:57:26 2018 +0530 +++ b/make/data/charsetmapping/charsets Thu Apr 12 23:26:05 2018 +0530 @@ -957,7 +957,7 @@ charset x-IBM943C IBM943C package sun.nio.cs.ext - type source + type template alias cp943C # JDK historical alias ibm943C alias ibm-943C diff -r a76dd37b1c6b -r 99542925f318 make/data/charsetmapping/stdcs-aix --- a/make/data/charsetmapping/stdcs-aix Thu Apr 12 10:57:26 2018 +0530 +++ b/make/data/charsetmapping/stdcs-aix Thu Apr 12 23:26:05 2018 +0530 @@ -2,6 +2,7 @@ # generate these charsets into sun.nio.cs # Big5 +Big5_Solaris Big5_HKSCS EUC_CN EUC_KR @@ -10,6 +11,7 @@ IBM942 IBM942C IBM943 +IBM943C IBM950 IBM970 IBM1124 diff -r a76dd37b1c6b -r 99542925f318 src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM943C.java --- a/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM943C.java Thu Apr 12 10:57:26 2018 +0530 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,85 +0,0 @@ -/* - * Copyright (c) 2003, 2004, 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. - */ - -package sun.nio.cs.ext; - -import java.nio.charset.Charset; -import java.nio.charset.CharsetDecoder; -import java.nio.charset.CharsetEncoder; -import java.util.Arrays; -import sun.nio.cs.DoubleByte; -import sun.nio.cs.HistoricallyNamedCharset; - -public class IBM943C extends Charset implements HistoricallyNamedCharset -{ - - public IBM943C() { - super("x-IBM943C", ExtendedCharsets.aliasesFor("x-IBM943C")); - } - - public String historicalName() { - return "Cp943C"; - } - - public boolean contains(Charset cs) { - return ((cs.name().equals("US-ASCII")) - || (cs instanceof IBM943C)); - } - - public CharsetDecoder newDecoder() { - return new DoubleByte.Decoder(this, - IBM943.b2c, - b2cSB, - 0x40, - 0xfc); - } - - public CharsetEncoder newEncoder() { - return new DoubleByte.Encoder(this, c2b, c2bIndex); - } - - final static char[] b2cSB; - final static char[] c2b; - final static char[] c2bIndex; - - static { - IBM943.initb2c(); - b2cSB = new char[0x100]; - for (int i = 0; i < 0x80; i++) { - b2cSB[i] = (char)i; - } - for (int i = 0x80; i < 0x100; i++) { - b2cSB[i] = IBM943.b2cSB[i]; - } - - IBM943.initc2b(); - c2b = Arrays.copyOf(IBM943.c2b, IBM943.c2b.length); - c2bIndex = Arrays.copyOf(IBM943.c2bIndex, IBM943.c2bIndex.length); - for (char c = '\0'; c < '\u0080'; ++c) { - int index = c2bIndex[c >> 8]; - c2b[index + (c & 0xff)] = c; - } - } -} diff -r a76dd37b1c6b -r 99542925f318 src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM943C.java.template --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM943C.java.template Thu Apr 12 23:26:05 2018 +0530 @@ -0,0 +1,85 @@ +/* + * Copyright (c) 2003, 2004, 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. + */ + +package $PACKAGE$; + +import java.nio.charset.Charset; +import java.nio.charset.CharsetDecoder; +import java.nio.charset.CharsetEncoder; +import java.util.Arrays; +import sun.nio.cs.DoubleByte; +import sun.nio.cs.HistoricallyNamedCharset; + +public class IBM943C extends Charset implements HistoricallyNamedCharset +{ + + public IBM943C() { + super("x-IBM943C", $ALIASES$); + } + + public String historicalName() { + return "Cp943C"; + } + + public boolean contains(Charset cs) { + return ((cs.name().equals("US-ASCII")) + || (cs instanceof IBM943C)); + } + + public CharsetDecoder newDecoder() { + return new DoubleByte.Decoder(this, + IBM943.b2c, + b2cSB, + 0x40, + 0xfc); + } + + public CharsetEncoder newEncoder() { + return new DoubleByte.Encoder(this, c2b, c2bIndex); + } + + final static char[] b2cSB; + final static char[] c2b; + final static char[] c2bIndex; + + static { + IBM943.initb2c(); + b2cSB = new char[0x100]; + for (int i = 0; i < 0x80; i++) { + b2cSB[i] = (char)i; + } + for (int i = 0x80; i < 0x100; i++) { + b2cSB[i] = IBM943.b2cSB[i]; + } + + IBM943.initc2b(); + c2b = Arrays.copyOf(IBM943.c2b, IBM943.c2b.length); + c2bIndex = Arrays.copyOf(IBM943.c2bIndex, IBM943.c2bIndex.length); + for (char c = '\0'; c < '\u0080'; ++c) { + int index = c2bIndex[c >> 8]; + c2b[index + (c & 0xff)] = c; + } + } +} Thanks, Bhaktavatsal Reddy -----"core-libs-dev" wrote: ----- To: core-libs-dev at openjdk.java.net From: "Bhaktavatsal R Maram" Sent by: "core-libs-dev" Date: 04/12/2018 03:16PM Subject: Re: Missing many locales support on AIX platform Patch I attached to previous mail is not seen. So, pasting patch here. Hope, it is fine. # HG changeset patch # User bhamaram # Date 1523510846 -19800 # Node ID 6134bbe9861111f8cc42b055081f2c48e91039a8 # Parent 0c3e252cea44f06aef570ef464950ab97c669970 java.lang.IllegalArgumentException from java -version on AIX with different locales diff -r 0c3e252cea44 -r 6134bbe98611 make/data/charsetmapping/charsets --- a/make/data/charsetmapping/charsets Thu Apr 12 10:19:31 2018 +0800 +++ b/make/data/charsetmapping/charsets Thu Apr 12 10:57:26 2018 +0530 @@ -933,11 +933,16 @@ charset x-IBM942C IBM942C package sun.nio.cs.ext - type source + type template alias cp942C # JDK historical alias ibm942C alias ibm-942C alias 942C + alias cp932 + alias ibm932 + alias ibm-932 + alias 932 + alias x-ibm932 charset x-IBM943 IBM943 package sun.nio.cs.ext diff -r 0c3e252cea44 -r 6134bbe98611 make/data/charsetmapping/stdcs-aix --- a/make/data/charsetmapping/stdcs-aix Thu Apr 12 10:19:31 2018 +0800 +++ b/make/data/charsetmapping/stdcs-aix Thu Apr 12 10:57:26 2018 +0530 @@ -1,6 +1,16 @@ # # generate these charsets into sun.nio.cs # +Big5 +Big5_HKSCS EUC_CN EUC_KR GBK +GB18030 +IBM942 +IBM942C +IBM943 +IBM950 +IBM970 +IBM1124 +TIS_620 diff -r 0c3e252cea44 -r 6134bbe98611 src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java --- a/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java Thu Apr 12 10:19:31 2018 +0800 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,93 +0,0 @@ -/* - * Copyright (c) 2003, 2004, 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. - */ - -package sun.nio.cs.ext; - -import java.nio.charset.Charset; -import java.nio.charset.CharsetDecoder; -import java.nio.charset.CharsetEncoder; -import java.util.Arrays; -import sun.nio.cs.DoubleByte; -import sun.nio.cs.HistoricallyNamedCharset; -import static sun.nio.cs.CharsetMapping.*; - -public class IBM942C extends Charset implements HistoricallyNamedCharset -{ - public IBM942C() { - super("x-IBM942C", ExtendedCharsets.aliasesFor("x-IBM942C")); - } - - public String historicalName() { - return "Cp942C"; - } - - public boolean contains(Charset cs) { - return ((cs.name().equals("US-ASCII")) - || (cs instanceof IBM942C)); - } - - public CharsetDecoder newDecoder() { - return new DoubleByte.Decoder(this, - IBM942.b2c, - b2cSB, - 0x40, - 0xfc); - } - - public CharsetEncoder newEncoder() { - return new DoubleByte.Encoder(this, c2b, c2bIndex); - } - - final static char[] b2cSB; - final static char[] c2b; - final static char[] c2bIndex; - - static { - IBM942.initb2c(); - - // the mappings need udpate are - // u+001a <-> 0x1a - // u+001c <-> 0x1c - // u+005c <-> 0x5c - // u+007e <-> 0x7e - // u+007f <-> 0x7f - - b2cSB = Arrays.copyOf(IBM942.b2cSB, IBM942.b2cSB.length); - b2cSB[0x1a] = 0x1a; - b2cSB[0x1c] = 0x1c; - b2cSB[0x5c] = 0x5c; - b2cSB[0x7e] = 0x7e; - b2cSB[0x7f] = 0x7f; - - IBM942.initc2b(); - c2b = Arrays.copyOf(IBM942.c2b, IBM942.c2b.length); - c2bIndex = Arrays.copyOf(IBM942.c2bIndex, IBM942.c2bIndex.length); - c2b[c2bIndex[0] + 0x1a] = 0x1a; - c2b[c2bIndex[0] + 0x1c] = 0x1c; - c2b[c2bIndex[0] + 0x5c] = 0x5c; - c2b[c2bIndex[0] + 0x7e] = 0x7e; - c2b[c2bIndex[0] + 0x7f] = 0x7f; - } -} diff -r 0c3e252cea44 -r 6134bbe98611 src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java.template --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java.template Thu Apr 12 10:57:26 2018 +0530 @@ -0,0 +1,93 @@ +/* + * Copyright (c) 2003, 2004, 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. + */ + +package $PACKAGE$; + +import java.nio.charset.Charset; +import java.nio.charset.CharsetDecoder; +import java.nio.charset.CharsetEncoder; +import java.util.Arrays; +import sun.nio.cs.DoubleByte; +import sun.nio.cs.HistoricallyNamedCharset; +import static sun.nio.cs.CharsetMapping.*; + +public class IBM942C extends Charset implements HistoricallyNamedCharset +{ + public IBM942C() { + super("x-IBM942C", $ALIASES$); + } + + public String historicalName() { + return "Cp942C"; + } + + public boolean contains(Charset cs) { + return ((cs.name().equals("US-ASCII")) + || (cs instanceof IBM942C)); + } + + public CharsetDecoder newDecoder() { + return new DoubleByte.Decoder(this, + IBM942.b2c, + b2cSB, + 0x40, + 0xfc); + } + + public CharsetEncoder newEncoder() { + return new DoubleByte.Encoder(this, c2b, c2bIndex); + } + + final static char[] b2cSB; + final static char[] c2b; + final static char[] c2bIndex; + + static { + IBM942.initb2c(); + + // the mappings need udpate are + // u+001a <-> 0x1a + // u+001c <-> 0x1c + // u+005c <-> 0x5c + // u+007e <-> 0x7e + // u+007f <-> 0x7f + + b2cSB = Arrays.copyOf(IBM942.b2cSB, IBM942.b2cSB.length); + b2cSB[0x1a] = 0x1a; + b2cSB[0x1c] = 0x1c; + b2cSB[0x5c] = 0x5c; + b2cSB[0x7e] = 0x7e; + b2cSB[0x7f] = 0x7f; + + IBM942.initc2b(); + c2b = Arrays.copyOf(IBM942.c2b, IBM942.c2b.length); + c2bIndex = Arrays.copyOf(IBM942.c2bIndex, IBM942.c2bIndex.length); + c2b[c2bIndex[0] + 0x1a] = 0x1a; + c2b[c2bIndex[0] + 0x1c] = 0x1c; + c2b[c2bIndex[0] + 0x5c] = 0x5c; + c2b[c2bIndex[0] + 0x7e] = 0x7e; + c2b[c2bIndex[0] + 0x7f] = 0x7f; + } +} Thanks, Bhaktavatsal Reddy -----"core-libs-dev" wrote: ----- To: core-libs-dev at openjdk.java.net From: "Bhaktavatsal R Maram" Sent by: "core-libs-dev" Date: 04/12/2018 03:12PM Subject: Missing many locales support on AIX platform Hi, On AIX platforms, Java is not starting on many locales. Java initialization fails with java.lang.IllegalArgumentException bash-4.4$ LANG=Ja_JP java -version Error occurred during initialization of VM java.lang.IllegalArgumentException: Null charset name at java.nio.charset.Charset.lookup(java.base/Charset.java:455) at java.nio.charset.Charset.defaultCharset(java.base/Charset.java:608) at java.lang.StringCoding.decode(java.base/StringCoding.java:314) at java.lang.String.(java.base/String.java:591) at java.lang.String.(java.base/String.java:613) at java.lang.System.initProperties(java.base/Native Method) at java.lang.System.initPhase1(java.base/System.java:1908) >From our analysis, following are locales that are impacted with this issue. Ar_AA.IBM-1046 ar_AA.ISO8859-6 ca_ES.IBM-1252 at euro Iw_IL.IBM-856 iw_IL.ISO8859-8 Et_EE.IBM-922 at euro Ja_JP.IBM-932 Ja_JP.IBM-943 ja_JP.IBM-eucJP ko_KR.IBM-eucKR Lt_LT.IBM-921 at euro th_TH.TIS-620 Uk_UA.IBM-1124 Vi_VN.IBM-1129 Zh_CN.GB18030 zh_CN.IBM-eucCN Zh_HK.BIG5-HKSCS Zh_TW.big5 The default charset for these locales are not available in the java.base module and hence java cannot be used with those locales. In the current fix, am fixing the issue for following locales. Ja_JP.IBM-932 Ja_JP.IBM-943 ko_KR.IBM-eucKR th_TH.TIS-620 Uk_UA.IBM-1124 Zh_CN.GB18030 Zh_HK.BIG5-HKSCS Zh_TW.big5 I've attached fix with this mail. I will continue working on other locales and provide the fix. In the mean time, I kindly request you to open a bug and review the fix for the above locales. Thanks, Bhaktavatsal Reddy [attachment "patchv2.txt" removed by Bhaktavatsal R Maram/India/IBM] From Alan.Bateman at oracle.com Fri Apr 13 10:22:21 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 Apr 2018 11:22:21 +0100 Subject: Missing many locales support on AIX platform In-Reply-To: References: Message-ID: <59d3d31b-b596-0678-c0bf-69b8f951a40d@oracle.com> On 13/04/2018 10:35, Bhaktavatsal R Maram wrote: > Given that patch is big, I am sending patch as attachment again after changing some mail settings. Hopefully, it will make to community this time. Your patch was attached. If I read it correctly, you've switched IBM943C to a template but there aren't additional aliases so this part is effectively a no-op, is that right? For IBM932C, you've moved it to be template and added several aliases. The rest is AIX specific and I hope the SAP engineers that maintain the AIX port can help you. It may be that you are testing with locales that aren't supported configurations for the AIX port in OpenJDK. As a general point, we try to keep as many of the exotic and multibyte charsets out of java.base. They are of course still available to applications via the API and the jdk.charsets service provider module. -Alan From maurizio.cimadamore at oracle.com Fri Apr 13 10:43:28 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 13 Apr 2018 11:43:28 +0100 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: References: <5ACFBE5C.1080508@oracle.com> Message-ID: <4913267c-9341-29e8-611c-b8e7766a733a@oracle.com> One small followup question - the test SourceLauncherTest is not covering any shebang cases - is that deliberate? I see that those seem to be covered in the launcher test too, but I wonder if we should have tests for clearly broken stuff, such as '#' '#!' '#!\n' Another small question - I see that the shebang process essentially replaces the first line separator with \n - that is probably ok given that the file is processed internally after that - but I wonder if you have thought about pros and cons of preserving the original line separator. Cheers Maurizio On 12/04/18 21:46, Maurizio Cimadamore wrote: > Looks great - some initial comments (I can't really comment on the > launcher changes): > > * This logic is efficient: > > int magic = (in.read() << 8) + in.read(); > boolean shebang = magic == (('#' << 8) + '!'); > > but convoluted to read; perhaps could be improved slightly by making > '#' << 8) + '!' a static constant, and comparing against that. > > * I note that the reading logic in general could be simplified, e.g. > using Files.lines(Path) - but I assume that you wrote the code as is > for performance reasons (e.g. to avoid creating too many string > objects) ? > > * I see that both the file manager and the class loader reasonably > share the same context: a Map. I would make this more > explicit, by having a Context class, whose state is the map, and then > have the context provide two methods: > > getClassLoader() > getFileManager() > > This way the sharing will be automatic, no need to extract one field > from one place and pass it over to the other place. > > * Big whohoo for being able to use the enhanced diagnostic framework > with a couple of tweaks on the makefile - I hope that would have been > the case when I put in the support, but since we have never done it - > wasn't 100% sure it would work ;-) > > > Overall I like it quite a lot and I think you went for a really clean > design - kudos! > > Maurizio > > > > On 12/04/18 21:15, Jonathan Gibbons wrote: >> Please review an initial implementation for the feature described in >> JEP 330: Launch Single-File Source-Code Programs. >> >> The work is described in the JEP and CSR, and falls into various parts: >> >> ? * The part to handle the new command-line options is in the native >> ??? Java launcher code. >> ? * The part to invoke the compiler and subsequently execute the code >> ??? found in the source file is in a new class in the jdk.compiler >> module. >> ? * There are some minor Makefile changes, to add support for a new >> ??? resource file. >> >> There are no changes to javac itself. >> >> JEP: http://openjdk.java.net/jeps/330 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 >> Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ >> >> -- Jon > From bhamaram at in.ibm.com Fri Apr 13 12:42:02 2018 From: bhamaram at in.ibm.com (Bhaktavatsal R Maram) Date: Fri, 13 Apr 2018 12:42:02 +0000 Subject: Missing many locales support on AIX platform In-Reply-To: <59d3d31b-b596-0678-c0bf-69b8f951a40d@oracle.com> References: <59d3d31b-b596-0678-c0bf-69b8f951a40d@oracle.com>, Message-ID: Hi Alan, Thank you for your response. I'm happy that my patch was attached. But, I don't see attachment. So, I inlined patch which contain diffs from 2 changesets in mail text. If a Jira bug is opened for this issue, probably I can attach complete and consolidated patch there. At high level, I'm adding following charsets to standard charset in java.base. For this, I have to change IBM943C and IBM942C from source to template to handle java package and aliases. It is also required to add codepage 932 as alias for IBM942C because both are one and same. Big5, Big5_HKSCS, GB18030, IBM942, IBM942C, IBM943, IBM943C, IBM950, IBM970, IBM1124, TIS_620 These are default charsets for some of locales supported by Operating System (AIX). Since these are not available in standard charset, JDK can't be used in those locale even if they are available in jdk.charset module (java -version fails). I've followed some of the discussions around this in community and understand that default charset of a locale should be made available in java.charset module by using stdcs-* mechanism. On Linux, they were added to java.base in similar way. As it is missing for AIX, I've added them to enable JDK support for more locales. Thanks, Bhaktavatsal Reddy -----Alan Bateman wrote: ----- To: Bhaktavatsal R Maram , core-libs-dev at openjdk.java.net From: Alan Bateman Date: 04/13/2018 03:52PM Subject: Re: Missing many locales support on AIX platform On 13/04/2018 10:35, Bhaktavatsal R Maram wrote: > Given that patch is big, I am sending patch as attachment again after changing some mail settings. Hopefully, it will make to community this time. Your patch was attached. If I read it correctly, you've switched IBM943C to a template but there aren't additional aliases so this part is effectively a no-op, is that right? For IBM932C, you've moved it to be template and added several aliases. The rest is AIX specific and I hope the SAP engineers that maintain the AIX port can help you. It may be that you are testing with locales that aren't supported configurations for the AIX port in OpenJDK. As a general point, we try to keep as many of the exotic and multibyte charsets out of java.base. They are of course still available to applications via the API and the jdk.charsets service provider module. -Alan From roger.riggs at oracle.com Fri Apr 13 13:00:38 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 13 Apr 2018 09:00:38 -0400 Subject: Missing many locales support on AIX platform In-Reply-To: References: Message-ID: Hi, The question has come up before:?? [1] Most OpenJDK mailing lists, ..., allow these attachment types: text/plain text/x-diff text/x-patch message/rfc822 Attachments with the following filename extensions are dropped: exe bat cmd com pif scr vbs cpl Regards, Roger [1] http://mail.openjdk.java.net/pipermail/code-tools-dev/2018-March/000378.html On 4/13/18 5:37 AM, Bhaktavatsal R Maram wrote: > No luck! :( > > How can I attach patch? Any suggestions? > > Thanks, > Bhaktavatsal Reddy > > > > -----Bhaktavatsal R Maram/India/IBM wrote: ----- > To: core-libs-dev at openjdk.java.net > From: Bhaktavatsal R Maram/India/IBM > Date: 04/13/2018 03:05PM > Subject: Re: Missing many locales support on AIX platform > > Given that patch is big, I am sending patch as attachment again after changing some mail settings. Hopefully, it will make to community this time. > > Thanks, > Bhaktavatsal Reddy > > > > > -----Bhaktavatsal R Maram/India/IBM wrote: ----- > To: core-libs-dev at openjdk.java.net > From: Bhaktavatsal R Maram/India/IBM > Date: 04/12/2018 11:47PM > Subject: Re: Missing many locales support on AIX platform > > Please review this patch for this issue. I have added IBM-943C as well to standard charset along with IBM-943. > > # HG changeset patch > # User bhamaram > # Date 1523510846 -19800 > # Thu Apr 12 10:57:26 2018 +0530 > # Node ID a76dd37b1c6b47e7ac99f279c4ba76832dd9736f > # Parent 129d60b5dac71872f3317d94c724304100bc2048 > java.lang.IllegalArgumentException from java -version on AIX with different locales > > diff -r 129d60b5dac7 -r a76dd37b1c6b make/data/charsetmapping/charsets > --- a/make/data/charsetmapping/charsets Thu Apr 12 09:03:46 2018 -0400 > +++ b/make/data/charsetmapping/charsets Thu Apr 12 10:57:26 2018 +0530 > @@ -933,11 +933,16 @@ > > charset x-IBM942C IBM942C > package sun.nio.cs.ext > - type source > + type template > alias cp942C # JDK historical > alias ibm942C > alias ibm-942C > alias 942C > + alias cp932 > + alias ibm932 > + alias ibm-932 > + alias 932 > + alias x-ibm932 > > charset x-IBM943 IBM943 > package sun.nio.cs.ext > diff -r 129d60b5dac7 -r a76dd37b1c6b make/data/charsetmapping/stdcs-aix > --- a/make/data/charsetmapping/stdcs-aix Thu Apr 12 09:03:46 2018 -0400 > +++ b/make/data/charsetmapping/stdcs-aix Thu Apr 12 10:57:26 2018 +0530 > @@ -1,6 +1,16 @@ > # > # generate these charsets into sun.nio.cs > # > +Big5 > +Big5_HKSCS > EUC_CN > EUC_KR > GBK > +GB18030 > +IBM942 > +IBM942C > +IBM943 > +IBM950 > +IBM970 > +IBM1124 > +TIS_620 > diff -r 129d60b5dac7 -r a76dd37b1c6b src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java > --- a/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java Thu Apr 12 09:03:46 2018 -0400 > +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 > @@ -1,93 +0,0 @@ > -/* > - * Copyright (c) 2003, 2004, 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. > - */ > - > -package sun.nio.cs.ext; > - > -import java.nio.charset.Charset; > -import java.nio.charset.CharsetDecoder; > -import java.nio.charset.CharsetEncoder; > -import java.util.Arrays; > -import sun.nio.cs.DoubleByte; > -import sun.nio.cs.HistoricallyNamedCharset; > -import static sun.nio.cs.CharsetMapping.*; > - > -public class IBM942C extends Charset implements HistoricallyNamedCharset > -{ > - public IBM942C() { > - super("x-IBM942C", ExtendedCharsets.aliasesFor("x-IBM942C")); > - } > - > - public String historicalName() { > - return "Cp942C"; > - } > - > - public boolean contains(Charset cs) { > - return ((cs.name().equals("US-ASCII")) > - || (cs instanceof IBM942C)); > - } > - > - public CharsetDecoder newDecoder() { > - return new DoubleByte.Decoder(this, > - IBM942.b2c, > - b2cSB, > - 0x40, > - 0xfc); > - } > - > - public CharsetEncoder newEncoder() { > - return new DoubleByte.Encoder(this, c2b, c2bIndex); > - } > - > - final static char[] b2cSB; > - final static char[] c2b; > - final static char[] c2bIndex; > - > - static { > - IBM942.initb2c(); > - > - // the mappings need udpate are > - // u+001a <-> 0x1a > - // u+001c <-> 0x1c > - // u+005c <-> 0x5c > - // u+007e <-> 0x7e > - // u+007f <-> 0x7f > - > - b2cSB = Arrays.copyOf(IBM942.b2cSB, IBM942.b2cSB.length); > - b2cSB[0x1a] = 0x1a; > - b2cSB[0x1c] = 0x1c; > - b2cSB[0x5c] = 0x5c; > - b2cSB[0x7e] = 0x7e; > - b2cSB[0x7f] = 0x7f; > - > - IBM942.initc2b(); > - c2b = Arrays.copyOf(IBM942.c2b, IBM942.c2b.length); > - c2bIndex = Arrays.copyOf(IBM942.c2bIndex, IBM942.c2bIndex.length); > - c2b[c2bIndex[0] + 0x1a] = 0x1a; > - c2b[c2bIndex[0] + 0x1c] = 0x1c; > - c2b[c2bIndex[0] + 0x5c] = 0x5c; > - c2b[c2bIndex[0] + 0x7e] = 0x7e; > - c2b[c2bIndex[0] + 0x7f] = 0x7f; > - } > -} > diff -r 129d60b5dac7 -r a76dd37b1c6b src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java.template > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java.template Thu Apr 12 10:57:26 2018 +0530 > @@ -0,0 +1,93 @@ > +/* > + * Copyright (c) 2003, 2004, 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. > + */ > + > +package $PACKAGE$; > + > +import java.nio.charset.Charset; > +import java.nio.charset.CharsetDecoder; > +import java.nio.charset.CharsetEncoder; > +import java.util.Arrays; > +import sun.nio.cs.DoubleByte; > +import sun.nio.cs.HistoricallyNamedCharset; > +import static sun.nio.cs.CharsetMapping.*; > + > +public class IBM942C extends Charset implements HistoricallyNamedCharset > +{ > + public IBM942C() { > + super("x-IBM942C", $ALIASES$); > + } > + > + public String historicalName() { > + return "Cp942C"; > + } > + > + public boolean contains(Charset cs) { > + return ((cs.name().equals("US-ASCII")) > + || (cs instanceof IBM942C)); > + } > + > + public CharsetDecoder newDecoder() { > + return new DoubleByte.Decoder(this, > + IBM942.b2c, > + b2cSB, > + 0x40, > + 0xfc); > + } > + > + public CharsetEncoder newEncoder() { > + return new DoubleByte.Encoder(this, c2b, c2bIndex); > + } > + > + final static char[] b2cSB; > + final static char[] c2b; > + final static char[] c2bIndex; > + > + static { > + IBM942.initb2c(); > + > + // the mappings need udpate are > + // u+001a <-> 0x1a > + // u+001c <-> 0x1c > + // u+005c <-> 0x5c > + // u+007e <-> 0x7e > + // u+007f <-> 0x7f > + > + b2cSB = Arrays.copyOf(IBM942.b2cSB, IBM942.b2cSB.length); > + b2cSB[0x1a] = 0x1a; > + b2cSB[0x1c] = 0x1c; > + b2cSB[0x5c] = 0x5c; > + b2cSB[0x7e] = 0x7e; > + b2cSB[0x7f] = 0x7f; > + > + IBM942.initc2b(); > + c2b = Arrays.copyOf(IBM942.c2b, IBM942.c2b.length); > + c2bIndex = Arrays.copyOf(IBM942.c2bIndex, IBM942.c2bIndex.length); > + c2b[c2bIndex[0] + 0x1a] = 0x1a; > + c2b[c2bIndex[0] + 0x1c] = 0x1c; > + c2b[c2bIndex[0] + 0x5c] = 0x5c; > + c2b[c2bIndex[0] + 0x7e] = 0x7e; > + c2b[c2bIndex[0] + 0x7f] = 0x7f; > + } > +} > > # HG changeset patch > # User bhamaram > # Date 1523555765 -19800 > # Thu Apr 12 23:26:05 2018 +0530 > # Node ID 99542925f31823e5f337a0890499c2647b803629 > # Parent a76dd37b1c6b47e7ac99f279c4ba76832dd9736f > include IBM-943C to standard charset > > diff -r a76dd37b1c6b -r 99542925f318 make/data/charsetmapping/charsets > --- a/make/data/charsetmapping/charsets Thu Apr 12 10:57:26 2018 +0530 > +++ b/make/data/charsetmapping/charsets Thu Apr 12 23:26:05 2018 +0530 > @@ -957,7 +957,7 @@ > > charset x-IBM943C IBM943C > package sun.nio.cs.ext > - type source > + type template > alias cp943C # JDK historical > alias ibm943C > alias ibm-943C > diff -r a76dd37b1c6b -r 99542925f318 make/data/charsetmapping/stdcs-aix > --- a/make/data/charsetmapping/stdcs-aix Thu Apr 12 10:57:26 2018 +0530 > +++ b/make/data/charsetmapping/stdcs-aix Thu Apr 12 23:26:05 2018 +0530 > @@ -2,6 +2,7 @@ > # generate these charsets into sun.nio.cs > # > Big5 > +Big5_Solaris > Big5_HKSCS > EUC_CN > EUC_KR > @@ -10,6 +11,7 @@ > IBM942 > IBM942C > IBM943 > +IBM943C > IBM950 > IBM970 > IBM1124 > diff -r a76dd37b1c6b -r 99542925f318 src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM943C.java > --- a/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM943C.java Thu Apr 12 10:57:26 2018 +0530 > +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 > @@ -1,85 +0,0 @@ > -/* > - * Copyright (c) 2003, 2004, 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. > - */ > - > -package sun.nio.cs.ext; > - > -import java.nio.charset.Charset; > -import java.nio.charset.CharsetDecoder; > -import java.nio.charset.CharsetEncoder; > -import java.util.Arrays; > -import sun.nio.cs.DoubleByte; > -import sun.nio.cs.HistoricallyNamedCharset; > - > -public class IBM943C extends Charset implements HistoricallyNamedCharset > -{ > - > - public IBM943C() { > - super("x-IBM943C", ExtendedCharsets.aliasesFor("x-IBM943C")); > - } > - > - public String historicalName() { > - return "Cp943C"; > - } > - > - public boolean contains(Charset cs) { > - return ((cs.name().equals("US-ASCII")) > - || (cs instanceof IBM943C)); > - } > - > - public CharsetDecoder newDecoder() { > - return new DoubleByte.Decoder(this, > - IBM943.b2c, > - b2cSB, > - 0x40, > - 0xfc); > - } > - > - public CharsetEncoder newEncoder() { > - return new DoubleByte.Encoder(this, c2b, c2bIndex); > - } > - > - final static char[] b2cSB; > - final static char[] c2b; > - final static char[] c2bIndex; > - > - static { > - IBM943.initb2c(); > - b2cSB = new char[0x100]; > - for (int i = 0; i < 0x80; i++) { > - b2cSB[i] = (char)i; > - } > - for (int i = 0x80; i < 0x100; i++) { > - b2cSB[i] = IBM943.b2cSB[i]; > - } > - > - IBM943.initc2b(); > - c2b = Arrays.copyOf(IBM943.c2b, IBM943.c2b.length); > - c2bIndex = Arrays.copyOf(IBM943.c2bIndex, IBM943.c2bIndex.length); > - for (char c = '\0'; c < '\u0080'; ++c) { > - int index = c2bIndex[c >> 8]; > - c2b[index + (c & 0xff)] = c; > - } > - } > -} > diff -r a76dd37b1c6b -r 99542925f318 src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM943C.java.template > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM943C.java.template Thu Apr 12 23:26:05 2018 +0530 > @@ -0,0 +1,85 @@ > +/* > + * Copyright (c) 2003, 2004, 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. > + */ > + > +package $PACKAGE$; > + > +import java.nio.charset.Charset; > +import java.nio.charset.CharsetDecoder; > +import java.nio.charset.CharsetEncoder; > +import java.util.Arrays; > +import sun.nio.cs.DoubleByte; > +import sun.nio.cs.HistoricallyNamedCharset; > + > +public class IBM943C extends Charset implements HistoricallyNamedCharset > +{ > + > + public IBM943C() { > + super("x-IBM943C", $ALIASES$); > + } > + > + public String historicalName() { > + return "Cp943C"; > + } > + > + public boolean contains(Charset cs) { > + return ((cs.name().equals("US-ASCII")) > + || (cs instanceof IBM943C)); > + } > + > + public CharsetDecoder newDecoder() { > + return new DoubleByte.Decoder(this, > + IBM943.b2c, > + b2cSB, > + 0x40, > + 0xfc); > + } > + > + public CharsetEncoder newEncoder() { > + return new DoubleByte.Encoder(this, c2b, c2bIndex); > + } > + > + final static char[] b2cSB; > + final static char[] c2b; > + final static char[] c2bIndex; > + > + static { > + IBM943.initb2c(); > + b2cSB = new char[0x100]; > + for (int i = 0; i < 0x80; i++) { > + b2cSB[i] = (char)i; > + } > + for (int i = 0x80; i < 0x100; i++) { > + b2cSB[i] = IBM943.b2cSB[i]; > + } > + > + IBM943.initc2b(); > + c2b = Arrays.copyOf(IBM943.c2b, IBM943.c2b.length); > + c2bIndex = Arrays.copyOf(IBM943.c2bIndex, IBM943.c2bIndex.length); > + for (char c = '\0'; c < '\u0080'; ++c) { > + int index = c2bIndex[c >> 8]; > + c2b[index + (c & 0xff)] = c; > + } > + } > +} > > > Thanks, > Bhaktavatsal Reddy > > > > -----"core-libs-dev" wrote: ----- > To: core-libs-dev at openjdk.java.net > From: "Bhaktavatsal R Maram" > Sent by: "core-libs-dev" > Date: 04/12/2018 03:16PM > Subject: Re: Missing many locales support on AIX platform > > Patch I attached to previous mail is not seen. So, pasting patch here. Hope, it is fine. > > > # HG changeset patch > # User bhamaram > # Date 1523510846 -19800 > # Node ID 6134bbe9861111f8cc42b055081f2c48e91039a8 > # Parent 0c3e252cea44f06aef570ef464950ab97c669970 > java.lang.IllegalArgumentException from java -version on AIX with different locales > > diff -r 0c3e252cea44 -r 6134bbe98611 make/data/charsetmapping/charsets > --- a/make/data/charsetmapping/charsets Thu Apr 12 10:19:31 2018 +0800 > +++ b/make/data/charsetmapping/charsets Thu Apr 12 10:57:26 2018 +0530 > @@ -933,11 +933,16 @@ > > charset x-IBM942C IBM942C > package sun.nio.cs.ext > - type source > + type template > alias cp942C # JDK historical > alias ibm942C > alias ibm-942C > alias 942C > + alias cp932 > + alias ibm932 > + alias ibm-932 > + alias 932 > + alias x-ibm932 > > charset x-IBM943 IBM943 > package sun.nio.cs.ext > diff -r 0c3e252cea44 -r 6134bbe98611 make/data/charsetmapping/stdcs-aix > --- a/make/data/charsetmapping/stdcs-aix Thu Apr 12 10:19:31 2018 +0800 > +++ b/make/data/charsetmapping/stdcs-aix Thu Apr 12 10:57:26 2018 +0530 > @@ -1,6 +1,16 @@ > # > # generate these charsets into sun.nio.cs > # > +Big5 > +Big5_HKSCS > EUC_CN > EUC_KR > GBK > +GB18030 > +IBM942 > +IBM942C > +IBM943 > +IBM950 > +IBM970 > +IBM1124 > +TIS_620 > diff -r 0c3e252cea44 -r 6134bbe98611 src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java > --- a/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java Thu Apr 12 10:19:31 2018 +0800 > +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 > @@ -1,93 +0,0 @@ > -/* > - * Copyright (c) 2003, 2004, 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. > - */ > - > -package sun.nio.cs.ext; > - > -import java.nio.charset.Charset; > -import java.nio.charset.CharsetDecoder; > -import java.nio.charset.CharsetEncoder; > -import java.util.Arrays; > -import sun.nio.cs.DoubleByte; > -import sun.nio.cs.HistoricallyNamedCharset; > -import static sun.nio.cs.CharsetMapping.*; > - > -public class IBM942C extends Charset implements HistoricallyNamedCharset > -{ > - public IBM942C() { > - super("x-IBM942C", ExtendedCharsets.aliasesFor("x-IBM942C")); > - } > - > - public String historicalName() { > - return "Cp942C"; > - } > - > - public boolean contains(Charset cs) { > - return ((cs.name().equals("US-ASCII")) > - || (cs instanceof IBM942C)); > - } > - > - public CharsetDecoder newDecoder() { > - return new DoubleByte.Decoder(this, > - IBM942.b2c, > - b2cSB, > - 0x40, > - 0xfc); > - } > - > - public CharsetEncoder newEncoder() { > - return new DoubleByte.Encoder(this, c2b, c2bIndex); > - } > - > - final static char[] b2cSB; > - final static char[] c2b; > - final static char[] c2bIndex; > - > - static { > - IBM942.initb2c(); > - > - // the mappings need udpate are > - // u+001a <-> 0x1a > - // u+001c <-> 0x1c > - // u+005c <-> 0x5c > - // u+007e <-> 0x7e > - // u+007f <-> 0x7f > - > - b2cSB = Arrays.copyOf(IBM942.b2cSB, IBM942.b2cSB.length); > - b2cSB[0x1a] = 0x1a; > - b2cSB[0x1c] = 0x1c; > - b2cSB[0x5c] = 0x5c; > - b2cSB[0x7e] = 0x7e; > - b2cSB[0x7f] = 0x7f; > - > - IBM942.initc2b(); > - c2b = Arrays.copyOf(IBM942.c2b, IBM942.c2b.length); > - c2bIndex = Arrays.copyOf(IBM942.c2bIndex, IBM942.c2bIndex.length); > - c2b[c2bIndex[0] + 0x1a] = 0x1a; > - c2b[c2bIndex[0] + 0x1c] = 0x1c; > - c2b[c2bIndex[0] + 0x5c] = 0x5c; > - c2b[c2bIndex[0] + 0x7e] = 0x7e; > - c2b[c2bIndex[0] + 0x7f] = 0x7f; > - } > -} > diff -r 0c3e252cea44 -r 6134bbe98611 src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java.template > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java.template Thu Apr 12 10:57:26 2018 +0530 > @@ -0,0 +1,93 @@ > +/* > + * Copyright (c) 2003, 2004, 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. > + */ > + > +package $PACKAGE$; > + > +import java.nio.charset.Charset; > +import java.nio.charset.CharsetDecoder; > +import java.nio.charset.CharsetEncoder; > +import java.util.Arrays; > +import sun.nio.cs.DoubleByte; > +import sun.nio.cs.HistoricallyNamedCharset; > +import static sun.nio.cs.CharsetMapping.*; > + > +public class IBM942C extends Charset implements HistoricallyNamedCharset > +{ > + public IBM942C() { > + super("x-IBM942C", $ALIASES$); > + } > + > + public String historicalName() { > + return "Cp942C"; > + } > + > + public boolean contains(Charset cs) { > + return ((cs.name().equals("US-ASCII")) > + || (cs instanceof IBM942C)); > + } > + > + public CharsetDecoder newDecoder() { > + return new DoubleByte.Decoder(this, > + IBM942.b2c, > + b2cSB, > + 0x40, > + 0xfc); > + } > + > + public CharsetEncoder newEncoder() { > + return new DoubleByte.Encoder(this, c2b, c2bIndex); > + } > + > + final static char[] b2cSB; > + final static char[] c2b; > + final static char[] c2bIndex; > + > + static { > + IBM942.initb2c(); > + > + // the mappings need udpate are > + // u+001a <-> 0x1a > + // u+001c <-> 0x1c > + // u+005c <-> 0x5c > + // u+007e <-> 0x7e > + // u+007f <-> 0x7f > + > + b2cSB = Arrays.copyOf(IBM942.b2cSB, IBM942.b2cSB.length); > + b2cSB[0x1a] = 0x1a; > + b2cSB[0x1c] = 0x1c; > + b2cSB[0x5c] = 0x5c; > + b2cSB[0x7e] = 0x7e; > + b2cSB[0x7f] = 0x7f; > + > + IBM942.initc2b(); > + c2b = Arrays.copyOf(IBM942.c2b, IBM942.c2b.length); > + c2bIndex = Arrays.copyOf(IBM942.c2bIndex, IBM942.c2bIndex.length); > + c2b[c2bIndex[0] + 0x1a] = 0x1a; > + c2b[c2bIndex[0] + 0x1c] = 0x1c; > + c2b[c2bIndex[0] + 0x5c] = 0x5c; > + c2b[c2bIndex[0] + 0x7e] = 0x7e; > + c2b[c2bIndex[0] + 0x7f] = 0x7f; > + } > +} > > > Thanks, > Bhaktavatsal Reddy > > > > > -----"core-libs-dev" wrote: ----- > To: core-libs-dev at openjdk.java.net > From: "Bhaktavatsal R Maram" > Sent by: "core-libs-dev" > Date: 04/12/2018 03:12PM > Subject: Missing many locales support on AIX platform > > Hi, > > On AIX platforms, Java is not starting on many locales. Java initialization fails with java.lang.IllegalArgumentException > > bash-4.4$ LANG=Ja_JP java -version > Error occurred during initialization of VM > java.lang.IllegalArgumentException: Null charset name > at java.nio.charset.Charset.lookup(java.base/Charset.java:455) > at java.nio.charset.Charset.defaultCharset(java.base/Charset.java:608) > at java.lang.StringCoding.decode(java.base/StringCoding.java:314) > at java.lang.String.(java.base/String.java:591) > at java.lang.String.(java.base/String.java:613) > at java.lang.System.initProperties(java.base/Native Method) > at java.lang.System.initPhase1(java.base/System.java:1908) > > From our analysis, following are locales that are impacted with this issue. > > Ar_AA.IBM-1046 > ar_AA.ISO8859-6 > ca_ES.IBM-1252 at euro > Iw_IL.IBM-856 > iw_IL.ISO8859-8 > Et_EE.IBM-922 at euro > Ja_JP.IBM-932 > Ja_JP.IBM-943 > ja_JP.IBM-eucJP > ko_KR.IBM-eucKR > Lt_LT.IBM-921 at euro > th_TH.TIS-620 > Uk_UA.IBM-1124 > Vi_VN.IBM-1129 > Zh_CN.GB18030 > zh_CN.IBM-eucCN > Zh_HK.BIG5-HKSCS > Zh_TW.big5 > > > The default charset for these locales are not available in the java.base module and hence java cannot be used with those locales. In the current fix, am fixing the issue for following locales. > > Ja_JP.IBM-932 > Ja_JP.IBM-943 > ko_KR.IBM-eucKR > th_TH.TIS-620 > Uk_UA.IBM-1124 > Zh_CN.GB18030 > Zh_HK.BIG5-HKSCS > Zh_TW.big5 > > I've attached fix with this mail. I will continue working on other locales and provide the fix. In the mean time, I kindly request you to open a bug and review the fix for the above locales. > > Thanks, > Bhaktavatsal Reddy > > > > > > [attachment "patchv2.txt" removed by Bhaktavatsal R Maram/India/IBM] > From adam.farley at uk.ibm.com Fri Apr 13 14:14:49 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Fri, 13 Apr 2018 15:14:49 +0100 Subject: [PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for Direct Byte Buffers Message-ID: Hi Alan, Peter, I see that native memory is tracked in java.nio.Bits, but that only includes what the user thinks they are allocating. When the VM adds extra memory to the allocation amount this extra bit is not represented in the Bits total. A cursory glance shows, minimum, that we round the requested memory quantity up to the heap word size in the Unsafe.allocateMemory code, and something to do with nmt_header_size in os:malloc() (os.cpp) too. Here's a set of solutions for the problem of "what you see isn't what you get" for DBBs (3 is my favourite, but I suspect 2 is the most likely to be accepted): 1) Use the code below to call DBB-specific Unsafe methods, allowing us to track the quantity of native memory reserved for DBBs at the point of allocation. Pros: - Doesn't require changing the Bits class. - Allows us to easily devise a list of DBB native memory allocation locations. - Fits with existing OpenJ9 code, which tracks DBB memory usage *after* native code has added to the total memory requested, resulting in more accurate totals than Bits. Cons: - Requires some work on the Hotspot side to make it happen if Hotspot users want the true benefit. OR - Requires a commit that only benefits Java if you're running on the OpenJ9 VM. 2) Modify the Bits code to interrogate the VM via an extra method in Unsafe, in order to determine the true quantity of native memory that is being allocated. E.g. User requests 10 bits, VM says it needs +2, add 12 to cumulative total, return "true". User later says to free 10 bits, VM says it needs +2, so we subtract 12 from the total. Note: For consistency, the VM and Bits should use the same code when figuring out how much space will be added to the request by the VM. Pros: - Much smaller change than (1) - Makes Bits much more accurate. - Retains the Bits interface, and doesn't require a change to Unsafe. Cons: - Requires us to add a native method to Bits, or somewhere visible to Bits. 3) Modify the Bits code to use an internal array for memory reservations, returns an index. The user can use this index to: - Return the amount of memory they requested. - Return the amount of memory the VM will actually reserve (Bits will retrieve this from the VM via a native method). - Set the address the VM gave them for this reservation. - Free the memory reserved. Note: The existing internal totals, along with Shared Secrets, remain. Pros: - *Much* more accurate memory tracking for DBBs. - Easier debugging for DBB overruns, as we know where all the DBBs are. - Prevents the user trying to free too much or too little memory for an allocated DBB. Cons: - Many changes to Bits. - Native code changes. - Probably best to restructure the memory allocation code to share the same logic (abstracting out the size+x gubbins so Bits' new native code logic remains up to date). Any thoughts? - Adam >> Hi Adam, >> >> Did you know that native memory is already tracked on the Java side for >> direct ByteBuffers? See class java.nio.Bits. Could you make use of it? >> > Right, these are the fields that are exposed at runtime via > BufferPoolMXBean. A SA based tool could read from a core file. I can't > tell if this is enough for Adam, it may be that the his tool reveals > more details on the buffers in the pools. > > -Alan P.S. Code: diff --git a/src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template b/src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template --- a/src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template +++ b/src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template @@ -85,7 +85,7 @@ // Paranoia return; } - UNSAFE.freeMemory(address); + UNSAFE.freeDBBMemory(address); address = 0; Bits.unreserveMemory(size, capacity); } @@ -118,7 +118,7 @@ long base = 0; try { - base = UNSAFE.allocateMemory(size); + base = UNSAFE.allocateDBBMemory(size); } catch (OutOfMemoryError x) { Bits.unreserveMemory(size, cap); throw x; diff --git a/src/java.base/share/classes/jdk/internal/misc/Unsafe.java b/src/java.base/share/classes/jdk/internal/misc/Unsafe.java --- a/src/java.base/share/classes/jdk/internal/misc/Unsafe.java +++ b/src/java.base/share/classes/jdk/internal/misc/Unsafe.java @@ -632,6 +632,26 @@ } /** + * Allocates a new block of native memory for DirectByteBuffers, of the + * given size in bytes. The contents of the memory are uninitialized; + * they will generally be garbage. The resulting native pointer will + * never be zero, and will be aligned for all value types. Dispose of + * this memory by calling {@link #freeDBBMemory} or resize it with + * {@link #reallocateDBBMemory}. + * + * @throws RuntimeException if the size is negative or too large + * for the native size_t type + * + * @throws OutOfMemoryError if the allocation is refused by the system + * + * @see #getByte(long) + * @see #putByte(long, byte) + */ + public long allocateDBBMemory(long bytes) { + return allocateMemory(bytes); + } + + /** * Resizes a new block of native memory, to the given size in bytes. The * contents of the new block past the size of the old block are * uninitialized; they will generally be garbage. The resulting native @@ -687,6 +707,27 @@ } /** + * Resizes a new block of native memory for DirectByteBuffers, to the + * given size in bytes. The contents of the new block past the size of + * the old block are uninitialized; they will generally be garbage. The + * resulting native pointer will be zero if and only if the requested size + * is zero. The resulting native pointer will be aligned for all value + * types. Dispose of this memory by calling {@link #freeDBBMemory}, or + * resize it with {@link #reallocateDBBMemory}. The address passed to + * this method may be null, in which case an allocation will be performed. + * + * @throws RuntimeException if the size is negative or too large + * for the native size_t type + * + * @throws OutOfMemoryError if the allocation is refused by the system + * + * @see #allocateDBBMemory + */ + public long reallocateDBBMemory(long address, long bytes) { + return reallocateMemory(address, bytes); + } + + /** * Sets all bytes in a given block of memory to a fixed value * (usually zero). * @@ -918,6 +959,17 @@ checkPointer(null, address); } + /** + * Disposes of a block of native memory, as obtained from {@link + * #allocateDBBMemory} or {@link #reallocateDBBMemory}. The address passed + * to this method may be null, in which case no action is taken. + * + * @see #allocateDBBMemory + */ + public void freeDBBMemory(long address) { + freeMemory(address); + } + /// random queries /** Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From jai.forums2013 at gmail.com Fri Apr 13 14:29:26 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 13 Apr 2018 19:59:26 +0530 Subject: InetAddress.getByName/getAllByName for empty host string Message-ID: <5ad894e2-7231-1827-672d-47b307586675@gmail.com> The javadoc of InetAddress.getByName(host) and getAllByName(host) states that: If the host is null then an InetAddress representing an address of the loopback interface is returned. For non-null values the javadoc explains what the implementation does. However, there seems to be no mention of what it does with an empty string (length == 0) value for the host param. Right now, the implementation seems to treat an empty value the same way it treats the host == null case and returns an InetAddress representing the loopback address. Consider the following example: public class InetAddressTest { ??? public static void main(final String[] args) throws Exception { ??? ??? System.out.println("InetAddress.getByName() for empty string returns " + java.net.InetAddress.getByName("")); ??? ??? System.out.println("InetAddress.getAllByName() for empty string returns " ??? ??? ??? + java.util.Arrays.toString(java.net.InetAddress.getAllByName(""))); ??? } } This outputs: InetAddress.getByName() for empty string returns localhost/127.0.0.1 InetAddress.getAllByName() for empty string returns [localhost/127.0.0.1] Is it intentional for these APIs to behave this way for empty string? If so, should the javadoc be updated to explicitly state this behaviour? -Jaikiran From chris.hegarty at oracle.com Fri Apr 13 15:11:14 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 13 Apr 2018 16:11:14 +0100 Subject: InetAddress.getByName/getAllByName for empty host string In-Reply-To: <5ad894e2-7231-1827-672d-47b307586675@gmail.com> References: <5ad894e2-7231-1827-672d-47b307586675@gmail.com> Message-ID: <06e1513a-c511-e28f-9acb-282bee6a0cab@oracle.com> Hi Jaikiran, On 13/04/18 15:29, Jaikiran Pai wrote: > The javadoc of InetAddress.getByName(host) and getAllByName(host) states > that: > > If the host is null then an InetAddress representing an address of the > loopback interface is returned. > > For non-null values the javadoc explains what the implementation does. > However, there seems to be no mention of what it does with an empty > string (length == 0) value for the host param. Right now, the > implementation seems to treat an empty value the same way it treats the > host == null case and returns an InetAddress representing the loopback > address. > > Consider the following example: > > public class InetAddressTest { > public static void main(final String[] args) throws Exception { > System.out.println("InetAddress.getByName() for empty string > returns " + java.net.InetAddress.getByName("")); > System.out.println("InetAddress.getAllByName() for empty string > returns " > + > java.util.Arrays.toString(java.net.InetAddress.getAllByName(""))); > > } > } > > This outputs: > > InetAddress.getByName() for empty string returns localhost/127.0.0.1 > InetAddress.getAllByName() for empty string returns [localhost/127.0.0.1] > > > Is it intentional for these APIs to behave this way for empty string? Yes. > If > so, should the javadoc be updated to explicitly state this behaviour? Yeah, probably. The following JIRA issue has been filed to track this: https://bugs.openjdk.java.net/browse/JDK-8201545 -Chris. From volker.simonis at gmail.com Fri Apr 13 15:21:25 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 13 Apr 2018 17:21:25 +0200 Subject: Missing many locales support on AIX platform In-Reply-To: References: <59d3d31b-b596-0678-c0bf-69b8f951a40d@oracle.com> Message-ID: Hi Bhaktavatsal Reddy, thanks for addressing this long standing issue. I've opened "8201540: [AIX] Extend the set of supported charsets in java.base" [1] to track this issue. As I wrote in the bug report, this problem is the consequence of an emergency fix (JDK-8081332) I did back in 2015 to fix the build on AIX after the integration of the modularity support change (see discussion: [2]). At that time I only added the minimal set of charsets which were required to fix the build. It would be great if you can get in touch with your IBM colleagues to find out which are the default extended charsets supported by IBM J9 on AIX. I think we should try to use a similar set here in our OpenJDK port which is also used by the OpenJ9 for building OpenJ9 on AIX. Also, your IBM colleagues can help you to host a webrev which will make the further review of these changes much easier. I've but Tim from IBM on CC which should have an overview of all the IBM people involved in the OpenJDK project. Besides that I know at least the following people who might help you: Michihiro Horie: HORIE at jp.ibm.com Hiroshi H Horii: horii at jp.ibm.com Gustavo Romero: gromero at linux.vnet.ibm.com Matthew Brandyberyy: mbrandy at linux.vnet.ibm.com Thank you and best regards, Volker [1] https://bugs.openjdk.java.net/browse/JDK-8201540 [2] http://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005431.html On Fri, Apr 13, 2018 at 2:42 PM, Bhaktavatsal R Maram wrote: > Hi Alan, > > Thank you for your response. I'm happy that my patch was attached. But, I don't see attachment. So, I inlined patch which contain diffs from 2 changesets in mail text. If a Jira bug is opened for this issue, probably I can attach complete and consolidated patch there. > > At high level, I'm adding following charsets to standard charset in java.base. For this, I have to change IBM943C and IBM942C from source to template to handle java package and aliases. It is also required to add codepage 932 as alias for IBM942C because both are one and same. > > Big5, Big5_HKSCS, GB18030, IBM942, IBM942C, IBM943, IBM943C, IBM950, IBM970, IBM1124, TIS_620 > > > These are default charsets for some of locales supported by Operating System (AIX). Since these are not available in standard charset, JDK can't be used in those locale even if they are available in jdk.charset module (java -version fails). > > I've followed some of the discussions around this in community and understand that default charset of a locale should be made available in java.charset module by using stdcs-* mechanism. On Linux, they were added to java.base in similar way. As it is missing for AIX, I've added them to enable JDK support for more locales. > > > Thanks, > Bhaktavatsal Reddy > > -----Alan Bateman wrote: ----- > To: Bhaktavatsal R Maram , core-libs-dev at openjdk.java.net > From: Alan Bateman > Date: 04/13/2018 03:52PM > Subject: Re: Missing many locales support on AIX platform > > On 13/04/2018 10:35, Bhaktavatsal R Maram wrote: >> Given that patch is big, I am sending patch as attachment again after changing some mail settings. Hopefully, it will make to community this time. > Your patch was attached. > > If I read it correctly, you've switched IBM943C to a template but there > aren't additional aliases so this part is effectively a no-op, is that > right? For IBM932C, you've moved it to be template and added several > aliases. > > The rest is AIX specific and I hope the SAP engineers that maintain the > AIX port can help you. It may be that you are testing with locales that > aren't supported configurations for the AIX port in OpenJDK. As a > general point, we try to keep as many of the exotic and multibyte > charsets out of java.base. They are of course still available to > applications via the API and the jdk.charsets service provider module. > > -Alan > > From jai.forums2013 at gmail.com Fri Apr 13 15:29:20 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 13 Apr 2018 20:59:20 +0530 Subject: InetAddress.getByName/getAllByName for empty host string In-Reply-To: <06e1513a-c511-e28f-9acb-282bee6a0cab@oracle.com> References: <5ad894e2-7231-1827-672d-47b307586675@gmail.com> <06e1513a-c511-e28f-9acb-282bee6a0cab@oracle.com> Message-ID: <28d02a89-1697-3736-853c-9f32dea262d5@gmail.com> Hi Chris, Thank you creating that JIRA. If the fix involves just updating the javadoc, is this something that youwould like me to contribute as a patch? I have a signed and approved OCA, but I will need a sponsor if I do come up with the patch. -Jaikiran On 13/04/18 8:41 PM, Chris Hegarty wrote: > Hi Jaikiran, > > On 13/04/18 15:29, Jaikiran Pai wrote: >> The javadoc of InetAddress.getByName(host) and getAllByName(host) >> states that: >> >> If the host is null then an InetAddress representing an address of >> the loopback interface is returned. >> >> For non-null values the javadoc explains what the implementation >> does. However, there seems to be no mention of what it does with an >> empty string (length == 0) value for the host param. Right now, the >> implementation seems to treat an empty value the same way it treats >> the host == null case and returns an InetAddress representing the >> loopback address. >> >> Consider the following example: >> >> public class InetAddressTest { >> ???? public static void main(final String[] args) throws Exception { >> ???????? System.out.println("InetAddress.getByName() for empty string >> returns " + java.net.InetAddress.getByName("")); >> ???????? System.out.println("InetAddress.getAllByName() for empty >> string returns " >> ???????????? + >> java.util.Arrays.toString(java.net.InetAddress.getAllByName(""))); >> >> ???? } >> } >> >> This outputs: >> >> InetAddress.getByName() for empty string returns localhost/127.0.0.1 >> InetAddress.getAllByName() for empty string returns >> [localhost/127.0.0.1] >> >> >> Is it intentional for these APIs to behave this way for empty string? > > Yes. > >> If so, should the javadoc be updated to explicitly state this behaviour? > > Yeah, probably. > > The following JIRA issue has been filed to track this: > ? https://bugs.openjdk.java.net/browse/JDK-8201545 > > -Chris. From bhamaram at in.ibm.com Fri Apr 13 15:31:05 2018 From: bhamaram at in.ibm.com (Bhaktavatsal R Maram) Date: Fri, 13 Apr 2018 15:31:05 +0000 Subject: Missing many locales support on AIX platform In-Reply-To: References: , <59d3d31b-b596-0678-c0bf-69b8f951a40d@oracle.com> Message-ID: Hi Volker, Thank you. I will take help of my colleagues and host webrev with all the default charsets that are missing for AIX. - Bhaktavatsal Reddy -----Volker Simonis wrote: ----- To: Bhaktavatsal R Maram From: Volker Simonis Date: 04/13/2018 08:51PM Cc: Alan Bateman , Java Core Libs , Tim Ellison , ppc-aix-port-dev at openjdk.java.net Subject: Re: Missing many locales support on AIX platform Hi Bhaktavatsal Reddy, thanks for addressing this long standing issue. I've opened "8201540: [AIX] Extend the set of supported charsets in java.base" [1] to track this issue. As I wrote in the bug report, this problem is the consequence of an emergency fix (JDK-8081332) I did back in 2015 to fix the build on AIX after the integration of the modularity support change (see discussion: [2]). At that time I only added the minimal set of charsets which were required to fix the build. It would be great if you can get in touch with your IBM colleagues to find out which are the default extended charsets supported by IBM J9 on AIX. I think we should try to use a similar set here in our OpenJDK port which is also used by the OpenJ9 for building OpenJ9 on AIX. Also, your IBM colleagues can help you to host a webrev which will make the further review of these changes much easier. I've but Tim from IBM on CC which should have an overview of all the IBM people involved in the OpenJDK project. Besides that I know at least the following people who might help you: Michihiro Horie: HORIE at jp.ibm.com Hiroshi H Horii: horii at jp.ibm.com Gustavo Romero: gromero at linux.vnet.ibm.com Matthew Brandyberyy: mbrandy at linux.vnet.ibm.com Thank you and best regards, Volker [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8201540&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=cieXGANE8bD3liEC2gJzl5hfZorR2qIfggL6U9t-Et8&s=hC4gcA6uomYgY26uR74VelobSIK1ReDsjRZGmI46UBY&e= [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_2d-2Ddev_2015-2DMay_005431.html&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=cieXGANE8bD3liEC2gJzl5hfZorR2qIfggL6U9t-Et8&s=qfYLaVVn7tapNDhv5bY6yE72nhngaWqte4wtRhQ3wB8&e= On Fri, Apr 13, 2018 at 2:42 PM, Bhaktavatsal R Maram wrote: > Hi Alan, > > Thank you for your response. I'm happy that my patch was attached. But, I don't see attachment. So, I inlined patch which contain diffs from 2 changesets in mail text. If a Jira bug is opened for this issue, probably I can attach complete and consolidated patch there. > > At high level, I'm adding following charsets to standard charset in java.base. For this, I have to change IBM943C and IBM942C from source to template to handle java package and aliases. It is also required to add codepage 932 as alias for IBM942C because both are one and same. > > Big5, Big5_HKSCS, GB18030, IBM942, IBM942C, IBM943, IBM943C, IBM950, IBM970, IBM1124, TIS_620 > > > These are default charsets for some of locales supported by Operating System (AIX). Since these are not available in standard charset, JDK can't be used in those locale even if they are available in jdk.charset module (java -version fails). > > I've followed some of the discussions around this in community and understand that default charset of a locale should be made available in java.charset module by using stdcs-* mechanism. On Linux, they were added to java.base in similar way. As it is missing for AIX, I've added them to enable JDK support for more locales. > > > Thanks, > Bhaktavatsal Reddy > > -----Alan Bateman wrote: ----- > To: Bhaktavatsal R Maram , core-libs-dev at openjdk.java.net > From: Alan Bateman > Date: 04/13/2018 03:52PM > Subject: Re: Missing many locales support on AIX platform > > On 13/04/2018 10:35, Bhaktavatsal R Maram wrote: >> Given that patch is big, I am sending patch as attachment again after changing some mail settings. Hopefully, it will make to community this time. > Your patch was attached. > > If I read it correctly, you've switched IBM943C to a template but there > aren't additional aliases so this part is effectively a no-op, is that > right? For IBM932C, you've moved it to be template and added several > aliases. > > The rest is AIX specific and I hope the SAP engineers that maintain the > AIX port can help you. It may be that you are testing with locales that > aren't supported configurations for the AIX port in OpenJDK. As a > general point, we try to keep as many of the exotic and multibyte > charsets out of java.base. They are of course still available to > applications via the API and the jdk.charsets service provider module. > > -Alan > > From erik.joelsson at oracle.com Fri Apr 13 15:50:11 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 13 Apr 2018 08:50:11 -0700 Subject: [11] RFR: 8201507: Generate alias entries in j.t.f.ZoneName from tzdb at build time In-Reply-To: References: Message-ID: <60d3bcd2-f9a2-64bb-4866-c6ee881d5ab4@oracle.com> Build changes look good. /Erik On 2018-04-12 17:34, Naoto Sato wrote: > Hi, > > Please review the fix to the subject issue. While fixing 8189784 [1], > I noticed that not only CLDR zones but also tzdb link entries are also > hard coded. So I further modified j.t.f.ZoneName to generate tzdb > entries at the build time. > > The issue: https://bugs.openjdk.java.net/browse/JDK-8201507 > Fix: http://cr.openjdk.java.net/~naoto/8201507/webrev.00/ > > Like the last time, including build-dev for makefile modification review. > > Naoto > > [1] > http://mail.openjdk.java.net/pipermail/i18n-dev/2018-April/002492.html From roger.riggs at oracle.com Fri Apr 13 16:47:20 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 13 Apr 2018 12:47:20 -0400 Subject: [11] RFR: 8201507: Generate alias entries in j.t.f.ZoneName from tzdb at build time In-Reply-To: References: Message-ID: Hi Naoto, Looks fine. Regards, Roger On 4/12/18 8:34 PM, Naoto Sato wrote: > Hi, > > Please review the fix to the subject issue. While fixing 8189784 [1], > I noticed that not only CLDR zones but also tzdb link entries are also > hard coded. So I further modified j.t.f.ZoneName to generate tzdb > entries at the build time. > > The issue: https://bugs.openjdk.java.net/browse/JDK-8201507 > Fix: http://cr.openjdk.java.net/~naoto/8201507/webrev.00/ > > Like the last time, including build-dev for makefile modification review. > > Naoto > > [1] > http://mail.openjdk.java.net/pipermail/i18n-dev/2018-April/002492.html From Alan.Bateman at oracle.com Fri Apr 13 17:26:05 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 Apr 2018 10:26:05 -0700 (PDT) Subject: [PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for Direct Byte Buffers In-Reply-To: References: Message-ID: <044af3a4-016c-9225-ee49-7cd7d23daefa@oracle.com> On 13/04/2018 15:14, Adam Farley8 wrote: > Hi Alan, Peter, > > I see that native memory is tracked in java.nio.Bits, but that only > includes what the user thinks they are allocating. > > When the VM adds extra memory to the allocation amount this extra bit > is not represented in the Bits total. > A cursory glance shows, minimum, that we round the requested memory > quantity up to the heap word size in > the Unsafe.allocateMemory code, and something to do with > nmt_header_size in os:malloc() (os.cpp) too. Is the align_up(sz, HeapWordSize) really causing an issue? We could change Bits to align with HotSpot. The BufferPoolMXBean API allows the capacity and memory usage to differ (when we originally added this, direct buffers were page aligned) so doing this would mean it more accurately reflects the memory allocated to direct buffers. -Alan From xueming.shen at oracle.com Fri Apr 13 21:10:36 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 13 Apr 2018 14:10:36 -0700 Subject: RFR: JDK-8194750, Console.readPassword does not save/restore tty settings Message-ID: <5AD11CCC.9000301@oracle.com> Hi, Please help review the change for JDK-8194750. issue: https://bugs.openjdk.java.net/browse/JDK-8194750 webrev: http://cr.openjdk.java.net/~sherman/8194750/webrev *fix has been manually verified. No new auto-regression test added. Thanks, Sherman From martinrb at google.com Sat Apr 14 03:04:01 2018 From: martinrb at google.com (Martin Buchholz) Date: Fri, 13 Apr 2018 20:04:01 -0700 Subject: RFR: JDK-8194750, Console.readPassword does not save/restore tty settings In-Reply-To: <5AD11CCC.9000301@oracle.com> References: <5AD11CCC.9000301@oracle.com> Message-ID: Emacs users thank you for working on this. To repro, try emacs -q, M-x shell and run your manual test in there. You'll see stty -a reports -echo. This is trickier than I expected, since you have to manage saving/restoring around each call to readPassword AND have an exit hook to restore in case the user never gets around to responding to the prompt. I see in the old code echo returns a boolean that you would think could be used to restore. You want to save/restore around each readPassword AND around the entire java program. It still seems right to restore after every readpassword, using the returned value from echo (which the suggested fix ignores!). But also, the very first time readPassword is called, you create an exit hook to restore the value known at that time. So you need echo0 as well ... or do you ... maybe you just need to keep track of a single state variable for you to do first-time setup. + return tio.c_lflag & ECHO; Pedantically, functions returning jboolean should return only JNI_TRUE and JNI_FALSE. I would do: return (tio.c_lflag & ECHO) != 0; although there's the even more pedantic return ((tio.c_lflag & ECHO) != 0) ? JNI_TRUE : JNI_FALSE; typo: chosole On Fri, Apr 13, 2018 at 2:10 PM, Xueming Shen wrote: > Hi, > > Please help review the change for JDK-8194750. > > issue: https://bugs.openjdk.java.net/browse/JDK-8194750 > webrev: http://cr.openjdk.java.net/~sherman/8194750/webrev > > *fix has been manually verified. No new auto-regression test added. > > Thanks, > Sherman > From vivek.theeyarath at oracle.com Sat Apr 14 06:22:50 2018 From: vivek.theeyarath at oracle.com (Vivek Theeyarath) Date: Fri, 13 Apr 2018 23:22:50 -0700 (PDT) Subject: RFR: 8184693: (opt) add Optional.isEmpty Message-ID: <546b2176-996a-4295-92d8-15d61e769a9a@default> Hi All, Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8184693 Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.00/ The related jtreg test was run and the test passed . Regards Vivek From forax at univ-mlv.fr Sat Apr 14 09:27:56 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 14 Apr 2018 11:27:56 +0200 (CEST) Subject: RFR: 8184693: (opt) add Optional.isEmpty In-Reply-To: <546b2176-996a-4295-92d8-15d61e769a9a@default> References: <546b2176-996a-4295-92d8-15d61e769a9a@default> Message-ID: <377271497.2556945.1523698076268.JavaMail.zimbra@u-pem.fr> Hi Vivek, OptionalInt, OptionalLong and OptionalDouble should be changed too. R?mi ----- Mail original ----- > De: "Vivek Theeyarath" > ?: "core-libs-dev" > Envoy?: Samedi 14 Avril 2018 08:22:50 > Objet: RFR: 8184693: (opt) add Optional.isEmpty > Hi All, > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8184693 > > Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.00/ > > > > The related jtreg test was run and the test passed . > > > > Regards > > Vivek From forax at univ-mlv.fr Sat Apr 14 09:31:43 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 14 Apr 2018 11:31:43 +0200 (CEST) Subject: RFR: 8184693: (opt) add Optional.isEmpty In-Reply-To: <546b2176-996a-4295-92d8-15d61e769a9a@default> References: <546b2176-996a-4295-92d8-15d61e769a9a@default> Message-ID: <237769553.2565179.1523698303042.JavaMail.zimbra@u-pem.fr> Hi Vivek, the parenthesis around the lambdas in Basic.java are unnecessary Predicate isPositiveNumber = (x -> x > 0); vs Predicate isPositiveNumber = x -> x > 0; the same remark for isNegativeNumber. cheers, R?mi ----- Mail original ----- > De: "Vivek Theeyarath" > ?: "core-libs-dev" > Envoy?: Samedi 14 Avril 2018 08:22:50 > Objet: RFR: 8184693: (opt) add Optional.isEmpty > Hi All, > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8184693 > > Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.00/ > > > > The related jtreg test was run and the test passed . > > > > Regards > > Vivek From vivek.theeyarath at oracle.com Sat Apr 14 12:54:16 2018 From: vivek.theeyarath at oracle.com (Vivek Theeyarath) Date: Sat, 14 Apr 2018 05:54:16 -0700 (PDT) Subject: RFR: 8184693: (opt) add Optional.isEmpty In-Reply-To: <377271497.2556945.1523698076268.JavaMail.zimbra@u-pem.fr> References: <546b2176-996a-4295-92d8-15d61e769a9a@default> <377271497.2556945.1523698076268.JavaMail.zimbra@u-pem.fr> Message-ID: <86e8387b-5fd7-4229-8cee-bffaf861f20c@default> I missed that Remi. Thanks for pointing it out. Will address those and get back. Regards Vivek -----Original Message----- From: Remi Forax [mailto:forax at univ-mlv.fr] Sent: Saturday, April 14, 2018 2:58 PM To: Vivek Theeyarath Cc: core-libs-dev Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty Hi Vivek, OptionalInt, OptionalLong and OptionalDouble should be changed too. R?mi ----- Mail original ----- > De: "Vivek Theeyarath" > ?: "core-libs-dev" > Envoy?: Samedi 14 Avril 2018 08:22:50 > Objet: RFR: 8184693: (opt) add Optional.isEmpty > Hi All, > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8184693 > > Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.00/ > > > > The related jtreg test was run and the test passed . > > > > Regards > > Vivek From vivek.theeyarath at oracle.com Sun Apr 15 10:25:09 2018 From: vivek.theeyarath at oracle.com (Vivek Theeyarath) Date: Sun, 15 Apr 2018 03:25:09 -0700 (PDT) Subject: RFR: 8184693: (opt) add Optional.isEmpty In-Reply-To: <86e8387b-5fd7-4229-8cee-bffaf861f20c@default> References: <546b2176-996a-4295-92d8-15d61e769a9a@default> <377271497.2556945.1523698076268.JavaMail.zimbra@u-pem.fr> <86e8387b-5fd7-4229-8cee-bffaf861f20c@default> Message-ID: <9c62e856-1241-4f43-a8dd-61fc0e6e4772@default> Hi All, Please review http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.01/ Regards Vivek -----Original Message----- From: Vivek Theeyarath Sent: Saturday, April 14, 2018 6:24 PM To: Remi Forax Cc: core-libs-dev Subject: RE: RFR: 8184693: (opt) add Optional.isEmpty I missed that Remi. Thanks for pointing it out. Will address those and get back. Regards Vivek -----Original Message----- From: Remi Forax [mailto:forax at univ-mlv.fr] Sent: Saturday, April 14, 2018 2:58 PM To: Vivek Theeyarath Cc: core-libs-dev Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty Hi Vivek, OptionalInt, OptionalLong and OptionalDouble should be changed too. R?mi ----- Mail original ----- > De: "Vivek Theeyarath" > ?: "core-libs-dev" > Envoy?: Samedi 14 Avril 2018 08:22:50 > Objet: RFR: 8184693: (opt) add Optional.isEmpty > Hi All, > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8184693 > > Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.00/ > > > > The related jtreg test was run and the test passed . > > > > Regards > > Vivek From forax at univ-mlv.fr Sun Apr 15 12:37:06 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sun, 15 Apr 2018 14:37:06 +0200 (CEST) Subject: RFR: 8184693: (opt) add Optional.isEmpty In-Reply-To: <9c62e856-1241-4f43-a8dd-61fc0e6e4772@default> References: <546b2176-996a-4295-92d8-15d61e769a9a@default> <377271497.2556945.1523698076268.JavaMail.zimbra@u-pem.fr> <86e8387b-5fd7-4229-8cee-bffaf861f20c@default> <9c62e856-1241-4f43-a8dd-61fc0e6e4772@default> Message-ID: <1338803047.2694432.1523795826191.JavaMail.zimbra@u-pem.fr> Hi Vivek, Looks good to me, nitpicking, when creating the list with List.of() in the tests, a space after each comma is missing var list = List.of(2, 3, 4); cheers, R?mi ----- Mail original ----- > De: "Vivek Theeyarath" > ?: "Remi Forax" , "core-libs-dev" > Envoy?: Dimanche 15 Avril 2018 12:25:09 > Objet: RE: RFR: 8184693: (opt) add Optional.isEmpty > Hi All, > Please review http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.01/ > > Regards > Vivek > -----Original Message----- > From: Vivek Theeyarath > Sent: Saturday, April 14, 2018 6:24 PM > To: Remi Forax > Cc: core-libs-dev > Subject: RE: RFR: 8184693: (opt) add Optional.isEmpty > > I missed that Remi. Thanks for pointing it out. Will address those and get back. > > Regards > Vivek > -----Original Message----- > From: Remi Forax [mailto:forax at univ-mlv.fr] > Sent: Saturday, April 14, 2018 2:58 PM > To: Vivek Theeyarath > Cc: core-libs-dev > Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty > > Hi Vivek, > OptionalInt, OptionalLong and OptionalDouble should be changed too. > > R?mi > > ----- Mail original ----- >> De: "Vivek Theeyarath" >> ?: "core-libs-dev" >> Envoy?: Samedi 14 Avril 2018 08:22:50 >> Objet: RFR: 8184693: (opt) add Optional.isEmpty > >> Hi All, >> >> Please review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8184693 >> >> Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.00/ >> >> >> >> The related jtreg test was run and the test passed . >> >> >> >> Regards >> > > Vivek From chris.hegarty at oracle.com Sun Apr 15 13:18:14 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 15 Apr 2018 14:18:14 +0100 Subject: RFR: 8184693: (opt) add Optional.isEmpty In-Reply-To: <9c62e856-1241-4f43-a8dd-61fc0e6e4772@default> References: <546b2176-996a-4295-92d8-15d61e769a9a@default> <377271497.2556945.1523698076268.JavaMail.zimbra@u-pem.fr> <86e8387b-5fd7-4229-8cee-bffaf861f20c@default> <9c62e856-1241-4f43-a8dd-61fc0e6e4772@default> Message-ID: <79351318-89C9-419D-A569-C60BDE3E3AC1@oracle.com> > On 15 Apr 2018, at 11:25, Vivek Theeyarath wrote: > > Hi All, > Please review http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.01/ This looks ok to me. For consistency, can you please update the copyright header year range in OptionalInt. -Chris. > Regards > Vivek > -----Original Message----- > From: Vivek Theeyarath > Sent: Saturday, April 14, 2018 6:24 PM > To: Remi Forax > Cc: core-libs-dev > Subject: RE: RFR: 8184693: (opt) add Optional.isEmpty > > I missed that Remi. Thanks for pointing it out. Will address those and get back. > > Regards > Vivek > -----Original Message----- > From: Remi Forax [mailto:forax at univ-mlv.fr] > Sent: Saturday, April 14, 2018 2:58 PM > To: Vivek Theeyarath > Cc: core-libs-dev > Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty > > Hi Vivek, > OptionalInt, OptionalLong and OptionalDouble should be changed too. > > R?mi > > ----- Mail original ----- >> De: "Vivek Theeyarath" >> ?: "core-libs-dev" >> Envoy?: Samedi 14 Avril 2018 08:22:50 >> Objet: RFR: 8184693: (opt) add Optional.isEmpty > >> Hi All, >> >> Please review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8184693 >> >> Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.00/ >> >> >> >> The related jtreg test was run and the test passed . >> >> >> >> Regards >> >> Vivek From bhamaram at in.ibm.com Mon Apr 16 08:22:34 2018 From: bhamaram at in.ibm.com (Bhaktavatsal R Maram) Date: Mon, 16 Apr 2018 08:22:34 +0000 Subject: RFR(S): 8201540: [AIX] Extend the set of supported charsets in java.base In-Reply-To: References: , <59d3d31b-b596-0678-c0bf-69b8f951a40d@oracle.com> Message-ID: Hi All, Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8201540 webrev: http://cr.openjdk.java.net/~gromero/8201540/v1/webrev/ In this patch, 1. Default charsets Big5, Big5_Solaris, Big5_HKSCS, GB18030, IBM856, IBM921, IBM922, IBM942, IBM942C, IBM943, IBM943C, IBM950, IBM970, IBM1046, IBM1124, IBM1383, ISO_8859_6, ISO_8859_8, MS1252, TIS_620 for different locales supported on AIX are added to standard charsets in java.base module 2. More aliases are added to existing charsets. 3. Source files for IBM-942C and IBM-943C are changed to template to support #1 4. Modified file make/jdk/src/classes/build/tools/charsetmapping/SPI.java to increase the Hashtable capacity that holds aliases of standard charsets. As the no.of charsets we include in standard charsets are more in this patch, existing capacity of Hashtable used to hold aliases is not efficient. Without change to this file, JDK won't get built and following error is seen Exception in thread "main" java.lang.RuntimeException: Cannot find a suitable size within given constraints at build.tools.charsetmapping.Hasher.build(Hasher.java:122) at build.tools.charsetmapping.Hasher.genClass(Hasher.java:261) at build.tools.charsetmapping.SPI.genClass(SPI.java:130) at build.tools.charsetmapping.Main.main(Main.java:99) Please note that webrev/index.html is not showing below 2 files I deleted. However, webrev/jdk11.changeset file show them deleted properly. src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM943C.java I've built the JDK with this patch on both Linux and Aix. Thanks, Bhaktavatsal Reddy -----Volker Simonis wrote: ----- To: Bhaktavatsal R Maram From: Volker Simonis Date: 04/13/2018 08:51PM Cc: Alan Bateman , Java Core Libs , Tim Ellison , ppc-aix-port-dev at openjdk.java.net Subject: Re: Missing many locales support on AIX platform Hi Bhaktavatsal Reddy, thanks for addressing this long standing issue. I've opened "8201540: [AIX] Extend the set of supported charsets in java.base" [1] to track this issue. As I wrote in the bug report, this problem is the consequence of an emergency fix (JDK-8081332) I did back in 2015 to fix the build on AIX after the integration of the modularity support change (see discussion: [2]). At that time I only added the minimal set of charsets which were required to fix the build. It would be great if you can get in touch with your IBM colleagues to find out which are the default extended charsets supported by IBM J9 on AIX. I think we should try to use a similar set here in our OpenJDK port which is also used by the OpenJ9 for building OpenJ9 on AIX. Also, your IBM colleagues can help you to host a webrev which will make the further review of these changes much easier. I've but Tim from IBM on CC which should have an overview of all the IBM people involved in the OpenJDK project. Besides that I know at least the following people who might help you: Michihiro Horie: HORIE at jp.ibm.com Hiroshi H Horii: horii at jp.ibm.com Gustavo Romero: gromero at linux.vnet.ibm.com Matthew Brandyberyy: mbrandy at linux.vnet.ibm.com Thank you and best regards, Volker [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8201540&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=cieXGANE8bD3liEC2gJzl5hfZorR2qIfggL6U9t-Et8&s=hC4gcA6uomYgY26uR74VelobSIK1ReDsjRZGmI46UBY&e= [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_2d-2Ddev_2015-2DMay_005431.html&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=cieXGANE8bD3liEC2gJzl5hfZorR2qIfggL6U9t-Et8&s=qfYLaVVn7tapNDhv5bY6yE72nhngaWqte4wtRhQ3wB8&e= On Fri, Apr 13, 2018 at 2:42 PM, Bhaktavatsal R Maram wrote: > Hi Alan, > > Thank you for your response. I'm happy that my patch was attached. But, I don't see attachment. So, I inlined patch which contain diffs from 2 changesets in mail text. If a Jira bug is opened for this issue, probably I can attach complete and consolidated patch there. > > At high level, I'm adding following charsets to standard charset in java.base. For this, I have to change IBM943C and IBM942C from source to template to handle java package and aliases. It is also required to add codepage 932 as alias for IBM942C because both are one and same. > > Big5, Big5_HKSCS, GB18030, IBM942, IBM942C, IBM943, IBM943C, IBM950, IBM970, IBM1124, TIS_620 > > > These are default charsets for some of locales supported by Operating System (AIX). Since these are not available in standard charset, JDK can't be used in those locale even if they are available in jdk.charset module (java -version fails). > > I've followed some of the discussions around this in community and understand that default charset of a locale should be made available in java.charset module by using stdcs-* mechanism. On Linux, they were added to java.base in similar way. As it is missing for AIX, I've added them to enable JDK support for more locales. > > > Thanks, > Bhaktavatsal Reddy > > -----Alan Bateman wrote: ----- > To: Bhaktavatsal R Maram , core-libs-dev at openjdk.java.net > From: Alan Bateman > Date: 04/13/2018 03:52PM > Subject: Re: Missing many locales support on AIX platform > > On 13/04/2018 10:35, Bhaktavatsal R Maram wrote: >> Given that patch is big, I am sending patch as attachment again after changing some mail settings. Hopefully, it will make to community this time. > Your patch was attached. > > If I read it correctly, you've switched IBM943C to a template but there > aren't additional aliases so this part is effectively a no-op, is that > right? For IBM932C, you've moved it to be template and added several > aliases. > > The rest is AIX specific and I hope the SAP engineers that maintain the > AIX port can help you. It may be that you are testing with locales that > aren't supported configurations for the AIX port in OpenJDK. As a > general point, we try to keep as many of the exotic and multibyte > charsets out of java.base. They are of course still available to > applications via the API and the jdk.charsets service provider module. > > -Alan > > From Alan.Bateman at oracle.com Mon Apr 16 08:46:39 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Apr 2018 09:46:39 +0100 Subject: RFR(S): 8201540: [AIX] Extend the set of supported charsets in java.base In-Reply-To: References: <59d3d31b-b596-0678-c0bf-69b8f951a40d@oracle.com> Message-ID: <79b9aaac-aa33-1fc8-93a2-0b6b5bf7ea8d@oracle.com> On 16/04/2018 09:22, Bhaktavatsal R Maram wrote: > > 3. Source files for IBM-942C and IBM-943C are changed to template to support #1 > You might want to double check the webrev as it looks like you've added templates where as I assume you mean to use "hg rename" to rename IBM942C.java and IBM943C.java. -Alan From bhamaram at in.ibm.com Mon Apr 16 09:07:17 2018 From: bhamaram at in.ibm.com (Bhaktavatsal R Maram) Date: Mon, 16 Apr 2018 09:07:17 +0000 Subject: RFR(S): 8201540: [AIX] Extend the set of supported charsets in java.base In-Reply-To: <79b9aaac-aa33-1fc8-93a2-0b6b5bf7ea8d@oracle.com> References: <79b9aaac-aa33-1fc8-93a2-0b6b5bf7ea8d@oracle.com>, <59d3d31b-b596-0678-c0bf-69b8f951a40d@oracle.com> Message-ID: Hi Alan, I deleted IBM943C.java (using hg remove) and added new file IBM943C.java.template (using hg add). I now understand that using "hg rename" is giving more meaningful representation in webrev/index.html. I will re-generate webrev by renaming source files to templates using "hg rename" Thanks, Bhaktavatsal Reddy -----Alan Bateman wrote: ----- To: Bhaktavatsal R Maram , Volker Simonis From: Alan Bateman Date: 04/16/2018 02:16PM Cc: Java Core Libs , Tim Ellison , ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR(S): 8201540: [AIX] Extend the set of supported charsets in java.base On 16/04/2018 09:22, Bhaktavatsal R Maram wrote: > > 3. Source files for IBM-942C and IBM-943C are changed to template to support #1 > You might want to double check the webrev as it looks like you've added templates where as I assume you mean to use "hg rename" to rename IBM942C.java and IBM943C.java. -Alan From adam.farley at uk.ibm.com Mon Apr 16 10:46:00 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Mon, 16 Apr 2018 11:46:00 +0100 Subject: [PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for Direct Byte Buffers In-Reply-To: <044af3a4-016c-9225-ee49-7cd7d23daefa@oracle.com> References: <044af3a4-016c-9225-ee49-7cd7d23daefa@oracle.com> Message-ID: > On 13/04/2018 15:14, Adam Farley8 wrote: >> Hi Alan, Peter, >> >> I see that native memory is tracked in java.nio.Bits, but that only includes what the user thinks they are allocating. >> >> When the VM adds extra memory to the allocation amount this extra bit is not represented in the Bits total. >> A cursory glance shows, minimum, that we round the requested memory quantity up to the heap word size in >> the Unsafe.allocateMemory code, and something to do with nmt_header_size in os:malloc() (os.cpp) too. > Is the align_up(sz, HeapWordSize) really causing an issue? Coupled with the nmt_header_size business, it makes the Bits values wrong. The more DBB allocations, the more inaccurate those numbers will be. > > We could change Bits to align with HotSpot. The BufferPoolMXBean API allows the capacity and memory usage to differ (when we originally added this, direct buffers were page aligned) so doing this would mean it more accurately reflects the memory allocated to direct buffers. > > -Alan I agree with you that the "+x" information should be added to only one of the two atomic longs. To get "X", it seems to me that the best option would be to introduce an native method in Bits that fetches "X" directly from Hotspot, using the same code that Hotspot uses (so we'd have to abstract-out the Hotspot logic that adds X to the memory quantity). This way, anyone modifying the Hotspot logic won't risk rendering the Bits logic wrong again. Best Regards Adam Farley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From adam.farley at uk.ibm.com Mon Apr 16 10:57:05 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Mon, 16 Apr 2018 10:57:05 +0000 Subject: RFR: JDK-8190187: C++ code calling JNI_CreateJavaVM can be killed by Java Message-ID: Hi All, I've attached the code to resolve JDK-8190187 Could a committer please take the fix (amended code attached, and available on request) and: 1) Complete the CSR process for the new JNI Return code. 2) Commit the changes that contain the Return code. And, optionally, 3) Perform 1 and 2 for the jdwp agent changes as well, so it can use this new functionality. Let me know if you need any help. :) Best Regards Adam Farley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hg_diff.txt URL: From bhamaram at in.ibm.com Mon Apr 16 11:10:24 2018 From: bhamaram at in.ibm.com (Bhaktavatsal R Maram) Date: Mon, 16 Apr 2018 11:10:24 +0000 Subject: RFR(S): 8201540: [AIX] Extend the set of supported charsets in java.base In-Reply-To: References: , <79b9aaac-aa33-1fc8-93a2-0b6b5bf7ea8d@oracle.com>, <59d3d31b-b596-0678-c0bf-69b8f951a40d@oracle.com> Message-ID: Hi All, I've regenerated webrev using "hg rename" to create template files. webrev looks much neat now.. Thanks Alan for suggestion. webrev - http://cr.openjdk.java.net/~gromero/8201540/v2/ Thanks, Bhaktavatsal Reddy -----"core-libs-dev" wrote: ----- To: Alan Bateman From: "Bhaktavatsal R Maram" Sent by: "core-libs-dev" Date: 04/16/2018 02:38PM Cc: Tim Ellison , ppc-aix-port-dev at openjdk.java.net, Java Core Libs Subject: Re: RFR(S): 8201540: [AIX] Extend the set of supported charsets in java.base Hi Alan, I deleted IBM943C.java (using hg remove) and added new file IBM943C.java.template (using hg add). I now understand that using "hg rename" is giving more meaningful representation in webrev/index.html. I will re-generate webrev by renaming source files to templates using "hg rename" Thanks, Bhaktavatsal Reddy -----Alan Bateman wrote: ----- To: Bhaktavatsal R Maram , Volker Simonis From: Alan Bateman Date: 04/16/2018 02:16PM Cc: Java Core Libs , Tim Ellison , ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR(S): 8201540: [AIX] Extend the set of supported charsets in java.base On 16/04/2018 09:22, Bhaktavatsal R Maram wrote: > > 3. Source files for IBM-942C and IBM-943C are changed to template to support #1 > You might want to double check the webrev as it looks like you've added templates where as I assume you mean to use "hg rename" to rename IBM942C.java and IBM943C.java. -Alan From adam.farley at uk.ibm.com Mon Apr 16 12:10:23 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Mon, 16 Apr 2018 13:10:23 +0100 Subject: RFR: JDK-8190187: C++ code calling JNI_CreateJavaVM can be killed by Java In-Reply-To: References: Message-ID: Hi All, Here is the code to resolve JDK-8190187: http://cr.openjdk.java.net/~mhorie/8190187/hg_diff.txt Could a committer please take the fix and: 1) Complete the CSR process for the new JNI Return code. 2) Commit the changes that contain the Return code. And, optionally, 3) Perform 1 and 2 for the jdwp agent changes as well, so it can use this new functionality. Let me know if you need any help. :) Best Regards Adam Farley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From alexey.ivanov at oracle.com Mon Apr 16 12:59:23 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 16 Apr 2018 13:59:23 +0100 Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations In-Reply-To: References: <9bae15f406ed4e029233415e6a8032b8@sap.com> <81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com> <7c5e68c2a023490e96ce6452fbda1700@sap.com> <9fff2e7e-06ac-54c1-8f66-33bff34ea621@oracle.com> Message-ID: Hi Matthias, Phil, The build of 32 bit Windows is broken because of mlib_image.dll. As JNICALL modifier has been added to function declarations, they're exported with a decorated name, for example _j2d_mlib_ImageCreate at 16. The functions in this library are looked up by their name [1] and therefore none can be found. If you run tests in test/jdk/java/awt/image, for example test/jdk/java/awt/image/mlib/MlibOpsTest.java, some of them fail because ImagingLib is not available. I'm working on a patch to fix it. Regards, Alexey [1] http://hg.openjdk.java.net/jdk/jdk/file/bc1c7e41e285/src/java.desktop/windows/native/libawt/windows/awt_Mlib.cpp#l60 On 13/04/2018 06:48, Baesken, Matthias wrote: > Hi Phil/Alexey, thanks for adding the other lists . > >> Is this the current version of the change : http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ ? > Yes. > > Best regards, Matthias > > >> -----Original Message----- >> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >> Sent: Donnerstag, 12. April 2018 23:53 >> To: Phil Race ; Baesken, Matthias >> ; Alan Bateman ; >> Magnus Ihse Bursie >> Cc: build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Doerr, >> Martin ; 2d-dev <2d-dev at openjdk.java.net>; >> hotspot-dev >> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function >> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at >> some places in function declarations/implementations >> >> >> On 12/04/2018 21:42, Phil Race wrote: >>> How can JNIEXPORT be different between 32 bit & 64 bit ? >>> I'm sure you saw compilation errors but I don't get why it failed for >>> 32 only. >>> >>> JNICALL (_stdcall) may be unnecessary on 64 bit Windows but that doesn't >>> explain why the 32 bit compiler would complain about inconsistent >>> application >>> of __declspec(dllexport) - ie JNIEXPORT. >>> >>> Or is that part (adding JNIEXPORT) pure clean up and the compilation >>> errors were all down to JNICALL ? >> Adding missing JNIEXPORT is for cleanup only. >> >> The compiler complained about mismatched JNICALL / non-JNICALL >> declarations as the macro changes calling convention from the default >> __cdecl? to __stdcall on 32 bit Windows. >> >> Another issue is that __stdcall decorates the functions: prefixes with >> underscore and postfixes with @ + size of parameters. Because of the >> decorations, classLoader.cpp can't lookup the required functions by name >> from zip.dll and jimage.dll. The functions are exported but with >> different name. >> >> I hope this information adds more details to the picture. >> >>> I was a bit puzzled at the removals I saw here : >> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.deskto >> p/share/native/libsplashscreen/splashscreen_impl.h.udiff.html >>> .. I needed to look at the whole file to realise that you were >>> removing a duplicate >>> declaration. >> That was tricky. I could have been mentioned in the review. >> >> >> Regards, >> Alexey >> >>> -phil. >>> >>> On 04/12/2018 04:04 AM, Baesken, Matthias wrote: >>>> Hi? Alan , this is the up to date webrev . >>>> However we want to add?? Alexey?? Ivanov? as additional? author . >>>> >>>>> As I read it, this changes the calling convention of these functions on >>>>> 32-bit Windows but it will have no impact on 64-bit Windows (as >>>>> __stdcall is ignored) or other platforms, is that correct? >>>>> >>>> The? change adds? JNIEXPORT?? at some places? where it is? ben >>>> forgotten , for example : >>>> >>>> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp.c.udiff.html >>>> >>>> This might have? potential? impact? on other platforms?? (fixes the >>>> mismatches) . >>>> >>>> Best regards, Matthias >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >>>>> Sent: Donnerstag, 12. April 2018 12:54 >>>>> To: Baesken, Matthias ; Magnus Ihse Bursie >>>>> Cc: build-dev at openjdk.java.net; Doerr, Martin ; core-libs-dev at openjdk.java.net >>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>>>> function >>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at >>>>> some places in function declarations/implementations >>>>> >>>>> Adding core-libs-dev as this is change code in libjava, libzip, >>>>> libjimage, ... >>>>> >>>>> Can you confirm that this is the up to date webrev: >>>>> ???? http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ >>>>> >>>>> As I read it, this changes the calling convention of these functions on >>>>> 32-bit Windows but it will have no impact on 64-bit Windows (as >>>>> __stdcall is ignored) or other platforms, is that correct? >>>>> >>>>> -Alan >>>>> >>>>> >>>>> From magnus.ihse.bursie at oracle.com Mon Apr 16 13:03:12 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 16 Apr 2018 15:03:12 +0200 Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations In-Reply-To: References: <9bae15f406ed4e029233415e6a8032b8@sap.com> <81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com> <7c5e68c2a023490e96ce6452fbda1700@sap.com> <9fff2e7e-06ac-54c1-8f66-33bff34ea621@oracle.com> Message-ID: On 2018-04-16 14:59, Alexey Ivanov wrote: > Hi Matthias, Phil, > > The build of 32 bit Windows is broken because of mlib_image.dll. As > JNICALL modifier has been added to function declarations, they're > exported with a decorated name, for example _j2d_mlib_ImageCreate at 16. > The functions in this library are looked up by their name [1] and > therefore none can be found. You should most likely just be able to remove the JNICALL modifiers for libmlib_image. /Magnus > > If you run tests in test/jdk/java/awt/image, for example > test/jdk/java/awt/image/mlib/MlibOpsTest.java, some of them fail > because ImagingLib is not available. > > I'm working on a patch to fix it. > > > Regards, > Alexey > > [1] > http://hg.openjdk.java.net/jdk/jdk/file/bc1c7e41e285/src/java.desktop/windows/native/libawt/windows/awt_Mlib.cpp#l60 > > On 13/04/2018 06:48, Baesken, Matthias wrote: >> Hi Phil/Alexey,? thanks for? adding the other lists . >> >>> Is this the current version of the change : >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ ? >> Yes. >> >> Best regards, Matthias >> >> >>> -----Original Message----- >>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >>> Sent: Donnerstag, 12. April 2018 23:53 >>> To: Phil Race ; Baesken, Matthias >>> ; Alan Bateman ; >>> Magnus Ihse Bursie >>> Cc: build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Doerr, >>> Martin ; 2d-dev <2d-dev at openjdk.java.net>; >>> hotspot-dev >>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>> function >>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at >>> some places in function declarations/implementations >>> >>> >>> On 12/04/2018 21:42, Phil Race wrote: >>>> How can JNIEXPORT be different between 32 bit & 64 bit ? >>>> I'm sure you saw compilation errors but I don't get why it failed for >>>> 32 only. >>>> >>>> JNICALL (_stdcall) may be unnecessary on 64 bit Windows but that >>>> doesn't >>>> explain why the 32 bit compiler would complain about inconsistent >>>> application >>>> of __declspec(dllexport) - ie JNIEXPORT. >>>> >>>> Or is that part (adding JNIEXPORT) pure clean up and the compilation >>>> errors were all down to JNICALL ? >>> Adding missing JNIEXPORT is for cleanup only. >>> >>> The compiler complained about mismatched JNICALL / non-JNICALL >>> declarations as the macro changes calling convention from the default >>> __cdecl? to __stdcall on 32 bit Windows. >>> >>> Another issue is that __stdcall decorates the functions: prefixes with >>> underscore and postfixes with @ + size of parameters. Because of the >>> decorations, classLoader.cpp can't lookup the required functions by >>> name >>> from zip.dll and jimage.dll. The functions are exported but with >>> different name. >>> >>> I hope this information adds more details to the picture. >>> >>>> I was a bit puzzled at the removals I saw here : >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.deskto >>> p/share/native/libsplashscreen/splashscreen_impl.h.udiff.html >>>> .. I needed to look at the whole file to realise that you were >>>> removing a duplicate >>>> declaration. >>> That was tricky. I could have been mentioned in the review. >>> >>> >>> Regards, >>> Alexey >>> >>>> -phil. >>>> >>>> On 04/12/2018 04:04 AM, Baesken, Matthias wrote: >>>>> Hi? Alan , this is the up to date webrev . >>>>> However we want to add?? Alexey?? Ivanov? as additional author . >>>>> >>>>>> As I read it, this changes the calling convention of these >>>>>> functions on >>>>>> 32-bit Windows but it will have no impact on 64-bit Windows (as >>>>>> __stdcall is ignored) or other platforms, is that correct? >>>>>> >>>>> The? change adds? JNIEXPORT?? at some places? where it is ben >>>>> forgotten , for example : >>>>> >>>>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp.c.udiff.html >>> >>>>> >>>>> This might have? potential? impact? on other platforms (fixes the >>>>> mismatches) . >>>>> >>>>> Best regards, Matthias >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >>>>>> Sent: Donnerstag, 12. April 2018 12:54 >>>>>> To: Baesken, Matthias ; Magnus Ihse >>>>>> Bursie >>>>>> Cc: build-dev at openjdk.java.net; Doerr, Martin >>>>>> ; core-libs-dev at openjdk.java.net >>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>>>>> function >>>>>> declarations/implementations - was : RE: missing JNIEXPORT / >>>>>> JNICALL at >>>>>> some places in function declarations/implementations >>>>>> >>>>>> Adding core-libs-dev as this is change code in libjava, libzip, >>>>>> libjimage, ... >>>>>> >>>>>> Can you confirm that this is the up to date webrev: >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ >>>>>> >>>>>> As I read it, this changes the calling convention of these >>>>>> functions on >>>>>> 32-bit Windows but it will have no impact on 64-bit Windows (as >>>>>> __stdcall is ignored) or other platforms, is that correct? >>>>>> >>>>>> -Alan >>>>>> >>>>>> >>>>>> > From neugens.limasoftware at gmail.com Mon Apr 16 13:22:13 2018 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 16 Apr 2018 15:22:13 +0200 Subject: Clean-room implementation of Double::toString(double) and Float::toString(float) In-Reply-To: <1806ffc6-fd62-0e15-77bb-4b53a28c9e36@gmail.com> References: <5c8944fa-4941-79b4-9320-a04ecb93b27a@gmail.com> <8FC2F9AF-7B48-45FD-B65E-405122F1E21D@oracle.com> <9ffa5039-82b6-6f0b-479b-307361d8ba7a@gmail.com> <3BD60996-BEC9-4179-91F8-39E002B33594@oracle.com> <1806ffc6-fd62-0e15-77bb-4b53a28c9e36@gmail.com> Message-ID: 2018-04-12 10:12 GMT+02:00 Raffaello Giulietti : > I asked Oracle about how the copyright notice should be adapted to meet the > OCA requirements but, as of today, I got no answer. All the headers need to have a valid copyright text, you can just copy the headers from any other file in the OpenJDK sources, as they are all the same (just keep attention to the year, as this may not always be up to date). The license and other useful things are explained here: http://openjdk.java.net/legal/ Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From chris.hegarty at oracle.com Mon Apr 16 16:03:55 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 16 Apr 2018 17:03:55 +0100 Subject: InetAddress.getByName/getAllByName for empty host string In-Reply-To: <28d02a89-1697-3736-853c-9f32dea262d5@gmail.com> References: <5ad894e2-7231-1827-672d-47b307586675@gmail.com> <06e1513a-c511-e28f-9acb-282bee6a0cab@oracle.com> <28d02a89-1697-3736-853c-9f32dea262d5@gmail.com> Message-ID: <5af3da70-aa47-a07d-e489-419eb5777bd0@oracle.com> Jaikiran, On 13/04/18 16:29, Jaikiran Pai wrote: > Hi Chris, > > Thank you creating that JIRA. > > If the fix involves just updating the javadoc, is this something that > youwould like me to contribute as a patch? I have a signed and approved > OCA, but I will need a sponsor if I do come up with the patch. A patch containing the specification clarification and an update to an existing test to cover said specification clarification would be helpful. The change will require a CSR, but I can do that on your behalf. -Chris. > -Jaikiran > > > On 13/04/18 8:41 PM, Chris Hegarty wrote: >> Hi Jaikiran, >> >> On 13/04/18 15:29, Jaikiran Pai wrote: >>> The javadoc of InetAddress.getByName(host) and getAllByName(host) >>> states that: >>> >>> If the host is null then an InetAddress representing an address of >>> the loopback interface is returned. >>> >>> For non-null values the javadoc explains what the implementation >>> does. However, there seems to be no mention of what it does with an >>> empty string (length == 0) value for the host param. Right now, the >>> implementation seems to treat an empty value the same way it treats >>> the host == null case and returns an InetAddress representing the >>> loopback address. >>> >>> Consider the following example: >>> >>> public class InetAddressTest { >>> public static void main(final String[] args) throws Exception { >>> System.out.println("InetAddress.getByName() for empty string >>> returns " + java.net.InetAddress.getByName("")); >>> System.out.println("InetAddress.getAllByName() for empty >>> string returns " >>> + >>> java.util.Arrays.toString(java.net.InetAddress.getAllByName(""))); >>> >>> } >>> } >>> >>> This outputs: >>> >>> InetAddress.getByName() for empty string returns localhost/127.0.0.1 >>> InetAddress.getAllByName() for empty string returns >>> [localhost/127.0.0.1] >>> >>> >>> Is it intentional for these APIs to behave this way for empty string? >> >> Yes. >> >>> If so, should the javadoc be updated to explicitly state this behaviour? >> >> Yeah, probably. >> >> The following JIRA issue has been filed to track this: >> https://bugs.openjdk.java.net/browse/JDK-8201545 >> >> -Chris. > From xueming.shen at oracle.com Mon Apr 16 17:43:50 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 16 Apr 2018 10:43:50 -0700 Subject: RFR(S): 8201540: [AIX] Extend the set of supported charsets in java.base In-Reply-To: References: , <79b9aaac-aa33-1fc8-93a2-0b6b5bf7ea8d@oracle.com>, <59d3d31b-b596-0678-c0bf-69b8f951a40d@oracle.com> Message-ID: <5AD4E0D6.6000404@oracle.com> It looks good to me. -Sherman On 4/16/18, 4:10 AM, Bhaktavatsal R Maram wrote: > Hi All, > > I've regenerated webrev using "hg rename" to create template files. webrev looks much neat now.. Thanks Alan for suggestion. > > webrev - http://cr.openjdk.java.net/~gromero/8201540/v2/ > > Thanks, > Bhaktavatsal Reddy > > > -----"core-libs-dev" wrote: ----- > To: Alan Bateman > From: "Bhaktavatsal R Maram" > Sent by: "core-libs-dev" > Date: 04/16/2018 02:38PM > Cc: Tim Ellison, ppc-aix-port-dev at openjdk.java.net, Java Core Libs > Subject: Re: RFR(S): 8201540: [AIX] Extend the set of supported charsets in java.base > > Hi Alan, > > I deleted IBM943C.java (using hg remove) and added new file IBM943C.java.template (using hg add). I now understand that using "hg rename" is giving more meaningful representation in webrev/index.html. > > I will re-generate webrev by renaming source files to templates using "hg rename" > > Thanks, > Bhaktavatsal Reddy > > > > -----Alan Bateman wrote: ----- > To: Bhaktavatsal R Maram, Volker Simonis > From: Alan Bateman > Date: 04/16/2018 02:16PM > Cc: Java Core Libs, Tim Ellison, ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR(S): 8201540: [AIX] Extend the set of supported charsets in java.base > > > On 16/04/2018 09:22, Bhaktavatsal R Maram wrote: >> 3. Source files for IBM-942C and IBM-943C are changed to template to support #1 >> > You might want to double check the webrev as it looks like you've added > templates where as I assume you mean to use "hg rename" to rename > IBM942C.java and IBM943C.java. > > -Alan > > > From vivek.theeyarath at oracle.com Mon Apr 16 18:08:06 2018 From: vivek.theeyarath at oracle.com (Vivek Theeyarath) Date: Mon, 16 Apr 2018 11:08:06 -0700 (PDT) Subject: RFR: 8184693: (opt) add Optional.isEmpty In-Reply-To: <79351318-89C9-419D-A569-C60BDE3E3AC1@oracle.com> References: <546b2176-996a-4295-92d8-15d61e769a9a@default> <377271497.2556945.1523698076268.JavaMail.zimbra@u-pem.fr> <86e8387b-5fd7-4229-8cee-bffaf861f20c@default> <9c62e856-1241-4f43-a8dd-61fc0e6e4772@default> <79351318-89C9-419D-A569-C60BDE3E3AC1@oracle.com> Message-ID: Hi All, Please find the updated webrev http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.02/ . Here is the csr which I have raised for this change https://bugs.openjdk.java.net/browse/JDK-8201606 Regards Vivek -----Original Message----- From: Chris Hegarty Sent: Sunday, April 15, 2018 6:48 PM To: Vivek Theeyarath Cc: Remi Forax ; core-libs-dev Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty > On 15 Apr 2018, at 11:25, Vivek Theeyarath wrote: > > Hi All, > Please review http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.01/ This looks ok to me. For consistency, can you please update the copyright header year range in OptionalInt. -Chris. > Regards > Vivek > -----Original Message----- > From: Vivek Theeyarath > Sent: Saturday, April 14, 2018 6:24 PM > To: Remi Forax > Cc: core-libs-dev > Subject: RE: RFR: 8184693: (opt) add Optional.isEmpty > > I missed that Remi. Thanks for pointing it out. Will address those and get back. > > Regards > Vivek > -----Original Message----- > From: Remi Forax [mailto:forax at univ-mlv.fr] > Sent: Saturday, April 14, 2018 2:58 PM > To: Vivek Theeyarath > Cc: core-libs-dev > Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty > > Hi Vivek, > OptionalInt, OptionalLong and OptionalDouble should be changed too. > > R?mi > > ----- Mail original ----- >> De: "Vivek Theeyarath" >> ?: "core-libs-dev" >> Envoy?: Samedi 14 Avril 2018 08:22:50 >> Objet: RFR: 8184693: (opt) add Optional.isEmpty > >> Hi All, >> >> Please review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8184693 >> >> Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.00/ >> >> >> >> The related jtreg test was run and the test passed . >> >> >> >> Regards >> >> Vivek From christian.tornqvist at oracle.com Mon Apr 16 18:15:45 2018 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Mon, 16 Apr 2018 14:15:45 -0400 Subject: RFR: 8201609 - Split test/jdk/:tier2 to enable better parallel execution Message-ID: <7A7B3D2A-2017-47C2-8967-A6E744009250@oracle.com> Please review this small change that splits the tier2 test group into three smaller test groups that can be executed in parallel. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8201609/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8201609 Thanks, Christian From xueming.shen at oracle.com Mon Apr 16 19:18:41 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 16 Apr 2018 12:18:41 -0700 Subject: RFR: JDK-8194750,Console.readPassword does not save/restore tty settings In-Reply-To: References: <5AD11CCC.9000301@oracle.com> Message-ID: <5AD4F711.8030900@oracle.com> On 4/13/18, 8:04 PM, Martin Buchholz wrote: > This is trickier than I expected, since you have to manage > saving/restoring around each call to readPassword AND have an exit > hook to restore in case the user never gets around to responding to > the prompt. > > I see in the old code echo returns a boolean that you would think > could be used to restore. You want to save/restore around each > readPassword AND around the entire java program. It still seems right > to restore after every readpassword, using the returned value from > echo (which the suggested fix ignores!). But also, the very first > time readPassword is called, you create an exit hook to restore the > value known at that time. So you need echo0 as well ... or do you ... > maybe you just need to keep track of a single state variable for you > to do first-time setup. > Updated to use a local flag for each "echo-off" setting for readPassword(), so the echo will not be turned on after readpw if its initial status is off before readpw. Still keep the global one & exit-hook for use scenario that someone ctrl-D to exit or the vm gets -kill signal during passwd reading. webrev has been updated accordingly (with the updates based on other comments). http://cr.openjdk.java.net/~sherman/8194750/webrev Thanks! Sherman > + return tio.c_lflag& ECHO; > Pedantically, functions returning jboolean should return only JNI_TRUE > and JNI_FALSE. I would do: > return (tio.c_lflag& ECHO) != 0; > although there's the even more pedantic > > return ((tio.c_lflag & ECHO) != 0) ? JNI_TRUE : JNI_FALSE; > > typo: chosole > > From Alan.Bateman at oracle.com Mon Apr 16 20:14:05 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Apr 2018 21:14:05 +0100 Subject: RFR: 8201609 - Split test/jdk/:tier2 to enable better parallel execution In-Reply-To: <7A7B3D2A-2017-47C2-8967-A6E744009250@oracle.com> References: <7A7B3D2A-2017-47C2-8967-A6E744009250@oracle.com> Message-ID: On 16/04/2018 19:15, Christian Tornqvist wrote: > Please review this small change that splits the tier2 test group into three smaller test groups that can be executed in parallel. > > Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8201609/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8201609 > tier_part2 is an odd mix that I couldn't imagine anyone using directly. It's okay for CI systems of course so no objection to the change. Do you know what sun/nio/cs/ISO8859x.java and com/sun/crypto/provider/Cipher are special cased? Just wondering if there is a historical or current reason to not run those. -Alan From Alan.Bateman at oracle.com Mon Apr 16 20:15:22 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Apr 2018 21:15:22 +0100 Subject: RFR(S): 8201540: [AIX] Extend the set of supported charsets in java.base In-Reply-To: <5AD4E0D6.6000404@oracle.com> References: <79b9aaac-aa33-1fc8-93a2-0b6b5bf7ea8d@oracle.com> <59d3d31b-b596-0678-c0bf-69b8f951a40d@oracle.com> <5AD4E0D6.6000404@oracle.com> Message-ID: On 16/04/2018 18:43, Xueming Shen wrote: > It looks good to me. I agree, the main thing is that it's not adding charsets to java.base for the other builds. -Alan From christian.tornqvist at oracle.com Mon Apr 16 20:20:58 2018 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Mon, 16 Apr 2018 16:20:58 -0400 Subject: RFR: 8201609 - Split test/jdk/:tier2 to enable better parallel execution In-Reply-To: References: <7A7B3D2A-2017-47C2-8967-A6E744009250@oracle.com> Message-ID: <8975932B-74D7-4546-B4D2-6D2A0DC14608@oracle.com> Hi Alan > On Apr 16, 2018, at 4:14 05PM, Alan Bateman wrote: > > On 16/04/2018 19:15, Christian Tornqvist wrote: >> Please review this small change that splits the tier2 test group into three smaller test groups that can be executed in parallel. >> >> Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8201609/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8201609 >> > tier_part2 is an odd mix that I couldn't imagine anyone using directly. It's okay for CI systems of course so no objection to the change. > Yeah, my intention here was to split the existing group into somewhat balanced smaller parts. I expect normal users to keep running the tier2 group rather than using the tier2_part* ones. > Do you know what sun/nio/cs/ISO8859x.java and com/sun/crypto/provider/Cipher are special cased? Just wondering if there is a historical or current reason to not run those. > No idea. Thanks, Christian > -Alan From david.holmes at oracle.com Mon Apr 16 22:03:32 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Apr 2018 08:03:32 +1000 Subject: Clean-room implementation of Double::toString(double) and Float::toString(float) In-Reply-To: References: <5c8944fa-4941-79b4-9320-a04ecb93b27a@gmail.com> <8FC2F9AF-7B48-45FD-B65E-405122F1E21D@oracle.com> <9ffa5039-82b6-6f0b-479b-307361d8ba7a@gmail.com> <3BD60996-BEC9-4179-91F8-39E002B33594@oracle.com> <1806ffc6-fd62-0e15-77bb-4b53a28c9e36@gmail.com> Message-ID: On 16/04/2018 11:22 PM, Mario Torre wrote: > 2018-04-12 10:12 GMT+02:00 Raffaello Giulietti : > >> I asked Oracle about how the copyright notice should be adapted to meet the >> OCA requirements but, as of today, I got no answer. > > All the headers need to have a valid copyright text, you can just copy > the headers from any other file in the OpenJDK sources, as they are > all the same (just keep attention to the year, as this may not always > be up to date). That's not true Mario. Files from different sources have different copyrights. Those that originated outside Oracle have non-Oracle copyrights. Some have dual copyrights. > The license and other useful things are explained here: > > http://openjdk.java.net/legal/ None of that explains how to formulate the initial copyright header for sources added to OpenJDK. Cheers, David > Cheers, > Mario > From mark.reinhold at oracle.com Mon Apr 16 22:52:24 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 16 Apr 2018 15:52:24 -0700 Subject: Clean-room implementation of Double::toString(double) and Float::toString(float) In-Reply-To: <1806ffc6-fd62-0e15-77bb-4b53a28c9e36@gmail.com> References: <5c8944fa-4941-79b4-9320-a04ecb93b27a@gmail.com> <8FC2F9AF-7B48-45FD-B65E-405122F1E21D@oracle.com> <9ffa5039-82b6-6f0b-479b-307361d8ba7a@gmail.com> <3BD60996-BEC9-4179-91F8-39E002B33594@oracle.com> <1806ffc6-fd62-0e15-77bb-4b53a28c9e36@gmail.com> Message-ID: <20180416155224.486146748@eggemoggin.niobe.net> 2018/4/12 1:12:36 -0700, raffaello.giulietti at gmail.com: > my code is now ready to be uploaded to the OpenJDK reps. Currently it > resides on GitHub and is under the "GPLv2 + Classpath Exception" > license, with myself as the copyright holder. > > I asked Oracle about how the copyright notice should be adapted to meet > the OCA requirements but, as of today, I got no answer. > > Is there any official reference about the copyright notice on OpenJDK > contributions? For library code, the template is in $JDK/make/templates/gpl-cp-header [1]. It begins: Copyright (c) %YEARS% 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 ... You can just use the Oracle copyright line or, at your option, replace it with your own. In any case %YEARS% should be replaced with the year in which the file was created, and if it was modified in any later year then the creation year should be followed by the latest year in which the file was modified, separated by a comma. (We can better advise you on the details once we see the actual code.) - Mark [1] http://hg.openjdk.java.net/jdk/jdk/file/tip/make/templates/gpl-cp-header From stuart.marks at oracle.com Mon Apr 16 23:41:02 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 16 Apr 2018 16:41:02 -0700 Subject: RFR: 8184693: (opt) add Optional.isEmpty In-Reply-To: References: <546b2176-996a-4295-92d8-15d61e769a9a@default> <377271497.2556945.1523698076268.JavaMail.zimbra@u-pem.fr> <86e8387b-5fd7-4229-8cee-bffaf861f20c@default> <9c62e856-1241-4f43-a8dd-61fc0e6e4772@default> <79351318-89C9-419D-A569-C60BDE3E3AC1@oracle.com> Message-ID: Hi Vivek, Please add "@since 11" tags to the doc comments of the four Optional*.isEmpty() methods. Regarding the tests, I don't think the various newly added testIsEmpty() tests are useful. The setup in those test files already generates a fairly comprehensive set of Optional values from a variety of sources. All the assertion checking is performed in the checkEmpty() and checkPresent() methods. It should be sufficient to add an assertTrue(isEmpty()) call to checkEmpty() -- as you've done -- and also to add an assertFalse(isEmpty()) call to checkPresent(). If these assertions are added, the additional testIsEmpty() test is unnecessary. This applies to all four of the regression test files. Thanks, s'marks On 4/16/18 11:08 AM, Vivek Theeyarath wrote: > Hi All, > Please find the updated webrev http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.02/ . > Here is the csr which I have raised for this change https://bugs.openjdk.java.net/browse/JDK-8201606 > > Regards > Vivek > -----Original Message----- > From: Chris Hegarty > Sent: Sunday, April 15, 2018 6:48 PM > To: Vivek Theeyarath > Cc: Remi Forax ; core-libs-dev > Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty > > > >> On 15 Apr 2018, at 11:25, Vivek Theeyarath wrote: >> >> Hi All, >> Please review http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.01/ > > This looks ok to me. > > For consistency, can you please update the copyright header year range in OptionalInt. > > -Chris. > >> Regards >> Vivek >> -----Original Message----- >> From: Vivek Theeyarath >> Sent: Saturday, April 14, 2018 6:24 PM >> To: Remi Forax >> Cc: core-libs-dev >> Subject: RE: RFR: 8184693: (opt) add Optional.isEmpty >> >> I missed that Remi. Thanks for pointing it out. Will address those and get back. >> >> Regards >> Vivek >> -----Original Message----- >> From: Remi Forax [mailto:forax at univ-mlv.fr] >> Sent: Saturday, April 14, 2018 2:58 PM >> To: Vivek Theeyarath >> Cc: core-libs-dev >> Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty >> >> Hi Vivek, >> OptionalInt, OptionalLong and OptionalDouble should be changed too. >> >> R?mi >> >> ----- Mail original ----- >>> De: "Vivek Theeyarath" >>> ?: "core-libs-dev" >>> Envoy?: Samedi 14 Avril 2018 08:22:50 >>> Objet: RFR: 8184693: (opt) add Optional.isEmpty >> >>> Hi All, >>> >>> Please review. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8184693 >>> >>> Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.00/ >>> >>> >>> >>> The related jtreg test was run and the test passed . >>> >>> >>> >>> Regards >>> >>> Vivek > From martinrb at google.com Tue Apr 17 02:20:01 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 16 Apr 2018 19:20:01 -0700 Subject: RFR: JDK-8194750, Console.readPassword does not save/restore tty settings In-Reply-To: <5AD4F711.8030900@oracle.com> References: <5AD11CCC.9000301@oracle.com> <5AD4F711.8030900@oracle.com> Message-ID: Thanks, this looks good. But I have my usual nitpicky comments 376 // sets the console echo on/off 377 private static native boolean echo(boolean on) throws IOException; I would document the return value. @returns the previous console echo on/off status 314 boolean echoWasOn = true; I much prefer leaving it blank (in Java, not C !) boolean echoWasOn; relying on definite assignment in Java for safety. On Mon, Apr 16, 2018 at 12:18 PM, Xueming Shen wrote: > On 4/13/18, 8:04 PM, Martin Buchholz wrote: > > This is trickier than I expected, since you have to manage > saving/restoring around each call to readPassword AND have an exit hook to > restore in case the user never gets around to responding to the prompt. > > I see in the old code echo returns a boolean that you would think could be > used to restore. You want to save/restore around each readPassword AND > around the entire java program. It still seems right to restore after > every readpassword, using the returned value from echo (which the suggested > fix ignores!). But also, the very first time readPassword is called, you > create an exit hook to restore the value known at that time. So you need > echo0 as well ... or do you ... maybe you just need to keep track of a > single state variable for you to do first-time setup. > > Updated to use a local flag for each "echo-off" setting for > readPassword(), so the > echo will not be turned on after readpw if its initial status is off > before readpw. > > Still keep the global one & exit-hook for use scenario that someone ctrl-D > to exit > or the vm gets -kill signal during passwd reading. > > webrev has been updated accordingly (with the updates based on other > comments). > > http://cr.openjdk.java.net/~sherman/8194750/webrev > > Thanks! > Sherman > > > + return tio.c_lflag & ECHO; > > Pedantically, functions returning jboolean should return only JNI_TRUE and > JNI_FALSE. I would do: > > return (tio.c_lflag & ECHO) != 0; > > although there's the even more pedantic > > return ((tio.c_lflag & ECHO) != 0) ? JNI_TRUE : JNI_FALSE; > > typo: chosole > > > > > From xueming.shen at oracle.com Tue Apr 17 05:15:00 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 16 Apr 2018 22:15:00 -0700 Subject: RFR: JDK-8194750,Console.readPassword does not save/restore tty settings In-Reply-To: References: <5AD11CCC.9000301@oracle.com> <5AD4F711.8030900@oracle.com> Message-ID: <5AD582D4.5010601@oracle.com> Thanks! webrev has been updated accordingly as suggested. http://cr.openjdk.java.net/~sherman/8194750/webrev sherman On 4/16/18, 7:20 PM, Martin Buchholz wrote: > Thanks, this looks good. > > But I have my usual nitpicky comments > > 376 // sets the console echo on/off > 377 private static native boolean echo(boolean on) throws IOException; > > I would document the return value. > @returnsthe previous console echo on/off status > > 314 boolean echoWasOn = true; > I much prefer leaving it blank (in Java, not C !) > > boolean echoWasOn; > > relying on definite assignment in Java for safety. > From joe.darcy at oracle.com Tue Apr 17 06:22:19 2018 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 16 Apr 2018 23:22:19 -0700 Subject: RFR: 8201609 - Split test/jdk/:tier2 to enable better parallel execution In-Reply-To: <8975932B-74D7-4546-B4D2-6D2A0DC14608@oracle.com> References: <7A7B3D2A-2017-47C2-8967-A6E744009250@oracle.com> <8975932B-74D7-4546-B4D2-6D2A0DC14608@oracle.com> Message-ID: <448726de-7af2-bedd-0780-05caf22910b6@oracle.com> Hi Christian, Regrouping of tests looks fine; cheers, -Joe PS Complementary changes for another day would be an effort to speed up long-running tests. On 4/16/2018 1:20 PM, Christian Tornqvist wrote: > Hi Alan > >> On Apr 16, 2018, at 4:14 05PM, Alan Bateman wrote: >> >> On 16/04/2018 19:15, Christian Tornqvist wrote: >>> Please review this small change that splits the tier2 test group into three smaller test groups that can be executed in parallel. >>> >>> Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8201609/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201609 >>> >> tier_part2 is an odd mix that I couldn't imagine anyone using directly. It's okay for CI systems of course so no objection to the change. >> > Yeah, my intention here was to split the existing group into somewhat balanced smaller parts. I expect normal users to keep running the tier2 group rather than using the tier2_part* ones. > >> Do you know what sun/nio/cs/ISO8859x.java and com/sun/crypto/provider/Cipher are special cased? Just wondering if there is a historical or current reason to not run those. >> > No idea. > > Thanks, > Christian > >> -Alan From martinrb at google.com Tue Apr 17 06:25:19 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 16 Apr 2018 23:25:19 -0700 Subject: RFR: JDK-8194750, Console.readPassword does not save/restore tty settings In-Reply-To: <5AD582D4.5010601@oracle.com> References: <5AD11CCC.9000301@oracle.com> <5AD4F711.8030900@oracle.com> <5AD582D4.5010601@oracle.com> Message-ID: Ship it! From Alan.Bateman at oracle.com Tue Apr 17 07:10:57 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 17 Apr 2018 08:10:57 +0100 Subject: RFR: 8201609 - Split test/jdk/:tier2 to enable better parallel execution In-Reply-To: <8975932B-74D7-4546-B4D2-6D2A0DC14608@oracle.com> References: <7A7B3D2A-2017-47C2-8967-A6E744009250@oracle.com> <8975932B-74D7-4546-B4D2-6D2A0DC14608@oracle.com> Message-ID: <953da1c3-98dc-fe71-e2fc-b6576648a64f@oracle.com> On 16/04/2018 21:20, Christian Tornqvist wrote: >> Do you know what sun/nio/cs/ISO8859x.java and com/sun/crypto/provider/Cipher are special cased? Just wondering if there is a historical or current reason to not run those. >> > No idea. It would be useful to find out why is was setup like this, if we can. The reason is that it will come up every time there is re-balancing of the tiers. -Alan From Alan.Bateman at oracle.com Tue Apr 17 07:13:12 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 17 Apr 2018 08:13:12 +0100 Subject: RFR: JDK-8194750,Console.readPassword does not save/restore tty settings In-Reply-To: <5AD582D4.5010601@oracle.com> References: <5AD11CCC.9000301@oracle.com> <5AD4F711.8030900@oracle.com> <5AD582D4.5010601@oracle.com> Message-ID: <9fb3d943-4776-db12-3a9e-a9779ff821bc@oracle.com> On 17/04/2018 06:15, Xueming Shen wrote: > Thanks! > > webrev has been updated accordingly as suggested. > http://cr.openjdk.java.net/~sherman/8194750/webrev Just catching on this one. The changes looks good, I'm just wondering if there is any way to create a reliable test for this. -Alan From raffaello.giulietti at gmail.com Tue Apr 17 08:22:35 2018 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 17 Apr 2018 10:22:35 +0200 Subject: Clean-room implementation of Double::toString(double) and Float::toString(float) In-Reply-To: <20180416155224.486146748@eggemoggin.niobe.net> References: <5c8944fa-4941-79b4-9320-a04ecb93b27a@gmail.com> <8FC2F9AF-7B48-45FD-B65E-405122F1E21D@oracle.com> <9ffa5039-82b6-6f0b-479b-307361d8ba7a@gmail.com> <3BD60996-BEC9-4179-91F8-39E002B33594@oracle.com> <1806ffc6-fd62-0e15-77bb-4b53a28c9e36@gmail.com> <20180416155224.486146748@eggemoggin.niobe.net> Message-ID: Thanks Mark, in your position as the Chief Architect, Java Platform Group at Oracle, I take yours as the most authoritative answer I've got so far. Tomorrow I should find the time to finally upload the code. Thanks to everybody who kindly replied to this thread. Greetings Raffaello On 2018-04-17 00:52, mark.reinhold at oracle.com wrote: > 2018/4/12 1:12:36 -0700, raffaello.giulietti at gmail.com: >> my code is now ready to be uploaded to the OpenJDK reps. Currently it >> resides on GitHub and is under the "GPLv2 + Classpath Exception" >> license, with myself as the copyright holder. >> >> I asked Oracle about how the copyright notice should be adapted to meet >> the OCA requirements but, as of today, I got no answer. >> >> Is there any official reference about the copyright notice on OpenJDK >> contributions? > > For library code, the template is in $JDK/make/templates/gpl-cp-header [1]. > It begins: > > Copyright (c) %YEARS% 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 > ... > > You can just use the Oracle copyright line or, at your option, replace > it with your own. In any case %YEARS% should be replaced with the year > in which the file was created, and if it was modified in any later year > then the creation year should be followed by the latest year in which > the file was modified, separated by a comma. > > (We can better advise you on the details once we see the actual code.) > > - Mark > > > [1] http://hg.openjdk.java.net/jdk/jdk/file/tip/make/templates/gpl-cp-header > From david.holmes at oracle.com Tue Apr 17 08:48:53 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Apr 2018 18:48:53 +1000 Subject: (M) RFR: 8200167: Validate more special case invocations Message-ID: <27391c2a-fd5c-8133-8e31-b8b45db157ce@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8200167 webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev/ Credit to John Rose and Vladimir Ivanov for the form of the MH fix; and to Tobias Hartmann for the C1 fix. Their help was very much appreciated (and needed!). tl;dr version: there are some places where badly formed interface method calls (which are not detected by the verifier) were missing runtime checks on the type of the receiver. Similar issues have been fixed in the past and this was a remaining hole in relation to invokespecial semantics and interface calls via MethodHandles. It also turned out there was an issue in C1 that affected direct invokespecial calls. Description of changes: - src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java Added a new form LF_INVSPECIAL_IFC for invokespecial of interface methods. - src/java.base/share/classes/java/lang/invoke/MethodHandles.java Renamed callerClass parameter to boundCallerClass, where it originates from findBoundCallerClass. The name "callerClass" is misleading because most of the time it is NULL! In getDirectMethodCommon, pass the actual caller class (lookupClass) to DirectMethodHandle.make. And correct the comment about restrictReceiver. - src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java DirectMethodHandle.make now takes a callerClass parameter (which may be null). DirectMethodHandle make "receiver" parameter is renamed "refc" as it is not the receiver (it's the resolved type of the method holder ie REFC). The Special subclass now takes a "checkClass" parameter which is either refc, or callerClass. This is what we will check the receiver against. In preparedLambdaForm we switch from LF_INVSPECIAL to LF_INVSPECIAL_IFC if the target method is in an interface. In makePreparedLambdaForm we augment the needsReceiverCheck test to include LF_INVSPECIAL_IFC. (So we will not be doing a new receiver type check on all invokespecials, just those involving interface methods.) Added DMH.checkReceiver which is overridden by both the Special and Interface subclasses. - src/hotspot/share/c1/c1_Canonicalizer.cpp Don't optimize away the checkcast when it is an invokespecial receiver check. - test/jdk/java/lang/invoke/SpecialInterfaceCall.java (I've moved this test back and forth between hotspot/runtime and j.l.invoke as it spans direct calls and MH calls. But I think on balance it lands better here.) The test sets up direct interface method calls for which invokespecial is generated by javac, and similarly it creates MethodHandles with invokespecial semantics. The should-not-throw cases are trivial. The should-throw cases involve MH wizardry. The test is broken into three parts to check the behaviour on first use (when the method has to be initially resolved); on second use (to test we don't use the cpcache in a way that is invalid); and again after forcing JIT compilation of the calls. The test is run 5 times to exercise the interpreter (yes the multiple runs internal to the test are redundant in this case, but it's much simpler to just run it all than try to work out what needs to be run); the three variants of using C1, plus a C2 only run. --- Testing: - the new test of course - hotspot/runtime/* - hotspot/compiler/jsr292 - jdk/java/lang/invoke - hs tiers 1 and 2 - jdk tiers 1, 2 and 3 Plus some related closed tests. Thanks, David ----- From sean.coffey at oracle.com Tue Apr 17 10:57:51 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 17 Apr 2018 11:57:51 +0100 Subject: RFR: 8201609 - Split test/jdk/:tier2 to enable better parallel execution In-Reply-To: <953da1c3-98dc-fe71-e2fc-b6576648a64f@oracle.com> References: <7A7B3D2A-2017-47C2-8967-A6E744009250@oracle.com> <8975932B-74D7-4546-B4D2-6D2A0DC14608@oracle.com> <953da1c3-98dc-fe71-e2fc-b6576648a64f@oracle.com> Message-ID: <0ae24375-fd0a-728a-532c-bdc21e9a130c@oracle.com> The Cipher tests were re-grouped via https://bugs.openjdk.java.net/browse/JDK-8132855 NIO re-grouped via https://bugs.openjdk.java.net/browse/JDK-8132854 All appears connected with exercising hotspot intrinsics in tier1 testing. regards, Sean. On 17/04/2018 08:10, Alan Bateman wrote: > > > On 16/04/2018 21:20, Christian Tornqvist wrote: >>> Do you know what sun/nio/cs/ISO8859x.java and >>> com/sun/crypto/provider/Cipher are special cased? Just wondering if >>> there is a historical or current reason to not run those. >>> >> No idea. > It would be useful to find out why is was setup like this, if we can. > The reason is that it will come up every time there is re-balancing of > the tiers. > > -Alan > From Alan.Bateman at oracle.com Tue Apr 17 11:01:38 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 17 Apr 2018 12:01:38 +0100 Subject: RFR: 8201609 - Split test/jdk/:tier2 to enable better parallel execution In-Reply-To: <0ae24375-fd0a-728a-532c-bdc21e9a130c@oracle.com> References: <7A7B3D2A-2017-47C2-8967-A6E744009250@oracle.com> <8975932B-74D7-4546-B4D2-6D2A0DC14608@oracle.com> <953da1c3-98dc-fe71-e2fc-b6576648a64f@oracle.com> <0ae24375-fd0a-728a-532c-bdc21e9a130c@oracle.com> Message-ID: <19a7a05c-1c79-1cc6-ec7b-6093fd229a6d@oracle.com> On 17/04/2018 11:57, Se?n Coffey wrote: > The Cipher tests were re-grouped via > https://bugs.openjdk.java.net/browse/JDK-8132855 > > NIO re-grouped via https://bugs.openjdk.java.net/browse/JDK-8132854 > > All appears connected with exercising hotspot intrinsics in tier1 > testing. Thanks for digging into this. We should probably add a comment to these test group definitions as the same question will come up each time that there is re-balancing. -Alan From vivek.theeyarath at oracle.com Tue Apr 17 13:23:33 2018 From: vivek.theeyarath at oracle.com (Vivek Theeyarath) Date: Tue, 17 Apr 2018 06:23:33 -0700 (PDT) Subject: RFR: 8184693: (opt) add Optional.isEmpty In-Reply-To: References: <546b2176-996a-4295-92d8-15d61e769a9a@default> <377271497.2556945.1523698076268.JavaMail.zimbra@u-pem.fr> <86e8387b-5fd7-4229-8cee-bffaf861f20c@default> <9c62e856-1241-4f43-a8dd-61fc0e6e4772@default> <79351318-89C9-419D-A569-C60BDE3E3AC1@oracle.com> Message-ID: <66c23b94-b095-44ee-9f53-8dda808c9b9d@default> Hi All, Please find the updated webrev http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.04 Regards Vivek -----Original Message----- From: Stuart Marks Sent: Tuesday, April 17, 2018 5:11 AM To: Vivek Theeyarath Cc: core-libs-dev ; Paul Sandoz Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty Hi Vivek, Please add "@since 11" tags to the doc comments of the four Optional*.isEmpty() methods. Regarding the tests, I don't think the various newly added testIsEmpty() tests are useful. The setup in those test files already generates a fairly comprehensive set of Optional values from a variety of sources. All the assertion checking is performed in the checkEmpty() and checkPresent() methods. It should be sufficient to add an assertTrue(isEmpty()) call to checkEmpty() -- as you've done -- and also to add an assertFalse(isEmpty()) call to checkPresent(). If these assertions are added, the additional testIsEmpty() test is unnecessary. This applies to all four of the regression test files. Thanks, s'marks On 4/16/18 11:08 AM, Vivek Theeyarath wrote: > Hi All, > Please find the updated webrev http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.02/ . > Here is the csr which I have raised for this change > https://bugs.openjdk.java.net/browse/JDK-8201606 > > Regards > Vivek > -----Original Message----- > From: Chris Hegarty > Sent: Sunday, April 15, 2018 6:48 PM > To: Vivek Theeyarath > Cc: Remi Forax ; core-libs-dev > > Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty > > > >> On 15 Apr 2018, at 11:25, Vivek Theeyarath wrote: >> >> Hi All, >> Please review >> http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.01/ > > This looks ok to me. > > For consistency, can you please update the copyright header year range in OptionalInt. > > -Chris. > >> Regards >> Vivek >> -----Original Message----- >> From: Vivek Theeyarath >> Sent: Saturday, April 14, 2018 6:24 PM >> To: Remi Forax >> Cc: core-libs-dev >> Subject: RE: RFR: 8184693: (opt) add Optional.isEmpty >> >> I missed that Remi. Thanks for pointing it out. Will address those and get back. >> >> Regards >> Vivek >> -----Original Message----- >> From: Remi Forax [mailto:forax at univ-mlv.fr] >> Sent: Saturday, April 14, 2018 2:58 PM >> To: Vivek Theeyarath >> Cc: core-libs-dev >> Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty >> >> Hi Vivek, >> OptionalInt, OptionalLong and OptionalDouble should be changed too. >> >> R?mi >> >> ----- Mail original ----- >>> De: "Vivek Theeyarath" >>> ?: "core-libs-dev" >>> Envoy?: Samedi 14 Avril 2018 08:22:50 >>> Objet: RFR: 8184693: (opt) add Optional.isEmpty >> >>> Hi All, >>> >>> Please review. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8184693 >>> >>> Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.00/ >>> >>> >>> >>> The related jtreg test was run and the test passed . >>> >>> >>> >>> Regards >>> >>> Vivek > From volker.simonis at gmail.com Tue Apr 17 14:52:57 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 17 Apr 2018 16:52:57 +0200 Subject: RFR(S): 8201540: [AIX] Extend the set of supported charsets in java.base In-Reply-To: References: <79b9aaac-aa33-1fc8-93a2-0b6b5bf7ea8d@oracle.com> <59d3d31b-b596-0678-c0bf-69b8f951a40d@oracle.com> Message-ID: Hi Bhaktavatsal Reddy, you change looks good, although I can't really verify all the charset aliases. For example Wikipedia mentions that "ibm-932" is equivalent to "ibm-942" [1] but you made it an alias for "ibm-942C". What's actually the difference between "ibm-942C" and "ibm-942"? I can sponsor your change although I would appreciate if somebody else from IBM could have another look at your change. I tried to compare with "IBM Java 9" but it doesn't seem to exist. They only refer to AdoptOpenJDK and AdoptOpenJDK just uses a vanilla version of OpenJDK. Finally, I hope you won't mind if I update the copyright years on the files you changed before pushing (this is a convention in the OpenJDK project). Best regards, Volker [1] https://en.wikipedia.org/wiki/Code_page_932_(IBM) On Mon, Apr 16, 2018 at 1:10 PM, Bhaktavatsal R Maram wrote: > Hi All, > > I've regenerated webrev using "hg rename" to create template files. webrev looks much neat now.. Thanks Alan for suggestion. > > webrev - http://cr.openjdk.java.net/~gromero/8201540/v2/ > > Thanks, > Bhaktavatsal Reddy > > > -----"core-libs-dev" wrote: ----- > To: Alan Bateman > From: "Bhaktavatsal R Maram" > Sent by: "core-libs-dev" > Date: 04/16/2018 02:38PM > Cc: Tim Ellison , ppc-aix-port-dev at openjdk.java.net, Java Core Libs > Subject: Re: RFR(S): 8201540: [AIX] Extend the set of supported charsets in java.base > > Hi Alan, > > I deleted IBM943C.java (using hg remove) and added new file IBM943C.java.template (using hg add). I now understand that using "hg rename" is giving more meaningful representation in webrev/index.html. > > I will re-generate webrev by renaming source files to templates using "hg rename" > > Thanks, > Bhaktavatsal Reddy > > > > -----Alan Bateman wrote: ----- > To: Bhaktavatsal R Maram , Volker Simonis > From: Alan Bateman > Date: 04/16/2018 02:16PM > Cc: Java Core Libs , Tim Ellison , ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR(S): 8201540: [AIX] Extend the set of supported charsets in java.base > > > On 16/04/2018 09:22, Bhaktavatsal R Maram wrote: >> >> 3. Source files for IBM-942C and IBM-943C are changed to template to support #1 >> > You might want to double check the webrev as it looks like you've added > templates where as I assume you mean to use "hg rename" to rename > IBM942C.java and IBM943C.java. > > -Alan > > > From xueming.shen at oracle.com Tue Apr 17 17:29:55 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 17 Apr 2018 10:29:55 -0700 Subject: RFR: JDK-8194750,Console.readPassword does not save/restore tty settings In-Reply-To: <9fb3d943-4776-db12-3a9e-a9779ff821bc@oracle.com> References: <5AD11CCC.9000301@oracle.com> <5AD4F711.8030900@oracle.com> <5AD582D4.5010601@oracle.com> <9fb3d943-4776-db12-3a9e-a9779ff821bc@oracle.com> Message-ID: <5AD62F13.4020604@oracle.com> On 04/17/2018 12:13 AM, Alan Bateman wrote: > > > On 17/04/2018 06:15, Xueming Shen wrote: >> Thanks! >> >> webrev has been updated accordingly as suggested. >> http://cr.openjdk.java.net/~sherman/8194750/webrev > Just catching on this one. The changes looks good, I'm just wondering if there is any way to create a reliable test for this. > > -Alan It's possible to add something into the regression test (in closed now) that I wrote before built on expect to verify the "echo" status before and after. But given "expect" itself is not that reliable on all platforms and it's in closed, it might not be worth the effort. Any suggestion? sherman From bhamaram at in.ibm.com Tue Apr 17 18:09:51 2018 From: bhamaram at in.ibm.com (Bhaktavatsal R Maram) Date: Tue, 17 Apr 2018 18:09:51 +0000 Subject: RFR(S): 8201540: [AIX] Extend the set of supported charsets in java.base In-Reply-To: References: , <79b9aaac-aa33-1fc8-93a2-0b6b5bf7ea8d@oracle.com> <59d3d31b-b596-0678-c0bf-69b8f951a40d@oracle.com> Message-ID: Hi Volker, Thank you for reviewing the patch. > you change looks good, although I can't really verify all the charset > aliases. For example Wikipedia mentions that "ibm-932" is equivalent > to "ibm-942" [1] but you made it an alias for "ibm-942C". What's > actually the difference between "ibm-942C" and "ibm-942"? IBM-942C is a customized version of IBM-942, in which following characters are replaced with ASCII thus making first 96 character mappings same as ASCII. 0x1A is mapped to 0x1C (in IBM-942) and to 0x1A (in IBM-942C) 0x1C is mapped to 0x7F (in IBM-942) and to 0x1C (in IBM-942C) 0x5C is mapped to 0xA5 (in IBM-942) and to 0x5C (in IBM-942C) 0x7E is mapped to 0x203E (in IBM-942) and to 0x7E (in IBM-942C) 0x7F is mapped to 0x1A (in IBM-942) and to 0x7F (in IBM-942C) Similarly, IBM-943C is a customization for IBM-943 in which character mappings for Yen(?) and overline(?) are replaced by their ASCII equivalents backslash (\) and tilde (~). So, we should be mapping OS code-page IBM-943 to code-page IBM-943C in Java. I am working on fixing these inconsistencies in another defect in-order not to confuse things (I hope it is alright). Current patch mainly address moving default codepage from extended codepage list to standard codepage list. Also, There are few codepages which are missing in OpenJDK. > I can sponsor your change although I would appreciate if somebody else > from IBM could have another look at your change. I tried to compare > with "IBM Java 9" but it doesn't seem to exist. They only refer to > AdoptOpenJDK and AdoptOpenJDK just uses a vanilla version of OpenJDK. Right! OpenJ9 version of JDK9 in AdoptOpenJDK is vanilla version of OpenJDK with OpenJ9. I've picked aliases for this patch from IBM JDK 8. > Finally, I hope you won't mind if I update the copyright years on the > files you changed before pushing (this is a convention in the OpenJDK > project). Sorry, I forgot to take care of copyright. Please change it this time before pushing. I will take care of it henceforth. Thanks, Bhaktavatsal Reddy -----Volker Simonis wrote: ----- To: Bhaktavatsal R Maram From: Volker Simonis Date: 04/17/2018 08:30PM Cc: Alan Bateman , Tim Ellison , ppc-aix-port-dev at openjdk.java.net, Java Core Libs Subject: Re: RFR(S): 8201540: [AIX] Extend the set of supported charsets in java.base Hi Bhaktavatsal Reddy, you change looks good, although I can't really verify all the charset aliases. For example Wikipedia mentions that "ibm-932" is equivalent to "ibm-942" [1] but you made it an alias for "ibm-942C". What's actually the difference between "ibm-942C" and "ibm-942"? I can sponsor your change although I would appreciate if somebody else from IBM could have another look at your change. I tried to compare with "IBM Java 9" but it doesn't seem to exist. They only refer to AdoptOpenJDK and AdoptOpenJDK just uses a vanilla version of OpenJDK. Finally, I hope you won't mind if I update the copyright years on the files you changed before pushing (this is a convention in the OpenJDK project). Best regards, Volker [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Code-5Fpage-5F932-5F-28IBM-29&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=DencrOI40Trgt_TxNW4dYVWqYtpT7dPnHzaSOEsw_ZQ&s=xYfspcI7N7ZAbVMqyjM7YIb_kd-RsFPn6pINIFz_Oa4&e= On Mon, Apr 16, 2018 at 1:10 PM, Bhaktavatsal R Maram wrote: > Hi All, > > I've regenerated webrev using "hg rename" to create template files. webrev looks much neat now.. Thanks Alan for suggestion. > > webrev - https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Egromero_8201540_v2_&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=DencrOI40Trgt_TxNW4dYVWqYtpT7dPnHzaSOEsw_ZQ&s=mDikak1wXAwU-a0yd6dJml9X5N1DJg-GkQmgPl4v_5g&e= > > Thanks, > Bhaktavatsal Reddy > > > -----"core-libs-dev" wrote: ----- > To: Alan Bateman > From: "Bhaktavatsal R Maram" > Sent by: "core-libs-dev" > Date: 04/16/2018 02:38PM > Cc: Tim Ellison , ppc-aix-port-dev at openjdk.java.net, Java Core Libs > Subject: Re: RFR(S): 8201540: [AIX] Extend the set of supported charsets in java.base > > Hi Alan, > > I deleted IBM943C.java (using hg remove) and added new file IBM943C.java.template (using hg add). I now understand that using "hg rename" is giving more meaningful representation in webrev/index.html. > > I will re-generate webrev by renaming source files to templates using "hg rename" > > Thanks, > Bhaktavatsal Reddy > > > > -----Alan Bateman wrote: ----- > To: Bhaktavatsal R Maram , Volker Simonis > From: Alan Bateman > Date: 04/16/2018 02:16PM > Cc: Java Core Libs , Tim Ellison , ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR(S): 8201540: [AIX] Extend the set of supported charsets in java.base > > > On 16/04/2018 09:22, Bhaktavatsal R Maram wrote: >> >> 3. Source files for IBM-942C and IBM-943C are changed to template to support #1 >> > You might want to double check the webrev as it looks like you've added > templates where as I assume you mean to use "hg rename" to rename > IBM942C.java and IBM943C.java. > > -Alan > > > From christian.tornqvist at oracle.com Tue Apr 17 20:11:55 2018 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 17 Apr 2018 16:11:55 -0400 Subject: RFR: 8201609 - Split test/jdk/:tier2 to enable better parallel execution In-Reply-To: <19a7a05c-1c79-1cc6-ec7b-6093fd229a6d@oracle.com> References: <7A7B3D2A-2017-47C2-8967-A6E744009250@oracle.com> <8975932B-74D7-4546-B4D2-6D2A0DC14608@oracle.com> <953da1c3-98dc-fe71-e2fc-b6576648a64f@oracle.com> <0ae24375-fd0a-728a-532c-bdc21e9a130c@oracle.com> <19a7a05c-1c79-1cc6-ec7b-6093fd229a6d@oracle.com> Message-ID: <322CB0BD-2799-4EDF-B331-94A96CC4FD2C@oracle.com> I?ll add a comment in TEST.groups referencing these bugs > On Apr 17, 2018, at 7:01 38AM, Alan Bateman wrote: > > On 17/04/2018 11:57, Se?n Coffey wrote: >> The Cipher tests were re-grouped via https://bugs.openjdk.java.net/browse/JDK-8132855 >> >> NIO re-grouped via https://bugs.openjdk.java.net/browse/JDK-8132854 >> >> All appears connected with exercising hotspot intrinsics in tier1 testing. > Thanks for digging into this. We should probably add a comment to these test group definitions as the same question will come up each time that there is re-balancing. > > -Alan From naoto.sato at oracle.com Tue Apr 17 21:28:16 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 17 Apr 2018 14:28:16 -0700 Subject: [11] RFR: 8181157: CLDR Timezone name fallback implementation Message-ID: Hello, Please review the changes to the following issue: https://bugs.openjdk.java.net/browse/JDK-8181157 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8181157/webrev.05/ This RFE is to implement CLDR time zone names fallback mechanism [1]. Prior to this fix, time zone names are substituted with English names. With this change, it is generated according to the logic defined in TR 35. Here are the highlight of the changes: CLDRConverter: - CLDRConverter has changed to not substitute/invent time zone display names, except English bundle for compatibility & runtime performance. - For English bundle, copy over COMPAT's names as before. - CLDRConverer now parses regionFormat/gmtZeroFormat/exemplarCity CLDR provider: - CLDRTimeZoneNameProviderImpl is introduced to generate fallback names at runtime. - If COMPAT provider is present, use it also as a fallback, before the last resort (GMT offset format) Naoto [1] http://www.unicode.org/reports/tr35/tr35-dates.html#Time_Zone_Names From alexandr.miloslavskiy at gmail.com Wed Apr 18 01:33:37 2018 From: alexandr.miloslavskiy at gmail.com (Alexander Miloslavskiy) Date: Wed, 18 Apr 2018 04:33:37 +0300 Subject: 8194734 : Handle to jimage file inherited into child processes (win) In-Reply-To: <218a902b-6512-fa45-082d-ac690c879852@gmail.com> References: <3efdeaaa-7cb7-15b7-05fe-7409997e44ba@gmail.com> <218a902b-6512-fa45-082d-ac690c879852@gmail.com> Message-ID: <0ccbc9fa-edd3-d4c8-f9be-11a2f11abf30@gmail.com> Alan, thanks a lot for applying my patch! Now, do I need to try and remove the magic from Unix process creation code? Or you'd rather have it untouched? From mandy.chung at oracle.com Wed Apr 18 02:25:01 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 18 Apr 2018 10:25:01 +0800 Subject: RFR: 81820709 - Container Awareness JEP In-Reply-To: References: Message-ID: <4e73dfdf-54f5-eb43-5e7d-0cfb316fb9e7@oracle.com> On 4/3/18 10:09 PM, Bob Vandette wrote: > WEBREV: > > http://cr.openjdk.java.net/~bobv/8182070/v01/webrev I reviewed the webrev and look okay in general. I will look through the javadoc next. Metrics.java 37 *

  • 1. All processes, including the current process within a container.
      includes the numbering. You can drop "1." and other numbers. 42 *
    1. or This adds a bullet. Maybe dropping this line. 81 * @return The name of the provider or null if Metrics are 82 * not enabled. 85 public String getProvider(); Should this method always return non-null name? For optional metric (when it's not available), the method returns 0. For example: 533 * @return The number of bytes transferred or 0 if this metric is not available. How does the client know if the metrics is not available or zero? Or the client does not care? jdk/internal/platform/cgroupv1/Metrics.java 274 return SubSystem.getLongValue(cpuacct, "cpuacct.usage"); Should this be an instance method? like cpuacct.getLongValue("cpuacct.usage"); final field name can be made all caps. I know you are going to include regression tests. > > WEBREV including a Prototype MBEAN for exposing these Metrics: > > This prototype will not be integrated as part of this JEP. It?s for information only. > > http://cr.openjdk.java.net/~bobv/8182070/v01/mbean-proto/ > > > This feature adds a new -XshowSetting option ?system? which displays the > available system Metrics. What does java --help-extra show?? The help message should include -XshowSettings:system only on Linux. > > % java -XshowSettings:system I expect this option shows static/configuration information rather than timing statistics e.g. CPU time and usage.? It may be a smaller set but it may be good information though. It's more appropriate for monitoring tools to show the timing statistics and resource consumption rather than the launcher. Mandy From stuart.marks at oracle.com Wed Apr 18 03:26:24 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 17 Apr 2018 20:26:24 -0700 Subject: RFR: 8184693: (opt) add Optional.isEmpty In-Reply-To: <66c23b94-b095-44ee-9f53-8dda808c9b9d@default> References: <546b2176-996a-4295-92d8-15d61e769a9a@default> <377271497.2556945.1523698076268.JavaMail.zimbra@u-pem.fr> <86e8387b-5fd7-4229-8cee-bffaf861f20c@default> <9c62e856-1241-4f43-a8dd-61fc0e6e4772@default> <79351318-89C9-419D-A569-C60BDE3E3AC1@oracle.com> <66c23b94-b095-44ee-9f53-8dda808c9b9d@default> Message-ID: <08db4e25-a222-89de-e283-34ed70a3883f@oracle.com> Hi Vivek, Thanks for the update. In the test files, please remove the unnecessary imports of List and the various Predicate types. In most cases it's not a problem to have unnecessary imports. I happened to notice in this case that they're left over from the previous version of the webrev, and looking at the current webrev by itself, it's clear they're unnecessary. Thanks, s'marks On 4/17/18 6:23 AM, Vivek Theeyarath wrote: > Hi All, > Please find the updated webrev http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.04 > Regards > Vivek > > -----Original Message----- > From: Stuart Marks > Sent: Tuesday, April 17, 2018 5:11 AM > To: Vivek Theeyarath > Cc: core-libs-dev ; Paul Sandoz > Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty > > Hi Vivek, > > Please add "@since 11" tags to the doc comments of the four Optional*.isEmpty() methods. > > Regarding the tests, I don't think the various newly added testIsEmpty() tests are useful. The setup in those test files already generates a fairly comprehensive set of Optional values from a variety of sources. All the assertion checking is performed in the checkEmpty() and checkPresent() methods. > It should be sufficient to add an assertTrue(isEmpty()) call to checkEmpty() -- as you've done -- and also to add an assertFalse(isEmpty()) call to checkPresent(). If these assertions are added, the additional testIsEmpty() test is unnecessary. > > This applies to all four of the regression test files. > > Thanks, > > s'marks > > On 4/16/18 11:08 AM, Vivek Theeyarath wrote: >> Hi All, >> Please find the updated webrev http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.02/ . >> Here is the csr which I have raised for this change >> https://bugs.openjdk.java.net/browse/JDK-8201606 >> >> Regards >> Vivek >> -----Original Message----- >> From: Chris Hegarty >> Sent: Sunday, April 15, 2018 6:48 PM >> To: Vivek Theeyarath >> Cc: Remi Forax ; core-libs-dev >> >> Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty >> >> >> >>> On 15 Apr 2018, at 11:25, Vivek Theeyarath wrote: >>> >>> Hi All, >>> Please review >>> http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.01/ >> >> This looks ok to me. >> >> For consistency, can you please update the copyright header year range in OptionalInt. >> >> -Chris. >> >>> Regards >>> Vivek >>> -----Original Message----- >>> From: Vivek Theeyarath >>> Sent: Saturday, April 14, 2018 6:24 PM >>> To: Remi Forax >>> Cc: core-libs-dev >>> Subject: RE: RFR: 8184693: (opt) add Optional.isEmpty >>> >>> I missed that Remi. Thanks for pointing it out. Will address those and get back. >>> >>> Regards >>> Vivek >>> -----Original Message----- >>> From: Remi Forax [mailto:forax at univ-mlv.fr] >>> Sent: Saturday, April 14, 2018 2:58 PM >>> To: Vivek Theeyarath >>> Cc: core-libs-dev >>> Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty >>> >>> Hi Vivek, >>> OptionalInt, OptionalLong and OptionalDouble should be changed too. >>> >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "Vivek Theeyarath" >>>> ?: "core-libs-dev" >>>> Envoy?: Samedi 14 Avril 2018 08:22:50 >>>> Objet: RFR: 8184693: (opt) add Optional.isEmpty >>> >>>> Hi All, >>>> >>>> Please review. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8184693 >>>> >>>> Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.00/ >>>> >>>> >>>> >>>> The related jtreg test was run and the test passed . >>>> >>>> >>>> >>>> Regards >>>> >>>> Vivek >> From joe.darcy at oracle.com Wed Apr 18 03:59:08 2018 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 17 Apr 2018 20:59:08 -0700 Subject: JDK 11 RFR of JDK-8201766: Mark TimSortStackSize2.java as intermittently failing Message-ID: Hello, Please review the patch below to address ??? JDK-8201766: Mark TimSortStackSize2.java as intermittently failing which marks the test as failing intermittently and demotes it to tier 2 from tier 1. Thanks, -Joe diff -r 4c77b1453427 test/jdk/TEST.groups --- a/test/jdk/TEST.groups??? Tue Apr 17 16:13:30 2018 -0700 +++ b/test/jdk/TEST.groups??? Tue Apr 17 20:57:01 2018 -0700 @@ -1,4 +1,4 @@ -#? Copyright (c) 2013, 2017, Oracle and/or its affiliates. All rights reserved. +#? Copyright (c) 2013, 2018, 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 @@ -34,12 +34,14 @@ ???? java/nio/Buffer \ ???? com/sun/crypto/provider/Cipher \ ???? :jdk_math \ -??? tools/pack200 +??? tools/pack200 \ +??? -java/util/Arrays/TimSortStackSize2.java ?tier2 = \ ???? :tier2_part1 \ ???? :tier2_part2 \ -??? :tier2_part3 +??? :tier2_part3 \ +??? java/util/Arrays/TimSortStackSize2.java ?# com/sun/crypto/provider/Cipher is in tier1 because of JDK-8132855 ?tier2_part1 = \ diff -r 4c77b1453427 test/jdk/java/util/Arrays/TimSortStackSize2.java --- a/test/jdk/java/util/Arrays/TimSortStackSize2.java??? Tue Apr 17 16:13:30 2018 -0700 +++ b/test/jdk/java/util/Arrays/TimSortStackSize2.java??? Tue Apr 17 20:57:01 2018 -0700 @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2018, 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 @@ -34,6 +34,7 @@ ? * @run main/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions ? *???? -XX:+WhiteBoxAPI TimSortStackSize2 ? * @summary Test TimSort stack size on big arrays + * @key intermittent ? */ ?import java.util.ArrayList; ?import java.util.Arrays; From david.holmes at oracle.com Wed Apr 18 04:06:00 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Apr 2018 14:06:00 +1000 Subject: JDK 11 RFR of JDK-8201766: Mark TimSortStackSize2.java as intermittently failing In-Reply-To: References: Message-ID: Looks fine to me Joe! Thanks, David On 18/04/2018 1:59 PM, joe darcy wrote: > Hello, > > Please review the patch below to address > > ??? JDK-8201766: Mark TimSortStackSize2.java as intermittently failing > > which marks the test as failing intermittently and demotes it to tier 2 > from tier 1. > > Thanks, > > -Joe > > diff -r 4c77b1453427 test/jdk/TEST.groups > --- a/test/jdk/TEST.groups??? Tue Apr 17 16:13:30 2018 -0700 > +++ b/test/jdk/TEST.groups??? Tue Apr 17 20:57:01 2018 -0700 > @@ -1,4 +1,4 @@ > -#? Copyright (c) 2013, 2017, Oracle and/or its affiliates. All rights > reserved. > +#? Copyright (c) 2013, 2018, 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 > @@ -34,12 +34,14 @@ > ???? java/nio/Buffer \ > ???? com/sun/crypto/provider/Cipher \ > ???? :jdk_math \ > -??? tools/pack200 > +??? tools/pack200 \ > +??? -java/util/Arrays/TimSortStackSize2.java > > ?tier2 = \ > ???? :tier2_part1 \ > ???? :tier2_part2 \ > -??? :tier2_part3 > +??? :tier2_part3 \ > +??? java/util/Arrays/TimSortStackSize2.java > > ?# com/sun/crypto/provider/Cipher is in tier1 because of JDK-8132855 > ?tier2_part1 = \ > diff -r 4c77b1453427 test/jdk/java/util/Arrays/TimSortStackSize2.java > --- a/test/jdk/java/util/Arrays/TimSortStackSize2.java??? Tue Apr 17 > 16:13:30 2018 -0700 > +++ b/test/jdk/java/util/Arrays/TimSortStackSize2.java??? Tue Apr 17 > 20:57:01 2018 -0700 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2015, 2018, 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 > @@ -34,6 +34,7 @@ > ? * @run main/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions > ? *???? -XX:+WhiteBoxAPI TimSortStackSize2 > ? * @summary Test TimSort stack size on big arrays > + * @key intermittent > ? */ > ?import java.util.ArrayList; > ?import java.util.Arrays; > From vivek.theeyarath at oracle.com Wed Apr 18 05:34:06 2018 From: vivek.theeyarath at oracle.com (Vivek Theeyarath) Date: Tue, 17 Apr 2018 22:34:06 -0700 (PDT) Subject: RFR: 8184693: (opt) add Optional.isEmpty In-Reply-To: <08db4e25-a222-89de-e283-34ed70a3883f@oracle.com> References: <546b2176-996a-4295-92d8-15d61e769a9a@default> <377271497.2556945.1523698076268.JavaMail.zimbra@u-pem.fr> <86e8387b-5fd7-4229-8cee-bffaf861f20c@default> <9c62e856-1241-4f43-a8dd-61fc0e6e4772@default> <79351318-89C9-419D-A569-C60BDE3E3AC1@oracle.com> <66c23b94-b095-44ee-9f53-8dda808c9b9d@default> <08db4e25-a222-89de-e283-34ed70a3883f@oracle.com> Message-ID: <9a28d433-9b51-46e7-8805-5494e69ace94@default> Hi Stuart, Done with the changes http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.05/ . Regards Vivek -----Original Message----- From: Stuart Marks Sent: Wednesday, April 18, 2018 8:56 AM To: Vivek Theeyarath Cc: core-libs-dev ; Paul Sandoz Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty Hi Vivek, Thanks for the update. In the test files, please remove the unnecessary imports of List and the various Predicate types. In most cases it's not a problem to have unnecessary imports. I happened to notice in this case that they're left over from the previous version of the webrev, and looking at the current webrev by itself, it's clear they're unnecessary. Thanks, s'marks On 4/17/18 6:23 AM, Vivek Theeyarath wrote: > Hi All, > Please find the updated webrev > http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.04 > Regards > Vivek > > -----Original Message----- > From: Stuart Marks > Sent: Tuesday, April 17, 2018 5:11 AM > To: Vivek Theeyarath > Cc: core-libs-dev ; Paul Sandoz > > Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty > > Hi Vivek, > > Please add "@since 11" tags to the doc comments of the four Optional*.isEmpty() methods. > > Regarding the tests, I don't think the various newly added testIsEmpty() tests are useful. The setup in those test files already generates a fairly comprehensive set of Optional values from a variety of sources. All the assertion checking is performed in the checkEmpty() and checkPresent() methods. > It should be sufficient to add an assertTrue(isEmpty()) call to checkEmpty() -- as you've done -- and also to add an assertFalse(isEmpty()) call to checkPresent(). If these assertions are added, the additional testIsEmpty() test is unnecessary. > > This applies to all four of the regression test files. > > Thanks, > > s'marks > > On 4/16/18 11:08 AM, Vivek Theeyarath wrote: >> Hi All, >> Please find the updated webrev http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.02/ . >> Here is the csr which I have raised for this change >> https://bugs.openjdk.java.net/browse/JDK-8201606 >> >> Regards >> Vivek >> -----Original Message----- >> From: Chris Hegarty >> Sent: Sunday, April 15, 2018 6:48 PM >> To: Vivek Theeyarath >> Cc: Remi Forax ; core-libs-dev >> >> Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty >> >> >> >>> On 15 Apr 2018, at 11:25, Vivek Theeyarath wrote: >>> >>> Hi All, >>> Please review >>> http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.01/ >> >> This looks ok to me. >> >> For consistency, can you please update the copyright header year range in OptionalInt. >> >> -Chris. >> >>> Regards >>> Vivek >>> -----Original Message----- >>> From: Vivek Theeyarath >>> Sent: Saturday, April 14, 2018 6:24 PM >>> To: Remi Forax >>> Cc: core-libs-dev >>> Subject: RE: RFR: 8184693: (opt) add Optional.isEmpty >>> >>> I missed that Remi. Thanks for pointing it out. Will address those and get back. >>> >>> Regards >>> Vivek >>> -----Original Message----- >>> From: Remi Forax [mailto:forax at univ-mlv.fr] >>> Sent: Saturday, April 14, 2018 2:58 PM >>> To: Vivek Theeyarath >>> Cc: core-libs-dev >>> Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty >>> >>> Hi Vivek, >>> OptionalInt, OptionalLong and OptionalDouble should be changed too. >>> >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "Vivek Theeyarath" >>>> ?: "core-libs-dev" >>>> Envoy?: Samedi 14 Avril 2018 08:22:50 >>>> Objet: RFR: 8184693: (opt) add Optional.isEmpty >>> >>>> Hi All, >>>> >>>> Please review. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8184693 >>>> >>>> Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.00/ >>>> >>>> >>>> >>>> The related jtreg test was run and the test passed . >>>> >>>> >>>> >>>> Regards >>>> >>>> Vivek >> From stuart.marks at oracle.com Wed Apr 18 06:06:25 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 17 Apr 2018 23:06:25 -0700 Subject: RFR: 8184693: (opt) add Optional.isEmpty In-Reply-To: <9a28d433-9b51-46e7-8805-5494e69ace94@default> References: <546b2176-996a-4295-92d8-15d61e769a9a@default> <377271497.2556945.1523698076268.JavaMail.zimbra@u-pem.fr> <86e8387b-5fd7-4229-8cee-bffaf861f20c@default> <9c62e856-1241-4f43-a8dd-61fc0e6e4772@default> <79351318-89C9-419D-A569-C60BDE3E3AC1@oracle.com> <66c23b94-b095-44ee-9f53-8dda808c9b9d@default> <08db4e25-a222-89de-e283-34ed70a3883f@oracle.com> <9a28d433-9b51-46e7-8805-5494e69ace94@default> Message-ID: <8adae084-7da6-11a8-e614-90eee7d897ef@oracle.com> OK, looks good! +1 from me. s'marks On 4/17/18 10:34 PM, Vivek Theeyarath wrote: > Hi Stuart, > Done with the changes http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.05/ . > Regards > Vivek > -----Original Message----- > From: Stuart Marks > Sent: Wednesday, April 18, 2018 8:56 AM > To: Vivek Theeyarath > Cc: core-libs-dev ; Paul Sandoz > Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty > > Hi Vivek, > > Thanks for the update. In the test files, please remove the unnecessary imports of List and the various Predicate types. In most cases it's not a problem to have unnecessary imports. I happened to notice in this case that they're left over from the previous version of the webrev, and looking at the current webrev by itself, it's clear they're unnecessary. > > Thanks, > > s'marks > > On 4/17/18 6:23 AM, Vivek Theeyarath wrote: >> Hi All, >> Please find the updated webrev >> http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.04 >> Regards >> Vivek >> >> -----Original Message----- >> From: Stuart Marks >> Sent: Tuesday, April 17, 2018 5:11 AM >> To: Vivek Theeyarath >> Cc: core-libs-dev ; Paul Sandoz >> >> Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty >> >> Hi Vivek, >> >> Please add "@since 11" tags to the doc comments of the four Optional*.isEmpty() methods. >> >> Regarding the tests, I don't think the various newly added testIsEmpty() tests are useful. The setup in those test files already generates a fairly comprehensive set of Optional values from a variety of sources. All the assertion checking is performed in the checkEmpty() and checkPresent() methods. >> It should be sufficient to add an assertTrue(isEmpty()) call to checkEmpty() -- as you've done -- and also to add an assertFalse(isEmpty()) call to checkPresent(). If these assertions are added, the additional testIsEmpty() test is unnecessary. >> >> This applies to all four of the regression test files. >> >> Thanks, >> >> s'marks >> >> On 4/16/18 11:08 AM, Vivek Theeyarath wrote: >>> Hi All, >>> Please find the updated webrev http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.02/ . >>> Here is the csr which I have raised for this change >>> https://bugs.openjdk.java.net/browse/JDK-8201606 >>> >>> Regards >>> Vivek >>> -----Original Message----- >>> From: Chris Hegarty >>> Sent: Sunday, April 15, 2018 6:48 PM >>> To: Vivek Theeyarath >>> Cc: Remi Forax ; core-libs-dev >>> >>> Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty >>> >>> >>> >>>> On 15 Apr 2018, at 11:25, Vivek Theeyarath wrote: >>>> >>>> Hi All, >>>> Please review >>>> http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.01/ >>> >>> This looks ok to me. >>> >>> For consistency, can you please update the copyright header year range in OptionalInt. >>> >>> -Chris. >>> >>>> Regards >>>> Vivek >>>> -----Original Message----- >>>> From: Vivek Theeyarath >>>> Sent: Saturday, April 14, 2018 6:24 PM >>>> To: Remi Forax >>>> Cc: core-libs-dev >>>> Subject: RE: RFR: 8184693: (opt) add Optional.isEmpty >>>> >>>> I missed that Remi. Thanks for pointing it out. Will address those and get back. >>>> >>>> Regards >>>> Vivek >>>> -----Original Message----- >>>> From: Remi Forax [mailto:forax at univ-mlv.fr] >>>> Sent: Saturday, April 14, 2018 2:58 PM >>>> To: Vivek Theeyarath >>>> Cc: core-libs-dev >>>> Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty >>>> >>>> Hi Vivek, >>>> OptionalInt, OptionalLong and OptionalDouble should be changed too. >>>> >>>> R?mi >>>> >>>> ----- Mail original ----- >>>>> De: "Vivek Theeyarath" >>>>> ?: "core-libs-dev" >>>>> Envoy?: Samedi 14 Avril 2018 08:22:50 >>>>> Objet: RFR: 8184693: (opt) add Optional.isEmpty >>>> >>>>> Hi All, >>>>> >>>>> Please review. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8184693 >>>>> >>>>> Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.00/ >>>>> >>>>> >>>>> >>>>> The related jtreg test was run and the test passed . >>>>> >>>>> >>>>> >>>>> Regards >>>>> >>>>> Vivek >>> From magnus.ihse.bursie at oracle.com Wed Apr 18 08:40:53 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 18 Apr 2018 10:40:53 +0200 Subject: Clean-room implementation of Double::toString(double) and Float::toString(float) In-Reply-To: <20180416155224.486146748@eggemoggin.niobe.net> References: <5c8944fa-4941-79b4-9320-a04ecb93b27a@gmail.com> <8FC2F9AF-7B48-45FD-B65E-405122F1E21D@oracle.com> <9ffa5039-82b6-6f0b-479b-307361d8ba7a@gmail.com> <3BD60996-BEC9-4179-91F8-39E002B33594@oracle.com> <1806ffc6-fd62-0e15-77bb-4b53a28c9e36@gmail.com> <20180416155224.486146748@eggemoggin.niobe.net> Message-ID: > 17 apr. 2018 kl. 00:52 skrev mark.reinhold at oracle.com: > > 2018/4/12 1:12:36 -0700, raffaello.giulietti at gmail.com: >> my code is now ready to be uploaded to the OpenJDK reps. Currently it >> resides on GitHub and is under the "GPLv2 + Classpath Exception" >> license, with myself as the copyright holder. >> >> I asked Oracle about how the copyright notice should be adapted to meet >> the OCA requirements but, as of today, I got no answer. >> >> Is there any official reference about the copyright notice on OpenJDK >> contributions? > > For library code, the template is in $JDK/make/templates/gpl-cp-header [1]. > It begins: > > Copyright (c) %YEARS% 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 > ... > > You can just use the Oracle copyright line or, at your option, replace > it with your own. In any case %YEARS% should be replaced with the year > in which the file was created, and if it was modified in any later year > then the creation year should be followed by the latest year in which > the file was modified, separated by a comma. The Oracle praxis is that the year or years should still be followed by a comma. E.g: Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. or Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved. I don?t know if this is an Oracle quirk or and (in)official OpenJDK requirement, but it probably doesn?t harm to follow it. :-) /Magnus > > (We can better advise you on the details once we see the actual code.) > > - Mark > > > [1] http://hg.openjdk.java.net/jdk/jdk/file/tip/make/templates/gpl-cp-header From takiguc at linux.vnet.ibm.com Wed Apr 18 08:56:50 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 18 Apr 2018 17:56:50 +0900 Subject: RFR(S): 8201540: [AIX] Extend the set of supported charsets in java.base In-Reply-To: References: <79b9aaac-aa33-1fc8-93a2-0b6b5bf7ea8d@oracle.com> <59d3d31b-b596-0678-c0bf-69b8f951a40d@oracle.com> Message-ID: <5909b598a1162cf353e928ef9b3ddff8@linux.vnet.ibm.com> Hello Volker. (I'm sorry for duplicate posting, I did bad operation) >> What's actually the difference between "ibm-942C" and "ibm-942"? They have two differences on single byte part: 1. Control Character rotation for 0x1A and 0x1C, 0x7F [2] 2. Character replacement for 0x5C and 0x7E (0xFE, 0xFF) For IBM-942 [3], 0x1A<=>U+001C,0x1C<=>U+007F,0x5C<=>U+00A5,0x7E<=>U+203E,0x7F<=>U+001A 0xFE<=>U+005C,0xFF<=>U+007E For IBM-942C, 0x1A<=>U+001A,0x1C<=>U+001C,0x5C<=>U+005C,0x7E<=>U+007E,0x7F<=>U+007F, 0x5C<=U+00A5,0x7E<=U+203E 0xFE=>U+005C,0xFF=>U+007E (It's ASCII compatible) IBM-942's single byte part is IBM-1041 [4]. IBM-932's single byte part is IBM-897 [5]. IBM-1041 is not same as IBM-897. 5 characters were added into IBM-1041 [4]. (0x80,0xA0,0xFD,0xFE,0xFF [2]) [2] https://www-01.ibm.com/software/globalization/cdra/appendix_g.html [3] https://en.wikipedia.org/wiki/Code_page_942 [4] http://www-01.ibm.com/software/globalization/cp/cp01041.html [5] http://www-01.ibm.com/software/globalization/cp/cp00897.html On 2018-04-17 23:52, Volker Simonis wrote: > Hi Bhaktavatsal Reddy, > > you change looks good, although I can't really verify all the charset > aliases. For example Wikipedia mentions that "ibm-932" is equivalent > to "ibm-942" [1] but you made it an alias for "ibm-942C". What's > actually the difference between "ibm-942C" and "ibm-942"? > > I can sponsor your change although I would appreciate if somebody else > from IBM could have another look at your change. I tried to compare > with "IBM Java 9" but it doesn't seem to exist. They only refer to > AdoptOpenJDK and AdoptOpenJDK just uses a vanilla version of OpenJDK. > > Finally, I hope you won't mind if I update the copyright years on the > files you changed before pushing (this is a convention in the OpenJDK > project). > > Best regards, > Volker > > [1] https://en.wikipedia.org/wiki/Code_page_932_(IBM) > > On Mon, Apr 16, 2018 at 1:10 PM, Bhaktavatsal R Maram > wrote: >> Hi All, >> >> I've regenerated webrev using "hg rename" to create template files. >> webrev looks much neat now.. Thanks Alan for suggestion. >> >> webrev - http://cr.openjdk.java.net/~gromero/8201540/v2/ >> >> Thanks, >> Bhaktavatsal Reddy >> >> >> -----"core-libs-dev" wrote: >> ----- >> To: Alan Bateman >> From: "Bhaktavatsal R Maram" >> Sent by: "core-libs-dev" >> Date: 04/16/2018 02:38PM >> Cc: Tim Ellison , >> ppc-aix-port-dev at openjdk.java.net, Java Core Libs >> >> Subject: Re: RFR(S): 8201540: [AIX] Extend the set of supported >> charsets in java.base >> >> Hi Alan, >> >> I deleted IBM943C.java (using hg remove) and added new file >> IBM943C.java.template (using hg add). I now understand that using "hg >> rename" is giving more meaningful representation in webrev/index.html. >> >> I will re-generate webrev by renaming source files to templates using >> "hg rename" >> >> Thanks, >> Bhaktavatsal Reddy >> >> >> >> -----Alan Bateman wrote: ----- >> To: Bhaktavatsal R Maram , Volker Simonis >> >> From: Alan Bateman >> Date: 04/16/2018 02:16PM >> Cc: Java Core Libs , Tim Ellison >> , ppc-aix-port-dev at openjdk.java.net >> Subject: Re: RFR(S): 8201540: [AIX] Extend the set of supported >> charsets in java.base >> >> >> On 16/04/2018 09:22, Bhaktavatsal R Maram wrote: >>> >>> 3. Source files for IBM-942C and IBM-943C are changed to template to >>> support #1 >>> >> You might want to double check the webrev as it looks like you've >> added >> templates where as I assume you mean to use "hg rename" to rename >> IBM942C.java and IBM943C.java. >> >> -Alan >> >> >> From david.holmes at oracle.com Wed Apr 18 08:54:48 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Apr 2018 18:54:48 +1000 Subject: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> Message-ID: <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> Adding core-libs-dev as you're changing java.lang.ArrayIndexOutOfBoundsException. I appreciate the intent here but I find the messages excessively verbose. The basic error is: index N is outside range [0, length-1] David On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: > Hi, > > I would like to print a more verbose text on ArrayIndexOutOfBounds exception > that not only mentions the index, but also the length of the array accessed. > See the bug for documentation of the change of the message. > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ > > @aarch/arm people: > I edited the aarch/arm files. Could you please verify this is correct? > I can not build on these platforms. > > The code on all the other platforms is tested with all the jtreg and jck tests etc. > > Best regards, > Goetz. > > From pallavi.sonal at oracle.com Wed Apr 18 12:41:51 2018 From: pallavi.sonal at oracle.com (Pallavi Sonal) Date: Wed, 18 Apr 2018 05:41:51 -0700 (PDT) Subject: RFR: JDK-8193877- DateTimeFormatterBuilder throws ClassCastException when using padding Message-ID: <55cfb77b-b931-440a-a17d-0dbb7ff04d4c@default> Hi, Please review the changes to the following issue: Bug : https://bugs.openjdk.java.net/browse/JDK-8193877 The proposed fix is located at: Webrev : http://cr.openjdk.java.net/~rpatil/8193877/webrev.00/ When padding is used in a pattern where there are unpadded values adjacent to padded ones (like "pdQ") , the previous PrinterParser (used for parsing 'd' in the example ) is fetched to use its settings for parsing the next value('Q' in the example). But , in cases like this , it is a PadPrinterDecoratorParser instead of an assumed NumberPrinterParser and a ClassCastException is thrown. The fix has been done to check such cases where the previous parserprinter is PadPrinterDecoratorParser and use the new NumberPrinterParser instead for parsing the next value. All the tier1 and tier2 Mach 5 tests have passed. Thanks, Pallavi Sonal From raffaello.giulietti at gmail.com Wed Apr 18 13:55:23 2018 From: raffaello.giulietti at gmail.com (raffaello.giulietti at gmail.com) Date: Wed, 18 Apr 2018 15:55:23 +0200 Subject: uploading of new code Message-ID: <5999fea1-c63b-fca2-3cb7-2198e14f6434@gmail.com> Hi, in thread [1] I mention a clean room implementation of Double.toString(double) and my willingness to contribute it to the OpenJDK project to fix [2]. As of today, my code resides in a module that exports a package simply named "math". The reason I do not alter the original OpenJDK implementation is that I need it *along* my code to be able to compare results. I developed the code in total ignorance of the OpenJDK implementation, so to speak. This is not the end goal, of course, but the safest way to review/test it without potentially breaking existing code. As a consequence, I wonder how to best deliver my contribution to the OpenJDK project in this phase. As far as I understand, webrev [3] is better suited for *changes* to existing code, not specifically for *new* code. I also understand that attachments are not recommended. On the other hand, pasting some thousands of Java lines in a post on the mailing list isn't practical either, I guess. The code currently consists of about 8 files for a total of about 3000 + 600 lines for code + tests. So, how can I best proceed with this initial delivery? Greetings Raffaello [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052355.html [2] https://bugs.openjdk.java.net/browse/JDK-4511638 [3] http://openjdk.java.net/guide/codeReview.html From aph at redhat.com Wed Apr 18 13:58:25 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 18 Apr 2018 14:58:25 +0100 Subject: uploading of new code In-Reply-To: <5999fea1-c63b-fca2-3cb7-2198e14f6434@gmail.com> References: <5999fea1-c63b-fca2-3cb7-2198e14f6434@gmail.com> Message-ID: <2a75915d-dc8e-904b-f05d-58d65d46c80c@redhat.com> On 04/18/2018 02:55 PM, raffaello.giulietti at gmail.com wrote: > So, how can I best proceed with this initial delivery? Once you have an OpenJDK id you can get an account on cr.openjdk.java.net. That's where you should put your changes. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From roger.riggs at oracle.com Wed Apr 18 14:30:25 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 18 Apr 2018 10:30:25 -0400 Subject: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> Message-ID: <627a9603-b04c-d987-bd1e-6f7371c5d2fb@oracle.com> Hi, The message can be simpler and more efficiently convey the information. It should be more consistent with existing uses of ArrayIndexOutOfBoundsException as throw by:? Objects.checkIndex(index, length). Which roughly reads as: Index %d out-of-bounds for length %d Regards, Roger On 4/18/18 4:54 AM, David Holmes wrote: > Adding core-libs-dev as you're changing > java.lang.ArrayIndexOutOfBoundsException. > > I appreciate the intent here but I find the messages excessively > verbose. The basic error is: > > index N is outside range [0, length-1] > > David > > On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> I would like to print a more verbose text on ArrayIndexOutOfBounds >> exception >> that not only mentions the index, but also the length of the array >> accessed. >> See the bug for documentation of the change of the message. >> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ >> >> @aarch/arm people: >> I edited the aarch/arm files. Could you please verify this is correct? >> I can not build on these platforms. >> >> The code on all the other platforms is tested with all the jtreg and >> jck tests etc. >> >> Best regards, >> ?? Goetz. >> >> From shade at redhat.com Wed Apr 18 14:35:38 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 18 Apr 2018 16:35:38 +0200 Subject: uploading of new code In-Reply-To: <2a75915d-dc8e-904b-f05d-58d65d46c80c@redhat.com> References: <5999fea1-c63b-fca2-3cb7-2198e14f6434@gmail.com> <2a75915d-dc8e-904b-f05d-58d65d46c80c@redhat.com> Message-ID: On 04/18/2018 03:58 PM, Andrew Haley wrote: > On 04/18/2018 02:55 PM, raffaello.giulietti at gmail.com wrote: >> So, how can I best proceed with this initial delivery? > > Once you have an OpenJDK id you can get an account on cr.openjdk.java.net. > That's where you should put your changes. ...and until that happens you can ask existing users to host the webrev for you, probably your current sponsor. Brian Burkhalter seems to be your sponsor for this work? -Aleksey From raffaello.giulietti at gmail.com Wed Apr 18 14:49:45 2018 From: raffaello.giulietti at gmail.com (raffaello.giulietti at gmail.com) Date: Wed, 18 Apr 2018 16:49:45 +0200 Subject: uploading of new code In-Reply-To: References: <5999fea1-c63b-fca2-3cb7-2198e14f6434@gmail.com> <2a75915d-dc8e-904b-f05d-58d65d46c80c@redhat.com> Message-ID: <7c9bd6de-1846-ff6c-6a9c-46083e461a38@gmail.com> On 2018-04-18 16:35, Aleksey Shipilev wrote: > On 04/18/2018 03:58 PM, Andrew Haley wrote: >> On 04/18/2018 02:55 PM, raffaello.giulietti at gmail.com wrote: >>> So, how can I best proceed with this initial delivery? >> >> Once you have an OpenJDK id you can get an account on cr.openjdk.java.net. >> That's where you should put your changes. > @Andrew I can't recall having got an OpenJDK id when I got my Oracle Contributor Agreement confirmed. But I'll double check. > ...and until that happens you can ask existing users to host the webrev for you, probably your > current sponsor. Brian Burkhalter seems to be your sponsor for this work? > @Aleksey Right, I suppose Brian is my sponsor. Greetings Raffaello From roger.riggs at oracle.com Wed Apr 18 15:15:21 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 18 Apr 2018 11:15:21 -0400 Subject: uploading of new code In-Reply-To: <7c9bd6de-1846-ff6c-6a9c-46083e461a38@gmail.com> References: <5999fea1-c63b-fca2-3cb7-2198e14f6434@gmail.com> <2a75915d-dc8e-904b-f05d-58d65d46c80c@redhat.com> <7c9bd6de-1846-ff6c-6a9c-46083e461a38@gmail.com> Message-ID: <1dbd8dda-baee-1ae0-2afd-3390aa44ab5d@oracle.com> Hi, The requirements to become an OpenJDK Author[1] are fairly modest but follow from a couple of sponsored contributions after which you can request to become an author. Regards, Roger [1] http://openjdk.java.net/projects/#project-author On 4/18/18 10:49 AM, raffaello.giulietti at gmail.com wrote: > On 2018-04-18 16:35, Aleksey Shipilev wrote: >> On 04/18/2018 03:58 PM, Andrew Haley wrote: >>> On 04/18/2018 02:55 PM, raffaello.giulietti at gmail.com wrote: >>>> So, how can I best proceed with this initial delivery? >>> Once you have an OpenJDK id you can get an account on cr.openjdk.java.net. >>> That's where you should put your changes. > @Andrew > I can't recall having got an OpenJDK id when I got my Oracle Contributor > Agreement confirmed. But I'll double check. > > > >> ...and until that happens you can ask existing users to host the webrev for you, probably your >> current sponsor. Brian Burkhalter seems to be your sponsor for this work? >> > @Aleksey > Right, I suppose Brian is my sponsor. > > > > Greetings > Raffaello From claes.redestad at oracle.com Wed Apr 18 15:20:52 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 18 Apr 2018 17:20:52 +0200 Subject: RFR: 8201650: Move iteration order randomization of unmodifiable Set and Map to iterators Message-ID: Hi, please review this change that moves the use of SALT to iterator creation, which would allow for certain startup optimizations in the future. Bug: https://bugs.openjdk.java.net/browse/JDK-8201650 Webrev: http://cr.openjdk.java.net/~redestad/8201650/open.00/ This does make the randomness of iteration order weaker as we're only randomizing the starting point (varying with the size of the collection) and the iteration direction (run-to-run variant; weaker than calculating per size, but allows this patch to be performance neutral). Some Set/Map operations become very slightly faster with this patch, but that's in the noise. Iterator operations remain largely performance neutral, sometimes even a bit faster. Thanks! /Claes From roger.riggs at oracle.com Wed Apr 18 15:26:40 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 18 Apr 2018 11:26:40 -0400 Subject: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <627a9603-b04c-d987-bd1e-6f7371c5d2fb@oracle.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <627a9603-b04c-d987-bd1e-6f7371c5d2fb@oracle.com> Message-ID: Hi, Also, the new constructor should be public so it can be used in other places. It seems in some cases the error message is a literal in the VM code ( typeArrayKlass.cpp:149). That would seem to be a duplication and not really a good idea. Roger On 4/18/18 10:30 AM, Roger Riggs wrote: > Hi, > > The message can be simpler and more efficiently convey the information. > It should be more consistent with existing uses of > ArrayIndexOutOfBoundsException as > throw by:? Objects.checkIndex(index, length). > > Which roughly reads as: > > ?? Index %d out-of-bounds for length %d > > Regards, Roger > > On 4/18/18 4:54 AM, David Holmes wrote: >> Adding core-libs-dev as you're changing >> java.lang.ArrayIndexOutOfBoundsException. >> >> I appreciate the intent here but I find the messages excessively >> verbose. The basic error is: >> >> index N is outside range [0, length-1] >> >> David >> >> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I would like to print a more verbose text on ArrayIndexOutOfBounds >>> exception >>> that not only mentions the index, but also the length of the array >>> accessed. >>> See the bug for documentation of the change of the message. >>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ >>> >>> @aarch/arm people: >>> I edited the aarch/arm files. Could you please verify this is correct? >>> I can not build on these platforms. >>> >>> The code on all the other platforms is tested with all the jtreg and >>> jck tests etc. >>> >>> Best regards, >>> ?? Goetz. >>> >>> > From ecki at zusammenkunft.net Wed Apr 18 17:27:36 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 18 Apr 2018 19:27:36 +0200 Subject: uploading of new code In-Reply-To: <7c9bd6de-1846-ff6c-6a9c-46083e461a38@gmail.com> References: <5999fea1-c63b-fca2-3cb7-2198e14f6434@gmail.com> <2a75915d-dc8e-904b-f05d-58d65d46c80c@redhat.com> <7c9bd6de-1846-ff6c-6a9c-46083e461a38@gmail.com> Message-ID: <5ad7800f.1c69fb81.50018.a03e@mx.google.com> Hello, I would put it on a standalone Git repo on one of the public hosting sites lile.Github, especially for a first discussion (especially good if added JMH comparisions). I would not expect a id quickly/easily and a in-tree webrev could be created by sponsor for final ok. Bernd Von: raffaello.giulietti at gmail.com Gesendet: Mittwoch, 18. April 2018 19:20 An: Aleksey Shipilev; Andrew Haley; core-libs-dev Betreff: Re: uploading of new code On 2018-04-18 16:35, Aleksey Shipilev wrote: > On 04/18/2018 03:58 PM, Andrew Haley wrote: >> On 04/18/2018 02:55 PM, raffaello.giulietti at gmail.com wrote: >>> So, how can I best proceed with this initial delivery? >> >> Once you have an OpenJDK id you can get an account on cr.openjdk.java.net. >> That's where you should put your changes. > @Andrew I can't recall having got an OpenJDK id when I got my Oracle Contributor Agreement confirmed. But I'll double check. > ...and until that happens you can ask existing users to host the webrev for you, probably your > current sponsor. Brian Burkhalter seems to be your sponsor for this work? > @Aleksey Right, I suppose Brian is my sponsor. Greetings Raffaello From mark.reinhold at oracle.com Wed Apr 18 17:42:42 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 18 Apr 2018 10:42:42 -0700 Subject: uploading of new code In-Reply-To: <5ad7800f.1c69fb81.50018.a03e@mx.google.com> References: <5999fea1-c63b-fca2-3cb7-2198e14f6434@gmail.com> <2a75915d-dc8e-904b-f05d-58d65d46c80c@redhat.com> <7c9bd6de-1846-ff6c-6a9c-46083e461a38@gmail.com> <5ad7800f.1c69fb81.50018.a03e@mx.google.com> Message-ID: <20180418104242.201022647@eggemoggin.niobe.net> 2018/4/18 10:27:36 -0700, ecki at zusammenkunft.net: > Hello, I would put it on a standalone Git repo on one of the public > hosting sites lile.Github, especially for a first discussion > (especially good if added JMH comparisions). I would not expect a id > quickly/easily and a in-tree webrev could be created by sponsor for > final ok. For IP clarity, no Oracle engineer will review code that is not posted, in some form or another (e-mail, webrev, JIRA), directly to OpenJDK. For an initial discussion a patch in e-mail is a fine way to start, even for 3,000 lines of code. Those who care can either read it directly or else import it into a local repo for further evaluation. - Mark From roger.riggs at Oracle.com Wed Apr 18 18:34:39 2018 From: roger.riggs at Oracle.com (Roger Riggs) Date: Wed, 18 Apr 2018 14:34:39 -0400 Subject: RFR: JDK-8193877- DateTimeFormatterBuilder throws ClassCastException when using padding In-Reply-To: <55cfb77b-b931-440a-a17d-0dbb7ff04d4c@default> References: <55cfb77b-b931-440a-a17d-0dbb7ff04d4c@default> Message-ID: Hi Pallavi, The fix here seems to make padding to a fixed width incompatible with adjacent value parsing. That's not intuitive, since adjacent value parsing is intended to allow more flexible parsing of a combination leading fixed-width fields and subsequent variable length fields. The specification of the behavior of padding vs adjacent value parsing should be investigated and clarified if necessary. The implementation would be better expressed as checking whether the active PrinterParser *is* a NumberPrinterParser as a precondition for entering the adjacent parsing mode block (and the necessary cast). And otherwise, fall into the existing code in which the new Parser becomes the new active parser. The tests should be included in the existing test classes for padding, and be written using the direct DateTimeFormatterBuilder methods (padNext(), instead of the patterns) since the patterns are just a front end for the builder methods. See test/java/time/format/TestPadPrinterDecorator.java TestDateTimeFormatter.java: line 96: please keep the static imports for testng together Line 662: The odd formatting and incorrect indentation should no longer be a problem because the indentation will not need to change. Regards, Roger On 4/18/18 8:41 AM, Pallavi Sonal wrote: > Hi, > > Please review the changes to the following issue: > > Bug :https://bugs.openjdk.java.net/browse/JDK-8193877 > > > > The proposed fix is located at: > > Webrev :http://cr.openjdk.java.net/~rpatil/8193877/webrev.00/ > > > > When padding is used in a pattern where there are unpadded values adjacent to padded ones (like "pdQ") , the previous PrinterParser (used for parsing 'd' in the example ) is fetched to use its settings for parsing the next value('Q' in the example). But , in cases like this , it is a PadPrinterDecoratorParser instead of an assumed NumberPrinterParser and a ClassCastException is thrown. > > The fix has been done to check such cases where the previous parserprinter is PadPrinterDecoratorParser and use the new NumberPrinterParser instead for parsing the next value. > > > > All the tier1 and tier2 Mach 5 tests have passed. > > > > Thanks, > > Pallavi Sonal > > From isaac.r.levy at gmail.com Wed Apr 18 18:58:09 2018 From: isaac.r.levy at gmail.com (Isaac Levy) Date: Wed, 18 Apr 2018 14:58:09 -0400 Subject: [PATCH] minor regex cleanup: use switch for enum Message-ID: Hi, Minor improvement in readability (and probably perf) for Pattern. Switch is more consistent with the rest of the impl and the resulting tableswitch avoids a comparison for possessives. -Isaac --- a/src/java.base/share/classes/java/util/regex/Pattern.java +++ b/src/java.base/share/classes/java/util/regex/Pattern.java @@ -4356,7 +4356,9 @@ - if (type == Qtype.GREEDY) + switch (type) { + case GREEDY: return match0(matcher, i, j, seq); - else if (type == Qtype.LAZY) + case LAZY: return match1(matcher, i, j, seq); - else + default: return match2(matcher, i, j, seq); + } @@ -4527,7 +4529,10 @@ - if (type == Qtype.GREEDY) { + switch (type) { + case GREEDY: ret = match0(matcher, i, cmin, seq); + break; - } else if (type == Qtype.LAZY) { + case LAZY: ret = match1(matcher, i, cmin, seq); + break; - } else { + default: ret = match2(matcher, i, cmin, seq); } From roger.riggs at oracle.com Wed Apr 18 19:27:21 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 18 Apr 2018 15:27:21 -0400 Subject: RFR: 8184693: (opt) add Optional.isEmpty In-Reply-To: <8adae084-7da6-11a8-e614-90eee7d897ef@oracle.com> References: <546b2176-996a-4295-92d8-15d61e769a9a@default> <377271497.2556945.1523698076268.JavaMail.zimbra@u-pem.fr> <86e8387b-5fd7-4229-8cee-bffaf861f20c@default> <9c62e856-1241-4f43-a8dd-61fc0e6e4772@default> <79351318-89C9-419D-A569-C60BDE3E3AC1@oracle.com> <66c23b94-b095-44ee-9f53-8dda808c9b9d@default> <08db4e25-a222-89de-e283-34ed70a3883f@oracle.com> <9a28d433-9b51-46e7-8805-5494e69ace94@default> <8adae084-7da6-11a8-e614-90eee7d897ef@oracle.com> Message-ID: <10aa83d9-5bd1-3111-6a4a-962578c3ac68@oracle.com> +1 There is one extra space in Optional.java: line 163:? "is__not". Thanks, Roger On 4/18/18 2:06 AM, Stuart Marks wrote: > OK, looks good! +1 from me. > > s'marks > > On 4/17/18 10:34 PM, Vivek Theeyarath wrote: >> Hi Stuart, >> ????Done with the changes >> http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.05/ . >> Regards >> Vivek >> -----Original Message----- >> From: Stuart Marks >> Sent: Wednesday, April 18, 2018 8:56 AM >> To: Vivek Theeyarath >> Cc: core-libs-dev ; Paul Sandoz >> >> Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty >> >> Hi Vivek, >> >> Thanks for the update. In the test files, please remove the >> unnecessary imports of List and the various Predicate types. In most >> cases it's not a problem to have unnecessary imports. I happened to >> notice in this case that they're left over from the previous version >> of the webrev, and looking at the current webrev by itself, it's >> clear they're unnecessary. >> >> Thanks, >> >> s'marks >> >> On 4/17/18 6:23 AM, Vivek Theeyarath wrote: >>> Hi All, >>> ????Please find the updated webrev >>> http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.04 >>> Regards >>> Vivek >>> >>> -----Original Message----- >>> From: Stuart Marks >>> Sent: Tuesday, April 17, 2018 5:11 AM >>> To: Vivek Theeyarath >>> Cc: core-libs-dev ; Paul Sandoz >>> >>> Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty >>> >>> Hi Vivek, >>> >>> Please add "@since 11" tags to the doc comments of the four >>> Optional*.isEmpty() methods. >>> >>> Regarding the tests, I don't think the various newly added >>> testIsEmpty() tests are useful. The setup in those test files >>> already generates a fairly comprehensive set of Optional values from >>> a variety of sources. All the assertion checking is performed in the >>> checkEmpty() and checkPresent() methods. >>> It should be sufficient to add an assertTrue(isEmpty()) call to >>> checkEmpty() -- as you've done -- and also to add an >>> assertFalse(isEmpty()) call to checkPresent(). If these assertions >>> are added, the additional testIsEmpty() test is unnecessary. >>> >>> This applies to all four of the regression test files. >>> >>> Thanks, >>> >>> s'marks >>> >>> On 4/16/18 11:08 AM, Vivek Theeyarath wrote: >>>> Hi All, >>>> ????Please find the updated webrev >>>> http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.02/ . >>>> Here is the csr which I have raised for this change >>>> https://bugs.openjdk.java.net/browse/JDK-8201606 >>>> >>>> Regards >>>> Vivek >>>> -----Original Message----- >>>> From: Chris Hegarty >>>> Sent: Sunday, April 15, 2018 6:48 PM >>>> To: Vivek Theeyarath >>>> Cc: Remi Forax ; core-libs-dev >>>> >>>> Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty >>>> >>>> >>>> >>>>> On 15 Apr 2018, at 11:25, Vivek Theeyarath >>>>> wrote: >>>>> >>>>> Hi All, >>>>> ????? Please review >>>>> http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.01/ >>>> >>>> This looks ok to me. >>>> >>>> For consistency, can you please update the copyright header year >>>> range in OptionalInt. >>>> >>>> -Chris. >>>> >>>>> Regards >>>>> Vivek >>>>> -----Original Message----- >>>>> From: Vivek Theeyarath >>>>> Sent: Saturday, April 14, 2018 6:24 PM >>>>> To: Remi Forax >>>>> Cc: core-libs-dev >>>>> Subject: RE: RFR: 8184693: (opt) add Optional.isEmpty >>>>> >>>>> I missed that Remi. Thanks for pointing it out. Will address those >>>>> and get back. >>>>> >>>>> Regards >>>>> Vivek >>>>> -----Original Message----- >>>>> From: Remi Forax [mailto:forax at univ-mlv.fr] >>>>> Sent: Saturday, April 14, 2018 2:58 PM >>>>> To: Vivek Theeyarath >>>>> Cc: core-libs-dev >>>>> Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty >>>>> >>>>> Hi Vivek, >>>>> OptionalInt, OptionalLong and OptionalDouble should be changed too. >>>>> >>>>> R?mi >>>>> >>>>> ----- Mail original ----- >>>>>> De: "Vivek Theeyarath" >>>>>> ?: "core-libs-dev" >>>>>> Envoy?: Samedi 14 Avril 2018 08:22:50 >>>>>> Objet: RFR: 8184693: (opt) add Optional.isEmpty >>>>> >>>>>> Hi All, >>>>>> >>>>>> ??????????????? Please review. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8184693 >>>>>> >>>>>> Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.00/ >>>>>> >>>>>> >>>>>> >>>>>> The related jtreg test was run and the test passed . >>>>>> >>>>>> >>>>>> >>>>>> Regards >>>>>> >>>>>> Vivek >>>> From xueming.shen at oracle.com Wed Apr 18 20:09:33 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 18 Apr 2018 13:09:33 -0700 Subject: [JDK-6341887] RFR: Patch V3: java.util.zip: Add ByteBuffer methods to Inflater/Deflater In-Reply-To: <5ACD85AD.4010009@oracle.com> References: <5AB53E95.9080308@oracle.com> <10728b43-110c-5dc3-1fdb-2e0241e3a0ff@oracle.com> <5ABC6DCF.10504@oracle.com> <6a2c6a54-9174-5815-80c1-35029931e0f2@oracle.com> <5ABE6B4A.1010701@oracle.com> <5ABE6E64.1060806@oracle.com> <5ACD85AD.4010009@oracle.com> Message-ID: <5AD7A5FD.8090301@oracle.com> Alan, David, Any more update/comment/suggestion on this one? I have updated DeInflate.java with some new test cases to cover the newly added methods. Good to go? -Sherman On 04/10/2018 08:49 PM, Xueming Shen wrote: > > > http://cr.openjdk.java.net/~sherman/6341887.David.Lloyd/webrev/ > > Thanks, > Sherman > From david.lloyd at redhat.com Wed Apr 18 20:16:00 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 18 Apr 2018 15:16:00 -0500 Subject: [JDK-6341887] RFR: Patch V3: java.util.zip: Add ByteBuffer methods to Inflater/Deflater In-Reply-To: <5AD7A5FD.8090301@oracle.com> References: <5AB53E95.9080308@oracle.com> <10728b43-110c-5dc3-1fdb-2e0241e3a0ff@oracle.com> <5ABC6DCF.10504@oracle.com> <6a2c6a54-9174-5815-80c1-35029931e0f2@oracle.com> <5ABE6B4A.1010701@oracle.com> <5ABE6E64.1060806@oracle.com> <5ACD85AD.4010009@oracle.com> <5AD7A5FD.8090301@oracle.com> Message-ID: +1 from me, thanks! On Wed, Apr 18, 2018 at 3:09 PM, Xueming Shen wrote: > Alan, David, > > Any more update/comment/suggestion on this one? I have updated > DeInflate.java with > some new test cases to cover the newly added methods. Good to go? > > -Sherman > > On 04/10/2018 08:49 PM, Xueming Shen wrote: >> >> >> >> http://cr.openjdk.java.net/~sherman/6341887.David.Lloyd/webrev/ >> >> Thanks, >> Sherman >> > -- - DML From david.holmes at oracle.com Wed Apr 18 22:07:59 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Apr 2018 08:07:59 +1000 Subject: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <627a9603-b04c-d987-bd1e-6f7371c5d2fb@oracle.com> Message-ID: <294280a2-c687-0d38-c0cf-6b21d44ecfea@oracle.com> Adding back hotspot-runtime-dev - please reply-all On 19/04/2018 1:26 AM, Roger Riggs wrote: > Hi, > > Also, the new constructor should be public so it can be used in other > places. That takes this from being a simple change that adds more info to the exception message, to an API addition that requires a CSR etc. That changes the scope considerably. I'm not 100% clear why we need to change the Java side of this when we can push a message with the desired info from the VM side? David > It seems in some cases the error message is a literal in the VM code ( > typeArrayKlass.cpp:149). > That would seem to be a duplication and not really a good idea. > > Roger > > > On 4/18/18 10:30 AM, Roger Riggs wrote: >> Hi, >> >> The message can be simpler and more efficiently convey the information. >> It should be more consistent with existing uses of >> ArrayIndexOutOfBoundsException as >> throw by:? Objects.checkIndex(index, length). >> >> Which roughly reads as: >> >> ?? Index %d out-of-bounds for length %d >> >> Regards, Roger >> >> On 4/18/18 4:54 AM, David Holmes wrote: >>> Adding core-libs-dev as you're changing >>> java.lang.ArrayIndexOutOfBoundsException. >>> >>> I appreciate the intent here but I find the messages excessively >>> verbose. The basic error is: >>> >>> index N is outside range [0, length-1] >>> >>> David >>> >>> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I would like to print a more verbose text on ArrayIndexOutOfBounds >>>> exception >>>> that not only mentions the index, but also the length of the array >>>> accessed. >>>> See the bug for documentation of the change of the message. >>>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ >>>> >>>> @aarch/arm people: >>>> I edited the aarch/arm files. Could you please verify this is correct? >>>> I can not build on these platforms. >>>> >>>> The code on all the other platforms is tested with all the jtreg and >>>> jck tests etc. >>>> >>>> Best regards, >>>> ?? Goetz. >>>> >>>> >> > From jiangli.zhou at oracle.com Thu Apr 19 00:04:50 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 18 Apr 2018 17:04:50 -0700 Subject: RFR: 8201650: Move iteration order randomization of unmodifiable Set and Map to iterators In-Reply-To: References: Message-ID: <728B2ADC-352D-4BAA-864A-22D879FA6D42@oracle.com> Hi Claes, Moving the use of SALT to iterator creation is a great idea! You change looks really good. Thanks for making the change! Jiangli > On Apr 18, 2018, at 8:20 AM, Claes Redestad wrote: > > Hi, > > please review this change that moves the use of SALT to iterator creation, which would allow for certain startup > optimizations in the future. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8201650 > Webrev: http://cr.openjdk.java.net/~redestad/8201650/open.00/ > > This does make the randomness of iteration order weaker as we're only randomizing the starting point (varying with > the size of the collection) and the iteration direction (run-to-run variant; weaker than calculating per size, but > allows this patch to be performance neutral). > > Some Set/Map operations become very slightly faster with this patch, but that's in the noise. Iterator operations > remain largely performance neutral, sometimes even a bit faster. > > Thanks! > > /Claes > > > From xueming.shen at oracle.com Thu Apr 19 06:13:13 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 18 Apr 2018 23:13:13 -0700 Subject: [JDK-6341887] RFR: Patch V3: java.util.zip: Add ByteBuffer methods to Inflater/Deflater In-Reply-To: References: <5AB53E95.9080308@oracle.com> <10728b43-110c-5dc3-1fdb-2e0241e3a0ff@oracle.com> <5ABC6DCF.10504@oracle.com> <6a2c6a54-9174-5815-80c1-35029931e0f2@oracle.com> <5ABE6B4A.1010701@oracle.com> <5ABE6E64.1060806@oracle.com> <5ACD85AD.4010009@oracle.com> <5AD7A5FD.8090301@oracle.com> Message-ID: <5AD83379.7050201@oracle.com> David, webrev has been updated to address the compiler error on solaris-sparcv9. The C comipler on solaris-sparcv9 platform does not like those "declaration follow a statement" new code in Deflater.c and Inflater.c http://cr.openjdk.java.net/~sherman/6341887.David.Lloyd/webrev/ Thanks, Sherman On 4/18/18, 1:16 PM, David Lloyd wrote: > +1 from me, thanks! > > On Wed, Apr 18, 2018 at 3:09 PM, Xueming Shen wrote: >> Alan, David, >> >> Any more update/comment/suggestion on this one? I have updated >> DeInflate.java with >> some new test cases to cover the newly added methods. Good to go? >> >> -Sherman >> >> On 04/10/2018 08:49 PM, Xueming Shen wrote: >>> >>> >>> http://cr.openjdk.java.net/~sherman/6341887.David.Lloyd/webrev/ >>> >>> Thanks, >>> Sherman >>> > > From raffaello.giulietti at gmail.com Thu Apr 19 08:07:36 2018 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Thu, 19 Apr 2018 10:07:36 +0200 Subject: uploading of new code In-Reply-To: <20180418104242.201022647@eggemoggin.niobe.net> References: <5999fea1-c63b-fca2-3cb7-2198e14f6434@gmail.com> <2a75915d-dc8e-904b-f05d-58d65d46c80c@redhat.com> <7c9bd6de-1846-ff6c-6a9c-46083e461a38@gmail.com> <5ad7800f.1c69fb81.50018.a03e@mx.google.com> <20180418104242.201022647@eggemoggin.niobe.net> Message-ID: <10a0bd01-e3ed-022d-499a-77ea2756210e@gmail.com> On 2018-04-18 19:42, mark.reinhold at oracle.com wrote: > 2018/4/18 10:27:36 -0700, ecki at zusammenkunft.net: >> Hello, I would put it on a standalone Git repo on one of the public >> hosting sites lile.Github, especially for a first discussion >> (especially good if added JMH comparisions). I would not expect a id >> quickly/easily and a in-tree webrev could be created by sponsor for >> final ok. > > For IP clarity, no Oracle engineer will review code that is not posted, > in some form or another (e-mail, webrev, JIRA), directly to OpenJDK. > > For an initial discussion a patch in e-mail is a fine way to start, even > for 3,000 lines of code. Those who care can either read it directly or > else import it into a local repo for further evaluation. > > - Mark > I already uploaded the code on a GitHub repo last week, just to have it published somewhere, but in fact didn't expect this move to be recognized as an official delivery to the OpenJDK project, hence never advertised the URL. So I will deliver the exact same code as found on GitHub both to this mailing list and to Brian Burkhalter, who is the Oracle engineer in charge of [1]. Sorry guys for all these trivia. Greetings Raffaello [1] https://bugs.openjdk.java.net/browse/JDK-4511638 From huaming.li at oracle.com Thu Apr 19 08:17:31 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 19 Apr 2018 16:17:31 +0800 Subject: RFR of JDK-8201469,test under java/rmi should be restricted to not run concurrently Message-ID: <36dd9cd1-d748-b67e-3bff-edee4cab5edd@oracle.com> would you please review the following patch? bug: https://bugs.openjdk.java.net/browse/JDK-8201469 http://cr.openjdk.java.net/~mli/8201469/webrev.00/ ( For othervm.dirs property, I just reformat it. ) In my test result, with jtreg option "-concurrency:4", after apply the patch, tier3 tests on different platforms will be slower about 1.5~2.0 times than before. I think stability of tests are more important than executing time, how do you think about it? Thank you -Hamlin From david.lloyd at redhat.com Thu Apr 19 12:16:55 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 19 Apr 2018 07:16:55 -0500 Subject: [JDK-6341887] RFR: Patch V3: java.util.zip: Add ByteBuffer methods to Inflater/Deflater In-Reply-To: <5AD83379.7050201@oracle.com> References: <5AB53E95.9080308@oracle.com> <10728b43-110c-5dc3-1fdb-2e0241e3a0ff@oracle.com> <5ABC6DCF.10504@oracle.com> <6a2c6a54-9174-5815-80c1-35029931e0f2@oracle.com> <5ABE6B4A.1010701@oracle.com> <5ABE6E64.1060806@oracle.com> <5ACD85AD.4010009@oracle.com> <5AD7A5FD.8090301@oracle.com> <5AD83379.7050201@oracle.com> Message-ID: OK thanks for the update. It seems odd to me - C99 has been around for a pretty long time - but, as long as the change goes in, I'm happy. Thanks! On Thu, Apr 19, 2018 at 1:13 AM, Xueming Shen wrote: > David, > > webrev has been updated to address the compiler error on solaris-sparcv9. > The C comipler on > solaris-sparcv9 platform does not like those "declaration follow a > statement" new code in > Deflater.c and Inflater.c > > http://cr.openjdk.java.net/~sherman/6341887.David.Lloyd/webrev/ > > Thanks, > Sherman > > > On 4/18/18, 1:16 PM, David Lloyd wrote: > > +1 from me, thanks! > > On Wed, Apr 18, 2018 at 3:09 PM, Xueming Shen > wrote: > > Alan, David, > > Any more update/comment/suggestion on this one? I have updated > DeInflate.java with > some new test cases to cover the newly added methods. Good to go? > > -Sherman > > On 04/10/2018 08:49 PM, Xueming Shen wrote: > > > http://cr.openjdk.java.net/~sherman/6341887.David.Lloyd/webrev/ > > Thanks, > Sherman > > > > -- - DML From Alan.Bateman at oracle.com Thu Apr 19 12:20:35 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Apr 2018 13:20:35 +0100 Subject: [JDK-6341887] RFR: Patch V3: java.util.zip: Add ByteBuffer methods to Inflater/Deflater In-Reply-To: References: <10728b43-110c-5dc3-1fdb-2e0241e3a0ff@oracle.com> <5ABC6DCF.10504@oracle.com> <6a2c6a54-9174-5815-80c1-35029931e0f2@oracle.com> <5ABE6B4A.1010701@oracle.com> <5ABE6E64.1060806@oracle.com> <5ACD85AD.4010009@oracle.com> <5AD7A5FD.8090301@oracle.com> <5AD83379.7050201@oracle.com> Message-ID: On 19/04/2018 13:16, David Lloyd wrote: > OK thanks for the update. It seems odd to me - C99 has been around > for a pretty long time - but, as long as the change goes in, I'm > happy. Thanks! > I think this is about the compiler options that are used by the build, specifically when compiling JNI code. It came up recently on build-dev too and I thought there was a JIRA issue created to re-examine them. -Alan From goetz.lindenmaier at sap.com Thu Apr 19 12:24:55 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 19 Apr 2018 12:24:55 +0000 Subject: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> Message-ID: <5be0f86df2834aa8a881206ba285011e@sap.com> Hi, New webrev: http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ I admit my wording is not optimal. It's because I extracted this change from a bigger one. Our message reads like this: Object [] oa1 = new Object[10] oa1[12] "ArrayIndexOutOfBoundsException while trying to load from index 12 of an object array with length 10, loaded from local variable 'oa1'" ... which seems not optimal, either. But it mentions the type (object), the operation (load, store etc ...) and the variable name. Naming the array is quite detailed if it is in a complex expression (like returned from a call). I'll contribute more of this if appreciated, this is a first step. Printing "index N is outside range [0, length-1]" is problematic for length '0'. I followed the proposal by Roger: "Index -1 out-of-bounds for length 10." I removed the change to ArrayIndexOutOfBoundsException.java. I extended the test to cover the exception thrown in arraycopy better and added the elementary type to the message text. This probably needs improvement in the text, too. There are (currently) these cases: bject[] oa1 = new Object[10]; Object[] oa2 = new Object[5]; System.arraycopy(oa1, -17, oa2, 0, 5); "while trying to copy from index -17 of an object array with length 10"); System.arraycopy(oa1, 2, oa2, -18, 5); "while trying to copy to index -18 of an object array with length 5"); System.arraycopy(oa1, 2, oa2, 0, -19); "while trying to copy a negative range -19 from an object array with length 10 to an object array with length 5"); System.arraycopy(oa1, 8, oa2, 0, 5); "while trying to copy from index 13 of an object array with length 10"); System.arraycopy(oa1, 1, oa2, 0, 7); "while trying to copy to index 7 of an object array with length 5"); double[] ta1 = new double[10]; double[] ta2 = new double[5]; System.arraycopy(ta1, -17, ta2, 0, 5); "while trying to copy from index -17 of a doubl array with length 10"); System.arraycopy(ta1, 2, ta2, -18, 5); "while trying to copy to index -18 of a double array with length 5"); System.arraycopy(ta1, 2, ta2, 0, -19); "while trying to copy a negative range -19 from a double array with length 10 to a double array with length 5"); System.arraycopy(ta1, 8, ta2, 0, 5); "while trying to copy from index 13 of a double array with length 10"); System.arraycopy(ta1, 1, ta2, 0, 7); "while trying to copy to index 7 of a double array with length 5"); Maybe it should say: Arraycopy source index -1 out-of-bounds for double array of length 10. Arraycopy target index 10 out-of-bounds for object array of length 10. Negative range -19 when copying from an object array of length 10 to an object array of length 5. Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Mittwoch, 18. April 2018 10:55 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; aarch64- > port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core-libs- > dev Libs > Subject: Re: RFR(M): 8201593: Print array length in > ArrayIndexOutOfBoundsException. > > Adding core-libs-dev as you're changing > java.lang.ArrayIndexOutOfBoundsException. > > I appreciate the intent here but I find the messages excessively > verbose. The basic error is: > > index N is outside range [0, length-1] > > David > > On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > I would like to print a more verbose text on ArrayIndexOutOfBounds > exception > > that not only mentions the index, but also the length of the array accessed. > > See the bug for documentation of the change of the message. > > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ > > > > @aarch/arm people: > > I edited the aarch/arm files. Could you please verify this is correct? > > I can not build on these platforms. > > > > The code on all the other platforms is tested with all the jtreg and jck tests > etc. > > > > Best regards, > > Goetz. > > > > From aph at redhat.com Thu Apr 19 12:56:12 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Apr 2018 13:56:12 +0100 Subject: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <627a9603-b04c-d987-bd1e-6f7371c5d2fb@oracle.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <627a9603-b04c-d987-bd1e-6f7371c5d2fb@oracle.com> Message-ID: <2b3204bd-2fe9-b7c5-fa49-011a464e488b@redhat.com> On 04/18/2018 03:30 PM, Roger Riggs wrote: > Which roughly reads as: > > Index %d out-of-bounds for length %d "out-of-bounds" shouldn't be hyphenated because it's not a compound adjective. Besides that, it's unnecessary because you already know its an ArrayIndexOutOfBoundsException. Index %d in array[%d] is all you need. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From roger.riggs at oracle.com Thu Apr 19 17:21:27 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 19 Apr 2018 13:21:27 -0400 Subject: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <294280a2-c687-0d38-c0cf-6b21d44ecfea@oracle.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <627a9603-b04c-d987-bd1e-6f7371c5d2fb@oracle.com> <294280a2-c687-0d38-c0cf-6b21d44ecfea@oracle.com> Message-ID: <712f0a3d-3ac0-3b6f-afbe-856a95f8ec53@oracle.com> Hi David, A private constructor that is apparently unused (because it is used implicitly by code buried in HotSpot) is going to raise questions. Strictly speaking the new constructor is not necessary since the native code can compose the full message and use the existing constructor. I'd recommend that approach. Thanks, Roger p.s. I'm headed out on vacation today On 4/18/18 6:07 PM, David Holmes wrote: > Adding back hotspot-runtime-dev? - please reply-all > > On 19/04/2018 1:26 AM, Roger Riggs wrote: >> Hi, >> >> Also, the new constructor should be public so it can be used in other >> places. > > That takes this from being a simple change that adds more info to the > exception message, to an API addition that requires a CSR etc. That > changes the scope considerably. > > I'm not 100% clear why we need to change the Java side of this when we > can push a message with the desired info from the VM side? Agreed > > David > >> It seems in some cases the error message is a literal in the VM code >> ( typeArrayKlass.cpp:149). >> That would seem to be a duplication and not really a good idea. >> >> Roger >> >> >> On 4/18/18 10:30 AM, Roger Riggs wrote: >>> Hi, >>> >>> The message can be simpler and more efficiently convey the information. >>> It should be more consistent with existing uses of >>> ArrayIndexOutOfBoundsException as >>> throw by:? Objects.checkIndex(index, length). >>> >>> Which roughly reads as: >>> >>> ?? Index %d out-of-bounds for length %d >>> >>> Regards, Roger >>> >>> On 4/18/18 4:54 AM, David Holmes wrote: >>>> Adding core-libs-dev as you're changing >>>> java.lang.ArrayIndexOutOfBoundsException. >>>> >>>> I appreciate the intent here but I find the messages excessively >>>> verbose. The basic error is: >>>> >>>> index N is outside range [0, length-1] >>>> >>>> David >>>> >>>> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I would like to print a more verbose text on ArrayIndexOutOfBounds >>>>> exception >>>>> that not only mentions the index, but also the length of the array >>>>> accessed. >>>>> See the bug for documentation of the change of the message. >>>>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ >>>>> >>>>> @aarch/arm people: >>>>> I edited the aarch/arm files. Could you please verify this is >>>>> correct? >>>>> I can not build on these platforms. >>>>> >>>>> The code on all the other platforms is tested with all the jtreg >>>>> and jck tests etc. >>>>> >>>>> Best regards, >>>>> ?? Goetz. >>>>> >>>>> >>> >> From philipp.kunz at paratix.ch Thu Apr 19 22:58:05 2018 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Fri, 20 Apr 2018 00:58:05 +0200 Subject: JDK-6202130: java.util.jar.Attributes.writeMain() can't handle multi-byte chars Message-ID: Hi, I tried to fix bug 6202130 about manifest utf support and come up now with a test as suggested in the bug's comments that shows that utf charset actually works before removing the comments from the code. When I wanted to remove the XXX comments about utf it occurred to me that version attributes ("Signature-Version" and "Manifest-Version") would never be broken across lines and should anyway not support the whole utf character set which sounds more like related to bugs 6910466 or 4935610 but it's not a real fit. Therefore, I could not remove one such comment of Attributes#writeMain but I changed it. The first comment in bug 6202130 mentions only two comments but there are three in Attributes. In the attached patch I removed only two of three and changed the remaining third to not mention utf anymore. At the moment, at least until 6443578 is fixed, multi-byte utf characters can be broken across lines. It might be worth a consideration to test that explicitly as well but then I guess there is not much of a point in testing the current behavior that will change with 6443578, hopefully soon. There are in my opinion enough characters broken across lines in the attached test that demonstrate that this still works like it did before. I would have preferred also to remove the calls to deprecated String(byte[], int, int, int) but then figured it relates more to bug 6443578 than 6202130 and now prefer to do that in another separate patch. Bug 6202130 also states that lines are broken by String.length not by byte length. While it looks so at first glance, I could not confirm. The combination of getBytes("UTF8"), String(byte[], int, int, int), and then DataOutputStream.writeBytes(String) in that combination does not drop high-bytes because every byte (whether a whole character or only a part of a multi-byte character) becomes a character in String(...) containing that byte in its low-byte which will be read again from writeBytes(...). Or put in a different way, every utf encoded byte becomes a character and multi-byte utf characters are converted into multiple string characters containing one byte each in their lower bytes. The current solution is not nice, but at least works. With that respect I'd like to suggest to deprecate DataOutputStream.writeBytes(String) because it does something not exactly expected when guessing from its name and that would suit a byte[] parameter better very much like it has been done with String(byte[], int, int, int). Any advice about the procedure to deprecate something? I was surprised that it was not trivial to list all valid utf characters. If someone has a better idea than isValidUtfCharacter in the attached test, let me know. Altogether, I would not consider 6202130 resolved completely, unless maybe all remaining points are copied to 6443578 and maybe another bug about valid values for "Signature-Version" and "Manifest-Version" if at all desired. But still I consider the attached patch an improvement and most of the remainder can then be solved in 6443578 and so far I am looking forward to any kind of feedback. Regards, Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: 6202130.patch Type: text/x-patch Size: 10586 bytes Desc: not available URL: From jai.forums2013 at gmail.com Fri Apr 20 04:37:03 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 20 Apr 2018 10:07:03 +0530 Subject: InetAddress.getByName/getAllByName for empty host string In-Reply-To: <5af3da70-aa47-a07d-e489-419eb5777bd0@oracle.com> References: <5ad894e2-7231-1827-672d-47b307586675@gmail.com> <06e1513a-c511-e28f-9acb-282bee6a0cab@oracle.com> <28d02a89-1697-3736-853c-9f32dea262d5@gmail.com> <5af3da70-aa47-a07d-e489-419eb5777bd0@oracle.com> Message-ID: Hi Chris, On 16/04/18 9:33 PM, Chris Hegarty wrote: > Jaikiran, > > On 13/04/18 16:29, Jaikiran Pai wrote: >> Hi Chris, >> >> Thank you creating that JIRA. >> >> If the fix involves just updating the javadoc, is this something that >> youwould like me to contribute as a patch? I have a signed and >> approved OCA, but I will need a sponsor if I do come up with the patch. > > A patch containing the specification clarification I'm a bit new to the OpenJDK project - does the specification clarification (at least in the context of this issue) mean anything more than updating the javadoc? > and an > update to an existing test to cover said specification > clarification would be helpful. I have started working on a test. > > The change will require a CSR, but I can do that on your > behalf. Thank you, can you please file one (if it can be done before a patch is submitted)? I'm in the process of creating the patch and will send it out to this list soon. -Jaikiran From Alan.Bateman at oracle.com Fri Apr 20 05:54:28 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Apr 2018 06:54:28 +0100 Subject: InetAddress.getByName/getAllByName for empty host string In-Reply-To: References: <5ad894e2-7231-1827-672d-47b307586675@gmail.com> <06e1513a-c511-e28f-9acb-282bee6a0cab@oracle.com> <28d02a89-1697-3736-853c-9f32dea262d5@gmail.com> <5af3da70-aa47-a07d-e489-419eb5777bd0@oracle.com> Message-ID: <89de26af-14fd-1544-235e-641ea32d192a@oracle.com> On 20/04/2018 05:37, Jaikiran Pai wrote: > : > >> >> The change will require a CSR, but I can do that on your >> behalf. > Thank you, can you please file one (if it can be done before a patch > is submitted)? I'm in the process of creating the patch and will send > it out to this list soon. Best to send it to the net-dev list as this is where the java.net API is mostly maintained. -Alan. From jai.forums2013 at gmail.com Fri Apr 20 06:01:50 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 20 Apr 2018 11:31:50 +0530 Subject: InetAddress.getByName/getAllByName for empty host string In-Reply-To: <89de26af-14fd-1544-235e-641ea32d192a@oracle.com> References: <5ad894e2-7231-1827-672d-47b307586675@gmail.com> <06e1513a-c511-e28f-9acb-282bee6a0cab@oracle.com> <28d02a89-1697-3736-853c-9f32dea262d5@gmail.com> <5af3da70-aa47-a07d-e489-419eb5777bd0@oracle.com> <89de26af-14fd-1544-235e-641ea32d192a@oracle.com> Message-ID: <2c2454eb-3c4c-374a-bedb-a48489b3bb4a@gmail.com> On 20/04/18 11:24 AM, Alan Bateman wrote: > On 20/04/2018 05:37, Jaikiran Pai wrote: >> ?I'm in the process of creating the patch and will send it out to >> this list soon. > Best to send it to the net-dev list as this is where the java.net API > is mostly maintained. Will do. Thank you. -Jaikiran From goetz.lindenmaier at sap.com Fri Apr 20 06:51:29 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 20 Apr 2018 06:51:29 +0000 Subject: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <712f0a3d-3ac0-3b6f-afbe-856a95f8ec53@oracle.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <627a9603-b04c-d987-bd1e-6f7371c5d2fb@oracle.com> <294280a2-c687-0d38-c0cf-6b21d44ecfea@oracle.com> <712f0a3d-3ac0-3b6f-afbe-856a95f8ec53@oracle.com> Message-ID: <6d2b9c40aab14d9faea4b8e9011a1377@sap.com> Hi Roger, I removed the constructor im my latest webrev. Best regards, Goetz. > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Roger Riggs > Sent: Donnerstag, 19. April 2018 19:21 > To: David Holmes ; core-libs- > dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(M): 8201593: Print array length in > ArrayIndexOutOfBoundsException. > > Hi David, > > A private constructor that is apparently unused (because it is used > implicitly by code > buried in HotSpot) is going to raise questions. > > Strictly speaking the new constructor is not necessary since the native > code can > compose the full message and use the existing constructor. > I'd recommend that approach. > > Thanks, Roger > > p.s. I'm headed out on vacation today > > > On 4/18/18 6:07 PM, David Holmes wrote: > > Adding back hotspot-runtime-dev? - please reply-all > > > > On 19/04/2018 1:26 AM, Roger Riggs wrote: > >> Hi, > >> > >> Also, the new constructor should be public so it can be used in other > >> places. > > > > That takes this from being a simple change that adds more info to the > > exception message, to an API addition that requires a CSR etc. That > > changes the scope considerably. > > > > I'm not 100% clear why we need to change the Java side of this when we > > can push a message with the desired info from the VM side? > Agreed > > > > David > > > >> It seems in some cases the error message is a literal in the VM code > >> ( typeArrayKlass.cpp:149). > >> That would seem to be a duplication and not really a good idea. > >> > >> Roger > >> > >> > >> On 4/18/18 10:30 AM, Roger Riggs wrote: > >>> Hi, > >>> > >>> The message can be simpler and more efficiently convey the > information. > >>> It should be more consistent with existing uses of > >>> ArrayIndexOutOfBoundsException as > >>> throw by:? Objects.checkIndex(index, length). > >>> > >>> Which roughly reads as: > >>> > >>> ?? Index %d out-of-bounds for length %d > >>> > >>> Regards, Roger > >>> > >>> On 4/18/18 4:54 AM, David Holmes wrote: > >>>> Adding core-libs-dev as you're changing > >>>> java.lang.ArrayIndexOutOfBoundsException. > >>>> > >>>> I appreciate the intent here but I find the messages excessively > >>>> verbose. The basic error is: > >>>> > >>>> index N is outside range [0, length-1] > >>>> > >>>> David > >>>> > >>>> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: > >>>>> Hi, > >>>>> > >>>>> I would like to print a more verbose text on ArrayIndexOutOfBounds > >>>>> exception > >>>>> that not only mentions the index, but also the length of the array > >>>>> accessed. > >>>>> See the bug for documentation of the change of the message. > >>>>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ > >>>>> > >>>>> @aarch/arm people: > >>>>> I edited the aarch/arm files. Could you please verify this is > >>>>> correct? > >>>>> I can not build on these platforms. > >>>>> > >>>>> The code on all the other platforms is tested with all the jtreg > >>>>> and jck tests etc. > >>>>> > >>>>> Best regards, > >>>>> ?? Goetz. > >>>>> > >>>>> > >>> > >> From huaming.li at oracle.com Fri Apr 20 07:21:31 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 20 Apr 2018 15:21:31 +0800 Subject: RFR of JDK-8201469,test under java/rmi should be restricted to not run concurrently In-Reply-To: <36dd9cd1-d748-b67e-3bff-edee4cab5edd@oracle.com> References: <36dd9cd1-d748-b67e-3bff-edee4cab5edd@oracle.com> Message-ID: <608c4a45-1dba-c5f4-92ac-8ed8be66468f@oracle.com> Is someone available to review the following patch? Thank you -Hamlin On 19/04/2018 4:17 PM, Hamlin Li wrote: > would you please review the following patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8201469 > > http://cr.openjdk.java.net/~mli/8201469/webrev.00/ > > ( For othervm.dirs property, I just reformat it. ) > > > In my test result, with jtreg option "-concurrency:4", after apply the > patch, tier3 tests on different platforms will be slower about 1.5~2.0 > times than before. > I think stability of tests are more important than executing time, how > do you think about it? > > Thank you > -Hamlin From david.holmes at oracle.com Fri Apr 20 07:25:19 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 20 Apr 2018 17:25:19 +1000 Subject: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <5be0f86df2834aa8a881206ba285011e@sap.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <5be0f86df2834aa8a881206ba285011e@sap.com> Message-ID: <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> Hi Goetz, This is not a file by file review ... On 19/04/2018 10:24 PM, Lindenmaier, Goetz wrote: > Hi, > > New webrev: > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ > > I admit my wording is not optimal. src/hotspot/share/oops/typeArrayKlass.cpp Sorry but this is still far too verbose for my tastes. The type of the array is not relevant. For the array copy its okay to indicate src or dst array. But the message should be clear and succinct not prose-like. Plus you have a lot of repetition in the ss.print statements when only one thing is changing. src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp I'm not seeing why the throw_index_out_of_bounds_exception should be tied to whether or not you have an array reference. Certainly I hate seeing the array ref being used as an implicit bool! > It's because I extracted this change from a bigger one. Our message reads like this: > Object [] oa1 = new Object[10] > oa1[12] > "ArrayIndexOutOfBoundsException while trying to load from index 12 of an object array with length 10, loaded from local variable 'oa1'" > ... which seems not optimal, either. But it mentions the type (object), the operation (load, store etc ...) and the variable name. > Naming the array is quite detailed if it is in a complex expression (like returned from a call). > I'll contribute more of this if appreciated, this is a first step. I've never thought this complexity was warranted. We've had a few RFE's of this nature over the years and they have been closed (not necessarily by me I should point out!). > Printing "index N is outside range [0, length-1]" is problematic > for length '0'. I followed the proposal by Roger: > "Index -1 out-of-bounds for length 10." You can easily special-case length 0. But Roger's proposal for consistency with existing messages make sense - not withstanding Andrew's dislike for the hyphens. > I removed the change to ArrayIndexOutOfBoundsException.java. That's good. > I extended the test to cover the exception thrown in arraycopy better The test seems somewhat excessive, and I now see it is because of the more elaborate error messages you have at SAP. But with only the index and the array length of interest here the test can be considerably smaller. The creation tests for ArrayIndexOutOfBoundsException don't seem relevant in this context either. This looks more TCK like. David ----- > and added the elementary type to the message text. This probably > needs improvement in the text, too. There are (currently) these cases: > > bject[] oa1 = new Object[10]; > Object[] oa2 = new Object[5]; > System.arraycopy(oa1, -17, oa2, 0, 5); > "while trying to copy from index -17 of an object array with length 10"); > System.arraycopy(oa1, 2, oa2, -18, 5); > "while trying to copy to index -18 of an object array with length 5"); > System.arraycopy(oa1, 2, oa2, 0, -19); > "while trying to copy a negative range -19 from an object array with length 10 to an object array with length 5"); > System.arraycopy(oa1, 8, oa2, 0, 5); > "while trying to copy from index 13 of an object array with length 10"); > System.arraycopy(oa1, 1, oa2, 0, 7); > "while trying to copy to index 7 of an object array with length 5"); > double[] ta1 = new double[10]; > double[] ta2 = new double[5]; > System.arraycopy(ta1, -17, ta2, 0, 5); > "while trying to copy from index -17 of a doubl array with length 10"); > System.arraycopy(ta1, 2, ta2, -18, 5); > "while trying to copy to index -18 of a double array with length 5"); > System.arraycopy(ta1, 2, ta2, 0, -19); > "while trying to copy a negative range -19 from a double array with length 10 to a double array with length 5"); > System.arraycopy(ta1, 8, ta2, 0, 5); > "while trying to copy from index 13 of a double array with length 10"); > System.arraycopy(ta1, 1, ta2, 0, 7); > "while trying to copy to index 7 of a double array with length 5"); > > Maybe it should say: > Arraycopy source index -1 out-of-bounds for double array of length 10. > Arraycopy target index 10 out-of-bounds for object array of length 10. > Negative range -19 when copying from an object array of length 10 to an object array of length 5. > > Best regards, > Goetz. > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 18. April 2018 10:55 >> To: Lindenmaier, Goetz ; hotspot-runtime- >> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; aarch64- >> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core-libs- >> dev Libs >> Subject: Re: RFR(M): 8201593: Print array length in >> ArrayIndexOutOfBoundsException. >> >> Adding core-libs-dev as you're changing >> java.lang.ArrayIndexOutOfBoundsException. >> >> I appreciate the intent here but I find the messages excessively >> verbose. The basic error is: >> >> index N is outside range [0, length-1] >> >> David >> >> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I would like to print a more verbose text on ArrayIndexOutOfBounds >> exception >>> that not only mentions the index, but also the length of the array accessed. >>> See the bug for documentation of the change of the message. >>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ >>> >>> @aarch/arm people: >>> I edited the aarch/arm files. Could you please verify this is correct? >>> I can not build on these platforms. >>> >>> The code on all the other platforms is tested with all the jtreg and jck tests >> etc. >>> >>> Best regards, >>> Goetz. >>> >>> From goetz.lindenmaier at sap.com Fri Apr 20 10:03:21 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 20 Apr 2018 10:03:21 +0000 Subject: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <5be0f86df2834aa8a881206ba285011e@sap.com> <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> Message-ID: <1a27932d85304155b68beb81014298ad@sap.com> Hi David, What about this: java.lang.ArrayIndexOutOfBoundsException: Arraycopy source index -1 out-of-bounds for double[10]. java.lang.ArrayIndexOutOfBoundsException: Arraycopy target index 10 out-of-bounds for object array[10]. java.lang.ArrayIndexOutOfBoundsException: Negative length -19 in arraycopy from int[3] to int[9]. I'll reply to the other points in a comprehensive mail when I know how to put the message. Thanks, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Freitag, 20. April 2018 09:25 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; aarch64- > port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core-libs- > dev Libs > Subject: Re: RFR(M): 8201593: Print array length in > ArrayIndexOutOfBoundsException. > > Hi Goetz, > > This is not a file by file review ... > > On 19/04/2018 10:24 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > New webrev: > > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ > > > > I admit my wording is not optimal. > > src/hotspot/share/oops/typeArrayKlass.cpp > > Sorry but this is still far too verbose for my tastes. The type of the > array is not relevant. For the array copy its okay to indicate src or > dst array. But the message should be clear and succinct not prose-like. > Plus you have a lot of repetition in the ss.print statements when only > one thing is changing. > > src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp > > I'm not seeing why the throw_index_out_of_bounds_exception should be > tied to whether or not you have an array reference. Certainly I hate > seeing the array ref being used as an implicit bool! > > > It's because I extracted this change from a bigger one. Our message reads > like this: > > Object [] oa1 = new Object[10] > > oa1[12] > > "ArrayIndexOutOfBoundsException while trying to load from index 12 of an > object array with length 10, loaded from local variable 'oa1'" > > ... which seems not optimal, either. But it mentions the type (object), the > operation (load, store etc ...) and the variable name. > > Naming the array is quite detailed if it is in a complex expression (like > returned from a call). > > I'll contribute more of this if appreciated, this is a first step. > > I've never thought this complexity was warranted. We've had a few RFE's > of this nature over the years and they have been closed (not necessarily > by me I should point out!). > > > Printing "index N is outside range [0, length-1]" is problematic > > for length '0'. I followed the proposal by Roger: > > "Index -1 out-of-bounds for length 10." > > You can easily special-case length 0. But Roger's proposal for > consistency with existing messages make sense - not withstanding > Andrew's dislike for the hyphens. > > > I removed the change to ArrayIndexOutOfBoundsException.java. > > That's good. > > > I extended the test to cover the exception thrown in arraycopy better > > The test seems somewhat excessive, and I now see it is because of the > more elaborate error messages you have at SAP. But with only the index > and the array length of interest here the test can be considerably smaller. > > The creation tests for ArrayIndexOutOfBoundsException don't seem > relevant in this context either. This looks more TCK like. > > David > ----- > > > and added the elementary type to the message text. This probably > > needs improvement in the text, too. There are (currently) these cases: > > > > bject[] oa1 = new Object[10]; > > Object[] oa2 = new Object[5]; > > System.arraycopy(oa1, -17, oa2, 0, 5); > > "while trying to copy from index -17 of an object array with length 10"); > > System.arraycopy(oa1, 2, oa2, -18, 5); > > "while trying to copy to index -18 of an object array with length 5"); > > System.arraycopy(oa1, 2, oa2, 0, -19); > > "while trying to copy a negative range -19 from an object array with length > 10 to an object array with length 5"); > > System.arraycopy(oa1, 8, oa2, 0, 5); > > "while trying to copy from index 13 of an object array with length 10"); > > System.arraycopy(oa1, 1, oa2, 0, 7); > > "while trying to copy to index 7 of an object array with length 5"); > > double[] ta1 = new double[10]; > > double[] ta2 = new double[5]; > > System.arraycopy(ta1, -17, ta2, 0, 5); > > "while trying to copy from index -17 of a doubl array with length 10"); > > System.arraycopy(ta1, 2, ta2, -18, 5); > > "while trying to copy to index -18 of a double array with length 5"); > > System.arraycopy(ta1, 2, ta2, 0, -19); > > "while trying to copy a negative range -19 from a double array with length > 10 to a double array with length 5"); > > System.arraycopy(ta1, 8, ta2, 0, 5); > > "while trying to copy from index 13 of a double array with length 10"); > > System.arraycopy(ta1, 1, ta2, 0, 7); > > "while trying to copy to index 7 of a double array with length 5"); > > > > Maybe it should say: > > Arraycopy source index -1 out-of-bounds for double array of length 10. > > Arraycopy target index 10 out-of-bounds for object array of length 10. > > Negative range -19 when copying from an object array of length 10 to an > object array of length 5. > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Mittwoch, 18. April 2018 10:55 > >> To: Lindenmaier, Goetz ; hotspot-runtime- > >> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; > aarch64- > >> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core- > libs- > >> dev Libs > >> Subject: Re: RFR(M): 8201593: Print array length in > >> ArrayIndexOutOfBoundsException. > >> > >> Adding core-libs-dev as you're changing > >> java.lang.ArrayIndexOutOfBoundsException. > >> > >> I appreciate the intent here but I find the messages excessively > >> verbose. The basic error is: > >> > >> index N is outside range [0, length-1] > >> > >> David > >> > >> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> I would like to print a more verbose text on ArrayIndexOutOfBounds > >> exception > >>> that not only mentions the index, but also the length of the array > accessed. > >>> See the bug for documentation of the change of the message. > >>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ > >>> > >>> @aarch/arm people: > >>> I edited the aarch/arm files. Could you please verify this is correct? > >>> I can not build on these platforms. > >>> > >>> The code on all the other platforms is tested with all the jtreg and jck > tests > >> etc. > >>> > >>> Best regards, > >>> Goetz. > >>> > >>> From raffaello.giulietti at gmail.com Fri Apr 20 13:32:30 2018 From: raffaello.giulietti at gmail.com (raffaello.giulietti at gmail.com) Date: Fri, 20 Apr 2018 15:32:30 +0200 Subject: Upload of drop-in replacement for Double:::toString(double) Message-ID: Hi Brian, as agreed in [1], here is the first batch of my code. It includes everything needed to replace Double::toString(double), if so wished. It is accompanied by some JUnit tests in math.DoubleToDecimalTest and by straightforward benchmarks in math.D2DBenchmark The code still has notices attributing the copyright to me under the GPL2 + Classpath exception license because I just copied the code verbatim from my GitHub repo. What is currently *not* included is the drop-in replacement for Float.toString(float). Before I polish this part, which should take a couple of hours, I'll wait for comments about the code delivered so far. Source files are preceded by a line of the form: -------- They are * LICENSE * module-info.java * math.Natural.java * math.Powers.java * math.MathUtils.java * math.DoubleToDecimal.java * math.DecimalChecker.java * math.DoubleToDecimalTest.java * math.D2DBenchmark.java Let me know if the format I chose, namely dumb copy&paste, is appropriate. Greetings Raffaello [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052681.html -------- LICENSE GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Lesser General Public License instead.) You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations. Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. The precise terms and conditions for copying, distribution and modification follow. GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. 7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. 10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Programs If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program 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 for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. Also add information on how to contact you by electronic and paper mail. If the program is interactive, make it output a short notice like this when it starts in an interactive mode: Gnomovision version 69, Copyright (C) year name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker. , 1 April 1989 Ty Coon, President of Vice This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. "CLASSPATH" EXCEPTION TO THE GPL Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination. As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. -------- module-info.java /* * Copyright (c) 2018, Raffaello Giulietti. 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. * This particular file is subject to the "Classpath" exception as provided * 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. */ module todec { exports math; } -------- math.Natural.java /* * Copyright (c) 2018, Raffaello Giulietti. 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. * This particular file is subject to the "Classpath" exception as provided * 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. */ package math; import java.math.BigInteger; import static java.lang.Math.max; /** * A minimal, limited implementation of non-negative large integers. * *

      All operations implemented here are needed in other parts of the package, * while many are missing entirely because they are not needed. */ final class Natural { private static final long I_SZ = Integer.SIZE; private static final long I_MASK = (1L << I_SZ) - 1; private static final int I_MSB = -1 << I_SZ - 1; private static final long L_MSB = -1L << Long.SIZE - 1; /* A large natural is represented as a sequence of len B-ary digits, that is, in base B = 2^Integer.SIZE = 2^32 Its value is d[0] + d[1]*B + d[2]*B^2 + ... + d[len-1]*B^(len-1) where each B-ary digit d[i] is interpreted as unsigned int. As usual, an empty sum has value 0, so if len = 0 then the value is 0. The following invariants hold: 0 <= len <= d.length either len = 0 or d[len-1] != 0 */ private final int[] d; private final int len; private Natural(int[] d) { int i = d.length; while (--i >= 0 && d[i] == 0); // empty body intended this.len = i + 1; this.d = d; } /** * Returns a {@link Natural} with the same value as {@code v}, * which is interpreted as an unsigned {@code long}. */ static Natural valueOf(long v) { return new Natural(new int[]{(int) v, (int) (v >>> 32)}); } /** * Returns a {@link Natural} with the value * {@code v} · 2{@code n}. * The value {@code v} is interpreted as an unsigned {@code long} and * {@code n} must be non-negative. */ static Natural valueOfShiftLeft(long v, int n) { // I_SZ = 2^5 int q = n >> 5; int r = n & 0x1f; // length is q plus additional 2 for v and 1 for possible overlapping int[] rd = new int[q + 3]; rd[q] = (int) v << r; rd[q + 1] = (int) (v >>> I_SZ - r); // A safe shift by 64 - r, even when r = 0 rd[q + 2] = (int) (v >>> I_SZ >>> I_SZ - r); return new Natural(rd); } /** * Returns -1, 0 or 1, depending on whether {@code this} is * <, = or > {@code y}, respectively. */ int compareTo(Natural y) { if (len < y.len) { return -1; } if (len > y.len) { return 1; } int i = len; while (--i >= 0 && d[i] == y.d[i]); // empty body intended if (i < 0) { return 0; } // Perform an unsigned int comparision if ((d[i] ^ I_MSB) < (y.d[i] ^ I_MSB)) { return -1; } return 1; } /** * Returns -1, 0 or 1, depending on whether {@code this} is closer to * {@code x}, equally close to both {@code x} and {@code y} or closer to * {@code y}, respectively. */ int closerTo(Natural x, Natural y) { /* computes (2 * this - x - y).compareTo(0) without allocating objects for the intermediate results. */ int cmp = 0; long c = 0; int maxLen = max(max(x.len, y.len), len); for (int i = 0; i < maxLen; ++i) { long td = i < len ? d[i] & I_MASK : 0; long xd = i < x.len ? x.d[i] & I_MASK : 0; long yd = i < y.len ? y.d[i] & I_MASK : 0; long s = (td << 1) - xd - yd + c; cmp |= (int) s; c = s >> I_SZ; } if (c < 0) { return -1; } if (cmp != 0) { return 1; } return 0; } /** * Returns {@code this} * {@code y}, where {@code y} is taken as an * unsigned {@code long}. */ Natural multiply(long y) { // Straightforward paper-and-pencil method for multiplication. int[] rd = new int[len + 2]; long y0 = y & I_MASK; long y1 = y >>> I_SZ; long c = 0; long r1 = 0; long q0 = 0; long q1 = 0; long s; int i = 0; for (; i < len; ++i) { long td = d[i] & I_MASK; long p0 = y0 * td; s = (r1 >>> I_SZ) + (q0 >>> I_SZ) + (q1 & I_MASK) + (p0 & I_MASK) + c; rd[i] = (int) s; c = s >>> I_SZ; r1 = q1; q0 = p0; q1 = y1 * td; } s = (r1 >>> I_SZ) + (q0 >>> I_SZ) + (q1 & I_MASK) + c; rd[i] = (int) s; c = s >>> I_SZ; rd[i + 1] = (int) (c + (q1 >>> I_SZ)); return new Natural(rd); } /** * Returns {@code this} - {@code y}, where it is assumed that * {@code this} ≥ {@code y}. */ Natural subtract(Natural y) { int[] rd = new int[len]; long c = 0; int i = 0; for (; i < y.len; ++i) { long s = (d[i] & I_MASK) - (y.d[i] & I_MASK) + c; rd[i] = (int) s; c = s >> I_SZ; } for (; i < len; ++i) { long s = (d[i] & I_MASK) + c; rd[i] = (int) s; c = s >> I_SZ; } return new Natural(rd); } /** * Returns ⎣{@code this} · 2-{@code n}⎦, * where it is assumed that {@code n} ≥ 0 and that the result * is an unsigned {@code long}. */ long shiftRight(int n) { int q = n >> 5; int r = n & 0x1f; long d0 = d[q] & I_MASK; long d1 = d[q + 1] & I_MASK; long d2 = q + 2 < len ? d[q + 2] & I_MASK : 0; // The double shift is safe even when r = 0 return d0 >>> r | d1 << I_SZ - r | d2 << I_SZ << I_SZ - r; } /** * Returns {@code this} + {@code y} · 2{@code n}, * where it is assumed that {@code n} ≥ 0. */ Natural addShiftLeft(Natural y, int n) { int maxLen = max(len, y.len); int[] rd = new int[maxLen + 1]; long c = 0; long yd = 0; int i = 0; for (; i < maxLen; ++i) { long t0 = i < len ? d[i] & I_MASK : 0; long y0 = i < y.len ? y.d[i] & I_MASK : 0; yd = yd >>> I_SZ | y0 << n; long s = t0 + (yd & I_MASK) + c; rd[i] = (int) s; c = s >>> I_SZ; } rd[i] = (int) ((yd >>> I_SZ) + c); return new Natural(rd); } private BigInteger toBigInteger() { // additional 1 for the "sign" most significant byte at index 0 byte[] b = new byte[1 + (len << 2)]; for (int i = 1; i <= len; ++i) { int d0 = d[len - i]; b[(i << 2) - 3] = (byte) (d0 >>> 24); b[(i << 2) - 2] = (byte) (d0 >>> 16); b[(i << 2) - 1] = (byte) (d0 >>> 8); b[i << 2] = (byte) d0; } return new BigInteger(b); } /* Here for debugging purposes only. There's otherwise no need for it. */ @Override public String toString() { // Quick-and-dirty solution to avoid implementing a special division. return toBigInteger().toString(); } /* Assumes 0 <= n */ private Natural shiftLeft(int n) { int q = n >> 5; int r = n & 0x1f; // Allocates one int more than necessary to simplify the division if (r == 0) { int[] rd = new int[len + q + 1]; for (int i = 0; i < len; ++i) { rd[q + i] = d[i]; } return new Natural(rd); } int[] rd = new int[len + q + 2]; rd[q] = d[0] << r; int i = 1; for (; i < len; ++i) { // safe shift, as 0 < r < I_SZ rd[q + i] = d[i] << r | d[i - 1] >>> I_SZ - r; } rd[q + i] = d[i - 1] >>> I_SZ - r; return new Natural(rd); } /** * Returns ⎣{@code this} / {@code y}⎦. *

      Assumes that: *

        *
      • {@code this} ≥ 232. *
      • {@code y} > 0. *
      • The result is an unsigned {@code long} ≥ 232. *
      */ long divide(Natural y) { int r = Integer.numberOfLeadingZeros(y.d[y.len - 1]) - 1 & 0x1f; // Ensure that v.len >= 2 and that vp meets the inequalities below if (y.len == 1) { r += I_SZ; } Natural u = shiftLeft(r); Natural v = y.shiftLeft(r); // by construction, 2^30 <= vp < 2^31: no need for masking long vp = v.d[v.len - 1]; long v_n2 = v.d[v.len - 2] & I_MASK; long q = 0; for (int k = 1; k >= 0; --k) { int n = v.len + k; // this assumes that n <= u.d.length long up = (long) u.d[n] << I_SZ | u.d[n - 1] & I_MASK; long qb = up / vp; if (qb > I_MASK) qb = I_MASK; long rb = up - qb * vp; while (rb <= I_MASK && (qb * v_n2 ^ L_MSB) > ((rb << I_SZ | u.d[n - 2] & I_MASK) ^ L_MSB)) { qb -= 1; rb += vp; } long s = 0; int i = 0; for (; i < v.len; ++i) { long p = qb * (v.d[i] & I_MASK) + s; long t = (u.d[i + k] & I_MASK) - (p & I_MASK); u.d[i + k] = (int) t; s = (p >>> I_SZ) - (t >> I_SZ); } long t = (u.d[i + k] & I_MASK) - (s & I_MASK); u.d[i + k] = (int) t; s = -(t >> I_SZ); if (s > 0) { qb -= 1; s = 0; for (i = 0; i < v.len; ++i) { t = (u.d[i + k] & I_MASK) + (v.d[i] & I_MASK) + s; u.d[i + k] = (int) t; s = t >>> I_SZ; } } q = q << I_SZ | qb; } return q; } } -------- math.Powers.java /* * Copyright (c) 2018, Raffaello Giulietti. 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. * This particular file is subject to the "Classpath" exception as provided * 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. */ package math; import static math.Natural.valueOf; /** * Package-privately exposes *
        *
      • integer powers of 5 as unsigned {@code long}s, up to the exponent * {@link #MAX_POW_5_EXP} *
      • integer powers of 10 as unsigned {@code long}s, up to the exponent * {@link #MAX_POW_10_EXP} *
      • integer powers of 5 as {@link Natural}s, up to the exponent * {@link #MAX_POW_5_N_EXP} *
      * *

      * Since this is a package-private class, no checks are made to ensure * that usages are correct. */ final class Powers { /** * The integer e such that * 5e ≤ M < 5e+1, * where M is the largest unsigned {@code long}, namely * M = 2{@link Long#SIZE} - 1. */ static final int MAX_POW_5_EXP = 27; /* The greatest power of 5 fitting in an unsigned {@code long}, namely 5^MAX_POW_5_EXP */ private static final long MAX_POW_5 = 7_450_580_596_923_828_125L; /** * The integer e such that * 10e ≤ M < 10e+1, * where M is the largest unsigned {@code long}, namely * M = 2{@link Long#SIZE} - 1. */ static final int MAX_POW_10_EXP = 19; /** * The greatest exponent for {@link #pow5(int)}. */ /* MAX_POW_5_N_EXP = Double.H - Double.E_MIN_VALUE */ static final int MAX_POW_5_N_EXP = 340; /** * Powers of 5, as unsigned {@code long}s, for exponents between * 0 and {@link #MAX_POW_5_EXP}. */ static final long[] pow5; /** * Powers of 10, as unsigned {@code long}s, for exponents between * 0 and {@link #MAX_POW_10_EXP}. */ static final long[] pow10; /* pow5n is populated lazily. More precisely, values for the exponents between 0 and MAX_POW_5_EXP are initialized upon class loading. Other values are computed upon request (see pow5()). Invariant: e0max is a multiple of MAX_POW_5_EXP and all values for exponents that are multiples of MAX_POW_5_EXP, up to e0max, are already present in the array. */ private static final Natural[] pow5n; private static int e0max = MAX_POW_5_EXP; static { /* Fully initializes the pow5 and pow10 array and partial initializes pow5n, which will be populated lazily, as need arises. */ pow5n = new Natural[MAX_POW_5_N_EXP + 1]; pow5 = new long[MAX_POW_5_EXP + 1]; pow5[0] = 1; for (int k = 1; k < pow5.length; ++k) { pow5[k] = 5 * pow5[k - 1]; pow5n[k] = valueOf(pow5[k]); } pow10 = new long[MAX_POW_10_EXP + 1]; pow10[0] = 1; for (int k = 1; k < pow10.length; ++k) { pow10[k] = 10 * pow10[k - 1]; } } private Powers() { } /** * Powers of 5, for exponents between 0 and {@link #MAX_POW_5_N_EXP}. */ static synchronized Natural pow5(int e) { if (pow5n[e] != null) { return pow5n[e]; } int e0 = e / MAX_POW_5_EXP * MAX_POW_5_EXP; /* Guard for the loop: mathematically not necessary but measurably enhances performance when there's no need to enter the loop. */ if (e0max < e0) { for (; e0max < e0; e0max += MAX_POW_5_EXP) { pow5n[e0max + MAX_POW_5_EXP] = pow5n[e0max].multiply(MAX_POW_5); } } if (e0 < e) { pow5n[e] = pow5n[e0].multiply(pow5[e - e0]); } return pow5n[e]; } } -------- math.MathUtils.java /* * Copyright (c) 2018, Raffaello Giulietti. 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. * This particular file is subject to the "Classpath" exception as provided * 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. */ package math; import static math.DoubleToDecimal.Double.c; import static math.DoubleToDecimal.Double.q; final class MathUtils { private static final int I = Integer.SIZE; private static final long MASK_I = (1L << I) - 1; /* The doubles below are expressed in hex notation to avoid possible anomalies during decimal tokenization. Hex tokenization is assumed to be completely reliable, as it is simpler from a mathematical perspective. */ // The double closest to log10(2), 0.3010299956639812 in decimal private static final double LOG_10_2 = 0x1.34413509F79FFp-2; // The double closest to log2(10), 3.321928094887362 in decimal private static final double LOG_2_10 = 0x1.A934F0979A371p1; /** * The minimum exponent for {@link #floorPow10d(int)} * and {@link #pow10r(int)} */ static final int MIN_EXP = -324; /** * The maximum exponent for {@link #floorPow10d(int)} * and {@link #pow10r(int)} */ static final int MAX_EXP = 324; private MathUtils() { } /* This implementation is simple but is restricted to its usage here, when the assumptions below hold. It assumes v = 0 (thus c = 0) or 0 <= -q < Long.SIZE Also note that for v < 0 floor(v) = -ceil(-v) */ private static int floor(double v) { if (v >= 0) { long bits = java.lang.Double.doubleToRawLongBits(v); return (int) (c(bits) >>> -q(bits)); } long bits = java.lang.Double.doubleToRawLongBits(-v); int q = q(bits); return -(int) (c(bits) + (1L << -q) - 1 >>> -q); } /** * Returns the integer k such that 10k-1 ≤ * 2{@code e} < 10k. *

      * The result is correct when -198'096'464 ≤ {@code e} ≤ * 146'964'307. * Otherwise the result may or may not be correct. */ static int ord10pow2(int e) { return floor(e * LOG_10_2) + 1; } /** * Returns the integer k such that 2k-1 ≤ * 10{@code e} < 2k. *

      * The result is correct when -44'240'664 ≤ {@code e} ≤ * 59'632'977. * Otherwise the result may or may not be correct. */ static int ord2pow10(int e) { return floor(e * LOG_2_10) + 1; } /** * Returns the high {@link Long#SIZE} bits of the full product * {@code x}{@code y}, namely * ⎣{@code x}{@code y} · 2-{@link Long#SIZE}⎦. *

      * Both {@code x} and {@code y} as well as the result are interpreted as * unsigned {@code long}s. */ static long multiplyHighUnsigned(long x, long y) { /* Unfortunately, the plain version of Karatsuba cannot be applied here: the mixed product would overflow with unrecoverable loss of bits. Thus, the plain paper-and-pencil scheme requiring 4 long multiplications is used. This could be a good candidate a for JIT compiler intrinsic. */ final long x1 = x >>> I; final long x0 = x & MASK_I; final long y1 = y >>> I; final long y0 = y & MASK_I; final long x1y0 = x1 * y0; final long x0y1 = x0 * y1; return x1 * y1 + (x0y1 >>> I) + (x1y0 >>> I) + ((x0y1 & MASK_I) + (x1y0 & MASK_I) + (x0 * y0 >>> I) >>> I); } /** * Returns one of two components of an approximation of a power of 10. * *

      More precisely, let * 10{@code e} = d · 2r * for some integer r and real d with * 2{@link Long#SIZE}-1 ≤ d < * 2{@link Long#SIZE}. * *

      This method returns ⎣d⎦ as an * unsigned {@code long}, while {@link #pow10r(int)} returns r. * * @param e The exponent of the power of 10, bounded by * {@link #MIN_EXP} ≤ {@code e} ≤ {@link #MAX_EXP} * @see #pow10r(int) */ static long floorPow10d(int e) { return floorPow10d[e - MIN_EXP]; } /** * Returns one of two components of an approximation of a power of 10. * *

      This method returns r from the representation described in * {@link #floorPow10d(int)}. * * @param e The exponent of the power of 10, bounded by * {@link #MIN_EXP} ≤ {@code e} ≤ {@link #MAX_EXP} * @see #floorPow10d(int) */ static int pow10r(int e) { return ord2pow10(e) - Long.SIZE; } /* The array has been computed and checked using full precision. The values are prefixed with a comment indicating the exponent. Contrary to common coding conventions, its definition is located here, at the end of the file, because the length of its source would be distracting for reading the rest. */ private static final long[] floorPow10d = { /* -324 */ 0xCF42_894A_5DCE_35EAL, /* -323 */ 0x8189_95CE_7AA0_E1B2L, /* -322 */ 0xA1EB_FB42_1949_1A1FL, /* -321 */ 0xCA66_FA12_9F9B_60A6L, /* -320 */ 0xFD00_B897_4782_38D0L, /* -319 */ 0x9E20_735E_8CB1_6382L, /* -318 */ 0xC5A8_9036_2FDD_BC62L, /* -317 */ 0xF712_B443_BBD5_2B7BL, /* -316 */ 0x9A6B_B0AA_5565_3B2DL, /* -315 */ 0xC106_9CD4_EABE_89F8L, /* -314 */ 0xF148_440A_256E_2C76L, /* -313 */ 0x96CD_2A86_5764_DBCAL, /* -312 */ 0xBC80_7527_ED3E_12BCL, /* -311 */ 0xEBA0_9271_E88D_976BL, /* -310 */ 0x9344_5B87_3158_7EA3L, /* -309 */ 0xB815_7268_FDAE_9E4CL, /* -308 */ 0xE61A_CF03_3D1A_45DFL, /* -307 */ 0x8FD0_C162_0630_6BABL, /* -306 */ 0xB3C4_F1BA_87BC_8696L, /* -305 */ 0xE0B6_2E29_29AB_A83CL, /* -304 */ 0x8C71_DCD9_BA0B_4925L, /* -303 */ 0xAF8E_5410_288E_1B6FL, /* -302 */ 0xDB71_E914_32B1_A24AL, /* -301 */ 0x8927_31AC_9FAF_056EL, /* -300 */ 0xAB70_FE17_C79A_C6CAL, /* -299 */ 0xD64D_3D9D_B981_787DL, /* -298 */ 0x85F0_4682_93F0_EB4EL, /* -297 */ 0xA76C_5823_38ED_2621L, /* -296 */ 0xD147_6E2C_0728_6FAAL, /* -295 */ 0x82CC_A4DB_8479_45CAL, /* -294 */ 0xA37F_CE12_6597_973CL, /* -293 */ 0xCC5F_C196_FEFD_7D0CL, /* -292 */ 0xFF77_B1FC_BEBC_DC4FL, /* -291 */ 0x9FAA_CF3D_F736_09B1L, /* -290 */ 0xC795_830D_7503_8C1DL, /* -289 */ 0xF97A_E3D0_D244_6F25L, /* -288 */ 0x9BEC_CE62_836A_C577L, /* -287 */ 0xC2E8_01FB_2445_76D5L, /* -286 */ 0xF3A2_0279_ED56_D48AL, /* -285 */ 0x9845_418C_3456_44D6L, /* -284 */ 0xBE56_91EF_416B_D60CL, /* -283 */ 0xEDEC_366B_11C6_CB8FL, /* -282 */ 0x94B3_A202_EB1C_3F39L, /* -281 */ 0xB9E0_8A83_A5E3_4F07L, /* -280 */ 0xE858_AD24_8F5C_22C9L, /* -279 */ 0x9137_6C36_D999_95BEL, /* -278 */ 0xB585_4744_8FFF_FB2DL, /* -277 */ 0xE2E6_9915_B3FF_F9F9L, /* -276 */ 0x8DD0_1FAD_907F_FC3BL, /* -275 */ 0xB144_2798_F49F_FB4AL, /* -274 */ 0xDD95_317F_31C7_FA1DL, /* -273 */ 0x8A7D_3EEF_7F1C_FC52L, /* -272 */ 0xAD1C_8EAB_5EE4_3B66L, /* -271 */ 0xD863_B256_369D_4A40L, /* -270 */ 0x873E_4F75_E222_4E68L, /* -269 */ 0xA90D_E353_5AAA_E202L, /* -268 */ 0xD351_5C28_3155_9A83L, /* -267 */ 0x8412_D999_1ED5_8091L, /* -266 */ 0xA517_8FFF_668A_E0B6L, /* -265 */ 0xCE5D_73FF_402D_98E3L, /* -264 */ 0x80FA_687F_881C_7F8EL, /* -263 */ 0xA139_029F_6A23_9F72L, /* -262 */ 0xC987_4347_44AC_874EL, /* -261 */ 0xFBE9_1419_15D7_A922L, /* -260 */ 0x9D71_AC8F_ADA6_C9B5L, /* -259 */ 0xC4CE_17B3_9910_7C22L, /* -258 */ 0xF601_9DA0_7F54_9B2BL, /* -257 */ 0x99C1_0284_4F94_E0FBL, /* -256 */ 0xC031_4325_637A_1939L, /* -255 */ 0xF03D_93EE_BC58_9F88L, /* -254 */ 0x9626_7C75_35B7_63B5L, /* -253 */ 0xBBB0_1B92_8325_3CA2L, /* -252 */ 0xEA9C_2277_23EE_8BCBL, /* -251 */ 0x92A1_958A_7675_175FL, /* -250 */ 0xB749_FAED_1412_5D36L, /* -249 */ 0xE51C_79A8_5916_F484L, /* -248 */ 0x8F31_CC09_37AE_58D2L, /* -247 */ 0xB2FE_3F0B_8599_EF07L, /* -246 */ 0xDFBD_CECE_6700_6AC9L, /* -245 */ 0x8BD6_A141_0060_42BDL, /* -244 */ 0xAECC_4991_4078_536DL, /* -243 */ 0xDA7F_5BF5_9096_6848L, /* -242 */ 0x888F_9979_7A5E_012DL, /* -241 */ 0xAAB3_7FD7_D8F5_8178L, /* -240 */ 0xD560_5FCD_CF32_E1D6L, /* -239 */ 0x855C_3BE0_A17F_CD26L, /* -238 */ 0xA6B3_4AD8_C9DF_C06FL, /* -237 */ 0xD060_1D8E_FC57_B08BL, /* -236 */ 0x823C_1279_5DB6_CE57L, /* -235 */ 0xA2CB_1717_B524_81EDL, /* -234 */ 0xCB7D_DCDD_A26D_A268L, /* -233 */ 0xFE5D_5415_0B09_0B02L, /* -232 */ 0x9EFA_548D_26E5_A6E1L, /* -231 */ 0xC6B8_E9B0_709F_109AL, /* -230 */ 0xF867_241C_8CC6_D4C0L, /* -229 */ 0x9B40_7691_D7FC_44F8L, /* -228 */ 0xC210_9436_4DFB_5636L, /* -227 */ 0xF294_B943_E17A_2BC4L, /* -226 */ 0x979C_F3CA_6CEC_5B5AL, /* -225 */ 0xBD84_30BD_0827_7231L, /* -224 */ 0xECE5_3CEC_4A31_4EBDL, /* -223 */ 0x940F_4613_AE5E_D136L, /* -222 */ 0xB913_1798_99F6_8584L, /* -221 */ 0xE757_DD7E_C074_26E5L, /* -220 */ 0x9096_EA6F_3848_984FL, /* -219 */ 0xB4BC_A50B_065A_BE63L, /* -218 */ 0xE1EB_CE4D_C7F1_6DFBL, /* -217 */ 0x8D33_60F0_9CF6_E4BDL, /* -216 */ 0xB080_392C_C434_9DECL, /* -215 */ 0xDCA0_4777_F541_C567L, /* -214 */ 0x89E4_2CAA_F949_1B60L, /* -213 */ 0xAC5D_37D5_B79B_6239L, /* -212 */ 0xD774_85CB_2582_3AC7L, /* -211 */ 0x86A8_D39E_F771_64BCL, /* -210 */ 0xA853_0886_B54D_BDEBL, /* -209 */ 0xD267_CAA8_62A1_2D66L, /* -208 */ 0x8380_DEA9_3DA4_BC60L, /* -207 */ 0xA461_1653_8D0D_EB78L, /* -206 */ 0xCD79_5BE8_7051_6656L, /* -205 */ 0x806B_D971_4632_DFF6L, /* -204 */ 0xA086_CFCD_97BF_97F3L, /* -203 */ 0xC8A8_83C0_FDAF_7DF0L, /* -202 */ 0xFAD2_A4B1_3D1B_5D6CL, /* -201 */ 0x9CC3_A6EE_C631_1A63L, /* -200 */ 0xC3F4_90AA_77BD_60FCL, /* -199 */ 0xF4F1_B4D5_15AC_B93BL, /* -198 */ 0x9917_1105_2D8B_F3C5L, /* -197 */ 0xBF5C_D546_78EE_F0B6L, /* -196 */ 0xEF34_0A98_172A_ACE4L, /* -195 */ 0x9580_869F_0E7A_AC0EL, /* -194 */ 0xBAE0_A846_D219_5712L, /* -193 */ 0xE998_D258_869F_ACD7L, /* -192 */ 0x91FF_8377_5423_CC06L, /* -191 */ 0xB67F_6455_292C_BF08L, /* -190 */ 0xE41F_3D6A_7377_EECAL, /* -189 */ 0x8E93_8662_882A_F53EL, /* -188 */ 0xB238_67FB_2A35_B28DL, /* -187 */ 0xDEC6_81F9_F4C3_1F31L, /* -186 */ 0x8B3C_113C_38F9_F37EL, /* -185 */ 0xAE0B_158B_4738_705EL, /* -184 */ 0xD98D_DAEE_1906_8C76L, /* -183 */ 0x87F8_A8D4_CFA4_17C9L, /* -182 */ 0xA9F6_D30A_038D_1DBCL, /* -181 */ 0xD474_87CC_8470_652BL, /* -180 */ 0x84C8_D4DF_D2C6_3F3BL, /* -179 */ 0xA5FB_0A17_C777_CF09L, /* -178 */ 0xCF79_CC9D_B955_C2CCL, /* -177 */ 0x81AC_1FE2_93D5_99BFL, /* -176 */ 0xA217_27DB_38CB_002FL, /* -175 */ 0xCA9C_F1D2_06FD_C03BL, /* -174 */ 0xFD44_2E46_88BD_304AL, /* -173 */ 0x9E4A_9CEC_1576_3E2EL, /* -172 */ 0xC5DD_4427_1AD3_CDBAL, /* -171 */ 0xF754_9530_E188_C128L, /* -170 */ 0x9A94_DD3E_8CF5_78B9L, /* -169 */ 0xC13A_148E_3032_D6E7L, /* -168 */ 0xF188_99B1_BC3F_8CA1L, /* -167 */ 0x96F5_600F_15A7_B7E5L, /* -166 */ 0xBCB2_B812_DB11_A5DEL, /* -165 */ 0xEBDF_6617_91D6_0F56L, /* -164 */ 0x936B_9FCE_BB25_C995L, /* -163 */ 0xB846_87C2_69EF_3BFBL, /* -162 */ 0xE658_29B3_046B_0AFAL, /* -161 */ 0x8FF7_1A0F_E2C2_E6DCL, /* -160 */ 0xB3F4_E093_DB73_A093L, /* -159 */ 0xE0F2_18B8_D250_88B8L, /* -158 */ 0x8C97_4F73_8372_5573L, /* -157 */ 0xAFBD_2350_644E_EACFL, /* -156 */ 0xDBAC_6C24_7D62_A583L, /* -155 */ 0x894B_C396_CE5D_A772L, /* -154 */ 0xAB9E_B47C_81F5_114FL, /* -153 */ 0xD686_619B_A272_55A2L, /* -152 */ 0x8613_FD01_4587_7585L, /* -151 */ 0xA798_FC41_96E9_52E7L, /* -150 */ 0xD17F_3B51_FCA3_A7A0L, /* -149 */ 0x82EF_8513_3DE6_48C4L, /* -148 */ 0xA3AB_6658_0D5F_DAF5L, /* -147 */ 0xCC96_3FEE_10B7_D1B3L, /* -146 */ 0xFFBB_CFE9_94E5_C61FL, /* -145 */ 0x9FD5_61F1_FD0F_9BD3L, /* -144 */ 0xC7CA_BA6E_7C53_82C8L, /* -143 */ 0xF9BD_690A_1B68_637BL, /* -142 */ 0x9C16_61A6_5121_3E2DL, /* -141 */ 0xC31B_FA0F_E569_8DB8L, /* -140 */ 0xF3E2_F893_DEC3_F126L, /* -139 */ 0x986D_DB5C_6B3A_76B7L, /* -138 */ 0xBE89_5233_8609_1465L, /* -137 */ 0xEE2B_A6C0_678B_597FL, /* -136 */ 0x94DB_4838_40B7_17EFL, /* -135 */ 0xBA12_1A46_50E4_DDEBL, /* -134 */ 0xE896_A0D7_E51E_1566L, /* -133 */ 0x915E_2486_EF32_CD60L, /* -132 */ 0xB5B5_ADA8_AAFF_80B8L, /* -131 */ 0xE323_1912_D5BF_60E6L, /* -130 */ 0x8DF5_EFAB_C597_9C8FL, /* -129 */ 0xB173_6B96_B6FD_83B3L, /* -128 */ 0xDDD0_467C_64BC_E4A0L, /* -127 */ 0x8AA2_2C0D_BEF6_0EE4L, /* -126 */ 0xAD4A_B711_2EB3_929DL, /* -125 */ 0xD89D_64D5_7A60_7744L, /* -124 */ 0x8762_5F05_6C7C_4A8BL, /* -123 */ 0xA93A_F6C6_C79B_5D2DL, /* -122 */ 0xD389_B478_7982_3479L, /* -121 */ 0x8436_10CB_4BF1_60CBL, /* -120 */ 0xA543_94FE_1EED_B8FEL, /* -119 */ 0xCE94_7A3D_A6A9_273EL, /* -118 */ 0x811C_CC66_8829_B887L, /* -117 */ 0xA163_FF80_2A34_26A8L, /* -116 */ 0xC9BC_FF60_34C1_3052L, /* -115 */ 0xFC2C_3F38_41F1_7C67L, /* -114 */ 0x9D9B_A783_2936_EDC0L, /* -113 */ 0xC502_9163_F384_A931L, /* -112 */ 0xF643_35BC_F065_D37DL, /* -111 */ 0x99EA_0196_163F_A42EL, /* -110 */ 0xC064_81FB_9BCF_8D39L, /* -109 */ 0xF07D_A27A_82C3_7088L, /* -108 */ 0x964E_858C_91BA_2655L, /* -107 */ 0xBBE2_26EF_B628_AFEAL, /* -106 */ 0xEADA_B0AB_A3B2_DBE5L, /* -105 */ 0x92C8_AE6B_464F_C96FL, /* -104 */ 0xB77A_DA06_17E3_BBCBL, /* -103 */ 0xE559_9087_9DDC_AABDL, /* -102 */ 0x8F57_FA54_C2A9_EAB6L, /* -101 */ 0xB32D_F8E9_F354_6564L, /* -100 */ 0xDFF9_7724_7029_7EBDL, /* -99 */ 0x8BFB_EA76_C619_EF36L, /* -98 */ 0xAEFA_E514_77A0_6B03L, /* -97 */ 0xDAB9_9E59_9588_85C4L, /* -96 */ 0x88B4_02F7_FD75_539BL, /* -95 */ 0xAAE1_03B5_FCD2_A881L, /* -94 */ 0xD599_44A3_7C07_52A2L, /* -93 */ 0x857F_CAE6_2D84_93A5L, /* -92 */ 0xA6DF_BD9F_B8E5_B88EL, /* -91 */ 0xD097_AD07_A71F_26B2L, /* -90 */ 0x825E_CC24_C873_782FL, /* -89 */ 0xA2F6_7F2D_FA90_563BL, /* -88 */ 0xCBB4_1EF9_7934_6BCAL, /* -87 */ 0xFEA1_26B7_D781_86BCL, /* -86 */ 0x9F24_B832_E6B0_F436L, /* -85 */ 0xC6ED_E63F_A05D_3143L, /* -84 */ 0xF8A9_5FCF_8874_7D94L, /* -83 */ 0x9B69_DBE1_B548_CE7CL, /* -82 */ 0xC244_52DA_229B_021BL, /* -81 */ 0xF2D5_6790_AB41_C2A2L, /* -80 */ 0x97C5_60BA_6B09_19A5L, /* -79 */ 0xBDB6_B8E9_05CB_600FL, /* -78 */ 0xED24_6723_473E_3813L, /* -77 */ 0x9436_C076_0C86_E30BL, /* -76 */ 0xB944_7093_8FA8_9BCEL, /* -75 */ 0xE795_8CB8_7392_C2C2L, /* -74 */ 0x90BD_77F3_483B_B9B9L, /* -73 */ 0xB4EC_D5F0_1A4A_A828L, /* -72 */ 0xE228_0B6C_20DD_5232L, /* -71 */ 0x8D59_0723_948A_535FL, /* -70 */ 0xB0AF_48EC_79AC_E837L, /* -69 */ 0xDCDB_1B27_9818_2244L, /* -68 */ 0x8A08_F0F8_BF0F_156BL, /* -67 */ 0xAC8B_2D36_EED2_DAC5L, /* -66 */ 0xD7AD_F884_AA87_9177L, /* -65 */ 0x86CC_BB52_EA94_BAEAL, /* -64 */ 0xA87F_EA27_A539_E9A5L, /* -63 */ 0xD29F_E4B1_8E88_640EL, /* -62 */ 0x83A3_EEEE_F915_3E89L, /* -61 */ 0xA48C_EAAA_B75A_8E2BL, /* -60 */ 0xCDB0_2555_6531_31B6L, /* -59 */ 0x808E_1755_5F3E_BF11L, /* -58 */ 0xA0B1_9D2A_B70E_6ED6L, /* -57 */ 0xC8DE_0475_64D2_0A8BL, /* -56 */ 0xFB15_8592_BE06_8D2EL, /* -55 */ 0x9CED_737B_B6C4_183DL, /* -54 */ 0xC428_D05A_A475_1E4CL, /* -53 */ 0xF533_0471_4D92_65DFL, /* -52 */ 0x993F_E2C6_D07B_7FABL, /* -51 */ 0xBF8F_DB78_849A_5F96L, /* -50 */ 0xEF73_D256_A5C0_F77CL, /* -49 */ 0x95A8_6376_2798_9AADL, /* -48 */ 0xBB12_7C53_B17E_C159L, /* -47 */ 0xE9D7_1B68_9DDE_71AFL, /* -46 */ 0x9226_7121_62AB_070DL, /* -45 */ 0xB6B0_0D69_BB55_C8D1L, /* -44 */ 0xE45C_10C4_2A2B_3B05L, /* -43 */ 0x8EB9_8A7A_9A5B_04E3L, /* -42 */ 0xB267_ED19_40F1_C61CL, /* -41 */ 0xDF01_E85F_912E_37A3L, /* -40 */ 0x8B61_313B_BABC_E2C6L, /* -39 */ 0xAE39_7D8A_A96C_1B77L, /* -38 */ 0xD9C7_DCED_53C7_2255L, /* -37 */ 0x881C_EA14_545C_7575L, /* -36 */ 0xAA24_2499_6973_92D2L, /* -35 */ 0xD4AD_2DBF_C3D0_7787L, /* -34 */ 0x84EC_3C97_DA62_4AB4L, /* -33 */ 0xA627_4BBD_D0FA_DD61L, /* -32 */ 0xCFB1_1EAD_4539_94BAL, /* -31 */ 0x81CE_B32C_4B43_FCF4L, /* -30 */ 0xA242_5FF7_5E14_FC31L, /* -29 */ 0xCAD2_F7F5_359A_3B3EL, /* -28 */ 0xFD87_B5F2_8300_CA0DL, /* -27 */ 0x9E74_D1B7_91E0_7E48L, /* -26 */ 0xC612_0625_7658_9DDAL, /* -25 */ 0xF796_87AE_D3EE_C551L, /* -24 */ 0x9ABE_14CD_4475_3B52L, /* -23 */ 0xC16D_9A00_9592_8A27L, /* -22 */ 0xF1C9_0080_BAF7_2CB1L, /* -21 */ 0x971D_A050_74DA_7BEEL, /* -20 */ 0xBCE5_0864_9211_1AEAL, /* -19 */ 0xEC1E_4A7D_B695_61A5L, /* -18 */ 0x9392_EE8E_921D_5D07L, /* -17 */ 0xB877_AA32_36A4_B449L, /* -16 */ 0xE695_94BE_C44D_E15BL, /* -15 */ 0x901D_7CF7_3AB0_ACD9L, /* -14 */ 0xB424_DC35_095C_D80FL, /* -13 */ 0xE12E_1342_4BB4_0E13L, /* -12 */ 0x8CBC_CC09_6F50_88CBL, /* -11 */ 0xAFEB_FF0B_CB24_AAFEL, /* -10 */ 0xDBE6_FECE_BDED_D5BEL, /* -9 */ 0x8970_5F41_36B4_A597L, /* -8 */ 0xABCC_7711_8461_CEFCL, /* -7 */ 0xD6BF_94D5_E57A_42BCL, /* -6 */ 0x8637_BD05_AF6C_69B5L, /* -5 */ 0xA7C5_AC47_1B47_8423L, /* -4 */ 0xD1B7_1758_E219_652BL, /* -3 */ 0x8312_6E97_8D4F_DF3BL, /* -2 */ 0xA3D7_0A3D_70A3_D70AL, /* -1 */ 0xCCCC_CCCC_CCCC_CCCCL, /* 0 */ 0x8000_0000_0000_0000L, /* 1 */ 0xA000_0000_0000_0000L, /* 2 */ 0xC800_0000_0000_0000L, /* 3 */ 0xFA00_0000_0000_0000L, /* 4 */ 0x9C40_0000_0000_0000L, /* 5 */ 0xC350_0000_0000_0000L, /* 6 */ 0xF424_0000_0000_0000L, /* 7 */ 0x9896_8000_0000_0000L, /* 8 */ 0xBEBC_2000_0000_0000L, /* 9 */ 0xEE6B_2800_0000_0000L, /* 10 */ 0x9502_F900_0000_0000L, /* 11 */ 0xBA43_B740_0000_0000L, /* 12 */ 0xE8D4_A510_0000_0000L, /* 13 */ 0x9184_E72A_0000_0000L, /* 14 */ 0xB5E6_20F4_8000_0000L, /* 15 */ 0xE35F_A931_A000_0000L, /* 16 */ 0x8E1B_C9BF_0400_0000L, /* 17 */ 0xB1A2_BC2E_C500_0000L, /* 18 */ 0xDE0B_6B3A_7640_0000L, /* 19 */ 0x8AC7_2304_89E8_0000L, /* 20 */ 0xAD78_EBC5_AC62_0000L, /* 21 */ 0xD8D7_26B7_177A_8000L, /* 22 */ 0x8786_7832_6EAC_9000L, /* 23 */ 0xA968_163F_0A57_B400L, /* 24 */ 0xD3C2_1BCE_CCED_A100L, /* 25 */ 0x8459_5161_4014_84A0L, /* 26 */ 0xA56F_A5B9_9019_A5C8L, /* 27 */ 0xCECB_8F27_F420_0F3AL, /* 28 */ 0x813F_3978_F894_0984L, /* 29 */ 0xA18F_07D7_36B9_0BE5L, /* 30 */ 0xC9F2_C9CD_0467_4EDEL, /* 31 */ 0xFC6F_7C40_4581_2296L, /* 32 */ 0x9DC5_ADA8_2B70_B59DL, /* 33 */ 0xC537_1912_364C_E305L, /* 34 */ 0xF684_DF56_C3E0_1BC6L, /* 35 */ 0x9A13_0B96_3A6C_115CL, /* 36 */ 0xC097_CE7B_C907_15B3L, /* 37 */ 0xF0BD_C21A_BB48_DB20L, /* 38 */ 0x9676_9950_B50D_88F4L, /* 39 */ 0xBC14_3FA4_E250_EB31L, /* 40 */ 0xEB19_4F8E_1AE5_25FDL, /* 41 */ 0x92EF_D1B8_D0CF_37BEL, /* 42 */ 0xB7AB_C627_0503_05ADL, /* 43 */ 0xE596_B7B0_C643_C719L, /* 44 */ 0x8F7E_32CE_7BEA_5C6FL, /* 45 */ 0xB35D_BF82_1AE4_F38BL, /* 46 */ 0xE035_2F62_A19E_306EL, /* 47 */ 0x8C21_3D9D_A502_DE45L, /* 48 */ 0xAF29_8D05_0E43_95D6L, /* 49 */ 0xDAF3_F046_51D4_7B4CL, /* 50 */ 0x88D8_762B_F324_CD0FL, /* 51 */ 0xAB0E_93B6_EFEE_0053L, /* 52 */ 0xD5D2_38A4_ABE9_8068L, /* 53 */ 0x85A3_6366_EB71_F041L, /* 54 */ 0xA70C_3C40_A64E_6C51L, /* 55 */ 0xD0CF_4B50_CFE2_0765L, /* 56 */ 0x8281_8F12_81ED_449FL, /* 57 */ 0xA321_F2D7_2268_95C7L, /* 58 */ 0xCBEA_6F8C_EB02_BB39L, /* 59 */ 0xFEE5_0B70_25C3_6A08L, /* 60 */ 0x9F4F_2726_179A_2245L, /* 61 */ 0xC722_F0EF_9D80_AAD6L, /* 62 */ 0xF8EB_AD2B_84E0_D58BL, /* 63 */ 0x9B93_4C3B_330C_8577L, /* 64 */ 0xC278_1F49_FFCF_A6D5L, /* 65 */ 0xF316_271C_7FC3_908AL, /* 66 */ 0x97ED_D871_CFDA_3A56L, /* 67 */ 0xBDE9_4E8E_43D0_C8ECL, /* 68 */ 0xED63_A231_D4C4_FB27L, /* 69 */ 0x945E_455F_24FB_1CF8L, /* 70 */ 0xB975_D6B6_EE39_E436L, /* 71 */ 0xE7D3_4C64_A9C8_5D44L, /* 72 */ 0x90E4_0FBE_EA1D_3A4AL, /* 73 */ 0xB51D_13AE_A4A4_88DDL, /* 74 */ 0xE264_589A_4DCD_AB14L, /* 75 */ 0x8D7E_B760_70A0_8AECL, /* 76 */ 0xB0DE_6538_8CC8_ADA8L, /* 77 */ 0xDD15_FE86_AFFA_D912L, /* 78 */ 0x8A2D_BF14_2DFC_C7ABL, /* 79 */ 0xACB9_2ED9_397B_F996L, /* 80 */ 0xD7E7_7A8F_87DA_F7FBL, /* 81 */ 0x86F0_AC99_B4E8_DAFDL, /* 82 */ 0xA8AC_D7C0_2223_11BCL, /* 83 */ 0xD2D8_0DB0_2AAB_D62BL, /* 84 */ 0x83C7_088E_1AAB_65DBL, /* 85 */ 0xA4B8_CAB1_A156_3F52L, /* 86 */ 0xCDE6_FD5E_09AB_CF26L, /* 87 */ 0x80B0_5E5A_C60B_6178L, /* 88 */ 0xA0DC_75F1_778E_39D6L, /* 89 */ 0xC913_936D_D571_C84CL, /* 90 */ 0xFB58_7849_4ACE_3A5FL, /* 91 */ 0x9D17_4B2D_CEC0_E47BL, /* 92 */ 0xC45D_1DF9_4271_1D9AL, /* 93 */ 0xF574_6577_930D_6500L, /* 94 */ 0x9968_BF6A_BBE8_5F20L, /* 95 */ 0xBFC2_EF45_6AE2_76E8L, /* 96 */ 0xEFB3_AB16_C59B_14A2L, /* 97 */ 0x95D0_4AEE_3B80_ECE5L, /* 98 */ 0xBB44_5DA9_CA61_281FL, /* 99 */ 0xEA15_7514_3CF9_7226L, /* 100 */ 0x924D_692C_A61B_E758L, /* 101 */ 0xB6E0_C377_CFA2_E12EL, /* 102 */ 0xE498_F455_C38B_997AL, /* 103 */ 0x8EDF_98B5_9A37_3FECL, /* 104 */ 0xB297_7EE3_00C5_0FE7L, /* 105 */ 0xDF3D_5E9B_C0F6_53E1L, /* 106 */ 0x8B86_5B21_5899_F46CL, /* 107 */ 0xAE67_F1E9_AEC0_7187L, /* 108 */ 0xDA01_EE64_1A70_8DE9L, /* 109 */ 0x8841_34FE_9086_58B2L, /* 110 */ 0xAA51_823E_34A7_EEDEL, /* 111 */ 0xD4E5_E2CD_C1D1_EA96L, /* 112 */ 0x850F_ADC0_9923_329EL, /* 113 */ 0xA653_9930_BF6B_FF45L, /* 114 */ 0xCFE8_7F7C_EF46_FF16L, /* 115 */ 0x81F1_4FAE_158C_5F6EL, /* 116 */ 0xA26D_A399_9AEF_7749L, /* 117 */ 0xCB09_0C80_01AB_551CL, /* 118 */ 0xFDCB_4FA0_0216_2A63L, /* 119 */ 0x9E9F_11C4_014D_DA7EL, /* 120 */ 0xC646_D635_01A1_511DL, /* 121 */ 0xF7D8_8BC2_4209_A565L, /* 122 */ 0x9AE7_5759_6946_075FL, /* 123 */ 0xC1A1_2D2F_C397_8937L, /* 124 */ 0xF209_787B_B47D_6B84L, /* 125 */ 0x9745_EB4D_50CE_6332L, /* 126 */ 0xBD17_6620_A501_FBFFL, /* 127 */ 0xEC5D_3FA8_CE42_7AFFL, /* 128 */ 0x93BA_47C9_80E9_8CDFL, /* 129 */ 0xB8A8_D9BB_E123_F017L, /* 130 */ 0xE6D3_102A_D96C_EC1DL, /* 131 */ 0x9043_EA1A_C7E4_1392L, /* 132 */ 0xB454_E4A1_79DD_1877L, /* 133 */ 0xE16A_1DC9_D854_5E94L, /* 134 */ 0x8CE2_529E_2734_BB1DL, /* 135 */ 0xB01A_E745_B101_E9E4L, /* 136 */ 0xDC21_A117_1D42_645DL, /* 137 */ 0x8995_04AE_7249_7EBAL, /* 138 */ 0xABFA_45DA_0EDB_DE69L, /* 139 */ 0xD6F8_D750_9292_D603L, /* 140 */ 0x865B_8692_5B9B_C5C2L, /* 141 */ 0xA7F2_6836_F282_B732L, /* 142 */ 0xD1EF_0244_AF23_64FFL, /* 143 */ 0x8335_616A_ED76_1F1FL, /* 144 */ 0xA402_B9C5_A8D3_A6E7L, /* 145 */ 0xCD03_6837_1308_90A1L, /* 146 */ 0x8022_2122_6BE5_5A64L, /* 147 */ 0xA02A_A96B_06DE_B0FDL, /* 148 */ 0xC835_53C5_C896_5D3DL, /* 149 */ 0xFA42_A8B7_3ABB_F48CL, /* 150 */ 0x9C69_A972_84B5_78D7L, /* 151 */ 0xC384_13CF_25E2_D70DL, /* 152 */ 0xF465_18C2_EF5B_8CD1L, /* 153 */ 0x98BF_2F79_D599_3802L, /* 154 */ 0xBEEE_FB58_4AFF_8603L, /* 155 */ 0xEEAA_BA2E_5DBF_6784L, /* 156 */ 0x952A_B45C_FA97_A0B2L, /* 157 */ 0xBA75_6174_393D_88DFL, /* 158 */ 0xE912_B9D1_478C_EB17L, /* 159 */ 0x91AB_B422_CCB8_12EEL, /* 160 */ 0xB616_A12B_7FE6_17AAL, /* 161 */ 0xE39C_4976_5FDF_9D94L, /* 162 */ 0x8E41_ADE9_FBEB_C27DL, /* 163 */ 0xB1D2_1964_7AE6_B31CL, /* 164 */ 0xDE46_9FBD_99A0_5FE3L, /* 165 */ 0x8AEC_23D6_8004_3BEEL, /* 166 */ 0xADA7_2CCC_2005_4AE9L, /* 167 */ 0xD910_F7FF_2806_9DA4L, /* 168 */ 0x87AA_9AFF_7904_2286L, /* 169 */ 0xA995_41BF_5745_2B28L, /* 170 */ 0xD3FA_922F_2D16_75F2L, /* 171 */ 0x847C_9B5D_7C2E_09B7L, /* 172 */ 0xA59B_C234_DB39_8C25L, /* 173 */ 0xCF02_B2C2_1207_EF2EL, /* 174 */ 0x8161_AFB9_4B44_F57DL, /* 175 */ 0xA1BA_1BA7_9E16_32DCL, /* 176 */ 0xCA28_A291_859B_BF93L, /* 177 */ 0xFCB2_CB35_E702_AF78L, /* 178 */ 0x9DEF_BF01_B061_ADABL, /* 179 */ 0xC56B_AEC2_1C7A_1916L, /* 180 */ 0xF6C6_9A72_A398_9F5BL, /* 181 */ 0x9A3C_2087_A63F_6399L, /* 182 */ 0xC0CB_28A9_8FCF_3C7FL, /* 183 */ 0xF0FD_F2D3_F3C3_0B9FL, /* 184 */ 0x969E_B7C4_7859_E743L, /* 185 */ 0xBC46_65B5_9670_6114L, /* 186 */ 0xEB57_FF22_FC0C_7959L, /* 187 */ 0x9316_FF75_DD87_CBD8L, /* 188 */ 0xB7DC_BF53_54E9_BECEL, /* 189 */ 0xE5D3_EF28_2A24_2E81L, /* 190 */ 0x8FA4_7579_1A56_9D10L, /* 191 */ 0xB38D_92D7_60EC_4455L, /* 192 */ 0xE070_F78D_3927_556AL, /* 193 */ 0x8C46_9AB8_43B8_9562L, /* 194 */ 0xAF58_4166_54A6_BABBL, /* 195 */ 0xDB2E_51BF_E9D0_696AL, /* 196 */ 0x88FC_F317_F222_41E2L, /* 197 */ 0xAB3C_2FDD_EEAA_D25AL, /* 198 */ 0xD60B_3BD5_6A55_86F1L, /* 199 */ 0x85C7_0565_6275_7456L, /* 200 */ 0xA738_C6BE_BB12_D16CL, /* 201 */ 0xD106_F86E_69D7_85C7L, /* 202 */ 0x82A4_5B45_0226_B39CL, /* 203 */ 0xA34D_7216_42B0_6084L, /* 204 */ 0xCC20_CE9B_D35C_78A5L, /* 205 */ 0xFF29_0242_C833_96CEL, /* 206 */ 0x9F79_A169_BD20_3E41L, /* 207 */ 0xC758_09C4_2C68_4DD1L, /* 208 */ 0xF92E_0C35_3782_6145L, /* 209 */ 0x9BBC_C7A1_42B1_7CCBL, /* 210 */ 0xC2AB_F989_935D_DBFEL, /* 211 */ 0xF356_F7EB_F835_52FEL, /* 212 */ 0x9816_5AF3_7B21_53DEL, /* 213 */ 0xBE1B_F1B0_59E9_A8D6L, /* 214 */ 0xEDA2_EE1C_7064_130CL, /* 215 */ 0x9485_D4D1_C63E_8BE7L, /* 216 */ 0xB9A7_4A06_37CE_2EE1L, /* 217 */ 0xE811_1C87_C5C1_BA99L, /* 218 */ 0x910A_B1D4_DB99_14A0L, /* 219 */ 0xB54D_5E4A_127F_59C8L, /* 220 */ 0xE2A0_B5DC_971F_303AL, /* 221 */ 0x8DA4_71A9_DE73_7E24L, /* 222 */ 0xB10D_8E14_5610_5DADL, /* 223 */ 0xDD50_F199_6B94_7518L, /* 224 */ 0x8A52_96FF_E33C_C92FL, /* 225 */ 0xACE7_3CBF_DC0B_FB7BL, /* 226 */ 0xD821_0BEF_D30E_FA5AL, /* 227 */ 0x8714_A775_E3E9_5C78L, /* 228 */ 0xA8D9_D153_5CE3_B396L, /* 229 */ 0xD310_45A8_341C_A07CL, /* 230 */ 0x83EA_2B89_2091_E44DL, /* 231 */ 0xA4E4_B66B_68B6_5D60L, /* 232 */ 0xCE1D_E406_42E3_F4B9L, /* 233 */ 0x80D2_AE83_E9CE_78F3L, /* 234 */ 0xA107_5A24_E442_1730L, /* 235 */ 0xC949_30AE_1D52_9CFCL, /* 236 */ 0xFB9B_7CD9_A4A7_443CL, /* 237 */ 0x9D41_2E08_06E8_8AA5L, /* 238 */ 0xC491_798A_08A2_AD4EL, /* 239 */ 0xF5B5_D7EC_8ACB_58A2L, /* 240 */ 0x9991_A6F3_D6BF_1765L, /* 241 */ 0xBFF6_10B0_CC6E_DD3FL, /* 242 */ 0xEFF3_94DC_FF8A_948EL, /* 243 */ 0x95F8_3D0A_1FB6_9CD9L, /* 244 */ 0xBB76_4C4C_A7A4_440FL, /* 245 */ 0xEA53_DF5F_D18D_5513L, /* 246 */ 0x9274_6B9B_E2F8_552CL, /* 247 */ 0xB711_8682_DBB6_6A77L, /* 248 */ 0xE4D5_E823_92A4_0515L, /* 249 */ 0x8F05_B116_3BA6_832DL, /* 250 */ 0xB2C7_1D5B_CA90_23F8L, /* 251 */ 0xDF78_E4B2_BD34_2CF6L, /* 252 */ 0x8BAB_8EEF_B640_9C1AL, /* 253 */ 0xAE96_72AB_A3D0_C320L, /* 254 */ 0xDA3C_0F56_8CC4_F3E8L, /* 255 */ 0x8865_8996_17FB_1871L, /* 256 */ 0xAA7E_EBFB_9DF9_DE8DL, /* 257 */ 0xD51E_A6FA_8578_5631L, /* 258 */ 0x8533_285C_936B_35DEL, /* 259 */ 0xA67F_F273_B846_0356L, /* 260 */ 0xD01F_EF10_A657_842CL, /* 261 */ 0x8213_F56A_67F6_B29BL, /* 262 */ 0xA298_F2C5_01F4_5F42L, /* 263 */ 0xCB3F_2F76_4271_7713L, /* 264 */ 0xFE0E_FB53_D30D_D4D7L, /* 265 */ 0x9EC9_5D14_63E8_A506L, /* 266 */ 0xC67B_B459_7CE2_CE48L, /* 267 */ 0xF81A_A16F_DC1B_81DAL, /* 268 */ 0x9B10_A4E5_E991_3128L, /* 269 */ 0xC1D4_CE1F_63F5_7D72L, /* 270 */ 0xF24A_01A7_3CF2_DCCFL, /* 271 */ 0x976E_4108_8617_CA01L, /* 272 */ 0xBD49_D14A_A79D_BC82L, /* 273 */ 0xEC9C_459D_5185_2BA2L, /* 274 */ 0x93E1_AB82_52F3_3B45L, /* 275 */ 0xB8DA_1662_E7B0_0A17L, /* 276 */ 0xE710_9BFB_A19C_0C9DL, /* 277 */ 0x906A_617D_4501_87E2L, /* 278 */ 0xB484_F9DC_9641_E9DAL, /* 279 */ 0xE1A6_3853_BBD2_6451L, /* 280 */ 0x8D07_E334_5563_7EB2L, /* 281 */ 0xB049_DC01_6ABC_5E5FL, /* 282 */ 0xDC5C_5301_C56B_75F7L, /* 283 */ 0x89B9_B3E1_1B63_29BAL, /* 284 */ 0xAC28_20D9_623B_F429L, /* 285 */ 0xD732_290F_BACA_F133L, /* 286 */ 0x867F_59A9_D4BE_D6C0L, /* 287 */ 0xA81F_3014_49EE_8C70L, /* 288 */ 0xD226_FC19_5C6A_2F8CL, /* 289 */ 0x8358_5D8F_D9C2_5DB7L, /* 290 */ 0xA42E_74F3_D032_F525L, /* 291 */ 0xCD3A_1230_C43F_B26FL, /* 292 */ 0x8044_4B5E_7AA7_CF85L, /* 293 */ 0xA055_5E36_1951_C366L, /* 294 */ 0xC86A_B5C3_9FA6_3440L, /* 295 */ 0xFA85_6334_878F_C150L, /* 296 */ 0x9C93_5E00_D4B9_D8D2L, /* 297 */ 0xC3B8_3581_09E8_4F07L, /* 298 */ 0xF4A6_42E1_4C62_62C8L, /* 299 */ 0x98E7_E9CC_CFBD_7DBDL, /* 300 */ 0xBF21_E440_03AC_DD2CL, /* 301 */ 0xEEEA_5D50_0498_1478L, /* 302 */ 0x9552_7A52_02DF_0CCBL, /* 303 */ 0xBAA7_18E6_8396_CFFDL, /* 304 */ 0xE950_DF20_247C_83FDL, /* 305 */ 0x91D2_8B74_16CD_D27EL, /* 306 */ 0xB647_2E51_1C81_471DL, /* 307 */ 0xE3D8_F9E5_63A1_98E5L, /* 308 */ 0x8E67_9C2F_5E44_FF8FL, /* 309 */ 0xB201_833B_35D6_3F73L, /* 310 */ 0xDE81_E40A_034B_CF4FL, /* 311 */ 0x8B11_2E86_420F_6191L, /* 312 */ 0xADD5_7A27_D293_39F6L, /* 313 */ 0xD94A_D8B1_C738_0874L, /* 314 */ 0x87CE_C76F_1C83_0548L, /* 315 */ 0xA9C2_794A_E3A3_C69AL, /* 316 */ 0xD433_179D_9C8C_B841L, /* 317 */ 0x849F_EEC2_81D7_F328L, /* 318 */ 0xA5C7_EA73_224D_EFF3L, /* 319 */ 0xCF39_E50F_EAE1_6BEFL, /* 320 */ 0x8184_2F29_F2CC_E375L, /* 321 */ 0xA1E5_3AF4_6F80_1C53L, /* 322 */ 0xCA5E_89B1_8B60_2368L, /* 323 */ 0xFCF6_2C1D_EE38_2C42L, /* 324 */ 0x9E19_DB92_B4E3_1BA9L, }; } -------- math.DoubleToDecimal.java /* * Copyright (c) 2018, Raffaello Giulietti. 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. * This particular file is subject to the "Classpath" exception as provided * 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. */ package math; import static java.lang.Double.*; import static java.lang.Math.max; import static java.lang.Long.numberOfLeadingZeros; import static math.MathUtils.*; import static math.DoubleToDecimal.Double.*; import static math.Natural.valueOfShiftLeft; import static math.Powers.*; /** * This class exposes a method to render a {@code double} as a string. */ final public class DoubleToDecimal { /* For full details of the logic in this and the other supporting classes, search the web for d6b9e38fbe27f199d27e19f25acc26452e7e2ece and check that the title reads "Rendering doubles in Java" */ /** * Exposes some constants related to the IEEE 754-2008 breakdown of * {@code double}s and some extractors suited for finite positive values. * *

      A finite positive {@code double} v has the form * v = c·2q, * where integers c, q meet *

        *
      • either 2{@link #P}-1 ≤ c < * 2{@link #P} and {@link #Q_MIN} ≤ q ≤ * {@link #Q_MAX} (normal v) *
      • or 0 < c < 2{@link #P}-1 and * c = {@link #Q_MIN} (subnormal v) *
      */ static final class Double { /** * Precision of normal values in bits. */ static final int P = 53; /** * Length in bits of the exponent field. */ static final int W = (java.lang.Double.SIZE - 1) - (P - 1); /** * Minimum value of the exponent. */ static final int Q_MIN = (-1 << W - 1) - P + 3; /** * Maximum value of the exponent. */ static final int Q_MAX = (1 << W - 1) - P; /** * Minimum value of the coefficient of a normal value. */ static final long C_MIN = 1L << P - 1; /** * Maximum value of the coefficient of a normal value. */ static final long C_MAX = (1L << P) - 1; /** * H = min {n integer | 10^(n-1) > 2^P} */ static final int H = 17; /** * G = max {n integer | 2^(P-1) > 10^n} */ static final int G = 15; /** * The integer e such that * 10e-1 ≤ {@link java.lang.Double#MIN_VALUE} * < 10e. */ static final int E_MIN_VALUE = -323; /** * The integer e such that * 10e-1 ≤ {@link java.lang.Double#MIN_NORMAL} * < 10e. */ static final int E_MIN_NORMAL = -307; /** * The integer e such that * 10e-1 ≤ {@link java.lang.Double#MAX_VALUE} * < 10e. */ static final int E_MAX_VALUE = 309; // Mask to extract the IEEE 754-2008 biased exponent. private static final int BQ_MASK = (1 << W) - 1; // Mask to extract the IEEE 754-2008 fraction bits. private static final long T_MASK = (1L << P - 1) - 1; // Constants for the computation of roundCeilPow10() private static final int D = Long.SIZE - P; private static final long CEIL_EPS = (1L << D) - 1; private static final int ORD_2_MIN_NORMAL = Q_MIN + P; private Double() { } private static int bq(long bits) { return (int) (bits >>> P - 1) & BQ_MASK; } /** * Given the {@code bits} of a finite positive {@code double}, * returns q described in {@link java.lang.Double}. */ static int q(long bits) { int bq = bq(bits); if (bq > 0) { return Q_MIN - 1 + bq; } return Q_MIN; } /** * Given the {@code bits} of a finite positive {@code double}, * returns c described in {@link java.lang.Double}. */ static long c(long bits) { int bq = bq(bits); long t = bits & T_MASK; if (bq > 0) { return C_MIN | t; } return t; } private static int ord2(int q, long c) { // Fast path for the normal case. if (c >= C_MIN) { return P + q; } return Q_MIN + Long.SIZE - numberOfLeadingZeros(c); } /** * For finite positive {@code v}, returns the integer e such that * 2e-1 ≤ {@code v} < * 2e. */ private static int ord2(double v) { long bits = java.lang.Double.doubleToRawLongBits(v); return ord2(q(bits), c(bits)); } /** * For finite positive {@code v}, returns the integer e such that * 10e-1 ≤ {@code v} < * 10e. */ static int ord10(double v) { int ep = ord10pow2(ord2(v)) - 1; if (v < roundCeilPow10(ep)) return ep; return ep + 1; } // Returns the smallest double v such that 10^e <= v. private static double roundCeilPow10(int e) { int e2 = ord2pow10(e); if (e2 >= ORD_2_MIN_NORMAL) { long c = (floorPow10d(e) + CEIL_EPS) >>> D; int q = e2 - P; long bits = (long) (q - (Q_MIN - 1)) << P - 1 | c & T_MASK; return java.lang.Double.longBitsToDouble(bits); } int d = ORD_2_MIN_NORMAL + D - e2; if (d < Long.SIZE) { long c = (floorPow10d(e) + (1L << d) - 1) >>> d; return java.lang.Double.longBitsToDouble(c); } return java.lang.Double.MIN_VALUE; } } // used in the left-to-right extraction of the digits private static final int LTR = 28; private static final int MASK_LTR = (1 << LTR) - 1; // MAX_SIGNIFICAND = 10^H private static final long MAX_SIGNIFICAND = 100_000_000_000_000_000L; // The additional precision, used in reduced() private static final int D = Long.SIZE - P; // for thread-safety, each thread gets its own instance of this class private static final ThreadLocal threadLocal = ThreadLocal.withInitial(DoubleToDecimal::new); /* Given finite positive double v, there are two breakdowns: v = c * 2^q, as described in DoubleToDecimal.Double v = f * 10^e, with 0.1 <= f < 1 e, q, and c are kept in the following fields. */ private int e; private int q; private long c; /* For the default IEEE round-to-closest rounding, lout = rout always holds. However, two fields are kept for possible future extensions. Possible values are 0, if the boundary of the rounding interval is included 1, if the boundary of the rounding interval is excluded */ private int lout; // left (closer to 0) boundary private int rout; // right (farther from 0) boundary /* Room for H digits, 3 exponent digits, 2 '-', 1 '.', 1 'E' = H + 7 or for "-0.00" + H digits = H + 5 */ private final char[] buf = new char[H + 7]; private int index; // index of rightmost valid character private DoubleToDecimal() { } /** * Returns a string rendering of the {@code double} argument. * *

      The characters of the result are all drawn from the ASCII set. *

        *
      • Any NaN, whether quiet or signaling, is rendered symbolically * as {@code "NaN"}, regardless of the sign bit. *
      • The infinities +∞ and -∞ are rendered as * {@code "Infinity"} and {@code "-Infinity"}, respectively. *
      • The zeroes +0.0 and -0.0 are rendered as * {@code "0.0"} and {@code "-0.0"}, respectively. *
      • Otherwise {@code v} is finite and non-zero. * It is rendered in two stages: *
          *
        • Selection of a decimal: A well-specified non-zero decimal * d is selected to represent {@code v}. *
        • Formatting as a string: The decimal d is formatted * as a string, either in plain or in computerized scientific * notation, depending on its value. *
        *
      * *

      A decimal d is said to have length i if it has * the form d = c · 10q * for some integers c and q and if the decimal expansion of * c consists of i digits. Note that if d has some * length, then it has any other greater length as well: grow c by * appending trailing zeroes and decrease q accordingly. * *

      Abstractly, the unique decimal d to represent {@code v} * is selected as follows: *

        *
      • First, all decimals that round to {@code v} according to the * usual round-to-closest rule of IEEE 754 floating-point arithmetic * are tentatively selected, while the other are discarded. * There is never the need to go beyond a length of 17. *
      • Among these, only the ones that have the shortest possible * length not less than 2 are selected and the other are discarded. *
      • Finally, among these, only the one closest to {@code v} is * definitely selected: or if two are equally close to {@code v}, the * one whose least significant digit is even is definitely selected. *
      * *

      The selected decimal d is then formatted as a string. * If d < 0, the first character of the string is the sign * '{@code -}'. Then consider the absolute value and let * |d| = m · 10k, for some unique * real m meeting 1 ≤ m < 10 and integer k. * Further, let the decimal expansion of m be * m1.m2…mi, * with i ≥ 1 and mi ≠ 0. *

        *
      • Case -3 ≤ k < 0: |d| is formatted as * 0.0…0m1…mi, * where there are exactly -k leading zeroes before * m1, including the zero before the decimal point. * For example, {@code "0.01234"}. *
      • Case 0 ≤ k < 7: *
          *
        • Subcase i < k + 2: * |d| is formatted as * m1…mi0…0.0, * where there are exactly k + 2 - i trailing zeroes * after mi, including the zero after * the decimal point. * For example, {@code "1200.0"}. *
        • Subcase i ≥ k + 2: * |d| is formatted as * m1…mk+1.mk+2…mi. * For example, {@code "1234.567"}. *
        *
      • Case k < -3 or k ≥ 7: * computerized scientific notation is used to format |d|, * by combining m and k separated by the exponent * indicator '{@code E}'. *
          *
        • Subcase i = 1: * |d| is formatted as * m1.0Ek. * For example, {@code "2.0E23"}. *
        • Subcase i > 1: * |d| is formatted as * m1.m2…miEk. * For example, {@code "1.2345E-67"}. *
        * The exponent k is formatted as in * {@link Integer#toString(int)}. *
      * * @param v the {@code double} to be rendered. * @return a string rendering of the argument. */ public static String toString(double v) { return threadLocalInstance().toDecimal(v); } private static DoubleToDecimal threadLocalInstance() { return threadLocal.get(); } private String toDecimal(double v) { // Get rid of NaNs, infinities and zeroes right at the beginning if (v != v) { return "NaN"; } if (v == POSITIVE_INFINITY) { return "Infinity"; } if (v == NEGATIVE_INFINITY) { return "-Infinity"; } long bits = doubleToRawLongBits(v); if (bits == 0x0000_0000_0000_0000L) { return "0.0"; } if (bits == 0x8000_0000_0000_0000L) { return "-0.0"; } index = -1; if (bits < 0) { append('-'); v = -v; } e = ord10(v); /* When v is an integer less than 10^9, a common case in practice, use a customized faster method. */ long l = (long) v; if (l == v & l < 1_000_000_000L) { return integer(l); } q = q(bits); c = c(bits); lout = rout = (int) (c) & 0x1; /* The reduced() method assumes v is normal, i.e., has full precision P, and that powers of 2 have unequally distant predecessor and successor. MIN_NORMAL is normal and a power of 2 but its predecessor and its successor are equally close to it, so is excluded from reduced(). Note that reduced() might failover to full(). */ if (v > MIN_NORMAL) { return reduced(); } return full(); } private String integer(long l) { return toChars(l * pow10[H - 8 - e], e); } private String full() { long cb; int qb; long cbr; if (c != C_MIN | q == Q_MIN) { cb = c << 1; qb = q - 1; cbr = cb + 1; } else { cb = c << 2; qb = q - 2; cbr = cb + 2; } if (e <= H) { if (e - qb <= H) { return fullCaseM(qb, cb, cbr); } if (H - 3 <= e) { return fullSubcaseS(qb, cb, cbr); } int p = q > Q_MIN || c > C_MIN ? P : Long.SIZE - numberOfLeadingZeros(c - 1); int i = max(ord10pow2(p - 1) - 1, 2); return fullCaseXS(qb, cb, cbr, i); } if (qb - e <= 8 - H) { return fullSubcaseL(qb, cb, cbr); } return fullCaseXL(qb, cb, cbr); } private String fullCaseXS(int qb, long cb, long cb_r, int i) { Natural m = pow5(H - e); Natural vb = m.multiply(cb); Natural vbl = vb.subtract(m); Natural vbr = m.multiply(cb_r); int p = e - H - qb; long sbH = vb.shiftRight(p); for (int g = H - i; g >= 0; --g) { long di = pow10[g]; long sbi = sbH - sbH % di; Natural ubi = valueOfShiftLeft(sbi, p); Natural wbi = valueOfShiftLeft(sbi + di, p); boolean uin = vbl.compareTo(ubi) + lout <= 0; boolean win = wbi.compareTo(vbr) + rout <= 0; if (uin & !win) { return toChars(sbi, e); } if (!uin & win) { return toChars(sbi + di, e); } if (uin) { int cmp = vb.closerTo(ubi, wbi); if (cmp < 0 || cmp == 0 && (sbi / di & 0x1) == 0) { return toChars(sbi, e); } return toChars(sbi + di, e); } } throw new AssertionError("unreachable code"); } private String fullSubcaseS(int qb, long cb, long cb_r) { long m = pow5[H - e]; long vb = cb * m; long vbl = vb - m; long vbr = cb_r * m; int p = e - H - qb; long sbH = vb >> p; for (int g = H - G; g >= 0; --g) { long di = pow10(g); long sbi = sbH - sbH % di; long ubi = sbi << p; long wbi = sbi + di << p; boolean uin = vbl + lout <= ubi; boolean win = wbi + rout <= vbr; if (uin & !win) { return toChars(sbi, e); } if (!uin & win) { return toChars(sbi + di, e); } if (uin) { int cmp = (int) (2 * vb - ubi - wbi); if (cmp < 0 || cmp == 0 && (sbi / di & 0x1) == 0) { return toChars(sbi, e); } return toChars(sbi + di, e); } } throw new AssertionError("unreachable code"); } private String fullCaseM(int qb, long cb, long cb_r) { long m = pow5[H - e] << H - e + qb; long vb = cb * m; long vbl = vb - m; long vbr = cb_r * m; for (int g = H - G; g > 0; --g) { long di = pow10(g); long sbi = vb - vb % di; long tbi = sbi + di; boolean uin = vbl + lout <= sbi; boolean win = tbi + rout <= vbr; if (uin & !win) { return toChars(sbi, e); } if (!uin & win) { return toChars(tbi, e); } if (uin) { int cmp = (int) (2 * vb - sbi - tbi); if (cmp < 0 || cmp == 0 && (vb / di & 0x1) == 0) { return toChars(sbi, e); } return toChars(tbi, e); } } /* The loop didn't produce a shorter result. The full sb_H = s_H = vb is needed. This is done outside the loop, as there's no need to check tb_H = t_H as well. */ return toChars(vb, e); } private String fullSubcaseL(int qb, long cb, long cb_r) { int p = H - e + qb; long vb = cb << p; long vbl = cb - 1 << p; long vbr = cb_r << p; long m = pow5[e - H]; long sbH = vb / m; for (int g = H - G; g >= 0; --g) { long di = pow10(g); long sbi = sbH - sbH % di; long ubi = sbi * m; long wbi = ubi + (pow5[e - H + g] << g); boolean uin = vbl + lout <= ubi; boolean win = wbi + rout <= vbr; if (uin & !win) { return toChars(sbi, e); } if (!uin & win) { return toChars(sbi + di, e); } if (uin) { int cmp = (int) (2 * vb - ubi - wbi); if (cmp < 0 || cmp == 0 && (sbi / di & 0x1) == 0) { return toChars(sbi, e); } return toChars(sbi + di, e); } } throw new AssertionError("unreachable code"); } private String fullCaseXL(int qb, long cb, long cb_r) { int p = H - e + qb; Natural vb = valueOfShiftLeft(cb, p); Natural vbl = valueOfShiftLeft(cb - 1, p); Natural vbr = valueOfShiftLeft(cb_r, p); Natural m = pow5(e - H); long sbH = vb.divide(m); for (int g = H - G; g >= 0; --g) { long di = pow10(g); long sbi = sbH - sbH % di; Natural ubi = m.multiply(sbi); Natural wbi = ubi.addShiftLeft(pow5(e - H + g), g); boolean uin = vbl.compareTo(ubi) + lout <= 0; boolean win = wbi.compareTo(vbr) + rout <= 0; if (uin & !win) { return toChars(sbi, e); } if (!uin & win) { return toChars(sbi + di, e); } if (uin) { int cmp = vb.closerTo(ubi, wbi); if (cmp < 0 || cmp == 0 && (sbi / di & 0x1) == 0) { return toChars(sbi, e); } return toChars(sbi + di, e); } } throw new AssertionError("unreachable code"); } /* A faster version that succeeds in about 99.5% of the cases. It must be invoked only on values greater than MIN_NORMAL. When it fails, it resorts to the full() version. */ private String reduced() { int p = -P - q - pow10r(H - e); long t = floorPow10d(H - e); long cb = c << D; long vh = multiplyHighUnsigned(cb, t); long cbl = cb - (1L << D - (c != Double.C_MIN ? 1 : 2)); long vhl = multiplyHighUnsigned(cbl, t); long cbr = cb + (1L << D - 1); long vhr = multiplyHighUnsigned(cbr, t); long shH = vh >>> p; long vhu = vh + 2; for (int g = H - G; g >= 0; --g) { long di = pow10(g); long uhi = shH - shH % di << p; long whi = uhi + (di << p); boolean uin = uhi - vhl >= 2; boolean wout = whi - vhr >= 2; if (uin & wout) { return toChars(uhi >>> p, e); } boolean uout = uhi - vhl - lout < 0; boolean win = whi - vhr + rout <= 0; if (uout & win) { return toChars(whi >>> p, e); } if (uin & win) { if (vhu - uhi <= whi - vhu) { return toChars(uhi >>> p, e); } if (whi - vh < vh - uhi) { return toChars(whi >>> p, e); } return full(); } if (!uout & !uin | !wout) { return full(); } } throw new AssertionError("unreachable code"); } /* Limited usage, but does magic during JIT compilation. Note that 0 <= g <= 2 = H - G when invoked, so the default branch is never taken. */ private long pow10(int g) { switch (g) { case 0: return 1; case 1: return 10; case 2: return 100; default: return 0; } } /* f comes from integer(), from full() or from reduced(). In the former case 10^8 <= f < 10^9 and the method formats the number (f * 10^8) * 10^(e-H). Otherwise 10^(H-1) <= f <= 10^H and the method formats the number f * 10^(e-H) Division is avoided, where possible, by replacing it with multiplications and shifts. This makes a noticeable difference in performance, in particular when generating the digits of the exponent. For more in-depth readings, see for example Moeller N, Granlund T, "Improved division by invariant integers" ridiculous_fish, "Labor of Division (Episode III): Faster Unsigned Division by Constants" Also, once the quotient is known, the remainder is computed indirectly. */ private String toChars(long f, int e) { int h; // the 1 most significant int m; // the next 8 most significant digits int l; // the 8 least significant digits if (f != MAX_SIGNIFICAND) { long hm; if (f < 1_000_000_000L) { hm = f; l = 0; } else { hm = f / 100_000_000L; l = (int) (f - 100_000_000L * hm); } h = (int) (hm * 1_441_151_881L >>> 57); // h = hm / 100_000_000 m = (int) (hm - 100_000_000 * h); } else { // This might happen for doubles close or equal to powers of 10 h = 1; m = l = 0; e += 1; } /* The left-to-right digits generation in toChars_* is inspired by Bouvier C, Zimmermann P, "Division-Free Binary-to-Decimal Conversion" */ if (0 < e && e <= 7) { return toChars_1(h, m, l, e); } if (-3 < e && e <= 0) { return toChars_2(h, m, l, e); } return toChars_3(h, m, l, e); } private String toChars_1(int h, int m, int l, int e) { // 0 < e <= 7 appendDigit(h); int y = (int) (((long) (m + 1) << LTR) / 100_000_000L) - 1; int t; int i = 1; for (; i < e; ++i) { t = 10 * y; appendDigit(t >>> LTR); y = t & MASK_LTR; } append('.'); for (; i <= 8; ++i) { t = 10 * y; appendDigit(t >>> LTR); y = t & MASK_LTR; } lowDigits(l); return charsToString(); } private String toChars_2(int h, int m, int l, int e) { // -3 < e <= 0 appendDigit(0); append('.'); for (; e < 0; ++e) { appendDigit(0); } appendDigit(h); append8Digits(m); lowDigits(l); return charsToString(); } private String toChars_3(int h, int m, int l, int e) { // computerized scientific notation appendDigit(h); append('.'); append8Digits(m); lowDigits(l); exponent(e - 1); return charsToString(); } private void lowDigits(int l) { if (l != 0) { append8Digits(l); } removeTrailingZeroes(); } private void append8Digits(int v) { int y = (int) (((long) (v + 1) << LTR) / 100_000_000L) - 1; for (int i = 0; i < 8; ++i) { int t = 10 * y; appendDigit(t >>> LTR); y = t & MASK_LTR; } } private void removeTrailingZeroes() { while (buf[index] == '0') { --index; } if (buf[index] == '.') { ++index; } } private void exponent(int e) { append('E'); if (e < 0) { append('-'); e = -e; } if (e < 10) { appendDigit(e); } else if (e < 100) { int d = e * 205 >>> 11; // d = e / 10 appendDigit(d); appendDigit(e - 10 * d); } else { int d = e * 1_311 >>> 17; // d = e / 100 appendDigit(d); e -= 100 * d; d = e * 205 >>> 11; // d = e / 10 appendDigit(d); appendDigit(e - 10 * d); } } private void append(int c) { buf[++index] = (char) c; } private void appendDigit(int d) { buf[++index] = (char) ('0' + d); } private String charsToString() { return new String(buf, 0, index + 1); } } -------- math.DecimalChecker.java /* * Copyright (c) 2018, Raffaello Giulietti. 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. * This particular file is subject to the "Classpath" exception as provided * 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. */ package math; import java.io.IOException; import java.io.StringReader; import java.math.BigDecimal; class DecimalChecker { /* Returns whether s syntactically meets the expected output of Double.toString(double). It is restricted to finite positive outputs. It is an unusually long method but rather straightforward, too. Many conditionals could be merged, but KISS here. */ private static boolean hasCorrectFormat(String s) { try { // first determine interesting boundaries in the string StringReader r = new StringReader(s); int c = r.read(); int i = 0; while (c == '0') { ++i; c = r.read(); } // i is just after zeroes starting the integer int d = i; while ('0' <= c && c <= '9') { ++d; c = r.read(); } // d is just after digits ending the integer int fz = d; if (c == '.') { ++fz; c = r.read(); } // fz is just after a decimal '.' int f = fz; while (c == '0') { ++f; c = r.read(); } // f is just after zeroes starting the fraction int x = f; while ('0' <= c && c <= '9') { ++x; c = r.read(); } // x is just after digits ending the fraction int g = x; if (c == 'E') { ++g; c = r.read(); } // g is just after an exponent indicator 'E' int ez = g; if (c == '-') { ++ez; c = r.read(); } // ez is just after a '-' sign in the exponent int e = ez; while (c == '0') { ++e; c = r.read(); } // e is just after zeroes starting the exponent int z = e; while ('0' <= c && c <= '9') { ++z; c = r.read(); } // z is just after digits ending the exponent // No other chars after the number if (z != s.length()) { return false; } // The integer must be present if (d == 0) { return false; } // The decimal '.' must be present if (fz == d) { return false; } // The fraction must be present if (x == fz) { return false; } // Plain notation, no exponent if (x == z) { // At most one 0 starting the integer if (i > 1) { return false; } // The integer cannot have more than 7 digits if (d > 7) { return false; } // If the integer is 0, at most 2 zeroes start the fraction if (i == 1 && f - fz > 2) { return false; } // OK for plain notation return true; } // Computerized scientific notation // The integer has exactly one nonzero digit if (i != 0 || d != 1) { return false; } // There must be an exponent indicator if (x == g) { return false; } // There must be an exponent if (ez == z) { return false; } // The exponent must not start with zeroes if (ez != e) { return false; } int exp; // The exponent must parse as an int try { exp = Integer.parseInt(s, g, z, 10); } catch (NumberFormatException ex) { return false; } // The exponent must not lie in [-3, 7) if (-3 <= exp && exp < 7) { return false; } // OK for computerized scientific notation return true; } catch (IOException ex) { // An IOException on a StringReader??? Please... return false; } } /* And KISS even here. */ static boolean isCorrect(double v, String s) { if (v != v) { return s.equals("NaN"); } if (Double.doubleToRawLongBits(v) < 0) { if (s.isEmpty() || s.charAt(0) != '-') { return false; } return isCorrect(-v, s.substring(1)); } if (v == Double.POSITIVE_INFINITY) { return s.equals("Infinity"); } if (v == 0) { return s.equals("0.0"); } if (!hasCorrectFormat(s)) { return false; } // s must of course recover v try { if (v != Double.parseDouble(s)) { return false; } } catch (NumberFormatException e) { return false; } // b = d * 10^r for some integers d, r with d > 0 BigDecimal b = new BigDecimal(s); // d > 0 has at most 17 digits, so must fit in a positive long if (b.unscaledValue().bitLength() >= Long.SIZE) { return false; } long d = b.unscaledValue().longValue(); if (d >= 100_000_000_000_000_000L) { return false; } int r = -b.scale(); // Determine the number of digits in d int len2 = Long.SIZE - Long.numberOfLeadingZeros(d); int len10 = MathUtils.ord10pow2(len2) - 1; if (d >= Powers.pow10[len10]) { len10 += 1; } // ord10 is such that 10^(ord10-1) <= v < 10^ord10 int ord10 = r + len10; // Plain format iff -3 < ord10 <= 7 boolean isPlain = -3 < ord10 && ord10 <= 7; // If plain then len10 > ord10, i.e., r < 0 if (isPlain && r >= 0) { return false; } // If plain, trailing zero in fraction only if r = -1 if (isPlain && d % 10 == 0 && r < -1) { return false; } // If not plain, trailing zero in fraction only if len10 = 2 if (!isPlain && d % 10 == 0 && len10 > 2) { return false; } // Get rid of trailing zeroes while (d % 10 == 0) { d /= 10; r += 1; len10 -= 1; } if (len10 > 1) { // Try with a shorter number less than v long dsd = d / 10; int rsd = r + 1; BigDecimal bsd = BigDecimal.valueOf(dsd, -rsd); if (dsd >= 10 && bsd.doubleValue() == v) { return false; } // ... and with a shorter number greater than v long dsu = d / 10 + 1; int rsu = r + 1; BigDecimal bsu = BigDecimal.valueOf(dsu, -rsu); if (dsu > 10 && bsu.doubleValue() == v) { return false; } } BigDecimal bv = new BigDecimal(v); BigDecimal deltav = b.subtract(bv).abs(); // Check if the decimal predecessor is closer long dsp = d - 1; BigDecimal bsp = BigDecimal.valueOf(dsp, -r); int cmpp = 1; if (bsp.doubleValue() == v) { BigDecimal deltap = bsp.subtract(bv).abs(); cmpp = deltap.compareTo(deltav); if (cmpp < 0) { return false; } } // Check if the decimal successor is closer long dss = d + 1; BigDecimal bss = BigDecimal.valueOf(dss, -r); int cmps = 1; if (bss.doubleValue() == v) { BigDecimal deltas = bss.subtract(bv).abs(); cmps = deltas.compareTo(deltav); if (cmps < 0) { return false; } } if (cmpp == 0 && (d & 0x1) != 0) { return false; } if (cmps == 0 && (d & 0x1) != 0) { return false; } return true; } } -------- math.DoubleToDecimalTest.java /* * Copyright (c) 2018, Raffaello Giulietti. 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. * This particular file is subject to the "Classpath" exception as provided * 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. */ package math; import org.junit.Test; import java.util.Random; import static java.lang.Math.scalb; import static junit.framework.TestCase.*; import static math.DecimalChecker.isCorrect; import static math.DoubleToDecimal.Double.E_MAX_VALUE; import static math.DoubleToDecimal.Double.E_MIN_VALUE; public class DoubleToDecimalTest { private String toDecimal(double v) { String s = DoubleToDecimal.toString(v); assertTrue(isCorrect(v, s)); return s; } @Test public void testExtremeValues() { toDecimal(Double.NEGATIVE_INFINITY); toDecimal(-Double.MAX_VALUE); toDecimal(-Double.MIN_NORMAL); toDecimal(-Double.MIN_VALUE); toDecimal(-0.0); toDecimal(0.0); toDecimal(Double.MIN_VALUE); toDecimal(Double.MIN_NORMAL); toDecimal(Double.MAX_VALUE); toDecimal(Double.POSITIVE_INFINITY); toDecimal(Double.NaN); } /* A few powers of 10 are incorrectly rendered by the JDK. The rendering is either too long or it is not the closest decimal. */ @Test public void testPowersOf10() { for (int e = E_MIN_VALUE; e <= E_MAX_VALUE; ++e) { toDecimal(Double.parseDouble("1e" + e)); } } /* Many powers of 2 are incorrectly rendered by the JDK. The rendering is either too long or it is not the closest decimal. */ @Test public void testPowersOf2() { for (double v = Double.MIN_VALUE; v <= Double.MAX_VALUE; v *= 2.0) { toDecimal(v); } } /* There are tons of doubles that are rendered incorrectly by the JDK. While the renderings correctly round back to the original value, they are longer than needed or are not the closest decimal to the double. Here are just a very few examples. */ private static final String[] Anomalies = { // JDK renders these, and others, with 18 digits! "2.82879384806159E17", "1.387364135037754E18", "1.45800632428665E17", // JDK renders these longer than needed. "1.6E-322", "6.3E-322", "7.3879E20", "2.0E23", "7.0E22", "9.2E22", "9.5E21", "3.1E22", "5.63E21", "8.41E21", // JDK does not render these, and many others, as the closest. "9.9E-324", "9.9E-323", "1.9400994884341945E25", "3.6131332396758635E25", "2.5138990223946153E25", }; @Test public void testSomeAnomalies() { for (String dec : Anomalies) { toDecimal(Double.parseDouble(dec)); } } /* Values are from Paxson V, "A Program for Testing IEEE Decimal?Binary Conversion" */ private static final double[] PaxsonSignificands = { 8_511_030_020_275_656L, 5_201_988_407_066_741L, 6_406_892_948_269_899L, 8_431_154_198_732_492L, 6_475_049_196_144_587L, 8_274_307_542_972_842L, 5_381_065_484_265_332L, 6_761_728_585_499_734L, 7_976_538_478_610_756L, 5_982_403_858_958_067L, 5_536_995_190_630_837L, 7_225_450_889_282_194L, 7_225_450_889_282_194L, 8_703_372_741_147_379L, 8_944_262_675_275_217L, 7_459_803_696_087_692L, 6_080_469_016_670_379L, 8_385_515_147_034_757L, 7_514_216_811_389_786L, 8_397_297_803_260_511L, 6_733_459_239_310_543L, 8_091_450_587_292_794L, 6_567_258_882_077_402L, 6_712_731_423_444_934L, 6_712_731_423_444_934L, 5_298_405_411_573_037L, 5_137_311_167_659_507L, 6_722_280_709_661_868L, 5_344_436_398_034_927L, 8_369_123_604_277_281L, 8_995_822_108_487_663L, 8_942_832_835_564_782L, 8_942_832_835_564_782L, 8_942_832_835_564_782L, 6_965_949_469_487_146L, 6_965_949_469_487_146L, 6_965_949_469_487_146L, 7_487_252_720_986_826L, 5_592_117_679_628_511L, 8_887_055_249_355_788L, 6_994_187_472_632_449L, 8_797_576_579_012_143L, 7_363_326_733_505_337L, 8_549_497_411_294_502L, }; private static final int[] PaxsonExponents = { -342, -824, 237, 72, 99, 726, -456, -57, 376, 377, 93, 710, 709, 117, -1, -707, -381, 721, -828, -345, 202, -473, 952, 535, 534, -957, -144, 363, -169, -853, -780, -383, -384, -385, -249, -250, -251, 548, 164, 665, 690, 588, 272, -448, }; @Test public void testPaxson() { for (int i = 0; i < PaxsonSignificands.length; ++i) { toDecimal(scalb(PaxsonSignificands[i], PaxsonExponents[i])); } } /* Tests all integers of the form yx_xxx_000_000_000_000_000, y != 0. These are all exact doubles. */ @Test public void testLongs() { for (int i = 10_000; i < 100_000; ++i) { String s = toDecimal(i * 1e15); String xp = Integer.toString(i); int j = 5; while (--j >= 2 && xp.charAt(j) == '0') ; // empty body intended xp = xp.substring(0, 1) + "." + xp.substring(1, j + 1) + "E19"; assertEquals(xp, s); } } /* Tests all integers up to 100_000. These are all exact doubles. */ @Test public void testInts() { for (int i = -100_000; i <= 100_000; ++i) { String s = toDecimal(i); String xp = Integer.toString(i) + ".0"; assertEquals(xp, s); } } /* Random doubles over the whole range */ @Test public void testRandom() { Random r = new Random(); for (int i = 0; i < 10_000; ++i) { toDecimal(Double.longBitsToDouble(r.nextLong())); } } /* Random doubles over the integer range [0, 10^15). These integers are all exact doubles. */ @Test public void testRandomUnit() { Random r = new Random(); for (int i = 0; i < 10_000; ++i) { toDecimal(r.nextLong() % 1_000_000_000_000_000L); } } /* Random doubles over the range [0, 10^15) as "multiples" of 1e-3 */ @Test public void testRandomMilli() { Random r = new Random(); for (int i = 0; i < 10_000; ++i) { toDecimal(r.nextLong() % 1_000_000_000_000_000_000L / 1e3); } } /* Random doubles over the range [0, 10^15) as "multiples" of 1e-6 */ @Test public void testRandomMicro() { Random r = new Random(); for (int i = 0; i < 10_000; ++i) { toDecimal(r.nextLong() / 1e6); } } } -------- math.D2DBenchmark.java /* * Copyright (c) 2018, Raffaello Giulietti. 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. * This particular file is subject to the "Classpath" exception as provided * 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. */ package math; import java.text.DecimalFormat; import java.util.Random; /* Some simple benchmarks to evaluate speeds. */ public class D2DBenchmark { private static final int N = 100_000_000; private static final double[] x = new double[N]; private static final DecimalFormat intFormat = new DecimalFormat("#,##0"); private static final DecimalFormat doubleFormat = new DecimalFormat("#,##0.000"); private static final int RUNS_PER_LIB = 3; private static Random r; private static long d2dNs; private static long jdkNs; public static void main(String[] args) { if (args.length == 0) { System.out.println("arguments"); System.out.println(" [ ]"); System.out.println(); } Long seed = args.length > 0 ? Long.parseLong(args[0]) : null; r = seed != null ? new Random(seed) : new Random(); micro(); milli(); integers(); nonNaNRange(); } private static void benchmark() { d2dNs = jdkNs = 0; for (int i = 1; i <= RUNS_PER_LIB; ++i) { benchmarkD2d(i); } for (int i = 1; i <= RUNS_PER_LIB; ++i) { benchmarkJdk(i); } printSpeedup(); } private static void micro() { prepareMicro(); benchmark(); } private static void milli() { prepareMilli(); benchmark(); } private static void integers() { prepareIntegers(); benchmark(); } private static void nonNaNRange() { prepareNonNaNDoubles(); benchmark(); } private static void prepareIntegers() { System.out.print("generating " + intFormat.format(x.length) + " integer random doubles... "); System.out.flush(); for (int i = 0; i < x.length; ++i) { x[i] = r.nextInt(); } System.out.println("finished"); } private static void prepareMilli() { System.out.print("generating " + intFormat.format(x.length) + " \"milli\" random doubles... "); System.out.flush(); for (int i = 0; i < x.length; ++i) { x[i] = r.nextInt() / 1e3; } System.out.println("finished"); } private static void prepareMicro() { System.out.print("generating " + intFormat.format(x.length) + " \"micro\" random doubles... "); System.out.flush(); for (int i = 0; i < x.length; ++i) { x[i] = r.nextInt() / 1e6; } System.out.println("finished"); } private static void prepareNonNaNDoubles() { System.out.print("generating " + intFormat.format(x.length) + " non NaN random doubles... "); System.out.flush(); int i = 0; while (i < x.length) { double v = Double.longBitsToDouble(r.nextLong()); if (v == v) { x[i++] = v; } } System.out.println("finished"); } private static void benchmarkJdk(int take) { long tot = 0; long begin = System.nanoTime(); for (double v : x) { tot += Double.toString(v).length(); } long ns = System.nanoTime() - begin; jdkNs += ns; print("java.lang.Double",take, ns, tot); } private static void benchmarkD2d(int take) { long tot = 0; long begin = System.nanoTime(); for (double v : x) { tot += DoubleToDecimal.toString(v).length(); } long ns = System.nanoTime() - begin; d2dNs += ns; print("math.DoubleToDecimal", take, ns, tot); } private static void print(String lib, int take, long ns, long tot) { System.out.println(lib + "[" + take + "/" + RUNS_PER_LIB + "]"); System.out.println("--------"); System.out.println("n=" + intFormat.format(x.length)); System.out.println("elapsed=" + intFormat.format(ns) + " ns"); System.out.println(intFormat.format(ns / x.length) + " ns/rendering"); System.out.println("total length of output=" + intFormat.format(tot)); System.out.println(); } private static void printSpeedup() { System.out.println("speedup factor=" + doubleFormat.format((double) jdkNs / (double) d2dNs)); System.out.println(); } } From claes.redestad at oracle.com Fri Apr 20 14:07:58 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 20 Apr 2018 16:07:58 +0200 Subject: RFR: 6805750: Improve handling of Attributes.Name Message-ID: <1f11a0c0-66bb-2ceb-f420-faab6a5de5cf@oracle.com> Hi, please review this patch to address some of the legacy performance concerns arising when dealing extensively with java.util.jar.Attributes.Name (mainly when parsing jar Webrev: http://cr.openjdk.java.net/~redestad/6805750/open.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-6805750 While also picking up a few of the micro-optimizations suggested (eagerly calculate the hashCode since it will always be used), the main approach is to set up a small map of commonly used manifest attributes, including but not limited to (non-deprecated) ones declared as constants of Attributes.Name. For known strings, this can see speed-ups of ~10x of Attributes.putValue(String, String) and 25x on Attributes.get(String), while reducing the footprint of typical Manifest objects[1]. I've also done a few experiments with a concurrent and dynamic backing storage[2][3], each of which have some elegant properties (mainly getting similar benefits on arbitrary attributes), but adding too much complexity to improve performance of uncommon attributes while slightly reducing the efficiency for common ones doesn't really seem worthwhile. Thanks! /Claes [1] http://cr.openjdk.java.net/~redestad/6805750/Attributes.java [2] http://cr.openjdk.java.net/~redestad/6805750/open.00/ -- reuse MethodType$ConcurrentWeakInternSet. Nice to reuse some code, but only gets a 2.5x improvement since we can't avoid allocation. [3] http://cr.openjdk.java.net/~redestad/6805750/open.01/ -- create a custom interning map from String to WeakEntry: ~15x get and ~8x putValue perf for any repeatedly used attribute name. From aleksej.efimov at oracle.com Fri Apr 20 16:40:44 2018 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Fri, 20 Apr 2018 17:40:44 +0100 Subject: [jdk8u-dev] RFR: 8196491: Newlines in JAXB string values of SOAP-requests are escaped to " " Message-ID: <482f1e92-9734-8d31-b98f-37ac30b804c3@oracle.com> Hello, Would you, please, review the fix for JAXWS regression bug [1] that has been introduced by a fix that tried to preserve whitespaces in WS parameters [2]. The proposed fix addresses the reported UnsupportedOperationException and brings the JDK7 and JDK8 in-sync in terms of white-space processing: http://cr.openjdk.java.net/~aefimov/8196491/8/00 The fix has been integrated already into JAXWS/B-RI projects [3][4]. Regression and JCK tests showed no failures with the fix. With Best Regards, Aleksei [1] JBS bug: https://bugs.openjdk.java.net/browse/JDK-8196491 [2] Fix caused regression: https://bugs.openjdk.java.net/browse/JDK-8172297 [3] JAXWS-RI fix: https://github.com/javaee/metro-jax-ws/commit/5a06cb2d0b5ef884cc87ef431e7add458322aab8 [4] JAXB-RI fix: https://github.com/javaee/jaxb-v2/commit/8f1e74a7d3439d7f4c3f07689337c00d9e915628 From lance.andersen at oracle.com Fri Apr 20 17:15:24 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 20 Apr 2018 13:15:24 -0400 Subject: [jdk8u-dev] RFR: 8196491: Newlines in JAXB string values of SOAP-requests are escaped to " " In-Reply-To: <482f1e92-9734-8d31-b98f-37ac30b804c3@oracle.com> References: <482f1e92-9734-8d31-b98f-37ac30b804c3@oracle.com> Message-ID: <312A2EE0-1603-4C1A-9544-591365FE48F6@oracle.com> The changes look OK Aleks Best Lance > On Apr 20, 2018, at 12:40 PM, Aleks Efimov wrote: > > Hello, > > Would you, please, review the fix for JAXWS regression bug [1] that has been introduced by a fix that tried to preserve whitespaces in WS parameters [2]. > The proposed fix addresses the reported UnsupportedOperationException and brings the JDK7 and JDK8 in-sync in terms of white-space processing: > http://cr.openjdk.java.net/~aefimov/8196491/8/00 > > The fix has been integrated already into JAXWS/B-RI projects [3][4]. Regression and JCK tests showed no failures with the fix. > > With Best Regards, > Aleksei > > [1] JBS bug: https://bugs.openjdk.java.net/browse/JDK-8196491 > [2] Fix caused regression: https://bugs.openjdk.java.net/browse/JDK-8172297 > [3] JAXWS-RI fix: https://github.com/javaee/metro-jax-ws/commit/5a06cb2d0b5ef884cc87ef431e7add458322aab8 > [4] JAXB-RI fix: https://github.com/javaee/jaxb-v2/commit/8f1e74a7d3439d7f4c3f07689337c00d9e915628 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 Apr 20 17:41:12 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 20 Apr 2018 10:41:12 -0700 Subject: RFR: 6805750: Improve handling of Attributes.Name In-Reply-To: <1f11a0c0-66bb-2ceb-f420-faab6a5de5cf@oracle.com> References: <1f11a0c0-66bb-2ceb-f420-faab6a5de5cf@oracle.com> Message-ID: <5ADA2638.5050405@oracle.com> Claes, It loogsk good. One minor nit is that the "hashCode" check in Name.equals() might not be really necessary, given in most/normal use scenario the "Name" is used as a key in Attributes.map, which is a LinkedHashMap. Arguably the hashcode should be check already during lookup. Agreed what you suggested in previously email regarding equalsIgnoreCase vs CASE_INSENSITIVE_ORDER. It appears equalsIgnoreCase() at least can take advantage of "intern()" and "length()" match. Thanks, Sherman On 04/20/2018 07:07 AM, Claes Redestad wrote: > Hi, > > please review this patch to address some of the legacy performance concerns arising when dealing > extensively with java.util.jar.Attributes.Name (mainly when parsing jar > > Webrev: http://cr.openjdk.java.net/~redestad/6805750/open.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-6805750 > > While also picking up a few of the micro-optimizations suggested (eagerly calculate the hashCode > since it will always be used), the main approach is to set up a small map of commonly used manifest > attributes, including but not limited to (non-deprecated) ones declared as constants of Attributes.Name. > > For known strings, this can see speed-ups of ~10x of Attributes.putValue(String, String) and 25x on > Attributes.get(String), while reducing the footprint of typical Manifest objects[1]. > > I've also done a few experiments with a concurrent and dynamic backing storage[2][3], each of which > have some elegant properties (mainly getting similar benefits on arbitrary attributes), but adding too > much complexity to improve performance of uncommon attributes while slightly reducing the efficiency > for common ones doesn't really seem worthwhile. > > Thanks! > > /Claes > > [1] http://cr.openjdk.java.net/~redestad/6805750/Attributes.java > [2] http://cr.openjdk.java.net/~redestad/6805750/open.00/ -- reuse > MethodType$ConcurrentWeakInternSet. Nice to reuse some code, but only gets a 2.5x improvement > since we can't avoid allocation. > [3] http://cr.openjdk.java.net/~redestad/6805750/open.01/ -- create a custom interning map from > String to WeakEntry: ~15x get and ~8x putValue perf for any repeatedly used attribute > name. From kumar.x.srinivasan at oracle.com Fri Apr 20 21:19:31 2018 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 20 Apr 2018 14:19:31 -0700 Subject: RFR: 8201259: Fix warning with VS2017 in jdk.pack Message-ID: <5ADA5963.6030903@oracle.com> Hello, Please review fix [1] for VS2017 to compile pack200 native header file, without warnings. Thanks Kumar [1] http://cr.openjdk.java.net/~ksrini/8201259/ From erik.joelsson at oracle.com Fri Apr 20 22:28:13 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 20 Apr 2018 15:28:13 -0700 Subject: RFR: 8201259: Fix warning with VS2017 in jdk.pack In-Reply-To: <5ADA5963.6030903@oracle.com> References: <5ADA5963.6030903@oracle.com> Message-ID: Looks good to me. /Erik On 2018-04-20 14:19, Kumar Srinivasan wrote: > Hello, > > Please review fix [1] for VS2017 to compile pack200 native header > file,? without warnings. > > Thanks > Kumar > > [1] http://cr.openjdk.java.net/~ksrini/8201259/ From claes.redestad at oracle.com Sun Apr 22 21:40:16 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 22 Apr 2018 23:40:16 +0200 Subject: RFR: 6805750: Improve handling of Attributes.Name In-Reply-To: <5ADA2638.5050405@oracle.com> References: <1f11a0c0-66bb-2ceb-f420-faab6a5de5cf@oracle.com> <5ADA2638.5050405@oracle.com> Message-ID: Hi, On 2018-04-20 19:41, Xueming Shen wrote: > Claes, > > It loogsk good. thanks! > > One minor nit is that the "hashCode" check in Name.equals() might not > be really > necessary, given in most/normal use scenario the "Name" is used as a > key in > Attributes.map, which is a LinkedHashMap. Arguably the hashcode should be > check already during lookup. Agreed; I hadn't analyzed that particular check and seems it costs more in well-behaved cased than it would ever save us in the presence of excessive hash collisions. I'll remove it before push. Thanks! /Claes From david.holmes at oracle.com Mon Apr 23 03:33:33 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 23 Apr 2018 13:33:33 +1000 Subject: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <1a27932d85304155b68beb81014298ad@sap.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <5be0f86df2834aa8a881206ba285011e@sap.com> <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> <1a27932d85304155b68beb81014298ad@sap.com> Message-ID: On 20/04/2018 8:03 PM, Lindenmaier, Goetz wrote: > Hi David, > > What about this: > java.lang.ArrayIndexOutOfBoundsException: Arraycopy source index -1 out-of-bounds for double[10]. > java.lang.ArrayIndexOutOfBoundsException: Arraycopy target index 10 out-of-bounds for object array[10]. > java.lang.ArrayIndexOutOfBoundsException: Negative length -19 in arraycopy from int[3] to int[9]. I still don't like the array type information - it's not relevant to the error IMHO. That aside, for the array copy cases I'd go for something like: arraycopy src index -1 out of bounds for double[10] arraycopy dest index -1 out of bounds for double[10] arraycopy end src index 11 out of bounds for double[10] arraycopy end dest index 11 out of bounds for double[10] arraycopy length -19 is negative In the final case the array lengths are not relevant. > I'll reply to the other points in a comprehensive mail when I know > how to put the message. I don't oppose additional useful information in exception messages, but if it not directly relevant it just makes the error message harder to decipher IMO. I also don't want to pay additional runtime costs just to make an exception message a little bit clearer. Thanks, David > Thanks, > Goetz. > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Freitag, 20. April 2018 09:25 >> To: Lindenmaier, Goetz ; hotspot-runtime- >> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; aarch64- >> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core-libs- >> dev Libs >> Subject: Re: RFR(M): 8201593: Print array length in >> ArrayIndexOutOfBoundsException. >> >> Hi Goetz, >> >> This is not a file by file review ... >> >> On 19/04/2018 10:24 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> New webrev: >>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ >>> >>> I admit my wording is not optimal. >> >> src/hotspot/share/oops/typeArrayKlass.cpp >> >> Sorry but this is still far too verbose for my tastes. The type of the >> array is not relevant. For the array copy its okay to indicate src or >> dst array. But the message should be clear and succinct not prose-like. >> Plus you have a lot of repetition in the ss.print statements when only >> one thing is changing. >> >> src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp >> >> I'm not seeing why the throw_index_out_of_bounds_exception should be >> tied to whether or not you have an array reference. Certainly I hate >> seeing the array ref being used as an implicit bool! >> >>> It's because I extracted this change from a bigger one. Our message reads >> like this: >>> Object [] oa1 = new Object[10] >>> oa1[12] >>> "ArrayIndexOutOfBoundsException while trying to load from index 12 of an >> object array with length 10, loaded from local variable 'oa1'" >>> ... which seems not optimal, either. But it mentions the type (object), the >> operation (load, store etc ...) and the variable name. >>> Naming the array is quite detailed if it is in a complex expression (like >> returned from a call). >>> I'll contribute more of this if appreciated, this is a first step. >> >> I've never thought this complexity was warranted. We've had a few RFE's >> of this nature over the years and they have been closed (not necessarily >> by me I should point out!). >> >>> Printing "index N is outside range [0, length-1]" is problematic >>> for length '0'. I followed the proposal by Roger: >>> "Index -1 out-of-bounds for length 10." >> >> You can easily special-case length 0. But Roger's proposal for >> consistency with existing messages make sense - not withstanding >> Andrew's dislike for the hyphens. >> >>> I removed the change to ArrayIndexOutOfBoundsException.java. >> >> That's good. >> >>> I extended the test to cover the exception thrown in arraycopy better >> >> The test seems somewhat excessive, and I now see it is because of the >> more elaborate error messages you have at SAP. But with only the index >> and the array length of interest here the test can be considerably smaller. >> >> The creation tests for ArrayIndexOutOfBoundsException don't seem >> relevant in this context either. This looks more TCK like. >> >> David >> ----- >> >>> and added the elementary type to the message text. This probably >>> needs improvement in the text, too. There are (currently) these cases: >>> >>> bject[] oa1 = new Object[10]; >>> Object[] oa2 = new Object[5]; >>> System.arraycopy(oa1, -17, oa2, 0, 5); >>> "while trying to copy from index -17 of an object array with length 10"); >>> System.arraycopy(oa1, 2, oa2, -18, 5); >>> "while trying to copy to index -18 of an object array with length 5"); >>> System.arraycopy(oa1, 2, oa2, 0, -19); >>> "while trying to copy a negative range -19 from an object array with length >> 10 to an object array with length 5"); >>> System.arraycopy(oa1, 8, oa2, 0, 5); >>> "while trying to copy from index 13 of an object array with length 10"); >>> System.arraycopy(oa1, 1, oa2, 0, 7); >>> "while trying to copy to index 7 of an object array with length 5"); >>> double[] ta1 = new double[10]; >>> double[] ta2 = new double[5]; >>> System.arraycopy(ta1, -17, ta2, 0, 5); >>> "while trying to copy from index -17 of a doubl array with length 10"); >>> System.arraycopy(ta1, 2, ta2, -18, 5); >>> "while trying to copy to index -18 of a double array with length 5"); >>> System.arraycopy(ta1, 2, ta2, 0, -19); >>> "while trying to copy a negative range -19 from a double array with length >> 10 to a double array with length 5"); >>> System.arraycopy(ta1, 8, ta2, 0, 5); >>> "while trying to copy from index 13 of a double array with length 10"); >>> System.arraycopy(ta1, 1, ta2, 0, 7); >>> "while trying to copy to index 7 of a double array with length 5"); >>> >>> Maybe it should say: >>> Arraycopy source index -1 out-of-bounds for double array of length 10. >>> Arraycopy target index 10 out-of-bounds for object array of length 10. >>> Negative range -19 when copying from an object array of length 10 to an >> object array of length 5. >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Mittwoch, 18. April 2018 10:55 >>>> To: Lindenmaier, Goetz ; hotspot-runtime- >>>> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; >> aarch64- >>>> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core- >> libs- >>>> dev Libs >>>> Subject: Re: RFR(M): 8201593: Print array length in >>>> ArrayIndexOutOfBoundsException. >>>> >>>> Adding core-libs-dev as you're changing >>>> java.lang.ArrayIndexOutOfBoundsException. >>>> >>>> I appreciate the intent here but I find the messages excessively >>>> verbose. The basic error is: >>>> >>>> index N is outside range [0, length-1] >>>> >>>> David >>>> >>>> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I would like to print a more verbose text on ArrayIndexOutOfBounds >>>> exception >>>>> that not only mentions the index, but also the length of the array >> accessed. >>>>> See the bug for documentation of the change of the message. >>>>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ >>>>> >>>>> @aarch/arm people: >>>>> I edited the aarch/arm files. Could you please verify this is correct? >>>>> I can not build on these platforms. >>>>> >>>>> The code on all the other platforms is tested with all the jtreg and jck >> tests >>>> etc. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> From roman.grigoriadi at oracle.com Mon Apr 23 04:18:51 2018 From: roman.grigoriadi at oracle.com (Roman Grigoriadi) Date: Mon, 23 Apr 2018 06:18:51 +0200 Subject: [jdk8u-dev] RFR: 8196491: Newlines in JAXB string values of SOAP-requests are escaped to " " In-Reply-To: <482f1e92-9734-8d31-b98f-37ac30b804c3@oracle.com> References: <482f1e92-9734-8d31-b98f-37ac30b804c3@oracle.com> Message-ID: <6E4D9DFD-0128-4EB2-A8EF-5E052CFC358D@oracle.com> Looks good to me. -Roman > On 20 Apr 2018, at 18:40, Aleks Efimov wrote: > > Hello, > > Would you, please, review the fix for JAXWS regression bug [1] that has been introduced by a fix that tried to preserve whitespaces in WS parameters [2]. > The proposed fix addresses the reported UnsupportedOperationException and brings the JDK7 and JDK8 in-sync in terms of white-space processing: > http://cr.openjdk.java.net/~aefimov/8196491/8/00 > > The fix has been integrated already into JAXWS/B-RI projects [3][4]. Regression and JCK tests showed no failures with the fix. > > With Best Regards, > Aleksei > > [1] JBS bug: https://bugs.openjdk.java.net/browse/JDK-8196491 > [2] Fix caused regression: https://bugs.openjdk.java.net/browse/JDK-8172297 > [3] JAXWS-RI fix: https://github.com/javaee/metro-jax-ws/commit/5a06cb2d0b5ef884cc87ef431e7add458322aab8 > [4] JAXB-RI fix: https://github.com/javaee/jaxb-v2/commit/8f1e74a7d3439d7f4c3f07689337c00d9e915628 From goetz.lindenmaier at sap.com Mon Apr 23 07:08:03 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 23 Apr 2018 07:08:03 +0000 Subject: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <5be0f86df2834aa8a881206ba285011e@sap.com> <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> <1a27932d85304155b68beb81014298ad@sap.com> Message-ID: <2dfac30b29f44974a72cb26d9dfb15fc@sap.com> Hi, > I still don't like the array type information - it's not relevant to the > error IMHO. > > That aside, for the array copy cases I'd go for something like: > > arraycopy src index -1 out of bounds for double[10] > arraycopy dest index -1 out of bounds for double[10] > arraycopy end src index 11 out of bounds for double[10] > arraycopy end dest index 11 out of bounds for double[10] It's a good idea to point out it's the end of the region to copy. But I would find "last src index" better to understand than "end src index": "last arraycopy src index 11 out of bounds for double[10]" > arraycopy length -19 is negative > > In the final case the array lengths are not relevant. I think they might help in case the length computation depends on the array lengths, which is quite likely the case. But I'll leave it out. > > I'll reply to the other points in a comprehensive mail when I know > > how to put the message. ... these all are not related to the wording of the message. > > I don't oppose additional useful information in exception messages, but > if it not directly relevant it just makes the error message harder to > decipher IMO. SAP JVM tries to give all information useful to track down the cause. In many situations the printed information might be superfluous, but in this one critical situation you will be very happy to have it. SAP builds 'real' software on Java, not just 100 line jtreg tests ... But the message should stay clear. Therefore I also don't like the 1-sentence rule you sometimes mention. Several sentences can give structure to distinguish root cause information and additional information. Not relevant here currently, though. > I also don't want to pay additional runtime costs just to > make an exception message a little bit clearer. Yes, especially it should not impose any cost on the case without exception. Best regards, Goetz. > Thanks, > David > > > Thanks, > > Goetz. > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Freitag, 20. April 2018 09:25 > >> To: Lindenmaier, Goetz ; hotspot-runtime- > >> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; > aarch64- > >> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core- > libs- > >> dev Libs > >> Subject: Re: RFR(M): 8201593: Print array length in > >> ArrayIndexOutOfBoundsException. > >> > >> Hi Goetz, > >> > >> This is not a file by file review ... > >> > >> On 19/04/2018 10:24 PM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> New webrev: > >>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ > >>> > >>> I admit my wording is not optimal. > >> > >> src/hotspot/share/oops/typeArrayKlass.cpp > >> > >> Sorry but this is still far too verbose for my tastes. The type of the > >> array is not relevant. For the array copy its okay to indicate src or > >> dst array. But the message should be clear and succinct not prose-like. > >> Plus you have a lot of repetition in the ss.print statements when only > >> one thing is changing. > >> > >> src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp > >> > >> I'm not seeing why the throw_index_out_of_bounds_exception should > be > >> tied to whether or not you have an array reference. Certainly I hate > >> seeing the array ref being used as an implicit bool! > >> > >>> It's because I extracted this change from a bigger one. Our message > reads > >> like this: > >>> Object [] oa1 = new Object[10] > >>> oa1[12] > >>> "ArrayIndexOutOfBoundsException while trying to load from index 12 of > an > >> object array with length 10, loaded from local variable 'oa1'" > >>> ... which seems not optimal, either. But it mentions the type (object), > the > >> operation (load, store etc ...) and the variable name. > >>> Naming the array is quite detailed if it is in a complex expression (like > >> returned from a call). > >>> I'll contribute more of this if appreciated, this is a first step. > >> > >> I've never thought this complexity was warranted. We've had a few RFE's > >> of this nature over the years and they have been closed (not necessarily > >> by me I should point out!). > >> > >>> Printing "index N is outside range [0, length-1]" is problematic > >>> for length '0'. I followed the proposal by Roger: > >>> "Index -1 out-of-bounds for length 10." > >> > >> You can easily special-case length 0. But Roger's proposal for > >> consistency with existing messages make sense - not withstanding > >> Andrew's dislike for the hyphens. > >> > >>> I removed the change to ArrayIndexOutOfBoundsException.java. > >> > >> That's good. > >> > >>> I extended the test to cover the exception thrown in arraycopy better > >> > >> The test seems somewhat excessive, and I now see it is because of the > >> more elaborate error messages you have at SAP. But with only the index > >> and the array length of interest here the test can be considerably smaller. > >> > >> The creation tests for ArrayIndexOutOfBoundsException don't seem > >> relevant in this context either. This looks more TCK like. > >> > >> David > >> ----- > >> > >>> and added the elementary type to the message text. This probably > >>> needs improvement in the text, too. There are (currently) these cases: > >>> > >>> bject[] oa1 = new Object[10]; > >>> Object[] oa2 = new Object[5]; > >>> System.arraycopy(oa1, -17, oa2, 0, 5); > >>> "while trying to copy from index -17 of an object array with length 10"); > >>> System.arraycopy(oa1, 2, oa2, -18, 5); > >>> "while trying to copy to index -18 of an object array with length 5"); > >>> System.arraycopy(oa1, 2, oa2, 0, -19); > >>> "while trying to copy a negative range -19 from an object array with > length > >> 10 to an object array with length 5"); > >>> System.arraycopy(oa1, 8, oa2, 0, 5); > >>> "while trying to copy from index 13 of an object array with length 10"); > >>> System.arraycopy(oa1, 1, oa2, 0, 7); > >>> "while trying to copy to index 7 of an object array with length 5"); > >>> double[] ta1 = new double[10]; > >>> double[] ta2 = new double[5]; > >>> System.arraycopy(ta1, -17, ta2, 0, 5); > >>> "while trying to copy from index -17 of a doubl array with length 10"); > >>> System.arraycopy(ta1, 2, ta2, -18, 5); > >>> "while trying to copy to index -18 of a double array with length 5"); > >>> System.arraycopy(ta1, 2, ta2, 0, -19); > >>> "while trying to copy a negative range -19 from a double array with > length > >> 10 to a double array with length 5"); > >>> System.arraycopy(ta1, 8, ta2, 0, 5); > >>> "while trying to copy from index 13 of a double array with length 10"); > >>> System.arraycopy(ta1, 1, ta2, 0, 7); > >>> "while trying to copy to index 7 of a double array with length 5"); > >>> > >>> Maybe it should say: > >>> Arraycopy source index -1 out-of-bounds for double array of length 10. > >>> Arraycopy target index 10 out-of-bounds for object array of length 10. > >>> Negative range -19 when copying from an object array of length 10 to an > >> object array of length 5. > >>> > >>> Best regards, > >>> Goetz. > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Mittwoch, 18. April 2018 10:55 > >>>> To: Lindenmaier, Goetz ; hotspot- > runtime- > >>>> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; > >> aarch64- > >>>> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; > core- > >> libs- > >>>> dev Libs > >>>> Subject: Re: RFR(M): 8201593: Print array length in > >>>> ArrayIndexOutOfBoundsException. > >>>> > >>>> Adding core-libs-dev as you're changing > >>>> java.lang.ArrayIndexOutOfBoundsException. > >>>> > >>>> I appreciate the intent here but I find the messages excessively > >>>> verbose. The basic error is: > >>>> > >>>> index N is outside range [0, length-1] > >>>> > >>>> David > >>>> > >>>> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: > >>>>> Hi, > >>>>> > >>>>> I would like to print a more verbose text on ArrayIndexOutOfBounds > >>>> exception > >>>>> that not only mentions the index, but also the length of the array > >> accessed. > >>>>> See the bug for documentation of the change of the message. > >>>>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ > >>>>> > >>>>> @aarch/arm people: > >>>>> I edited the aarch/arm files. Could you please verify this is correct? > >>>>> I can not build on these platforms. > >>>>> > >>>>> The code on all the other platforms is tested with all the jtreg and jck > >> tests > >>>> etc. > >>>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> From goetz.lindenmaier at sap.com Mon Apr 23 07:13:25 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 23 Apr 2018 07:13:25 +0000 Subject: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <5ADA0456.7080607@cjnash.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <5be0f86df2834aa8a881206ba285011e@sap.com> <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> <1a27932d85304155b68beb81014298ad@sap.com> <5ADA0456.7080607@cjnash.com> Message-ID: Hi Simon, I chose hyphens because they are used in other AIOOB messages, too. But others (including me) seem not to like them either, so I'll leave them out. Best regards, Goetz. > -----Original Message----- > From: Simon Nash [mailto:simon at cjnash.com] > Sent: Freitag, 20. April 2018 17:17 > To: Lindenmaier, Goetz > Cc: David Holmes ; hotspot-runtime- > dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; aarch64- > port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core-libs- > dev Libs > Subject: Re: RFR(M): 8201593: Print array length in > ArrayIndexOutOfBoundsException. > > Hi Goetz, > It should be "out of bounds" without hyphens. > > Simon > > On 20/04/2018 11:03, Lindenmaier, Goetz wrote: > > Hi David, > > > > What about this: > > java.lang.ArrayIndexOutOfBoundsException: Arraycopy source index -1 > out-of-bounds for double[10]. > > java.lang.ArrayIndexOutOfBoundsException: Arraycopy target index 10 > out-of-bounds for object array[10]. > > java.lang.ArrayIndexOutOfBoundsException: Negative length -19 in > arraycopy from int[3] to int[9]. > > > > I'll reply to the other points in a comprehensive mail when I know > > how to put the message. > > > > Thanks, > > Goetz. > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Freitag, 20. April 2018 09:25 > >> To: Lindenmaier, Goetz ; hotspot-runtime- > >> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; > aarch64- > >> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core- > libs- > >> dev Libs > >> Subject: Re: RFR(M): 8201593: Print array length in > >> ArrayIndexOutOfBoundsException. > >> > >> Hi Goetz, > >> > >> This is not a file by file review ... > >> > >> On 19/04/2018 10:24 PM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> New webrev: > >>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ > >>> > >>> I admit my wording is not optimal. > >> src/hotspot/share/oops/typeArrayKlass.cpp > >> > >> Sorry but this is still far too verbose for my tastes. The type of the > >> array is not relevant. For the array copy its okay to indicate src or > >> dst array. But the message should be clear and succinct not prose-like. > >> Plus you have a lot of repetition in the ss.print statements when only > >> one thing is changing. > >> > >> src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp > >> > >> I'm not seeing why the throw_index_out_of_bounds_exception should > be > >> tied to whether or not you have an array reference. Certainly I hate > >> seeing the array ref being used as an implicit bool! > >> > >>> It's because I extracted this change from a bigger one. Our message > reads > >> like this: > >>> Object [] oa1 = new Object[10] > >>> oa1[12] > >>> "ArrayIndexOutOfBoundsException while trying to load from index 12 of > an > >> object array with length 10, loaded from local variable 'oa1'" > >>> ... which seems not optimal, either. But it mentions the type (object), > the > >> operation (load, store etc ...) and the variable name. > >>> Naming the array is quite detailed if it is in a complex expression (like > >> returned from a call). > >>> I'll contribute more of this if appreciated, this is a first step. > >> I've never thought this complexity was warranted. We've had a few RFE's > >> of this nature over the years and they have been closed (not necessarily > >> by me I should point out!). > >> > >>> Printing "index N is outside range [0, length-1]" is problematic > >>> for length '0'. I followed the proposal by Roger: > >>> "Index -1 out-of-bounds for length 10." > >> You can easily special-case length 0. But Roger's proposal for > >> consistency with existing messages make sense - not withstanding > >> Andrew's dislike for the hyphens. > >> > >>> I removed the change to ArrayIndexOutOfBoundsException.java. > >> That's good. > >> > >>> I extended the test to cover the exception thrown in arraycopy better > >> The test seems somewhat excessive, and I now see it is because of the > >> more elaborate error messages you have at SAP. But with only the index > >> and the array length of interest here the test can be considerably smaller. > >> > >> The creation tests for ArrayIndexOutOfBoundsException don't seem > >> relevant in this context either. This looks more TCK like. > >> > >> David > >> ----- > >> > >>> and added the elementary type to the message text. This probably > >>> needs improvement in the text, too. There are (currently) these cases: > >>> > >>> bject[] oa1 = new Object[10]; > >>> Object[] oa2 = new Object[5]; > >>> System.arraycopy(oa1, -17, oa2, 0, 5); > >>> "while trying to copy from index -17 of an object array with length 10"); > >>> System.arraycopy(oa1, 2, oa2, -18, 5); > >>> "while trying to copy to index -18 of an object array with length 5"); > >>> System.arraycopy(oa1, 2, oa2, 0, -19); > >>> "while trying to copy a negative range -19 from an object array with > length > >> 10 to an object array with length 5"); > >>> System.arraycopy(oa1, 8, oa2, 0, 5); > >>> "while trying to copy from index 13 of an object array with length 10"); > >>> System.arraycopy(oa1, 1, oa2, 0, 7); > >>> "while trying to copy to index 7 of an object array with length 5"); > >>> double[] ta1 = new double[10]; > >>> double[] ta2 = new double[5]; > >>> System.arraycopy(ta1, -17, ta2, 0, 5); > >>> "while trying to copy from index -17 of a doubl array with length 10"); > >>> System.arraycopy(ta1, 2, ta2, -18, 5); > >>> "while trying to copy to index -18 of a double array with length 5"); > >>> System.arraycopy(ta1, 2, ta2, 0, -19); > >>> "while trying to copy a negative range -19 from a double array with > length > >> 10 to a double array with length 5"); > >>> System.arraycopy(ta1, 8, ta2, 0, 5); > >>> "while trying to copy from index 13 of a double array with length 10"); > >>> System.arraycopy(ta1, 1, ta2, 0, 7); > >>> "while trying to copy to index 7 of a double array with length 5"); > >>> > >>> Maybe it should say: > >>> Arraycopy source index -1 out-of-bounds for double array of length 10. > >>> Arraycopy target index 10 out-of-bounds for object array of length 10. > >>> Negative range -19 when copying from an object array of length 10 to an > >> object array of length 5. > >>> Best regards, > >>> Goetz. > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Mittwoch, 18. April 2018 10:55 > >>>> To: Lindenmaier, Goetz ; hotspot- > runtime- > >>>> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; > >> aarch64- > >>>> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; > core- > >> libs- > >>>> dev Libs > >>>> Subject: Re: RFR(M): 8201593: Print array length in > >>>> ArrayIndexOutOfBoundsException. > >>>> > >>>> Adding core-libs-dev as you're changing > >>>> java.lang.ArrayIndexOutOfBoundsException. > >>>> > >>>> I appreciate the intent here but I find the messages excessively > >>>> verbose. The basic error is: > >>>> > >>>> index N is outside range [0, length-1] > >>>> > >>>> David > >>>> > >>>> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: > >>>>> Hi, > >>>>> > >>>>> I would like to print a more verbose text on ArrayIndexOutOfBounds > >>>> exception > >>>>> that not only mentions the index, but also the length of the array > >> accessed. > >>>>> See the bug for documentation of the change of the message. > >>>>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ > >>>>> > >>>>> @aarch/arm people: > >>>>> I edited the aarch/arm files. Could you please verify this is correct? > >>>>> I can not build on these platforms. > >>>>> > >>>>> The code on all the other platforms is tested with all the jtreg and jck > >> tests > >>>> etc. > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> From david.holmes at oracle.com Mon Apr 23 07:14:09 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 23 Apr 2018 17:14:09 +1000 Subject: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <2dfac30b29f44974a72cb26d9dfb15fc@sap.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <5be0f86df2834aa8a881206ba285011e@sap.com> <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> <1a27932d85304155b68beb81014298ad@sap.com> <2dfac30b29f44974a72cb26d9dfb15fc@sap.com> Message-ID: <81c38514-e6a7-208c-6f82-5b342d087d42@oracle.com> On 23/04/2018 5:08 PM, Lindenmaier, Goetz wrote: > Hi, > >> I still don't like the array type information - it's not relevant to the >> error IMHO. >> >> That aside, for the array copy cases I'd go for something like: >> >> arraycopy src index -1 out of bounds for double[10] >> arraycopy dest index -1 out of bounds for double[10] >> arraycopy end src index 11 out of bounds for double[10] >> arraycopy end dest index 11 out of bounds for double[10] > It's a good idea to point out it's the end of the region to copy. > But I would find "last src index" better to understand than > "end src index": Sure - end/last/final whatever you prefer. > "last arraycopy src index 11 out of bounds for double[10]" I'd prefer to see "arraycopy" always come first to show clearly these are specific to arraycopy. Even "arraycopy: ...". >> arraycopy length -19 is negative >> >> In the final case the array lengths are not relevant. > I think they might help in case the length computation depends on the > array lengths, which is quite likely the case. But I'll leave it out. Happy to let others give opinions. David ----- >>> I'll reply to the other points in a comprehensive mail when I know >>> how to put the message. > ... these all are not related to the wording of the message. >> >> I don't oppose additional useful information in exception messages, but >> if it not directly relevant it just makes the error message harder to >> decipher IMO. > SAP JVM tries to give all information useful to track down the cause. > In many situations the printed information might be superfluous, but > in this one critical situation you will be very happy to have it. SAP builds > 'real' software on Java, not just 100 line jtreg tests ... > But the message should stay clear. Therefore I also don't like the > 1-sentence rule you sometimes mention. Several sentences can give > structure to distinguish root cause information and additional information. > Not relevant here currently, though. > >> I also don't want to pay additional runtime costs just to >> make an exception message a little bit clearer. > Yes, especially it should not impose any cost on the case without exception. > > Best regards, > Goetz. > > >> Thanks, >> David >> >>> Thanks, >>> Goetz. >>> >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Freitag, 20. April 2018 09:25 >>>> To: Lindenmaier, Goetz ; hotspot-runtime- >>>> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; >> aarch64- >>>> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core- >> libs- >>>> dev Libs >>>> Subject: Re: RFR(M): 8201593: Print array length in >>>> ArrayIndexOutOfBoundsException. >>>> >>>> Hi Goetz, >>>> >>>> This is not a file by file review ... >>>> >>>> On 19/04/2018 10:24 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> New webrev: >>>>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ >>>>> >>>>> I admit my wording is not optimal. >>>> >>>> src/hotspot/share/oops/typeArrayKlass.cpp >>>> >>>> Sorry but this is still far too verbose for my tastes. The type of the >>>> array is not relevant. For the array copy its okay to indicate src or >>>> dst array. But the message should be clear and succinct not prose-like. >>>> Plus you have a lot of repetition in the ss.print statements when only >>>> one thing is changing. >>>> >>>> src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp >>>> >>>> I'm not seeing why the throw_index_out_of_bounds_exception should >> be >>>> tied to whether or not you have an array reference. Certainly I hate >>>> seeing the array ref being used as an implicit bool! >>>> >>>>> It's because I extracted this change from a bigger one. Our message >> reads >>>> like this: >>>>> Object [] oa1 = new Object[10] >>>>> oa1[12] >>>>> "ArrayIndexOutOfBoundsException while trying to load from index 12 of >> an >>>> object array with length 10, loaded from local variable 'oa1'" >>>>> ... which seems not optimal, either. But it mentions the type (object), >> the >>>> operation (load, store etc ...) and the variable name. >>>>> Naming the array is quite detailed if it is in a complex expression (like >>>> returned from a call). >>>>> I'll contribute more of this if appreciated, this is a first step. >>>> >>>> I've never thought this complexity was warranted. We've had a few RFE's >>>> of this nature over the years and they have been closed (not necessarily >>>> by me I should point out!). >>>> >>>>> Printing "index N is outside range [0, length-1]" is problematic >>>>> for length '0'. I followed the proposal by Roger: >>>>> "Index -1 out-of-bounds for length 10." >>>> >>>> You can easily special-case length 0. But Roger's proposal for >>>> consistency with existing messages make sense - not withstanding >>>> Andrew's dislike for the hyphens. >>>> >>>>> I removed the change to ArrayIndexOutOfBoundsException.java. >>>> >>>> That's good. >>>> >>>>> I extended the test to cover the exception thrown in arraycopy better >>>> >>>> The test seems somewhat excessive, and I now see it is because of the >>>> more elaborate error messages you have at SAP. But with only the index >>>> and the array length of interest here the test can be considerably smaller. >>>> >>>> The creation tests for ArrayIndexOutOfBoundsException don't seem >>>> relevant in this context either. This looks more TCK like. >>>> >>>> David >>>> ----- >>>> >>>>> and added the elementary type to the message text. This probably >>>>> needs improvement in the text, too. There are (currently) these cases: >>>>> >>>>> bject[] oa1 = new Object[10]; >>>>> Object[] oa2 = new Object[5]; >>>>> System.arraycopy(oa1, -17, oa2, 0, 5); >>>>> "while trying to copy from index -17 of an object array with length 10"); >>>>> System.arraycopy(oa1, 2, oa2, -18, 5); >>>>> "while trying to copy to index -18 of an object array with length 5"); >>>>> System.arraycopy(oa1, 2, oa2, 0, -19); >>>>> "while trying to copy a negative range -19 from an object array with >> length >>>> 10 to an object array with length 5"); >>>>> System.arraycopy(oa1, 8, oa2, 0, 5); >>>>> "while trying to copy from index 13 of an object array with length 10"); >>>>> System.arraycopy(oa1, 1, oa2, 0, 7); >>>>> "while trying to copy to index 7 of an object array with length 5"); >>>>> double[] ta1 = new double[10]; >>>>> double[] ta2 = new double[5]; >>>>> System.arraycopy(ta1, -17, ta2, 0, 5); >>>>> "while trying to copy from index -17 of a doubl array with length 10"); >>>>> System.arraycopy(ta1, 2, ta2, -18, 5); >>>>> "while trying to copy to index -18 of a double array with length 5"); >>>>> System.arraycopy(ta1, 2, ta2, 0, -19); >>>>> "while trying to copy a negative range -19 from a double array with >> length >>>> 10 to a double array with length 5"); >>>>> System.arraycopy(ta1, 8, ta2, 0, 5); >>>>> "while trying to copy from index 13 of a double array with length 10"); >>>>> System.arraycopy(ta1, 1, ta2, 0, 7); >>>>> "while trying to copy to index 7 of a double array with length 5"); >>>>> >>>>> Maybe it should say: >>>>> Arraycopy source index -1 out-of-bounds for double array of length 10. >>>>> Arraycopy target index 10 out-of-bounds for object array of length 10. >>>>> Negative range -19 when copying from an object array of length 10 to an >>>> object array of length 5. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Mittwoch, 18. April 2018 10:55 >>>>>> To: Lindenmaier, Goetz ; hotspot- >> runtime- >>>>>> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; >>>> aarch64- >>>>>> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; >> core- >>>> libs- >>>>>> dev Libs >>>>>> Subject: Re: RFR(M): 8201593: Print array length in >>>>>> ArrayIndexOutOfBoundsException. >>>>>> >>>>>> Adding core-libs-dev as you're changing >>>>>> java.lang.ArrayIndexOutOfBoundsException. >>>>>> >>>>>> I appreciate the intent here but I find the messages excessively >>>>>> verbose. The basic error is: >>>>>> >>>>>> index N is outside range [0, length-1] >>>>>> >>>>>> David >>>>>> >>>>>> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I would like to print a more verbose text on ArrayIndexOutOfBounds >>>>>> exception >>>>>>> that not only mentions the index, but also the length of the array >>>> accessed. >>>>>>> See the bug for documentation of the change of the message. >>>>>>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ >>>>>>> >>>>>>> @aarch/arm people: >>>>>>> I edited the aarch/arm files. Could you please verify this is correct? >>>>>>> I can not build on these platforms. >>>>>>> >>>>>>> The code on all the other platforms is tested with all the jtreg and jck >>>> tests >>>>>> etc. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> From snazy at snazy.de Mon Apr 23 14:23:41 2018 From: snazy at snazy.de (Robert Stupp) Date: Mon, 23 Apr 2018 16:23:41 +0200 Subject: [PATCH] Prefer TMPDIR over hard coded /tmp Message-ID: <8fd54174-54be-243f-443d-598c430a4ea5@snazy.de> For MacOS and Windows, Java prefers the user's temporary directory for java.io.tmpdir, but not for Linux, where it is always set to /tmp. The burden with this is that if you want to use a different temp directory, you have to explicitly pass -Djava.io.tmpdir=... on the command line, which can be difficult especially for unit tests or microbenchmarks in 3rd party code ran via Maven for example. java_props_t.tmp_dir is always initialized as P_tmpdir in GetJavaProperties (src/java.base/unix/native/libjava/java_props_md.c). The attached patch changed the behavior to use the content of the environment variable TMPDIR, if present. Note that this does not change where the hsperf* folders are created. I'm not sure why java.io.tmpdir is always /tmp in Linux as according to the SCM history, this was always as it is (references the initial OpenJDK commit). I haven't found any tests that validates the content of java.io.tmpdir. Robert -- Robert Stupp @snazy -------------- next part -------------- # HG changeset patch # User Robert Stupp # Date 1524398509 -7200 # Sun Apr 22 14:01:49 2018 +0200 # Branch use-TMPDIR-env-Linux # Node ID 3f9f58a5d4049fcba8e5201e321bf71984430ce9 # Parent fcd5df7aa235ca39852b04eb589e25f156870ce4 Use TMPDIR environment variable for java.io.tmpdir on Linux diff --git a/src/java.base/unix/native/libjava/java_props_md.c b/src/java.base/unix/native/libjava/java_props_md.c --- a/src/java.base/unix/native/libjava/java_props_md.c +++ b/src/java.base/unix/native/libjava/java_props_md.c @@ -358,7 +358,7 @@ return &sprops; } - /* tmp dir */ + /* tmp dir, use the default from _PATH_VARTMP */ sprops.tmp_dir = P_tmpdir; #ifdef MACOSX /* darwin has a per-user temp dir */ @@ -367,6 +367,14 @@ if (pathSize > 0 && pathSize <= PATH_MAX) { sprops.tmp_dir = tmp_path; } +#else + /* Use the temporary directory injected via the environment variable TMPDIR + * instead of the "hard coded" _PATH_VARTMP + */ + v = getenv("TMPDIR"); + if (v) { + sprops.tmp_dir = strdup(v); + } #endif /* MACOSX */ /* Printing properties */ From snazy at snazy.de Mon Apr 23 14:23:48 2018 From: snazy at snazy.de (Robert Stupp) Date: Mon, 23 Apr 2018 16:23:48 +0200 Subject: [PATCH] Add compareToUnsigned to java.nio.*Buffer Message-ID: <1d3a26e2-6dbc-e90d-781b-f0f636547263@snazy.de> The proposed patch is an improvement for Byte/Short/Int/LongBuffer classes to add compareToUnsigned() that works like compareTo() but treats the values as unsigned to leverage the vectorized mismatch implementations, which are not publicly accessible. In addition to that, it adds mismatch() for all *Buffer classes. Both new methods basically expose all the goodness of jdk.internal.util.ArraysSupport to *Buffer. The patch includes adoptions to the existing unit tests as well. Robert -- Robert Stupp @snazy -------------- next part -------------- # HG changeset patch # User Robert Stupp # Date 1524399060 -7200 # Sun Apr 22 14:11:00 2018 +0200 # Branch buffer-compUns-mismatch # Node ID 06f0013900eba02b3136aa3bd72b3f981e3339df # Parent fcd5df7aa235ca39852b04eb589e25f156870ce4 Add unsigned comparison to *Buffer diff --git a/src/java.base/share/classes/java/nio/X-Buffer.java.template b/src/java.base/share/classes/java/nio/X-Buffer.java.template --- a/src/java.base/share/classes/java/nio/X-Buffer.java.template +++ b/src/java.base/share/classes/java/nio/X-Buffer.java.template @@ -1342,6 +1342,35 @@ return this.remaining() - that.remaining(); } +#if[!char] +#if[integralType] + /** + * Compares this buffer to another treating the values as unsigned. + * + *

      Two $type$ buffers are compared by comparing their sequences of + * remaining elements lexicographically, without regard to the starting + * position of each sequence within its corresponding buffer. + * Pairs of {@code $type$} elements are compared as if by invoking + * {@link $Fulltype$#compareUnsigned($type$,$type$)}. + * + *

      A $type$ buffer is not comparable to any other type of object. + * + * @param that the $type$ buffer to be compared. + * @return A negative integer, zero, or a positive integer as this buffer + * is less than, equal to, or greater than the given buffer + */ + public int compareToUnsigned($Type$Buffer that) { + int i = BufferMismatch.mismatch(this, this.position(), + that, that.position(), + Math.min(this.remaining(), that.remaining())); + if (i >= 0) { + return compareUnsigned(this.get(this.position() + i), that.get(that.position() + i)); + } + return this.remaining() - that.remaining(); + } +#end[integralType] +#end[!char] + private static int compare($type$ x, $type$ y) { #if[floatingPointType] return ((x < y) ? -1 : @@ -1353,6 +1382,34 @@ #end[floatingPointType] } +#if[!char] +#if[integralType] + private static int compareUnsigned($type$ x, $type$ y) { + return $Fulltype$.compareUnsigned(x, y); + } +#end[integralType] +#end[!char] + + /** + * Find the relative index of a mismatch between this buffer and another + * starting the current positions. + * + *

      A $type$ buffer is not comparable to any other type of object. + * + * @param that the $type$ buffer to be compared. + * @return the relative index of a mismatch between the two buffers, + * otherwise -1 if no mismatch. The index will be within the range of + * (inclusive) {@link #position()} to (exclusive) the smaller of + * {@link #remaining() this.position()+this.remaining()} and + * {@link #remaining() this.position()+that.remaining()}. + */ + public int mismatch($Type$Buffer that) { + int r = BufferMismatch.mismatch(this, this.position(), + that, that.position(), + Math.min(this.remaining(), that.remaining())); + return r == -1 ? -1 : r + this.position(); + } + // -- Other char stuff -- #if[char] diff --git a/test/jdk/java/nio/Buffer/Basic-X.java.template b/test/jdk/java/nio/Buffer/Basic-X.java.template --- a/test/jdk/java/nio/Buffer/Basic-X.java.template +++ b/test/jdk/java/nio/Buffer/Basic-X.java.template @@ -697,6 +697,17 @@ if (b.compareTo(b2) != 0) { fail("Comparison to identical buffer != 0", b, b2); } +#if[compareToUnsigned] + if (b.compareToUnsigned(b2) != 0) { + fail("Unsighed comparison to identical buffer != 0", b, b2); + } +#end[compareToUnsigned] + if (b.mismatch(b2) != -1) { + fail("Mismatch to identical buffer != -1", b, b2); + } + if (b2.mismatch(b) != -1) { + fail("Mismatch to identical buffer != -1", b, b2); + } b.limit(b.limit() + 1); b.position(b.limit() - 1); b.put(($type$)99); @@ -706,6 +717,11 @@ fail("Non-identical buffers equal", b, b2); if (b.compareTo(b2) <= 0) fail("Comparison to shorter buffer <= 0", b, b2); +#if[compareToUnsigned] + if (b.compareToUnsigned(b2) <= 0) { + fail("Unsighed comparison to lesser shorter buffer <= 0", b, b2); + } +#end[compareToUnsigned] b.limit(b.limit() - 1); b.put(2, ($type$)42); @@ -713,16 +729,29 @@ fail("Non-identical buffers equal", b, b2); if (b.compareTo(b2) <= 0) fail("Comparison to lesser buffer <= 0", b, b2); +#if[compareToUnsigned] + if (b.compareToUnsigned(b2) <= 0) { + fail("Unsighed comparison to lesser value <= 0", b, b2); + } +#end[compareToUnsigned] - // Check equals and compareTo with interesting values + // Check equals, compareTo, compareToUnsigned, mismatch with interesting values for ($type$ x : VALUES) { $Type$Buffer xb = $Type$Buffer.wrap(new $type$[] { x }); if (xb.compareTo(xb) != 0) { fail("compareTo not reflexive", xb, xb, x, x); } +#if[compareToUnsigned] + if (xb.compareToUnsigned(xb) != 0) { + fail("compareToUnsigned not reflexive", xb, xb, x, x); + } +#end[compareToUnsigned] if (!xb.equals(xb)) { fail("equals not reflexive", xb, xb, x, x); } + if (xb.mismatch(xb) != -1) { + fail("mismatch not reflexive", xb, xb, x, x); + } for ($type$ y : VALUES) { $Type$Buffer yb = $Type$Buffer.wrap(new $type$[] { y }); if (xb.compareTo(yb) != - yb.compareTo(xb)) { @@ -743,10 +772,34 @@ fail("Incorrect results for $Type$Buffer.compareTo", xb, yb, x, y); } +#if[compareToUnsigned] + if (xb.compareToUnsigned(yb) != - yb.compareToUnsigned(xb)) { + fail("compareToUnsigned not anti-symmetric", + xb, yb, x, y); + } + if ((xb.compareToUnsigned(yb) == 0) != xb.equals(yb)) { + fail("compareToUnsigned inconsistent with equals", + xb, yb, x, y); + } + if (xb.compareToUnsigned(yb) != $Fulltype$.compareUnsigned(x, y)) { +#if[float] + if (x == 0.0 && y == 0.0) continue; +#end[float] +#if[double] + if (x == 0.0 && y == 0.0) continue; +#end[double] + fail("Incorrect results for $Type$Buffer.compareToUnsigned", + xb, yb, x, y); + } +#end[compareToUnsigned] if (xb.equals(yb) != ((x == y) || ((x != x) && (y != y)))) { fail("Incorrect results for $Type$Buffer.equals", xb, yb, x, y); } + if (xb.mismatch(yb) == -1 != ((x == y) || ((x != x) && (y != y)))) { + fail("Incorrect results for $Type$Buffer.mismatch", + xb, yb, x, y); + } } } diff --git a/test/jdk/java/nio/Buffer/BasicByte.java b/test/jdk/java/nio/Buffer/BasicByte.java --- a/test/jdk/java/nio/Buffer/BasicByte.java +++ b/test/jdk/java/nio/Buffer/BasicByte.java @@ -697,6 +697,17 @@ if (b.compareTo(b2) != 0) { fail("Comparison to identical buffer != 0", b, b2); } + + if (b.compareToUnsigned(b2) != 0) { + fail("Unsighed comparison to identical buffer != 0", b, b2); + } + + if (b.mismatch(b2) != -1) { + fail("Mismatch to identical buffer != -1", b, b2); + } + if (b2.mismatch(b) != -1) { + fail("Mismatch to identical buffer != -1", b, b2); + } b.limit(b.limit() + 1); b.position(b.limit() - 1); b.put((byte)99); @@ -706,6 +717,11 @@ fail("Non-identical buffers equal", b, b2); if (b.compareTo(b2) <= 0) fail("Comparison to shorter buffer <= 0", b, b2); + + if (b.compareToUnsigned(b2) <= 0) { + fail("Unsighed comparison to lesser shorter buffer <= 0", b, b2); + } + b.limit(b.limit() - 1); b.put(2, (byte)42); @@ -714,7 +730,12 @@ if (b.compareTo(b2) <= 0) fail("Comparison to lesser buffer <= 0", b, b2); - // Check equals and compareTo with interesting values + if (b.compareToUnsigned(b2) <= 0) { + fail("Unsighed comparison to lesser value <= 0", b, b2); + } + + + // Check equals, compareTo, compareToUnsigned, mismatch with interesting values for (byte x : VALUES) { ByteBuffer xb = ByteBuffer.wrap(new byte[] { x }); if (xb.compareTo(xb) != 0) { @@ -723,6 +744,9 @@ if (!xb.equals(xb)) { fail("equals not reflexive", xb, xb, x, x); } + if (xb.mismatch(xb) != -1) { + fail("mismatch not reflexive", xb, xb, x, x); + } for (byte y : VALUES) { ByteBuffer yb = ByteBuffer.wrap(new byte[] { y }); if (xb.compareTo(yb) != - yb.compareTo(xb)) { @@ -743,10 +767,34 @@ fail("Incorrect results for ByteBuffer.compareTo", xb, yb, x, y); } + + if (xb.compareToUnsigned(yb) != - yb.compareToUnsigned(xb)) { + fail("compareToUnsigned not anti-symmetric", + xb, yb, x, y); + } + if ((xb.compareToUnsigned(yb) == 0) != xb.equals(yb)) { + fail("compareToUnsigned inconsistent with equals", + xb, yb, x, y); + } + if (xb.compareToUnsigned(yb) != Byte.compareUnsigned(x, y)) { + + + + + + + fail("Incorrect results for ByteBuffer.compareToUnsigned", + xb, yb, x, y); + } + if (xb.equals(yb) != ((x == y) || ((x != x) && (y != y)))) { fail("Incorrect results for ByteBuffer.equals", xb, yb, x, y); } + if (xb.mismatch(yb) == -1 != ((x == y) || ((x != x) && (y != y)))) { + fail("Incorrect results for ByteBuffer.mismatch", + xb, yb, x, y); + } } } diff --git a/test/jdk/java/nio/Buffer/BasicChar.java b/test/jdk/java/nio/Buffer/BasicChar.java --- a/test/jdk/java/nio/Buffer/BasicChar.java +++ b/test/jdk/java/nio/Buffer/BasicChar.java @@ -697,6 +697,17 @@ if (b.compareTo(b2) != 0) { fail("Comparison to identical buffer != 0", b, b2); } + + + + + + if (b.mismatch(b2) != -1) { + fail("Mismatch to identical buffer != -1", b, b2); + } + if (b2.mismatch(b) != -1) { + fail("Mismatch to identical buffer != -1", b, b2); + } b.limit(b.limit() + 1); b.position(b.limit() - 1); b.put((char)99); @@ -706,6 +717,11 @@ fail("Non-identical buffers equal", b, b2); if (b.compareTo(b2) <= 0) fail("Comparison to shorter buffer <= 0", b, b2); + + + + + b.limit(b.limit() - 1); b.put(2, (char)42); @@ -714,7 +730,12 @@ if (b.compareTo(b2) <= 0) fail("Comparison to lesser buffer <= 0", b, b2); - // Check equals and compareTo with interesting values + + + + + + // Check equals, compareTo, compareToUnsigned, mismatch with interesting values for (char x : VALUES) { CharBuffer xb = CharBuffer.wrap(new char[] { x }); if (xb.compareTo(xb) != 0) { @@ -723,6 +744,9 @@ if (!xb.equals(xb)) { fail("equals not reflexive", xb, xb, x, x); } + if (xb.mismatch(xb) != -1) { + fail("mismatch not reflexive", xb, xb, x, x); + } for (char y : VALUES) { CharBuffer yb = CharBuffer.wrap(new char[] { y }); if (xb.compareTo(yb) != - yb.compareTo(xb)) { @@ -743,10 +767,34 @@ fail("Incorrect results for CharBuffer.compareTo", xb, yb, x, y); } + + + + + + + + + + + + + + + + + + + + if (xb.equals(yb) != ((x == y) || ((x != x) && (y != y)))) { fail("Incorrect results for CharBuffer.equals", xb, yb, x, y); } + if (xb.mismatch(yb) == -1 != ((x == y) || ((x != x) && (y != y)))) { + fail("Incorrect results for CharBuffer.mismatch", + xb, yb, x, y); + } } } diff --git a/test/jdk/java/nio/Buffer/BasicDouble.java b/test/jdk/java/nio/Buffer/BasicDouble.java --- a/test/jdk/java/nio/Buffer/BasicDouble.java +++ b/test/jdk/java/nio/Buffer/BasicDouble.java @@ -697,6 +697,17 @@ if (b.compareTo(b2) != 0) { fail("Comparison to identical buffer != 0", b, b2); } + + + + + + if (b.mismatch(b2) != -1) { + fail("Mismatch to identical buffer != -1", b, b2); + } + if (b2.mismatch(b) != -1) { + fail("Mismatch to identical buffer != -1", b, b2); + } b.limit(b.limit() + 1); b.position(b.limit() - 1); b.put((double)99); @@ -706,6 +717,11 @@ fail("Non-identical buffers equal", b, b2); if (b.compareTo(b2) <= 0) fail("Comparison to shorter buffer <= 0", b, b2); + + + + + b.limit(b.limit() - 1); b.put(2, (double)42); @@ -714,7 +730,12 @@ if (b.compareTo(b2) <= 0) fail("Comparison to lesser buffer <= 0", b, b2); - // Check equals and compareTo with interesting values + + + + + + // Check equals, compareTo, compareToUnsigned, mismatch with interesting values for (double x : VALUES) { DoubleBuffer xb = DoubleBuffer.wrap(new double[] { x }); if (xb.compareTo(xb) != 0) { @@ -723,6 +744,9 @@ if (!xb.equals(xb)) { fail("equals not reflexive", xb, xb, x, x); } + if (xb.mismatch(xb) != -1) { + fail("mismatch not reflexive", xb, xb, x, x); + } for (double y : VALUES) { DoubleBuffer yb = DoubleBuffer.wrap(new double[] { y }); if (xb.compareTo(yb) != - yb.compareTo(xb)) { @@ -743,10 +767,34 @@ fail("Incorrect results for DoubleBuffer.compareTo", xb, yb, x, y); } + + + + + + + + + + + + + + + + + + + + if (xb.equals(yb) != ((x == y) || ((x != x) && (y != y)))) { fail("Incorrect results for DoubleBuffer.equals", xb, yb, x, y); } + if (xb.mismatch(yb) == -1 != ((x == y) || ((x != x) && (y != y)))) { + fail("Incorrect results for DoubleBuffer.mismatch", + xb, yb, x, y); + } } } diff --git a/test/jdk/java/nio/Buffer/BasicFloat.java b/test/jdk/java/nio/Buffer/BasicFloat.java --- a/test/jdk/java/nio/Buffer/BasicFloat.java +++ b/test/jdk/java/nio/Buffer/BasicFloat.java @@ -697,6 +697,17 @@ if (b.compareTo(b2) != 0) { fail("Comparison to identical buffer != 0", b, b2); } + + + + + + if (b.mismatch(b2) != -1) { + fail("Mismatch to identical buffer != -1", b, b2); + } + if (b2.mismatch(b) != -1) { + fail("Mismatch to identical buffer != -1", b, b2); + } b.limit(b.limit() + 1); b.position(b.limit() - 1); b.put((float)99); @@ -706,6 +717,11 @@ fail("Non-identical buffers equal", b, b2); if (b.compareTo(b2) <= 0) fail("Comparison to shorter buffer <= 0", b, b2); + + + + + b.limit(b.limit() - 1); b.put(2, (float)42); @@ -714,7 +730,12 @@ if (b.compareTo(b2) <= 0) fail("Comparison to lesser buffer <= 0", b, b2); - // Check equals and compareTo with interesting values + + + + + + // Check equals, compareTo, compareToUnsigned, mismatch with interesting values for (float x : VALUES) { FloatBuffer xb = FloatBuffer.wrap(new float[] { x }); if (xb.compareTo(xb) != 0) { @@ -723,6 +744,9 @@ if (!xb.equals(xb)) { fail("equals not reflexive", xb, xb, x, x); } + if (xb.mismatch(xb) != -1) { + fail("mismatch not reflexive", xb, xb, x, x); + } for (float y : VALUES) { FloatBuffer yb = FloatBuffer.wrap(new float[] { y }); if (xb.compareTo(yb) != - yb.compareTo(xb)) { @@ -743,10 +767,34 @@ fail("Incorrect results for FloatBuffer.compareTo", xb, yb, x, y); } + + + + + + + + + + + + + + + + + + + + if (xb.equals(yb) != ((x == y) || ((x != x) && (y != y)))) { fail("Incorrect results for FloatBuffer.equals", xb, yb, x, y); } + if (xb.mismatch(yb) == -1 != ((x == y) || ((x != x) && (y != y)))) { + fail("Incorrect results for FloatBuffer.mismatch", + xb, yb, x, y); + } } } diff --git a/test/jdk/java/nio/Buffer/BasicInt.java b/test/jdk/java/nio/Buffer/BasicInt.java --- a/test/jdk/java/nio/Buffer/BasicInt.java +++ b/test/jdk/java/nio/Buffer/BasicInt.java @@ -697,6 +697,17 @@ if (b.compareTo(b2) != 0) { fail("Comparison to identical buffer != 0", b, b2); } + + if (b.compareToUnsigned(b2) != 0) { + fail("Unsighed comparison to identical buffer != 0", b, b2); + } + + if (b.mismatch(b2) != -1) { + fail("Mismatch to identical buffer != -1", b, b2); + } + if (b2.mismatch(b) != -1) { + fail("Mismatch to identical buffer != -1", b, b2); + } b.limit(b.limit() + 1); b.position(b.limit() - 1); b.put((int)99); @@ -706,6 +717,11 @@ fail("Non-identical buffers equal", b, b2); if (b.compareTo(b2) <= 0) fail("Comparison to shorter buffer <= 0", b, b2); + + if (b.compareToUnsigned(b2) <= 0) { + fail("Unsighed comparison to lesser shorter buffer <= 0", b, b2); + } + b.limit(b.limit() - 1); b.put(2, (int)42); @@ -714,7 +730,12 @@ if (b.compareTo(b2) <= 0) fail("Comparison to lesser buffer <= 0", b, b2); - // Check equals and compareTo with interesting values + if (b.compareToUnsigned(b2) <= 0) { + fail("Unsighed comparison to lesser value <= 0", b, b2); + } + + + // Check equals, compareTo, compareToUnsigned, mismatch with interesting values for (int x : VALUES) { IntBuffer xb = IntBuffer.wrap(new int[] { x }); if (xb.compareTo(xb) != 0) { @@ -723,6 +744,9 @@ if (!xb.equals(xb)) { fail("equals not reflexive", xb, xb, x, x); } + if (xb.mismatch(xb) != -1) { + fail("mismatch not reflexive", xb, xb, x, x); + } for (int y : VALUES) { IntBuffer yb = IntBuffer.wrap(new int[] { y }); if (xb.compareTo(yb) != - yb.compareTo(xb)) { @@ -743,10 +767,34 @@ fail("Incorrect results for IntBuffer.compareTo", xb, yb, x, y); } + + if (xb.compareToUnsigned(yb) != - yb.compareToUnsigned(xb)) { + fail("compareToUnsigned not anti-symmetric", + xb, yb, x, y); + } + if ((xb.compareToUnsigned(yb) == 0) != xb.equals(yb)) { + fail("compareToUnsigned inconsistent with equals", + xb, yb, x, y); + } + if (xb.compareToUnsigned(yb) != Integer.compareUnsigned(x, y)) { + + + + + + + fail("Incorrect results for IntBuffer.compareToUnsigned", + xb, yb, x, y); + } + if (xb.equals(yb) != ((x == y) || ((x != x) && (y != y)))) { fail("Incorrect results for IntBuffer.equals", xb, yb, x, y); } + if (xb.mismatch(yb) == -1 != ((x == y) || ((x != x) && (y != y)))) { + fail("Incorrect results for IntBuffer.mismatch", + xb, yb, x, y); + } } } diff --git a/test/jdk/java/nio/Buffer/BasicLong.java b/test/jdk/java/nio/Buffer/BasicLong.java --- a/test/jdk/java/nio/Buffer/BasicLong.java +++ b/test/jdk/java/nio/Buffer/BasicLong.java @@ -697,6 +697,17 @@ if (b.compareTo(b2) != 0) { fail("Comparison to identical buffer != 0", b, b2); } + + if (b.compareToUnsigned(b2) != 0) { + fail("Unsighed comparison to identical buffer != 0", b, b2); + } + + if (b.mismatch(b2) != -1) { + fail("Mismatch to identical buffer != -1", b, b2); + } + if (b2.mismatch(b) != -1) { + fail("Mismatch to identical buffer != -1", b, b2); + } b.limit(b.limit() + 1); b.position(b.limit() - 1); b.put((long)99); @@ -706,6 +717,11 @@ fail("Non-identical buffers equal", b, b2); if (b.compareTo(b2) <= 0) fail("Comparison to shorter buffer <= 0", b, b2); + + if (b.compareToUnsigned(b2) <= 0) { + fail("Unsighed comparison to lesser shorter buffer <= 0", b, b2); + } + b.limit(b.limit() - 1); b.put(2, (long)42); @@ -714,7 +730,12 @@ if (b.compareTo(b2) <= 0) fail("Comparison to lesser buffer <= 0", b, b2); - // Check equals and compareTo with interesting values + if (b.compareToUnsigned(b2) <= 0) { + fail("Unsighed comparison to lesser value <= 0", b, b2); + } + + + // Check equals, compareTo, compareToUnsigned, mismatch with interesting values for (long x : VALUES) { LongBuffer xb = LongBuffer.wrap(new long[] { x }); if (xb.compareTo(xb) != 0) { @@ -723,6 +744,9 @@ if (!xb.equals(xb)) { fail("equals not reflexive", xb, xb, x, x); } + if (xb.mismatch(xb) != -1) { + fail("mismatch not reflexive", xb, xb, x, x); + } for (long y : VALUES) { LongBuffer yb = LongBuffer.wrap(new long[] { y }); if (xb.compareTo(yb) != - yb.compareTo(xb)) { @@ -743,10 +767,34 @@ fail("Incorrect results for LongBuffer.compareTo", xb, yb, x, y); } + + if (xb.compareToUnsigned(yb) != - yb.compareToUnsigned(xb)) { + fail("compareToUnsigned not anti-symmetric", + xb, yb, x, y); + } + if ((xb.compareToUnsigned(yb) == 0) != xb.equals(yb)) { + fail("compareToUnsigned inconsistent with equals", + xb, yb, x, y); + } + if (xb.compareToUnsigned(yb) != Long.compareUnsigned(x, y)) { + + + + + + + fail("Incorrect results for LongBuffer.compareToUnsigned", + xb, yb, x, y); + } + if (xb.equals(yb) != ((x == y) || ((x != x) && (y != y)))) { fail("Incorrect results for LongBuffer.equals", xb, yb, x, y); } + if (xb.mismatch(yb) == -1 != ((x == y) || ((x != x) && (y != y)))) { + fail("Incorrect results for LongBuffer.mismatch", + xb, yb, x, y); + } } } diff --git a/test/jdk/java/nio/Buffer/BasicShort.java b/test/jdk/java/nio/Buffer/BasicShort.java --- a/test/jdk/java/nio/Buffer/BasicShort.java +++ b/test/jdk/java/nio/Buffer/BasicShort.java @@ -697,6 +697,17 @@ if (b.compareTo(b2) != 0) { fail("Comparison to identical buffer != 0", b, b2); } + + if (b.compareToUnsigned(b2) != 0) { + fail("Unsighed comparison to identical buffer != 0", b, b2); + } + + if (b.mismatch(b2) != -1) { + fail("Mismatch to identical buffer != -1", b, b2); + } + if (b2.mismatch(b) != -1) { + fail("Mismatch to identical buffer != -1", b, b2); + } b.limit(b.limit() + 1); b.position(b.limit() - 1); b.put((short)99); @@ -706,6 +717,11 @@ fail("Non-identical buffers equal", b, b2); if (b.compareTo(b2) <= 0) fail("Comparison to shorter buffer <= 0", b, b2); + + if (b.compareToUnsigned(b2) <= 0) { + fail("Unsighed comparison to lesser shorter buffer <= 0", b, b2); + } + b.limit(b.limit() - 1); b.put(2, (short)42); @@ -714,7 +730,12 @@ if (b.compareTo(b2) <= 0) fail("Comparison to lesser buffer <= 0", b, b2); - // Check equals and compareTo with interesting values + if (b.compareToUnsigned(b2) <= 0) { + fail("Unsighed comparison to lesser value <= 0", b, b2); + } + + + // Check equals, compareTo, compareToUnsigned, mismatch with interesting values for (short x : VALUES) { ShortBuffer xb = ShortBuffer.wrap(new short[] { x }); if (xb.compareTo(xb) != 0) { @@ -723,6 +744,9 @@ if (!xb.equals(xb)) { fail("equals not reflexive", xb, xb, x, x); } + if (xb.mismatch(xb) != -1) { + fail("mismatch not reflexive", xb, xb, x, x); + } for (short y : VALUES) { ShortBuffer yb = ShortBuffer.wrap(new short[] { y }); if (xb.compareTo(yb) != - yb.compareTo(xb)) { @@ -743,10 +767,34 @@ fail("Incorrect results for ShortBuffer.compareTo", xb, yb, x, y); } + + if (xb.compareToUnsigned(yb) != - yb.compareToUnsigned(xb)) { + fail("compareToUnsigned not anti-symmetric", + xb, yb, x, y); + } + if ((xb.compareToUnsigned(yb) == 0) != xb.equals(yb)) { + fail("compareToUnsigned inconsistent with equals", + xb, yb, x, y); + } + if (xb.compareToUnsigned(yb) != Short.compareUnsigned(x, y)) { + + + + + + + fail("Incorrect results for ShortBuffer.compareToUnsigned", + xb, yb, x, y); + } + if (xb.equals(yb) != ((x == y) || ((x != x) && (y != y)))) { fail("Incorrect results for ShortBuffer.equals", xb, yb, x, y); } + if (xb.mismatch(yb) == -1 != ((x == y) || ((x != x) && (y != y)))) { + fail("Incorrect results for ShortBuffer.mismatch", + xb, yb, x, y); + } } } diff --git a/test/jdk/java/nio/Buffer/EqualsCompareTest.java b/test/jdk/java/nio/Buffer/EqualsCompareTest.java --- a/test/jdk/java/nio/Buffer/EqualsCompareTest.java +++ b/test/jdk/java/nio/Buffer/EqualsCompareTest.java @@ -83,22 +83,28 @@ final BufferKind k; final Class bufferType; final Class elementType; + final boolean withCompareUnsigned; final MethodHandle eq; final MethodHandle cmp; + final MethodHandle cmpUns; + final MethodHandle mism; final MethodHandle getter; final MethodHandle setter; - BufferType(BufferKind k, Class bufferType, Class elementType) { + BufferType(BufferKind k, Class bufferType, Class elementType, boolean withCompareUnsigned) { this.k = k; this.bufferType = bufferType; this.elementType = elementType; + this.withCompareUnsigned = withCompareUnsigned; var lookup = MethodHandles.lookup(); try { eq = lookup.findVirtual(bufferType, "equals", MethodType.methodType(boolean.class, Object.class)); cmp = lookup.findVirtual(bufferType, "compareTo", MethodType.methodType(int.class, bufferType)); + cmpUns = withCompareUnsigned ? lookup.findVirtual(bufferType, "compareToUnsigned", MethodType.methodType(int.class, bufferType)) : null; + mism = lookup.findVirtual(bufferType, "mismatch", MethodType.methodType(int.class, bufferType)); getter = lookup.findVirtual(bufferType, "get", MethodType.methodType(elementType, int.class)); setter = lookup.findVirtual(bufferType, "put", MethodType.methodType(bufferType, int.class, elementType)); @@ -176,6 +182,30 @@ } } + int compareUnsigned(T a, T b) { + try { + return (int) cmpUns.invoke(a, b); + } + catch (RuntimeException | Error e) { + throw e; + } + catch (Throwable t) { + throw new Error(t); + } + } + + int mismatch(T a, T b) { + try { + return (int) mism.invoke(a, b); + } + catch (RuntimeException | Error e) { + throw e; + } + catch (Throwable t) { + throw new Error(t); + } + } + boolean pairWiseEquals(T a, T b) { if (a.remaining() != b.remaining()) return false; @@ -186,9 +216,16 @@ return true; } + int pairWiseMismatch(T a, T b) { + for (int i = a.position(), j = b.position(); i < a.position() + a.remaining() && j < b.position() + b.remaining(); i++, j++) + if (!get(a, i).equals(get(b, j))) + return i; + return -1; + } + static class Bytes extends BufferType { Bytes(BufferKind k) { - super(k, ByteBuffer.class, byte.class); + super(k, ByteBuffer.class, byte.class, true); } @Override @@ -213,7 +250,7 @@ static class Chars extends BufferType { Chars(BufferKind k) { - super(k, CharBuffer.class, char.class); + super(k, CharBuffer.class, char.class, false); } @Override @@ -249,7 +286,7 @@ static class Shorts extends BufferType { Shorts(BufferKind k) { - super(k, ShortBuffer.class, short.class); + super(k, ShortBuffer.class, short.class, true); } @Override @@ -279,7 +316,7 @@ static class Ints extends BufferType { Ints(BufferKind k) { - super(k, IntBuffer.class, int.class); + super(k, IntBuffer.class, int.class, true); } @Override @@ -306,7 +343,7 @@ static class Floats extends BufferType { Floats(BufferKind k) { - super(k, FloatBuffer.class, float.class); + super(k, FloatBuffer.class, float.class, false); } @Override @@ -346,11 +383,22 @@ } return true; } + + @Override + int pairWiseMismatch(FloatBuffer a, FloatBuffer b) { + for (int i = a.position(), j = b.position(); i < a.position() + a.remaining() && j < b.position() + b.remaining(); i++, j++) { + float av = a.get(i); + float bv = b.get(j); + if (av != bv && (!Float.isNaN(av) || !Float.isNaN(bv))) + return i; + } + return -1; + } } static class Longs extends BufferType { Longs(BufferKind k) { - super(k, LongBuffer.class, long.class); + super(k, LongBuffer.class, long.class, true); } @Override @@ -380,7 +428,7 @@ static class Doubles extends BufferType { Doubles(BufferKind k) { - super(k, DoubleBuffer.class, double.class); + super(k, DoubleBuffer.class, double.class, false); } @Override @@ -420,6 +468,17 @@ } return true; } + + @Override + int pairWiseMismatch(DoubleBuffer a, DoubleBuffer b) { + for (int i = a.position(), j = b.position(); i < a.position() + a.remaining() && j < b.position() + b.remaining(); i++, j++) { + double av = a.get(i); + double bv = b.get(j); + if (av != bv && (!Double.isNaN(av) || !Double.isNaN(bv))) + return i; + } + return -1; + } } } @@ -635,13 +694,28 @@ if (eq) { Assert.assertEquals(bt.compare(as, bs), 0); Assert.assertEquals(bt.compare(bs, as), 0); + + if (bt.withCompareUnsigned) { + Assert.assertEquals(bt.compareUnsigned(as, bs), 0); + Assert.assertEquals(bt.compareUnsigned(bs, as), 0); + } } else { int aCb = bt.compare(as, bs); int bCa = bt.compare(bs, as); int v = Integer.signum(aCb) * Integer.signum(bCa); Assert.assertTrue(v == -1); + + if (bt.withCompareUnsigned) { + aCb = bt.compareUnsigned(as, bs); + bCa = bt.compareUnsigned(bs, as); + v = Integer.signum(aCb) * Integer.signum(bCa); + Assert.assertTrue(v == -1); + } } + + Assert.assertEquals(bt.mismatch(as, bs), bt.pairWiseMismatch(as, bs)); + Assert.assertEquals(bt.mismatch(bs, as), bt.pairWiseMismatch(bs, as)); } } @@ -661,6 +735,16 @@ int aCc = bt.compare(as, cs); int v = Integer.signum(cCa) * Integer.signum(aCc); Assert.assertTrue(v == -1); + + if (bt.withCompareUnsigned) { + cCa = bt.compareUnsigned(cs, as); + aCc = bt.compareUnsigned(as, cs); + v = Integer.signum(cCa) * Integer.signum(aCc); + Assert.assertTrue(v == -1); + } + + Assert.assertEquals(bt.mismatch(as, cs), bt.pairWiseMismatch(as, cs)); + Assert.assertEquals(bt.mismatch(cs, as), bt.pairWiseMismatch(cs, as)); } } } diff --git a/test/jdk/java/nio/Buffer/genBasic.sh b/test/jdk/java/nio/Buffer/genBasic.sh --- a/test/jdk/java/nio/Buffer/genBasic.sh +++ b/test/jdk/java/nio/Buffer/genBasic.sh @@ -23,16 +23,20 @@ # questions. # -javac -d . ../../../../make/src/classes/build/tools/spp/Spp.java +javac -d . ../../../../../make/jdk/src/classes/build/tools/spp/Spp.java gen() { java build.tools.spp.Spp -K$1 -Dtype=$1 -DType=$2 -DFulltype=$3 Basic$2.java } -gen byte Byte Byte +genu() { + java build.tools.spp.Spp -K$1 -Dtype=$1 -DType=$2 -DFulltype=$3 -KcompareToUnsigned Basic$2.java +} + +genu byte Byte Byte gen char Char Character -gen short Short Short -gen int Int Integer -gen long Long Long +genu short Short Short +genu int Int Integer +genu long Long Long gen float Float Float gen double Double Double diff --git a/test/jdk/java/nio/Buffer/genCopyDirectMemory.sh b/test/jdk/java/nio/Buffer/genCopyDirectMemory.sh --- a/test/jdk/java/nio/Buffer/genCopyDirectMemory.sh +++ b/test/jdk/java/nio/Buffer/genCopyDirectMemory.sh @@ -23,7 +23,7 @@ # questions. # -javac -d . ../../../../make/src/classes/build/tools/spp/Spp.java > Spp.java +javac -d . ../../../../../make/jdk/src/classes/build/tools/spp/Spp.java gen() { java build.tools.spp.Spp -K$1 -Dtype=$1 -DType=$2 -DFulltype=$3CopyDirect$2Memory.java diff --git a/test/jdk/java/nio/Buffer/genOrder.sh b/test/jdk/java/nio/Buffer/genOrder.sh --- a/test/jdk/java/nio/Buffer/genOrder.sh +++ b/test/jdk/java/nio/Buffer/genOrder.sh @@ -23,7 +23,7 @@ # questions. # -javac -d . ../../../../make/src/classes/build/tools/spp/Spp.java > Spp.java +javac -d . ../../../../../make/jdk/src/classes/build/tools/spp/Spp.java gen() { java build.tools.spp.Spp -K$1 -Dtype=$1 -DType=$2 -DFulltype=$3Order$2.java From simon at cjnash.com Fri Apr 20 15:16:38 2018 From: simon at cjnash.com (Simon Nash) Date: Fri, 20 Apr 2018 16:16:38 +0100 Subject: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <1a27932d85304155b68beb81014298ad@sap.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <5be0f86df2834aa8a881206ba285011e@sap.com> <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> <1a27932d85304155b68beb81014298ad@sap.com> Message-ID: <5ADA0456.7080607@cjnash.com> Hi Goetz, It should be "out of bounds" without hyphens. Simon On 20/04/2018 11:03, Lindenmaier, Goetz wrote: > Hi David, > > What about this: > java.lang.ArrayIndexOutOfBoundsException: Arraycopy source index -1 out-of-bounds for double[10]. > java.lang.ArrayIndexOutOfBoundsException: Arraycopy target index 10 out-of-bounds for object array[10]. > java.lang.ArrayIndexOutOfBoundsException: Negative length -19 in arraycopy from int[3] to int[9]. > > I'll reply to the other points in a comprehensive mail when I know > how to put the message. > > Thanks, > Goetz. > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Freitag, 20. April 2018 09:25 >> To: Lindenmaier, Goetz ; hotspot-runtime- >> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; aarch64- >> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core-libs- >> dev Libs >> Subject: Re: RFR(M): 8201593: Print array length in >> ArrayIndexOutOfBoundsException. >> >> Hi Goetz, >> >> This is not a file by file review ... >> >> On 19/04/2018 10:24 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> New webrev: >>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ >>> >>> I admit my wording is not optimal. >> src/hotspot/share/oops/typeArrayKlass.cpp >> >> Sorry but this is still far too verbose for my tastes. The type of the >> array is not relevant. For the array copy its okay to indicate src or >> dst array. But the message should be clear and succinct not prose-like. >> Plus you have a lot of repetition in the ss.print statements when only >> one thing is changing. >> >> src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp >> >> I'm not seeing why the throw_index_out_of_bounds_exception should be >> tied to whether or not you have an array reference. Certainly I hate >> seeing the array ref being used as an implicit bool! >> >>> It's because I extracted this change from a bigger one. Our message reads >> like this: >>> Object [] oa1 = new Object[10] >>> oa1[12] >>> "ArrayIndexOutOfBoundsException while trying to load from index 12 of an >> object array with length 10, loaded from local variable 'oa1'" >>> ... which seems not optimal, either. But it mentions the type (object), the >> operation (load, store etc ...) and the variable name. >>> Naming the array is quite detailed if it is in a complex expression (like >> returned from a call). >>> I'll contribute more of this if appreciated, this is a first step. >> I've never thought this complexity was warranted. We've had a few RFE's >> of this nature over the years and they have been closed (not necessarily >> by me I should point out!). >> >>> Printing "index N is outside range [0, length-1]" is problematic >>> for length '0'. I followed the proposal by Roger: >>> "Index -1 out-of-bounds for length 10." >> You can easily special-case length 0. But Roger's proposal for >> consistency with existing messages make sense - not withstanding >> Andrew's dislike for the hyphens. >> >>> I removed the change to ArrayIndexOutOfBoundsException.java. >> That's good. >> >>> I extended the test to cover the exception thrown in arraycopy better >> The test seems somewhat excessive, and I now see it is because of the >> more elaborate error messages you have at SAP. But with only the index >> and the array length of interest here the test can be considerably smaller. >> >> The creation tests for ArrayIndexOutOfBoundsException don't seem >> relevant in this context either. This looks more TCK like. >> >> David >> ----- >> >>> and added the elementary type to the message text. This probably >>> needs improvement in the text, too. There are (currently) these cases: >>> >>> bject[] oa1 = new Object[10]; >>> Object[] oa2 = new Object[5]; >>> System.arraycopy(oa1, -17, oa2, 0, 5); >>> "while trying to copy from index -17 of an object array with length 10"); >>> System.arraycopy(oa1, 2, oa2, -18, 5); >>> "while trying to copy to index -18 of an object array with length 5"); >>> System.arraycopy(oa1, 2, oa2, 0, -19); >>> "while trying to copy a negative range -19 from an object array with length >> 10 to an object array with length 5"); >>> System.arraycopy(oa1, 8, oa2, 0, 5); >>> "while trying to copy from index 13 of an object array with length 10"); >>> System.arraycopy(oa1, 1, oa2, 0, 7); >>> "while trying to copy to index 7 of an object array with length 5"); >>> double[] ta1 = new double[10]; >>> double[] ta2 = new double[5]; >>> System.arraycopy(ta1, -17, ta2, 0, 5); >>> "while trying to copy from index -17 of a doubl array with length 10"); >>> System.arraycopy(ta1, 2, ta2, -18, 5); >>> "while trying to copy to index -18 of a double array with length 5"); >>> System.arraycopy(ta1, 2, ta2, 0, -19); >>> "while trying to copy a negative range -19 from a double array with length >> 10 to a double array with length 5"); >>> System.arraycopy(ta1, 8, ta2, 0, 5); >>> "while trying to copy from index 13 of a double array with length 10"); >>> System.arraycopy(ta1, 1, ta2, 0, 7); >>> "while trying to copy to index 7 of a double array with length 5"); >>> >>> Maybe it should say: >>> Arraycopy source index -1 out-of-bounds for double array of length 10. >>> Arraycopy target index 10 out-of-bounds for object array of length 10. >>> Negative range -19 when copying from an object array of length 10 to an >> object array of length 5. >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Mittwoch, 18. April 2018 10:55 >>>> To: Lindenmaier, Goetz ; hotspot-runtime- >>>> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; >> aarch64- >>>> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core- >> libs- >>>> dev Libs >>>> Subject: Re: RFR(M): 8201593: Print array length in >>>> ArrayIndexOutOfBoundsException. >>>> >>>> Adding core-libs-dev as you're changing >>>> java.lang.ArrayIndexOutOfBoundsException. >>>> >>>> I appreciate the intent here but I find the messages excessively >>>> verbose. The basic error is: >>>> >>>> index N is outside range [0, length-1] >>>> >>>> David >>>> >>>> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I would like to print a more verbose text on ArrayIndexOutOfBounds >>>> exception >>>>> that not only mentions the index, but also the length of the array >> accessed. >>>>> See the bug for documentation of the change of the message. >>>>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ >>>>> >>>>> @aarch/arm people: >>>>> I edited the aarch/arm files. Could you please verify this is correct? >>>>> I can not build on these platforms. >>>>> >>>>> The code on all the other platforms is tested with all the jtreg and jck >> tests >>>> etc. >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> From paul.sandoz at oracle.com Mon Apr 23 18:47:24 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 23 Apr 2018 11:47:24 -0700 Subject: RFR of JDK-8201469,test under java/rmi should be restricted to not run concurrently In-Reply-To: <608c4a45-1dba-c5f4-92ac-8ed8be66468f@oracle.com> References: <36dd9cd1-d748-b67e-3bff-edee4cab5edd@oracle.com> <608c4a45-1dba-c5f4-92ac-8ed8be66468f@oracle.com> Message-ID: Hi Hamlin, Do you have a sense of what rmi tests are problematic to run concurrently? Maybe you can subset to reduce the increased impact on execution time? Paul. > On Apr 20, 2018, at 12:21 AM, Hamlin Li wrote: > > Is someone available to review the following patch? > > Thank you > > -Hamlin > > > On 19/04/2018 4:17 PM, Hamlin Li wrote: >> would you please review the following patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8201469 >> >> http://cr.openjdk.java.net/~mli/8201469/webrev.00/ >> >> ( For othervm.dirs property, I just reformat it. ) >> >> >> In my test result, with jtreg option "-concurrency:4", after apply the patch, tier3 tests on different platforms will be slower about 1.5~2.0 times than before. >> I think stability of tests are more important than executing time, how do you think about it? >> >> Thank you >> -Hamlin > From isaac.r.levy at gmail.com Mon Apr 23 19:26:56 2018 From: isaac.r.levy at gmail.com (Isaac Levy) Date: Mon, 23 Apr 2018 15:26:56 -0400 Subject: [PATCH] minor regex cleanup: use switch for enum In-Reply-To: References: Message-ID: ping? Isaac On Wed, Apr 18, 2018 at 2:58 PM, Isaac Levy wrote: > Hi, > > Minor improvement in readability (and probably perf) for Pattern. Switch > is more consistent with the rest of the impl and the resulting tableswitch > avoids a comparison for possessives. > > -Isaac > > --- a/src/java.base/share/classes/java/util/regex/Pattern.java > +++ b/src/java.base/share/classes/java/util/regex/Pattern.java > @@ -4356,7 +4356,9 @@ > - if (type == Qtype.GREEDY) > + switch (type) { > + case GREEDY: > return match0(matcher, i, j, seq); > - else if (type == Qtype.LAZY) > + case LAZY: > return match1(matcher, i, j, seq); > - else > + default: > return match2(matcher, i, j, seq); > + } > > @@ -4527,7 +4529,10 @@ > - if (type == Qtype.GREEDY) { > + switch (type) { > + case GREEDY: > ret = match0(matcher, i, cmin, seq); > + break; > - } else if (type == Qtype.LAZY) { > + case LAZY: > ret = match1(matcher, i, cmin, seq); > + break; > - } else { > + default: > ret = match2(matcher, i, cmin, seq); > } > > From xueming.shen at oracle.com Mon Apr 23 20:06:50 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 23 Apr 2018 13:06:50 -0700 Subject: [11] RFR: 8181157: CLDR Timezone name fallback implementation In-Reply-To: References: Message-ID: <5ADE3CDA.600@oracle.com> Naoto, Here some comments (1) CLDRTimeZoneNameProviderImpl.java: Ln#58: to use Stream.toArray(String[]::new) ? no sure which one is faster Ln#155-160: is it worth considering to check all possible empty slots in "names" here (from index_std_long to index_std_short?) to avoid check/load "compact" multiple times? it appears doable for deriveFallbackNames() but I'm not sure about the invocation at #ln100, so a "?". (2) CLDRConverter.java: Ln#674: (not in updated code) why update the "local" jreMetaMap? just wonder it'd better to use Optional.ifPresentOrElse(...) here Ln:707: (don't know which one is better though :-)) .toMap(Map.Entry::getKey, Map.Entry::getValue); (3) LocaleResources.java just wanted to confirm the "locale.resources.debug" is something we wanted to be a public interface or not? Thanks, Sherman On 04/17/2018 02:28 PM, Naoto Sato wrote: > Hello, > > Please review the changes to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8181157 > > The proposed fix is located at: > > http://cr.openjdk.java.net/~naoto/8181157/webrev.05/ > > This RFE is to implement CLDR time zone names fallback mechanism [1]. Prior to this fix, time zone names are substituted with English names. With this change, it is generated according to the logic defined in TR 35. Here are the highlight of the changes: > > CLDRConverter: > - CLDRConverter has changed to not substitute/invent time zone display > names, except English bundle for compatibility & runtime performance. > - For English bundle, copy over COMPAT's names as before. > - CLDRConverer now parses regionFormat/gmtZeroFormat/exemplarCity > > CLDR provider: > - CLDRTimeZoneNameProviderImpl is introduced to generate fallback names > at runtime. > - If COMPAT provider is present, use it also as a fallback, before the > last resort (GMT offset format) > > Naoto > > [1] http://www.unicode.org/reports/tr35/tr35-dates.html#Time_Zone_Names From xueming.shen at oracle.com Mon Apr 23 20:31:27 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 23 Apr 2018 13:31:27 -0700 Subject: [PATCH] minor regex cleanup: use switch for enum In-Reply-To: References: Message-ID: <5ADE429F.8020003@oracle.com> this looks fine. -sherman On 4/23/18, 12:26 PM, Isaac Levy wrote: > ping? > > > Isaac > > On Wed, Apr 18, 2018 at 2:58 PM, Isaac Levy wrote: > >> Hi, >> >> Minor improvement in readability (and probably perf) for Pattern. Switch >> is more consistent with the rest of the impl and the resulting tableswitch >> avoids a comparison for possessives. >> >> -Isaac >> >> --- a/src/java.base/share/classes/java/util/regex/Pattern.java >> +++ b/src/java.base/share/classes/java/util/regex/Pattern.java >> @@ -4356,7 +4356,9 @@ >> - if (type == Qtype.GREEDY) >> + switch (type) { >> + case GREEDY: >> return match0(matcher, i, j, seq); >> - else if (type == Qtype.LAZY) >> + case LAZY: >> return match1(matcher, i, j, seq); >> - else >> + default: >> return match2(matcher, i, j, seq); >> + } >> >> @@ -4527,7 +4529,10 @@ >> - if (type == Qtype.GREEDY) { >> + switch (type) { >> + case GREEDY: >> ret = match0(matcher, i, cmin, seq); >> + break; >> - } else if (type == Qtype.LAZY) { >> + case LAZY: >> ret = match1(matcher, i, cmin, seq); >> + break; >> - } else { >> + default: >> ret = match2(matcher, i, cmin, seq); >> } >> >> From isaac.r.levy at gmail.com Mon Apr 23 20:49:59 2018 From: isaac.r.levy at gmail.com (Isaac Levy) Date: Mon, 23 Apr 2018 16:49:59 -0400 Subject: [PATCH] minor regex cleanup: use switch for enum In-Reply-To: <5ADE429F.8020003@oracle.com> References: <5ADE429F.8020003@oracle.com> Message-ID: Thanks. Another small perf patch below -- maybe we can combine. Avoids a StringBuilder allocation: --- a/src/java.base/share/classes/java/util/regex/Matcher.java +++ b/src/java.base/share/classes/java/util/regex/Matcher.java @@ -993,13 +993,11 @@ public Matcher appendReplacement(StringBuilder sb, String replacement) { // If no match, return error if (first < 0) throw new IllegalStateException("No match available"); - StringBuilder result = new StringBuilder(); - appendExpandedReplacement(replacement, result); // Append the intervening text sb.append(text, lastAppendPosition, first); // Append the match substitution + appendExpandedReplacement(replacement, sb); - sb.append(result); On Mon, Apr 23, 2018 at 4:31 PM, Xueming Shen wrote: > this looks fine. > > -sherman From xueming.shen at oracle.com Mon Apr 23 21:05:35 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 23 Apr 2018 14:05:35 -0700 Subject: [PATCH] minor regex cleanup: use switch for enum In-Reply-To: References: <5ADE429F.8020003@oracle.com> Message-ID: <5ADE4A9F.4060102@oracle.com> I would assume in case of an exception thrown from appendExpandedReplacement() we don't want "text" to be pushed into the "sb". -sherman On 4/23/18, 1:49 PM, Isaac Levy wrote: > Thanks. Another small perf patch below -- maybe we can combine. Avoids > a StringBuilder allocation: > > --- a/src/java.base/share/classes/java/util/regex/Matcher.java > +++ b/src/java.base/share/classes/java/util/regex/Matcher.java > @@ -993,13 +993,11 @@ > public Matcher appendReplacement(StringBuilder sb, String > replacement) { > // If no match, return error > if (first < 0) > throw new IllegalStateException("No match available"); > - StringBuilder result = new StringBuilder(); > - appendExpandedReplacement(replacement, result); > // Append the intervening text > sb.append(text, lastAppendPosition, first); > // Append the match substitution > + appendExpandedReplacement(replacement, sb); > - sb.append(result); > > > On Mon, Apr 23, 2018 at 4:31 PM, Xueming Shen > wrote: > > this looks fine. > > > > -sherman From paul.sandoz at oracle.com Mon Apr 23 21:16:58 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 23 Apr 2018 14:16:58 -0700 Subject: [PATCH] Add compareToUnsigned to java.nio.*Buffer In-Reply-To: <1d3a26e2-6dbc-e90d-781b-f0f636547263@snazy.de> References: <1d3a26e2-6dbc-e90d-781b-f0f636547263@snazy.de> Message-ID: <07121A81-EF65-4F60-BA69-C94F8557196A@oracle.com> Hi Robert, Thanks. The addition of mismatch is reasonable. I am unsure about compareToUnsigned, since we are trying to be a conservative about what we add to Buffer. I?ll take a closer look but it may take a little while to get around to it. Would you mind logging a web bug and attaching your patch? The bug will get triaged and make its way to me, then i won?t forget and you can track it. Thanks, Paul. > On Apr 23, 2018, at 7:23 AM, Robert Stupp wrote: > > The proposed patch is an improvement for Byte/Short/Int/LongBuffer classes to add compareToUnsigned() that works like compareTo() but treats the values as unsigned to leverage the vectorized mismatch implementations, which are not publicly accessible. > > In addition to that, it adds mismatch() for all *Buffer classes. > > Both new methods basically expose all the goodness of jdk.internal.util.ArraysSupport to *Buffer. > > The patch includes adoptions to the existing unit tests as well. > > Robert > > -- > Robert Stupp > @snazy > > From david.lloyd at redhat.com Mon Apr 23 21:18:15 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Mon, 23 Apr 2018 16:18:15 -0500 Subject: [PATCH] minor regex cleanup: use switch for enum In-Reply-To: <5ADE4A9F.4060102@oracle.com> References: <5ADE429F.8020003@oracle.com> <5ADE4A9F.4060102@oracle.com> Message-ID: FWIW I strongly doubt this will improve performance; probably the opposite in fact, as IIRC an enum switch generates an extra class (though perhaps this has changed). The original code was quite compact and utilized identity comparisons, and given there are only three alternatives it probably was able to exploit branch prediction as well (if such a thing even matters in this context). I'm not a reviewer but this change seems pointless without supporting perf data. On Mon, Apr 23, 2018 at 4:05 PM, Xueming Shen wrote: > > I would assume in case of an exception thrown from > appendExpandedReplacement() we don't > want "text" to be pushed into the "sb". > > -sherman > > On 4/23/18, 1:49 PM, Isaac Levy wrote: >> >> Thanks. Another small perf patch below -- maybe we can combine. Avoids a >> StringBuilder allocation: >> >> --- a/src/java.base/share/classes/java/util/regex/Matcher.java >> +++ b/src/java.base/share/classes/java/util/regex/Matcher.java >> @@ -993,13 +993,11 @@ >> public Matcher appendReplacement(StringBuilder sb, String replacement) >> { >> // If no match, return error >> if (first < 0) >> throw new IllegalStateException("No match available"); >> - StringBuilder result = new StringBuilder(); >> - appendExpandedReplacement(replacement, result); >> // Append the intervening text >> sb.append(text, lastAppendPosition, first); >> // Append the match substitution >> + appendExpandedReplacement(replacement, sb); >> - sb.append(result); >> >> >> On Mon, Apr 23, 2018 at 4:31 PM, Xueming Shen > > wrote: >> > this looks fine. >> > >> > -sherman > > -- - DML From isaac.r.levy at gmail.com Tue Apr 24 00:42:24 2018 From: isaac.r.levy at gmail.com (Isaac Levy) Date: Tue, 24 Apr 2018 00:42:24 +0000 Subject: [PATCH] minor regex cleanup: use switch for enum In-Reply-To: References: <5ADE429F.8020003@oracle.com> <5ADE4A9F.4060102@oracle.com> Message-ID: On Mon, Apr 23, 2018 at 5:18 PM David Lloyd wrote: > FWIW I strongly doubt this will improve performance; probably the > opposite in fact, as IIRC an enum switch generates an extra class > (though perhaps this has changed). The original code was quite > compact and utilized identity comparisons, and given there are only > three alternatives it probably was able to exploit branch prediction > as well (if such a thing even matters in this context). Well, there are enum switches on the same enum elsewhere in the class, so should those instead be replaced by if checks? A larger change could remove this branch entirely, with different classes for each of the types, which are known during compile. From isaac.r.levy at gmail.com Tue Apr 24 00:47:02 2018 From: isaac.r.levy at gmail.com (Isaac Levy) Date: Tue, 24 Apr 2018 00:47:02 +0000 Subject: [PATCH] minor regex cleanup: use switch for enum In-Reply-To: <5ADE4A9F.4060102@oracle.com> References: <5ADE429F.8020003@oracle.com> <5ADE4A9F.4060102@oracle.com> Message-ID: On Mon, Apr 23, 2018 at 5:05 PM Xueming Shen wrote: > > I would assume in case of an exception thrown from > appendExpandedReplacement() we don't > want "text" to be pushed into the "sb". > > -sherman > Perhaps. Though the behavior under exception is undefined and this function is probably primarily used though the replaceAll API, which wouldn?t return the intermediate sb under the case of exception. My reading of the blame was the temp StringBuilder was an artifact of the api previously using StringBuffer externally. > From naoto.sato at oracle.com Tue Apr 24 01:25:45 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 23 Apr 2018 18:25:45 -0700 Subject: [11] RFR: 8181157: CLDR Timezone name fallback implementation In-Reply-To: <5ADE3CDA.600@oracle.com> References: <5ADE3CDA.600@oracle.com> Message-ID: <7ae5d607-4471-8797-d4a0-385f2e3d0704@oracle.com> Hi Sherman, thanks for the review. On 4/23/18 1:06 PM, Xueming Shen wrote: > Naoto, > > Here some comments > > (1) CLDRTimeZoneNameProviderImpl.java: > ???? Ln#58:? to use Stream.toArray(String[]::new) ? no sure which one > is faster > > ???? Ln#155-160: > ???????? is it worth considering to check all possible empty slots in > "names" here > ???????? (from index_std_long to index_std_short?) to avoid check/load > "compact" multiple > ???????? times?? it appears doable for deriveFallbackNames() but I'm > not sure about > ???????? the invocation at #ln100, so a "?". > > (2) CLDRConverter.java: > ???? Ln#674: (not in updated code) why update the "local" jreMetaMap? > ?????????????????? just wonder it'd better to use > Optional.ifPresentOrElse(...) here > > ???? Ln:707:? (don't know which one is better though :-)) > ???? .toMap(Map.Entry::getKey, Map.Entry::getValue); Addressed all of the above suggestions. Unnecessary jreMetaMap update was a good catch! > > (3) LocaleResources.java > ???? just wanted to confirm the "locale.resources.debug" is something > we wanted to > ???? be a public interface or not? Eventually I'd be public (8057075), but it is a private use for the time being. Here's the updated webrev: http://cr.openjdk.java.net/~naoto/8181157/webrev.06/ Naoto > > Thanks, > Sherman > > > On 04/17/2018 02:28 PM, Naoto Sato wrote: >> Hello, >> >> Please review the changes to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8181157 >> >> The proposed fix is located at: >> >> http://cr.openjdk.java.net/~naoto/8181157/webrev.05/ >> >> This RFE is to implement CLDR time zone names fallback mechanism [1]. >> Prior to this fix, time zone names are substituted with English names. >> With this change, it is generated according to the logic defined in TR >> 35. Here are the highlight of the changes: >> >> CLDRConverter: >> - CLDRConverter has changed to not substitute/invent time zone display >> names, except English bundle for compatibility & runtime performance. >> - For English bundle, copy over COMPAT's names as before. >> - CLDRConverer now parses regionFormat/gmtZeroFormat/exemplarCity >> >> CLDR provider: >> - CLDRTimeZoneNameProviderImpl is introduced to generate fallback names >> at runtime. >> - If COMPAT provider is present, use it also as a fallback, before the >> last resort (GMT offset format) >> >> Naoto >> >> [1] http://www.unicode.org/reports/tr35/tr35-dates.html#Time_Zone_Names > From peter.levart at gmail.com Tue Apr 24 10:41:23 2018 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 24 Apr 2018 12:41:23 +0200 Subject: [PATCH] minor regex cleanup: use switch for enum In-Reply-To: References: <5ADE429F.8020003@oracle.com> <5ADE4A9F.4060102@oracle.com> Message-ID: <3952d07b-1ffe-ec70-e0a4-f340e96ec289@gmail.com> On 04/23/2018 11:18 PM, David Lloyd wrote: > FWIW I strongly doubt this will improve performance; probably the > opposite in fact, as IIRC an enum switch generates an extra class > (though perhaps this has changed). switch on enum is basically a switch on Enum's ordinal mapped via the int[] array constructed in a synthetic nested class of the class containing the switch statement, so that separate compilation of an Enum class that changes ordinal values of particular enum constants doesn't change the semantics of the switch logic. For example... // X.java public enum X { ??? A, B, C } // Code.java public class Code { ??? public void m(X x) { ??? ??? switch (x) { ??? ??? ??? case A: // ... branch A ??? ??? ??? ??? break; ??? ??? ??? case B: // ... branch B ??? ??? ??? ??? break; ??? ??? ??? case C: // ... branch C ??? ??? ??? ??? break; ??? ??? ??? default: // ... default branch ??? ??? } ??? } } ...Code.java translates to something like the following (modulo error handling)... public class Code {l ??? static class m$switch$1 { ??? ??? static final int[] caseindex = new int[X.values().length]; ??????? static { ??? ??? ??? caseindex[X.A.ordinal()] = 1; ??? ??? ??? caseindex[X.B.ordinal()] = 2; ??? ??? ??? caseindex[X.C.ordinal()] = 3; ??? ??? } ??? } ??? public void m(X x) { ??? ??? switch (m$switch$1.caseindex[x.ordinal()]) { ??? ??? ??? case 1: // ... branch A ??? ??? ??? ??? break; ??? ??? ??? case 2: // ... branch B ??? ??? ??? ??? break; ??? ??? ??? case 3: // ... branch C ??? ??? ??? ??? break; ??? ??? ??? default: // ... default branch??? ??? } ??? } } Pefrormance-wise this is similar to switch on int. So pretty optimal. Decision should only be made on the count of code clarity here. While speaking of performance of enum switches, I have a question for a more knowledgeable person... Should JIT be able to fold above 'x' variable/parameter into a constant (suppose m() was called in a loop with an explicitly specified constant value such as X.A), it could further expand this decision to the x.ordinal() value (if the final instance 'ordinal' field in the X enum class was marked with @Stable), it could then further expand this decision to the looked up value of the m$switch$1.caseindex[] slot if caseindex array field in sytnhetic class was marked with @Stable, therefore transforming the switch to a switch on int constant, optimizing the JITed code to directly execute branch A and eliminate all other branches from generated code. The question is whether JIT is presently treating those fields (and array) as @Stable or not? Regards, Peter > The original code was quite > compact and utilized identity comparisons, and given there are only > three alternatives it probably was able to exploit branch prediction > as well (if such a thing even matters in this context). > > I'm not a reviewer but this change seems pointless without supporting perf data. > > On Mon, Apr 23, 2018 at 4:05 PM, Xueming Shen wrote: >> I would assume in case of an exception thrown from >> appendExpandedReplacement() we don't >> want "text" to be pushed into the "sb". >> >> -sherman >> >> On 4/23/18, 1:49 PM, Isaac Levy wrote: >>> Thanks. Another small perf patch below -- maybe we can combine. Avoids a >>> StringBuilder allocation: >>> >>> --- a/src/java.base/share/classes/java/util/regex/Matcher.java >>> +++ b/src/java.base/share/classes/java/util/regex/Matcher.java >>> @@ -993,13 +993,11 @@ >>> public Matcher appendReplacement(StringBuilder sb, String replacement) >>> { >>> // If no match, return error >>> if (first < 0) >>> throw new IllegalStateException("No match available"); >>> - StringBuilder result = new StringBuilder(); >>> - appendExpandedReplacement(replacement, result); >>> // Append the intervening text >>> sb.append(text, lastAppendPosition, first); >>> // Append the match substitution >>> + appendExpandedReplacement(replacement, sb); >>> - sb.append(result); >>> >>> >>> On Mon, Apr 23, 2018 at 4:31 PM, Xueming Shen >> > wrote: >>>> this looks fine. >>>> >>>> -sherman >> > > From peter.levart at gmail.com Tue Apr 24 12:17:21 2018 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 24 Apr 2018 14:17:21 +0200 Subject: [PATCH] minor regex cleanup: use switch for enum In-Reply-To: <3952d07b-1ffe-ec70-e0a4-f340e96ec289@gmail.com> References: <5ADE429F.8020003@oracle.com> <5ADE4A9F.4060102@oracle.com> <3952d07b-1ffe-ec70-e0a4-f340e96ec289@gmail.com> Message-ID: <74d618c0-3a21-93bb-a72e-73e110d22eed@gmail.com> On 04/24/2018 12:41 PM, Peter Levart wrote: > public class Code {l > > ??? static class m$switch$1 { > ??? ??? static final int[] caseindex = new int[X.values().length]; > ??????? static { > ??? ??? ??? caseindex[X.A.ordinal()] = 1; > ??? ??? ??? caseindex[X.B.ordinal()] = 2; > ??? ??? ??? caseindex[X.C.ordinal()] = 3; > ??? ??? } > ??? } > > ??? public void m(X x) { > ??? ??? switch (m$switch$1.caseindex[x.ordinal()]) { > ??? ??? ??? case 1: // ... branch A > ??? ??? ??? ??? break; > ??? ??? ??? case 2: // ... branch B > ??? ??? ??? ??? break; > ??? ??? ??? case 3: // ... branch C > ??? ??? ??? ??? break; > ??? ??? ??? default: // ... default branch??? ??? } > ??? } > } > > > Pefrormance-wise this is similar to switch on int. So pretty optimal. > Decision should only be made on the count of code clarity here. > > While speaking of performance of enum switches, I have a question for > a more knowledgeable person... > > Should JIT be able to fold above 'x' variable/parameter into a > constant (suppose m() was called in a loop with an explicitly > specified constant value such as X.A), it could further expand this > decision to the x.ordinal() value (if the final instance 'ordinal' > field in the X enum class was marked with @Stable), it could then > further expand this decision to the looked up value of the > m$switch$1.caseindex[] slot if caseindex array field in sytnhetic > class was marked with @Stable, therefore transforming the switch to a > switch on int constant, optimizing the JITed code to directly execute > branch A and eliminate all other branches from generated code. > > The question is whether JIT is presently treating those fields (and > array) as @Stable or not? It seems not. Here's a benchmark: http://cr.openjdk.java.net/~plevart/misc/SwitchBench/SwitchBench.java See enumConstSwitch between "Original JDK 10" and "JDK 10 + @Stable Enum.ordinal field". Interesting thing is that JDK 9 seems to be better at JITing code than JDK 10 in these tests. Why is that? I included results for Graal JIT compiler which shows that it probably does not contain support for @Stable annotation. The relevant part for this "minor regex cleanup" patch is the following: SwitchBench.enumConstIf????? avgt?? 10? 2.125 ? 0.002? ns/op SwitchBench.enumConstSwitch? avgt?? 10? 2.501 ? 0.025 ns/op SwitchBench.enumVarIf??????? avgt?? 10? 2.593 ? 0.004 ns/op SwitchBench.enumVarSwitch??? avgt?? 10? 2.862 ? 0.053 ns/op which indicates that "switch" is a little slower, but with @Stable Enum.ordinal field, it is on par with "if" at least for constant folded switched on values: SwitchBench.enumConstIf????? avgt?? 10? 2.126 ? 0.007 ns/op SwitchBench.enumConstSwitch? avgt?? 10? 2.159 ? 0.003 ns/op SwitchBench.enumVarIf??????? avgt?? 10? 2.593 ? 0.004 ns/op SwitchBench.enumVarSwitch??? avgt?? 10? 2.842 ? 0.006 ns/op Regards, Peter From david.lloyd at redhat.com Tue Apr 24 12:22:45 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Tue, 24 Apr 2018 07:22:45 -0500 Subject: [PATCH] minor regex cleanup: use switch for enum In-Reply-To: References: <5ADE429F.8020003@oracle.com> <5ADE4A9F.4060102@oracle.com> Message-ID: On Mon, Apr 23, 2018 at 7:42 PM, Isaac Levy wrote: > On Mon, Apr 23, 2018 at 5:18 PM David Lloyd wrote: >> >> FWIW I strongly doubt this will improve performance; probably the >> opposite in fact, as IIRC an enum switch generates an extra class >> (though perhaps this has changed). The original code was quite >> compact and utilized identity comparisons, and given there are only >> three alternatives it probably was able to exploit branch prediction >> as well (if such a thing even matters in this context). > > > Well, there are enum switches on the same enum elsewhere in the class, so > should those instead be replaced by if checks? I think that any change that's made for performance should be tested against performance regression, generally speaking. My personal understanding is that, when there are a small number of alternatives, an identity "if" tree can perform slightly better in some cases because HotSpot C2 gathers and utilizes statistics about branches taken in these cases; for switch, it (still IIRC) does not do so. Given that this is regex, it might be worth testing. > A larger change could remove this branch entirely, with different classes for each of the types, which > are known during compile. If that is beneficial. However every new class adds metaspace usage and (in this case) some kind of polymorphic dispatch, so you'd want to be fairly confident that in a typical application, only one of the two would be loaded, or that there would be some other significant gain, as there is definitely a cost. Everything has a cost, especially in hot perf-sensitive code. Anyway I'm not a reviewer but these are considerations that I would have were I contributing the change. JMH might be of use. -- - DML From forax at univ-mlv.fr Tue Apr 24 12:46:05 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 24 Apr 2018 14:46:05 +0200 (CEST) Subject: [PATCH] minor regex cleanup: use switch for enum In-Reply-To: <74d618c0-3a21-93bb-a72e-73e110d22eed@gmail.com> References: <5ADE429F.8020003@oracle.com> <5ADE4A9F.4060102@oracle.com> <3952d07b-1ffe-ec70-e0a4-f340e96ec289@gmail.com> <74d618c0-3a21-93bb-a72e-73e110d22eed@gmail.com> Message-ID: <477028424.657454.1524573965638.JavaMail.zimbra@u-pem.fr> Hi Peter, instead of using @Stable, John Rose had an interesting idea, we talk about a similar issue at last FOSDEM, make all final fields in java.lang trusted by default. The idea is that classes in java.lang doesn't seems to use Unsafe when deserializing (like classes in java.util does), so if this is true, all fields of java.lang should be trusted by the VM. regards, R?mi ----- Mail original ----- > De: "Peter Levart" > ?: "David Lloyd" , "Xueming Shen" > Cc: "core-libs-dev" > Envoy?: Mardi 24 Avril 2018 14:17:21 > Objet: Re: [PATCH] minor regex cleanup: use switch for enum > On 04/24/2018 12:41 PM, Peter Levart wrote: >> public class Code {l >> >> ??? static class m$switch$1 { >> ??? ??? static final int[] caseindex = new int[X.values().length]; >> ??????? static { >> ??? ??? ??? caseindex[X.A.ordinal()] = 1; >> ??? ??? ??? caseindex[X.B.ordinal()] = 2; >> ??? ??? ??? caseindex[X.C.ordinal()] = 3; >> ??? ??? } >> ??? } >> >> ??? public void m(X x) { >> ??? ??? switch (m$switch$1.caseindex[x.ordinal()]) { >> ??? ??? ??? case 1: // ... branch A >> ??? ??? ??? ??? break; >> ??? ??? ??? case 2: // ... branch B >> ??? ??? ??? ??? break; >> ??? ??? ??? case 3: // ... branch C >> ??? ??? ??? ??? break; >> ??? ??? ??? default: // ... default branch??? ??? } >> ??? } >> } >> >> >> Pefrormance-wise this is similar to switch on int. So pretty optimal. >> Decision should only be made on the count of code clarity here. >> >> While speaking of performance of enum switches, I have a question for >> a more knowledgeable person... >> >> Should JIT be able to fold above 'x' variable/parameter into a >> constant (suppose m() was called in a loop with an explicitly >> specified constant value such as X.A), it could further expand this >> decision to the x.ordinal() value (if the final instance 'ordinal' >> field in the X enum class was marked with @Stable), it could then >> further expand this decision to the looked up value of the >> m$switch$1.caseindex[] slot if caseindex array field in sytnhetic >> class was marked with @Stable, therefore transforming the switch to a >> switch on int constant, optimizing the JITed code to directly execute >> branch A and eliminate all other branches from generated code. >> >> The question is whether JIT is presently treating those fields (and >> array) as @Stable or not? > > It seems not. Here's a benchmark: > > http://cr.openjdk.java.net/~plevart/misc/SwitchBench/SwitchBench.java > > > See enumConstSwitch between "Original JDK 10" and "JDK 10 + @Stable > Enum.ordinal field". > > Interesting thing is that JDK 9 seems to be better at JITing code than > JDK 10 in these tests. Why is that? > > I included results for Graal JIT compiler which shows that it probably > does not contain support for @Stable annotation. > > > The relevant part for this "minor regex cleanup" patch is the following: > > SwitchBench.enumConstIf????? avgt?? 10? 2.125 ? 0.002? ns/op > SwitchBench.enumConstSwitch? avgt?? 10? 2.501 ? 0.025 ns/op > SwitchBench.enumVarIf??????? avgt?? 10? 2.593 ? 0.004 ns/op > SwitchBench.enumVarSwitch??? avgt?? 10? 2.862 ? 0.053 ns/op > > which indicates that "switch" is a little slower, but with @Stable > Enum.ordinal field, it is on par with "if" at least for constant folded > switched on values: > > SwitchBench.enumConstIf????? avgt?? 10? 2.126 ? 0.007 ns/op > SwitchBench.enumConstSwitch? avgt?? 10? 2.159 ? 0.003 ns/op > SwitchBench.enumVarIf??????? avgt?? 10? 2.593 ? 0.004 ns/op > SwitchBench.enumVarSwitch??? avgt?? 10? 2.842 ? 0.006 ns/op > > > Regards, Peter From snazy at snazy.de Tue Apr 24 12:51:45 2018 From: snazy at snazy.de (Robert Stupp) Date: Tue, 24 Apr 2018 14:51:45 +0200 Subject: [PATCH] Add compareToUnsigned to java.nio.*Buffer In-Reply-To: <07121A81-EF65-4F60-BA69-C94F8557196A@oracle.com> References: <1d3a26e2-6dbc-e90d-781b-f0f636547263@snazy.de> <07121A81-EF65-4F60-BA69-C94F8557196A@oracle.com> Message-ID: <98232eb8-1ca9-6188-89c1-7236cc6fb52c@snazy.de> Hi Paul, Thank you. I've filed an RFE via https://bugreport.java.com/bugreport/start_form.do - seems to be JDK-9053522. It just has no option to add an attachment and I have no login to bugs.openjdk.java.net . On 04/23/2018 11:16 PM, Paul Sandoz wrote: > The addition of mismatch is reasonable. I am unsure about compareToUnsigned, since we are trying to be a conservative about what we add to Buffer. On the one hand, it would be very nice to have compareToUnsigned() since the primitive wrapper classes have compareToUnsigned() as well. On the other hand, it would not be a big issue to build a similar functionality using *Buffer.mismatch(). Robert -- Robert Stupp @snazy From forax at univ-mlv.fr Tue Apr 24 13:01:21 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 24 Apr 2018 15:01:21 +0200 (CEST) Subject: [PATCH] minor regex cleanup: use switch for enum In-Reply-To: <74d618c0-3a21-93bb-a72e-73e110d22eed@gmail.com> References: <5ADE429F.8020003@oracle.com> <5ADE4A9F.4060102@oracle.com> <3952d07b-1ffe-ec70-e0a4-f340e96ec289@gmail.com> <74d618c0-3a21-93bb-a72e-73e110d22eed@gmail.com> Message-ID: <629338494.667779.1524574881342.JavaMail.zimbra@u-pem.fr> And as part of Amber, we are likely change the bytecode translation of the switch on enums (in fact all switches apart the one on integers) to avoid the separate compilation issues you mention (and support more kind of switches). The idea is that the new translation is to use invokedynamic so the association between an enum and the corresponding case is done at runtime and not at compile time. I think there is already codes in the amber repository that deals with enums, so another way to optimize the switch on enum is to change the bootstrap method associated to the switch on enum (we may also have to introduce a new method handle combinator that works like the getter but with the @Stable semantics). R?mi ----- Mail original ----- > De: "Peter Levart" > ?: "David Lloyd" , "Xueming Shen" > Cc: "core-libs-dev" > Envoy?: Mardi 24 Avril 2018 14:17:21 > Objet: Re: [PATCH] minor regex cleanup: use switch for enum > On 04/24/2018 12:41 PM, Peter Levart wrote: >> public class Code {l >> >> ??? static class m$switch$1 { >> ??? ??? static final int[] caseindex = new int[X.values().length]; >> ??????? static { >> ??? ??? ??? caseindex[X.A.ordinal()] = 1; >> ??? ??? ??? caseindex[X.B.ordinal()] = 2; >> ??? ??? ??? caseindex[X.C.ordinal()] = 3; >> ??? ??? } >> ??? } >> >> ??? public void m(X x) { >> ??? ??? switch (m$switch$1.caseindex[x.ordinal()]) { >> ??? ??? ??? case 1: // ... branch A >> ??? ??? ??? ??? break; >> ??? ??? ??? case 2: // ... branch B >> ??? ??? ??? ??? break; >> ??? ??? ??? case 3: // ... branch C >> ??? ??? ??? ??? break; >> ??? ??? ??? default: // ... default branch??? ??? } >> ??? } >> } >> >> >> Pefrormance-wise this is similar to switch on int. So pretty optimal. >> Decision should only be made on the count of code clarity here. >> >> While speaking of performance of enum switches, I have a question for >> a more knowledgeable person... >> >> Should JIT be able to fold above 'x' variable/parameter into a >> constant (suppose m() was called in a loop with an explicitly >> specified constant value such as X.A), it could further expand this >> decision to the x.ordinal() value (if the final instance 'ordinal' >> field in the X enum class was marked with @Stable), it could then >> further expand this decision to the looked up value of the >> m$switch$1.caseindex[] slot if caseindex array field in sytnhetic >> class was marked with @Stable, therefore transforming the switch to a >> switch on int constant, optimizing the JITed code to directly execute >> branch A and eliminate all other branches from generated code. >> >> The question is whether JIT is presently treating those fields (and >> array) as @Stable or not? > > It seems not. Here's a benchmark: > > http://cr.openjdk.java.net/~plevart/misc/SwitchBench/SwitchBench.java > > > See enumConstSwitch between "Original JDK 10" and "JDK 10 + @Stable > Enum.ordinal field". > > Interesting thing is that JDK 9 seems to be better at JITing code than > JDK 10 in these tests. Why is that? > > I included results for Graal JIT compiler which shows that it probably > does not contain support for @Stable annotation. > > > The relevant part for this "minor regex cleanup" patch is the following: > > SwitchBench.enumConstIf????? avgt?? 10? 2.125 ? 0.002? ns/op > SwitchBench.enumConstSwitch? avgt?? 10? 2.501 ? 0.025 ns/op > SwitchBench.enumVarIf??????? avgt?? 10? 2.593 ? 0.004 ns/op > SwitchBench.enumVarSwitch??? avgt?? 10? 2.862 ? 0.053 ns/op > > which indicates that "switch" is a little slower, but with @Stable > Enum.ordinal field, it is on par with "if" at least for constant folded > switched on values: > > SwitchBench.enumConstIf????? avgt?? 10? 2.126 ? 0.007 ns/op > SwitchBench.enumConstSwitch? avgt?? 10? 2.159 ? 0.003 ns/op > SwitchBench.enumVarIf??????? avgt?? 10? 2.593 ? 0.004 ns/op > SwitchBench.enumVarSwitch??? avgt?? 10? 2.842 ? 0.006 ns/op > > > Regards, Peter From goetz.lindenmaier at sap.com Tue Apr 24 14:08:02 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 24 Apr 2018 14:08:02 +0000 Subject: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <5be0f86df2834aa8a881206ba285011e@sap.com> <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> Message-ID: Hi, I implemented what we figured out in http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-April/027555.html Some examples: "Index 12 out-of-bounds for length 10." "arraycopy source index -17 out of bounds for object array[10]." "arraycopy destination index -18 out of bounds for double[5]." "arraycopy length -19 is negative." "arraycopy: last source index 13 out of bounds for double[10]." "arraycopy: last destination index 7 out of bounds for long[5]." Incremental webrev: http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/03-incremental/ Full webrev: http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/03/ I'll push it through our tests tonight. See further comments in line: > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Freitag, 20. April 2018 09:25 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; aarch64- > port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core-libs- > dev Libs > Subject: Re: RFR(M): 8201593: Print array length in > ArrayIndexOutOfBoundsException. > > Hi Goetz, > > This is not a file by file review ... > > On 19/04/2018 10:24 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > New webrev: > > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ > > > > I admit my wording is not optimal. > > src/hotspot/share/oops/typeArrayKlass.cpp > > Sorry but this is still far too verbose for my tastes. The type of the > array is not relevant. For the array copy its okay to indicate src or > dst array. But the message should be clear and succinct not prose-like. > Plus you have a lot of repetition in the ss.print statements when only > one thing is changing. We discussed this in some further mails. Implemented as proposed there. > src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp > > I'm not seeing why the throw_index_out_of_bounds_exception should be > tied to whether or not you have an array reference. Certainly I hate > seeing the array ref being used as an implicit bool! I split the constructor into two, one for ArrayIndexOutOfBounds, the other for IndexOutOfBounds. ... > > I extended the test to cover the exception thrown in arraycopy better > > The test seems somewhat excessive, and I now see it is because of the > more elaborate error messages you have at SAP. But with only the index > and the array length of interest here the test can be considerably smaller. > > The creation tests for ArrayIndexOutOfBoundsException don't seem > relevant in this context either. This looks more TCK like. Yes, the constructor tests are for the code not yet contributed. I simplified the tests to only check the messages. Best regards, Goetz. > > David > ----- > > > and added the elementary type to the message text. This probably > > needs improvement in the text, too. There are (currently) these cases: > > > > bject[] oa1 = new Object[10]; > > Object[] oa2 = new Object[5]; > > System.arraycopy(oa1, -17, oa2, 0, 5); > > "while trying to copy from index -17 of an object array with length 10"); > > System.arraycopy(oa1, 2, oa2, -18, 5); > > "while trying to copy to index -18 of an object array with length 5"); > > System.arraycopy(oa1, 2, oa2, 0, -19); > > "while trying to copy a negative range -19 from an object array with length > 10 to an object array with length 5"); > > System.arraycopy(oa1, 8, oa2, 0, 5); > > "while trying to copy from index 13 of an object array with length 10"); > > System.arraycopy(oa1, 1, oa2, 0, 7); > > "while trying to copy to index 7 of an object array with length 5"); > > double[] ta1 = new double[10]; > > double[] ta2 = new double[5]; > > System.arraycopy(ta1, -17, ta2, 0, 5); > > "while trying to copy from index -17 of a doubl array with length 10"); > > System.arraycopy(ta1, 2, ta2, -18, 5); > > "while trying to copy to index -18 of a double array with length 5"); > > System.arraycopy(ta1, 2, ta2, 0, -19); > > "while trying to copy a negative range -19 from a double array with length > 10 to a double array with length 5"); > > System.arraycopy(ta1, 8, ta2, 0, 5); > > "while trying to copy from index 13 of a double array with length 10"); > > System.arraycopy(ta1, 1, ta2, 0, 7); > > "while trying to copy to index 7 of a double array with length 5"); > > > > Maybe it should say: > > Arraycopy source index -1 out-of-bounds for double array of length 10. > > Arraycopy target index 10 out-of-bounds for object array of length 10. > > Negative range -19 when copying from an object array of length 10 to an > object array of length 5. > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Mittwoch, 18. April 2018 10:55 > >> To: Lindenmaier, Goetz ; hotspot-runtime- > >> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; > aarch64- > >> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core- > libs- > >> dev Libs > >> Subject: Re: RFR(M): 8201593: Print array length in > >> ArrayIndexOutOfBoundsException. > >> > >> Adding core-libs-dev as you're changing > >> java.lang.ArrayIndexOutOfBoundsException. > >> > >> I appreciate the intent here but I find the messages excessively > >> verbose. The basic error is: > >> > >> index N is outside range [0, length-1] > >> > >> David > >> > >> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> I would like to print a more verbose text on ArrayIndexOutOfBounds > >> exception > >>> that not only mentions the index, but also the length of the array > accessed. > >>> See the bug for documentation of the change of the message. > >>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ > >>> > >>> @aarch/arm people: > >>> I edited the aarch/arm files. Could you please verify this is correct? > >>> I can not build on these platforms. > >>> > >>> The code on all the other platforms is tested with all the jtreg and jck > tests > >> etc. > >>> > >>> Best regards, > >>> Goetz. > >>> > >>> From isaac.r.levy at gmail.com Tue Apr 24 16:11:33 2018 From: isaac.r.levy at gmail.com (Isaac Levy) Date: Tue, 24 Apr 2018 12:11:33 -0400 Subject: [PATCH] regex matcher opt: remove redundant StringBuilder Message-ID: (moving this to a separate discussion) --- a/src/java.base/share/classes/java/util/regex/Matcher.java +++ b/src/java.base/share/classes/java/util/regex/Matcher.java @@ -993,13 +993,11 @@ public Matcher appendReplacement(StringBuilder sb, String replacement) { // If no match, return error if (first < 0) throw new IllegalStateException("No match available"); - StringBuilder result = new StringBuilder(); - appendExpandedReplacement(replacement, result); // Append the intervening text sb.append(text, lastAppendPosition, first); // Append the match substitution + appendExpandedReplacement(replacement, sb); - sb.append(result); On Mon, Apr 23, 2018 at 5:05 PM Xueming Shen wrote: > > > I would assume in case of an exception thrown from appendExpandedReplacement() we don't > want "text" to be pushed into the "sb". > > -sherman Perhaps. Though the behavior under exception is undefined and this function is probably primarily used though the replaceAll API, which wouldn?t return the intermediate sb under the case of exception. My reading of the blame was the temp StringBuilder was an artifact of the api previously using StringBuffer externally. See http://hg.openjdk.java.net/jdk9/dev/jdk/rev/763c564451b3 From goetz.lindenmaier at sap.com Tue Apr 24 16:25:25 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 24 Apr 2018 16:25:25 +0000 Subject: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: <5ADF5897.8070809@cjnash.com> References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <5be0f86df2834aa8a881206ba285011e@sap.com> <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> <5ADF5897.8070809@cjnash.com> Message-ID: <819d942132204f58992c236518e0c344@sap.com> Hi Simon, Because as stated here, http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052665.html it is used in other places like that, too. Later mails agreed on that usage to keep it consistent. Best regards, Goetz. > -----Original Message----- > From: Simon Nash [mailto:simon at cjnash.com] > Sent: Dienstag, 24. April 2018 18:17 > To: Lindenmaier, Goetz > Cc: David Holmes ; hotspot-runtime- > dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; aarch64- > port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core-libs- > dev Libs > Subject: Re: RFR(M): 8201593: Print array length in > ArrayIndexOutOfBoundsException. > > On 24/04/2018 15:08, Lindenmaier, Goetz wrote: > > Hi, > > > > I implemented what we figured out in > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018- > April/027555.html > > > > Some examples: > > "Index 12 out-of-bounds for length 10." > > "arraycopy source index -17 out of bounds for object array[10]." > > "arraycopy destination index -18 out of bounds for double[5]." > > "arraycopy length -19 is negative." > > "arraycopy: last source index 13 out of bounds for double[10]." > > "arraycopy: last destination index 7 out of bounds for long[5]." > > > Is there a reason why the first message says "out-of-bounds" but all others > say "out of bounds"? > > Simon > > > Incremental webrev: > > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/03- > incremental/ > > Full webrev: > > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/03/ > > > > I'll push it through our tests tonight. > > > > See further comments in line: > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Freitag, 20. April 2018 09:25 > >> To: Lindenmaier, Goetz ; hotspot-runtime- > >> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; > aarch64- > >> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core- > libs- > >> dev Libs > >> Subject: Re: RFR(M): 8201593: Print array length in > >> ArrayIndexOutOfBoundsException. > >> > >> Hi Goetz, > >> > >> This is not a file by file review ... > >> > >> On 19/04/2018 10:24 PM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> New webrev: > >>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ > >>> > >>> I admit my wording is not optimal. > >> src/hotspot/share/oops/typeArrayKlass.cpp > >> > >> Sorry but this is still far too verbose for my tastes. The type of the > >> array is not relevant. For the array copy its okay to indicate src or > >> dst array. But the message should be clear and succinct not prose-like. > >> Plus you have a lot of repetition in the ss.print statements when only > >> one thing is changing. > > We discussed this in some further mails. Implemented as proposed there. > > > >> src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp > >> > >> I'm not seeing why the throw_index_out_of_bounds_exception should > be > >> tied to whether or not you have an array reference. Certainly I hate > >> seeing the array ref being used as an implicit bool! > > I split the constructor into two, one for ArrayIndexOutOfBounds, the other > > for IndexOutOfBounds. > > > > ... > > > >>> I extended the test to cover the exception thrown in arraycopy better > >> The test seems somewhat excessive, and I now see it is because of the > >> more elaborate error messages you have at SAP. But with only the index > >> and the array length of interest here the test can be considerably smaller. > >> > >> The creation tests for ArrayIndexOutOfBoundsException don't seem > >> relevant in this context either. This looks more TCK like. > > Yes, the constructor tests are for the code not yet contributed. > > I simplified the tests to only check the messages. > > > > Best regards, > > Goetz. > > > > > > > > > > > >> David > >> ----- > >> > >>> and added the elementary type to the message text. This probably > >>> needs improvement in the text, too. There are (currently) these cases: > >>> > >>> bject[] oa1 = new Object[10]; > >>> Object[] oa2 = new Object[5]; > >>> System.arraycopy(oa1, -17, oa2, 0, 5); > >>> "while trying to copy from index -17 of an object array with length 10"); > >>> System.arraycopy(oa1, 2, oa2, -18, 5); > >>> "while trying to copy to index -18 of an object array with length 5"); > >>> System.arraycopy(oa1, 2, oa2, 0, -19); > >>> "while trying to copy a negative range -19 from an object array with > length > >> 10 to an object array with length 5"); > >>> System.arraycopy(oa1, 8, oa2, 0, 5); > >>> "while trying to copy from index 13 of an object array with length 10"); > >>> System.arraycopy(oa1, 1, oa2, 0, 7); > >>> "while trying to copy to index 7 of an object array with length 5"); > >>> double[] ta1 = new double[10]; > >>> double[] ta2 = new double[5]; > >>> System.arraycopy(ta1, -17, ta2, 0, 5); > >>> "while trying to copy from index -17 of a doubl array with length 10"); > >>> System.arraycopy(ta1, 2, ta2, -18, 5); > >>> "while trying to copy to index -18 of a double array with length 5"); > >>> System.arraycopy(ta1, 2, ta2, 0, -19); > >>> "while trying to copy a negative range -19 from a double array with > length > >> 10 to a double array with length 5"); > >>> System.arraycopy(ta1, 8, ta2, 0, 5); > >>> "while trying to copy from index 13 of a double array with length 10"); > >>> System.arraycopy(ta1, 1, ta2, 0, 7); > >>> "while trying to copy to index 7 of a double array with length 5"); > >>> > >>> Maybe it should say: > >>> Arraycopy source index -1 out-of-bounds for double array of length 10. > >>> Arraycopy target index 10 out-of-bounds for object array of length 10. > >>> Negative range -19 when copying from an object array of length 10 to an > >> object array of length 5. > >>> Best regards, > >>> Goetz. > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Mittwoch, 18. April 2018 10:55 > >>>> To: Lindenmaier, Goetz ; hotspot- > runtime- > >>>> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; > >> aarch64- > >>>> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; > core- > >> libs- > >>>> dev Libs > >>>> Subject: Re: RFR(M): 8201593: Print array length in > >>>> ArrayIndexOutOfBoundsException. > >>>> > >>>> Adding core-libs-dev as you're changing > >>>> java.lang.ArrayIndexOutOfBoundsException. > >>>> > >>>> I appreciate the intent here but I find the messages excessively > >>>> verbose. The basic error is: > >>>> > >>>> index N is outside range [0, length-1] > >>>> > >>>> David > >>>> > >>>> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: > >>>>> Hi, > >>>>> > >>>>> I would like to print a more verbose text on ArrayIndexOutOfBounds > >>>> exception > >>>>> that not only mentions the index, but also the length of the array > >> accessed. > >>>>> See the bug for documentation of the change of the message. > >>>>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ > >>>>> > >>>>> @aarch/arm people: > >>>>> I edited the aarch/arm files. Could you please verify this is correct? > >>>>> I can not build on these platforms. > >>>>> > >>>>> The code on all the other platforms is tested with all the jtreg and jck > >> tests > >>>> etc. > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> From xueming.shen at oracle.com Tue Apr 24 16:53:14 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 24 Apr 2018 09:53:14 -0700 Subject: [PATCH] regex matcher opt: remove redundant StringBuilder In-Reply-To: References: Message-ID: <5ADF60FA.2020109@oracle.com> Hi Isaac, I actually meant to say "we are not supposed to output the partial text into the output buffer in case of an exception". It has nothing to do with the changeset you cited. This has been the behavior since day one/JDK1.4, though it is not specified explicitly in the API doc. The newly added StringBuilder variant simply follows this behavior. If it's really desired it is kinda doable to save that StringBuilder without the "incompatible" behavior change but just wonder if it is really worth the effort. Thanks, Sherman On 4/24/18, 9:11 AM, Isaac Levy wrote: > (moving this to a separate discussion) > > > --- a/src/java.base/share/classes/java/util/regex/Matcher.java > +++ b/src/java.base/share/classes/java/util/regex/Matcher.java > @@ -993,13 +993,11 @@ > public Matcher appendReplacement(StringBuilder sb, String replacement) { > // If no match, return error > if (first< 0) > throw new IllegalStateException("No match available"); > - StringBuilder result = new StringBuilder(); > - appendExpandedReplacement(replacement, result); > // Append the intervening text > sb.append(text, lastAppendPosition, first); > // Append the match substitution > + appendExpandedReplacement(replacement, sb); > - sb.append(result); > > > > On Mon, Apr 23, 2018 at 5:05 PM Xueming Shen wrote: >> >> I would assume in case of an exception thrown from appendExpandedReplacement() we don't >> want "text" to be pushed into the "sb". >> >> -sherman > > Perhaps. Though the behavior under exception is undefined and this > function is probably primarily used though the replaceAll API, which > wouldn?t return the intermediate sb under the case of exception. > > My reading of the blame was the temp StringBuilder was an artifact of > the api previously using StringBuffer externally. See > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/763c564451b3 From claes.redestad at oracle.com Tue Apr 24 16:57:28 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 24 Apr 2018 18:57:28 +0200 Subject: RFR: 8202184: Reduce time blocking the ClassSpecializer cache creating SpeciesData Message-ID: <151613d5-e50b-8d39-d55e-ce85ee396911@oracle.com> Hi, the current implementation of ClassSpecializer.findSpecies may cause excessive blocking due to a potentially expensive computeIfAbsent, and we have reason to believe this might have been cause for a few very rare bootstrap issues in tests that attach debuggers to VM in the middle of this. Breaking this apart so that code generation and linking is done outside of the computeIfAbsent helps minimize the risk that a thread gets interrupted by a debugger at a critical point in time, while also removing a few limitations on what we can do from a findSpecies, e.g., look up other SpeciesData. Bug: https://bugs.openjdk.java.net/browse/JDK-8202184 Webrev: http://cr.openjdk.java.net/~redestad/8202184/open.00/ This implementation inserts a placeholder, unresolved SpeciesData, and then replaces it with another instance that is linked together fully before publishing it, which ensure safe publication. There might be alternatives involving volatiles and/or careful fencing, but I've not been able to measure any added startup cost from this anyway. Thanks! /Claes From paul.sandoz at oracle.com Tue Apr 24 17:41:00 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 24 Apr 2018 10:41:00 -0700 Subject: [PATCH] Add compareToUnsigned to java.nio.*Buffer In-Reply-To: <98232eb8-1ca9-6188-89c1-7236cc6fb52c@snazy.de> References: <1d3a26e2-6dbc-e90d-781b-f0f636547263@snazy.de> <07121A81-EF65-4F60-BA69-C94F8557196A@oracle.com> <98232eb8-1ca9-6188-89c1-7236cc6fb52c@snazy.de> Message-ID: <5C9AC4FD-3BF9-4E56-8110-8603B16CD047@oracle.com> Thanks. I attached your patch to the issue: https://bugs.openjdk.java.net/browse/JDK-8202216 > On Apr 24, 2018, at 5:51 AM, Robert Stupp wrote: > > Hi Paul, > > Thank you. > > I've filed an RFE via https://bugreport.java.com/bugreport/start_form.do - seems to be JDK-9053522. It just has no option to add an attachment and I have no login to bugs.openjdk.java.net . > > > On 04/23/2018 11:16 PM, Paul Sandoz wrote: >> The addition of mismatch is reasonable. I am unsure about compareToUnsigned, since we are trying to be a conservative about what we add to Buffer. > On the one hand, it would be very nice to have compareToUnsigned() since the primitive wrapper classes have compareToUnsigned() as well. On the other hand, it would not be a big issue to build a similar functionality using *Buffer.mismatch(). > Exactly. Paul. From isaac.r.levy at gmail.com Tue Apr 24 17:47:33 2018 From: isaac.r.levy at gmail.com (Isaac Levy) Date: Tue, 24 Apr 2018 13:47:33 -0400 Subject: [PATCH] regex matcher opt: remove redundant StringBuilder In-Reply-To: <5ADF60FA.2020109@oracle.com> References: <5ADF60FA.2020109@oracle.com> Message-ID: Hi Sherman, Thanks for clarifying. Looks like exceptions are caused by invalid format string. I wouldn't expect most programs to be catching this and preserving their buffer, but dunno. How much does it affect perf? Well it depends on use case, a jmh of replaceAll with a length 200 string of digits and regex "(\w)" shows about 30% speedup. [info] Benchmark Mode Cnt Score Error Units [info] origM avgt 10 11.669 ? 0.211 us/op [info] newM avgt 10 8.926 ? 0.095 us/op Isaac On Tue, Apr 24, 2018 at 12:53 PM, Xueming Shen wrote: > Hi Isaac, > > I actually meant to say "we are not supposed to output the partial text into > the output buffer in case of an exception". It has nothing to do with the > changeset you cited. This has been the behavior since day one/JDK1.4, > though it is not specified explicitly in the API doc. The newly added > StringBuilder variant simply follows this behavior. If it's really desired > it > is kinda doable to save that StringBuilder without the "incompatible" > behavior > change but just wonder if it is really worth the effort. > > Thanks, > Sherman > > > On 4/24/18, 9:11 AM, Isaac Levy wrote: >> >> (moving this to a separate discussion) >> >> >> --- a/src/java.base/share/classes/java/util/regex/Matcher.java >> +++ b/src/java.base/share/classes/java/util/regex/Matcher.java >> @@ -993,13 +993,11 @@ >> public Matcher appendReplacement(StringBuilder sb, String >> replacement) { >> // If no match, return error >> if (first< 0) >> throw new IllegalStateException("No match available"); >> - StringBuilder result = new StringBuilder(); >> - appendExpandedReplacement(replacement, result); >> // Append the intervening text >> sb.append(text, lastAppendPosition, first); >> // Append the match substitution >> + appendExpandedReplacement(replacement, sb); >> - sb.append(result); >> >> >> >> On Mon, Apr 23, 2018 at 5:05 PM Xueming Shen >> wrote: >>> >>> >>> I would assume in case of an exception thrown from >>> appendExpandedReplacement() we don't >>> want "text" to be pushed into the "sb". >>> >>> -sherman >> >> >> Perhaps. Though the behavior under exception is undefined and this >> function is probably primarily used though the replaceAll API, which >> wouldn?t return the intermediate sb under the case of exception. >> >> My reading of the blame was the temp StringBuilder was an artifact of >> the api previously using StringBuffer externally. See >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/763c564451b3 > > From paul.sandoz at oracle.com Tue Apr 24 19:01:39 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 24 Apr 2018 12:01:39 -0700 Subject: RFR: 8202184: Reduce time blocking the ClassSpecializer cache creating SpeciesData In-Reply-To: <151613d5-e50b-8d39-d55e-ce85ee396911@oracle.com> References: <151613d5-e50b-8d39-d55e-ce85ee396911@oracle.com> Message-ID: <71198779-2512-4B98-8FD3-9D28349BC105@oracle.com> Hi, This looks good. Took me a while to understand the interactions: you need to replace not update otherwise there is a race on isResolved (which currently queries multiple state, there is no singular guard here). We could push isResolved into the synchronized block and simplify but every findSpecies call may take a small hit (or there are potentially other ways looking more closely at how ClassSpecializer.Factory initializes state, i.e. a fenced static field write, but we go further down the rabbit hole) I think this might fix some rare and intermittent recursive exceptions from ConcurrentHashMap cache we have been observing, where a collision occurs on keys for recursive updates (rather than for the same key). Paul. > On Apr 24, 2018, at 9:57 AM, Claes Redestad wrote: > > Hi, > > the current implementation of ClassSpecializer.findSpecies may cause > excessive blocking due to a potentially expensive computeIfAbsent, and > we have reason to believe this might have been cause for a few very > rare bootstrap issues in tests that attach debuggers to VM in the middle > of this. > > Breaking this apart so that code generation and linking is done outside > of the computeIfAbsent helps minimize the risk that a thread gets > interrupted by a debugger at a critical point in time, while also removing > a few limitations on what we can do from a findSpecies, e.g., look up other > SpeciesData. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202184 > Webrev: http://cr.openjdk.java.net/~redestad/8202184/open.00/ > > This implementation inserts a placeholder, unresolved SpeciesData, > and then replaces it with another instance that is linked together > fully before publishing it, which ensure safe publication. There might > be alternatives involving volatiles and/or careful fencing, but I've not > been able to measure any added startup cost from this anyway. > > Thanks! > > /Claes From brian.burkhalter at oracle.com Tue Apr 24 22:15:57 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 24 Apr 2018 15:15:57 -0700 Subject: 8202062: Put FileChannel and FileOutpuStream variants of AtomicAppend on problem list Message-ID: <9DF4F879-1D26-41E6-AA60-2B4A62B6732B@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8202062 Recently more frequent failures have been observed on macOS. Put on the problem list until the underlying cause can be determined. Thanks, Brian --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -510,8 +510,10 @@ # jdk_io +java/io/FileOutputStream/AtomicAppend.java 8202062 macosx-all java/io/pathNames/GeneralWin32.java 8180264 windows-all + ############################################################################ # jdk_management @@ -545,10 +547,12 @@ java/nio/Buffer/EqualsCompareTest.java 8193917 solaris-all +java/nio/channels/DatagramChannel/ChangingAddress.java 7141822 macosx-all + +java/nio/channels/FileChannel/AtomicAppend.java 8202062 macosx-all + java/nio/channels/Selector/Wakeup.java 6963118 windows-all -java/nio/channels/DatagramChannel/ChangingAddress.java 7141822 macosx-all - java/nio/file/WatchService/Basic.java 7158947 solaris-all Solaris 11 java/nio/file/WatchService/MayFlies.java 7158947 solaris-all Solaris 11 java/nio/file/WatchService/LotsOfCancels.java 8188039 solaris-all Solaris 11 From lance.andersen at oracle.com Tue Apr 24 22:20:54 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 24 Apr 2018 18:20:54 -0400 Subject: 8202062: Put FileChannel and FileOutpuStream variants of AtomicAppend on problem list In-Reply-To: <9DF4F879-1D26-41E6-AA60-2B4A62B6732B@oracle.com> References: <9DF4F879-1D26-41E6-AA60-2B4A62B6732B@oracle.com> Message-ID: +1 > On Apr 24, 2018, at 6:15 PM, Brian Burkhalter wrote: > > https://bugs.openjdk.java.net/browse/JDK-8202062 > > Recently more frequent failures have been observed on macOS. Put on the problem list until the underlying cause can be determined. > > Thanks, > > Brian > > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -510,8 +510,10 @@ > > # jdk_io > > +java/io/FileOutputStream/AtomicAppend.java 8202062 macosx-all > java/io/pathNames/GeneralWin32.java 8180264 windows-all > > + > ############################################################################ > > # jdk_management > @@ -545,10 +547,12 @@ > > java/nio/Buffer/EqualsCompareTest.java 8193917 solaris-all > > +java/nio/channels/DatagramChannel/ChangingAddress.java 7141822 macosx-all > + > +java/nio/channels/FileChannel/AtomicAppend.java 8202062 macosx-all > + > java/nio/channels/Selector/Wakeup.java 6963118 windows-all > > -java/nio/channels/DatagramChannel/ChangingAddress.java 7141822 macosx-all > - > java/nio/file/WatchService/Basic.java 7158947 solaris-all Solaris 11 > java/nio/file/WatchService/MayFlies.java 7158947 solaris-all Solaris 11 > java/nio/file/WatchService/LotsOfCancels.java 8188039 solaris-all Solaris 11 > 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 scolebourne at joda.org Tue Apr 24 22:32:51 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 24 Apr 2018 23:32:51 +0100 Subject: RFR: JDK-8193877- DateTimeFormatterBuilder throws ClassCastException when using padding In-Reply-To: References: <55cfb77b-b931-440a-a17d-0dbb7ff04d4c@default> Message-ID: To add to Roger's comments, the tests should cover parsing as well as formatting. It is the adjacent parsing behaviour that will be most important to test and get right. For example, Pattern "dMyyyy" cannot be parsed (is "1122018" the 1st Dec or the 11th Feb?) But this one should be parsed "ppdppMyyyy" (" 1122018" has fixed width day = 1 and fixed width month = 12) ("11 22018" has fixed width day =11 and fixed width month = 2) And as Roger says, this should be tested using DateTimrFormatterBuilder::padNext as well as the pattern letters. thanks Stephen On 18 April 2018 at 19:34, Roger Riggs wrote: > Hi Pallavi, > > The fix here seems to make padding to a fixed width incompatible with > adjacent value parsing. > That's not intuitive, since adjacent value parsing is intended to allow more > flexible parsing > of a combination leading fixed-width fields and subsequent variable length > fields. > The specification of the behavior of padding vs adjacent value parsing > should be investigated > and clarified if necessary. > > The implementation would be better expressed as checking whether the active > PrinterParser > *is* a NumberPrinterParser as a precondition for entering the adjacent > parsing mode block > (and the necessary cast). > And otherwise, fall into the existing code in which the new Parser becomes > the new active parser. > > The tests should be included in the existing test classes for padding, and > be written using > the direct DateTimeFormatterBuilder methods (padNext(), instead of the > patterns) since the patterns > are just a front end for the builder methods. > See test/java/time/format/TestPadPrinterDecorator.java > > TestDateTimeFormatter.java: > > line 96: please keep the static imports for testng together > > Line 662: The odd formatting and incorrect indentation should no longer be a > problem > because the indentation will not need to change. > > Regards, Roger > > > > On 4/18/18 8:41 AM, Pallavi Sonal wrote: >> >> Hi, >> >> Please review the changes to the following issue: >> >> Bug :https://bugs.openjdk.java.net/browse/JDK-8193877 >> >> The proposed fix is located at: >> >> Webrev :http://cr.openjdk.java.net/~rpatil/8193877/webrev.00/ >> >> >> When padding is used in a pattern where there are unpadded values adjacent >> to padded ones (like "pdQ") , the previous PrinterParser (used for parsing >> 'd' in the example ) is fetched to use its settings for parsing the next >> value('Q' in the example). But , in cases like this , it is a >> PadPrinterDecoratorParser instead of an assumed NumberPrinterParser and a >> ClassCastException is thrown. >> >> The fix has been done to check such cases where the previous parserprinter >> is PadPrinterDecoratorParser and use the new NumberPrinterParser instead for >> parsing the next value. >> >> >> All the tier1 and tier2 Mach 5 tests have passed. >> >> >> Thanks, >> >> Pallavi Sonal >> >> > > From scolebourne at joda.org Tue Apr 24 22:41:16 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 24 Apr 2018 23:41:16 +0100 Subject: [11] RFR: 8181157: CLDR Timezone name fallback implementation In-Reply-To: References: Message-ID: I had a quick look through and didn't see anything obvious, but its not an area I know well. Stephen On 17 April 2018 at 22:28, Naoto Sato wrote: > Hello, > > Please review the changes to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8181157 > > The proposed fix is located at: > > http://cr.openjdk.java.net/~naoto/8181157/webrev.05/ > > This RFE is to implement CLDR time zone names fallback mechanism [1]. Prior > to this fix, time zone names are substituted with English names. With this > change, it is generated according to the logic defined in TR 35. Here are > the highlight of the changes: > > CLDRConverter: > - CLDRConverter has changed to not substitute/invent time zone display > names, except English bundle for compatibility & runtime performance. > - For English bundle, copy over COMPAT's names as before. > - CLDRConverer now parses regionFormat/gmtZeroFormat/exemplarCity > > CLDR provider: > - CLDRTimeZoneNameProviderImpl is introduced to generate fallback names > at runtime. > - If COMPAT provider is present, use it also as a fallback, before the > last resort (GMT offset format) > > Naoto > > [1] http://www.unicode.org/reports/tr35/tr35-dates.html#Time_Zone_Names From joe.darcy at oracle.com Wed Apr 25 00:30:34 2018 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 24 Apr 2018 17:30:34 -0700 Subject: JDK 11 RFR of 8200478: For boxing conversion javac uses Long.valueOf which does not guarantee caching according to its javadoc Message-ID: Hello, Please review the patch below to update the specification of Long.valueOf(long) to require caching on [-128, 127]. The JDK implementation of this functionality has always cached in that region, even though it is not required. Additionally, please review the corresponding CSR: ??? ??? JDK-8202231: For boxing conversion javac uses Long.valueOf which does not guarantee caching according to its javadoc Thanks, -Joe diff -r f909f09569ca src/java.base/share/classes/java/lang/Long.java --- a/src/java.base/share/classes/java/lang/Long.java??? Wed Apr 18 21:10:09 2018 -0700 +++ b/src/java.base/share/classes/java/lang/Long.java??? Tue Apr 24 17:25:24 2018 -0700 @@ -1164,10 +1164,8 @@ ????? * significantly better space and time performance by caching ????? * frequently requested values. ????? * -???? * Note that unlike the {@linkplain Integer#valueOf(int) -???? * corresponding method} in the {@code Integer} class, this method -???? * is not required to cache values within a particular -???? * range. +???? * This method will always cache values in the range -128 to 127, +???? * inclusive, and may cache other values outside of this range. ????? * ????? * @param? l a long value. ????? * @return a {@code Long} instance representing {@code l}. From brian.burkhalter at oracle.com Wed Apr 25 00:41:33 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 24 Apr 2018 17:41:33 -0700 Subject: JDK 11 RFR of 8200478: For boxing conversion javac uses Long.valueOf which does not guarantee caching according to its javadoc In-Reply-To: References: Message-ID: <10B34EE4-9BF5-4319-81BE-60FA69257D7D@oracle.com> Hi Joe, On Apr 24, 2018, at 5:30 PM, joe darcy wrote: > Please review the patch below to update the specification of Long.valueOf(long) to require caching on [-128, 127]. The JDK implementation of this functionality has always cached in that region, even though it is not required. Looks fine. > Additionally, please review the corresponding CSR: > > JDK-8202231: For boxing conversion javac uses Long.valueOf which does not guarantee caching according to its javadoc Done. Brian From jonathan.gibbons at oracle.com Wed Apr 25 00:53:11 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 24 Apr 2018 17:53:11 -0700 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <87e3bc79-aa0c-3241-d8f5-8c77850f61db@oracle.com> References: <5ACFBE5C.1080508@oracle.com> <87e3bc79-aa0c-3241-d8f5-8c77850f61db@oracle.com> Message-ID: <5ADFD177.7050600@oracle.com> On 04/12/2018 10:20 PM, mandy chung wrote: > > > On 4/13/18 4:15 AM, Jonathan Gibbons wrote: >> Please review an initial implementation for the feature described in >> JEP 330: Launch Single-File Source-Code Programs. >> >> The work is described in the JEP and CSR, and falls into various parts: >> >> * The part to handle the new command-line options is in the native >> Java launcher code. >> * The part to invoke the compiler and subsequently execute the code >> found in the source file is in a new class in the jdk.compiler >> module. >> * There are some minor Makefile changes, to add support for a new >> resource file. >> >> There are no changes to javac itself. >> >> JEP: http://openjdk.java.net/jeps/330 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 >> Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ > > This looks quite good to me. One small comment on the source launcher > Main class: > > 122 } catch (InvocationTargetException e) { > 123 // leave VM to handle the stacktrace, in the standard manner > 124 throw e.getTargetException(); > 125 } > 387 } catch (InvocationTargetException e) { > 388 // remove stack frames for source launcher > 389 int invocationFrames = e.getStackTrace().length; > 390 Throwable target = e.getTargetException(); > 391 StackTraceElement[] targetTrace = target.getStackTrace(); > 392 target.setStackTrace(Arrays.copyOfRange(targetTrace, 0, targetTrace.length - invocationFrames)); > 393 throw e; > 394 } > > This could simply throw target instead of the InvocationTargetException > and then the main method can propagate the target, if thrown. > > Mandy Mandy, Yes, but that would require the execute method and its callers to declare that they throw Throwable, or at least Exception. Since the exception is already wrapped, it seems better to propagate the wrapped exception, and to only unwrap it at the last moment. -- Jon From li.jiang at oracle.com Wed Apr 25 01:33:51 2018 From: li.jiang at oracle.com (Leo Jiang) Date: Wed, 25 Apr 2018 09:33:51 +0800 Subject: [11] RFR: 8202026 8193552 : ISO 4217 Amendment #165 # 166 Update Message-ID: <5d50ddec-884c-e78c-4c2c-b9e11d8c3236@oracle.com> Hi, Please review the changes to address the ISO 4217 Amendment 165 166 update. Bug: https://bugs.openjdk.java.net/browse/JDK-8193552 165 https://bugs.openjdk.java.net/browse/JDK-8202026 166 CR: http://cr.openjdk.java.net/~ljiang/8202026/webrev.00/ Detail: #165 From: MAURITANIA Ouguiya MRO 478 2 To: MAURITANIA Ouguiya MRU 929 2 #166 From: VENEZUELA (BOLIVARIAN REPUBLIC OF) Bol?var VEF 937 2 To: VENEZUELA (BOLIVARIAN REPUBLIC OF) Bol?var Soberano VES 928 2 Thanks, Leo From li.jiang at oracle.com Wed Apr 25 01:34:20 2018 From: li.jiang at oracle.com (Leo Jiang) Date: Wed, 25 Apr 2018 09:34:20 +0800 Subject: [11] RFR: 8202026 8193552 : ISO 4217 Amendment #165 # 166 Update In-Reply-To: <5d50ddec-884c-e78c-4c2c-b9e11d8c3236@oracle.com> References: <5d50ddec-884c-e78c-4c2c-b9e11d8c3236@oracle.com> Message-ID: <004c7f91-bd26-3d7e-9dad-3172758a7a53@oracle.com> + naoto On 04/25/2018 09:33 AM, Leo Jiang wrote: > Hi, > > Please review the changes to address the ISO 4217 Amendment 165 166 update. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8193552? 165 > https://bugs.openjdk.java.net/browse/JDK-8202026? 166 > > CR: > http://cr.openjdk.java.net/~ljiang/8202026/webrev.00/ > > > Detail: > #165 > From: > MAURITANIA??? Ouguiya??? MRO??? 478??? 2 > To: > MAURITANIA??? Ouguiya??? MRU??? 929??? 2 > > #166 > From: > VENEZUELA (BOLIVARIAN REPUBLIC OF)??? Bol?var??? VEF??? 937??? 2 > To: > VENEZUELA (BOLIVARIAN REPUBLIC OF)??? Bol?var Soberano??? VES??? 928??? 2 > > > Thanks, > Leo From xueming.shen at oracle.com Wed Apr 25 01:38:41 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 24 Apr 2018 18:38:41 -0700 Subject: [PATCH] regex matcher opt: remove redundant StringBuilder In-Reply-To: References: <5ADF60FA.2020109@oracle.com> Message-ID: <5ADFDC21.2040909@oracle.com> for String based replaceAll/First() it might be worth doing something like http://cr.openjdk.java.net/~sherman/regex_removesb/webrev/ On 4/24/18, 10:47 AM, Isaac Levy wrote: > Hi Sherman, > > Thanks for clarifying. Looks like exceptions are caused by invalid > format string. I wouldn't expect most programs to be catching this and > preserving their buffer, but dunno. > > How much does it affect perf? Well it depends on use case, a jmh of > replaceAll with a length 200 string of digits and regex "(\w)" shows > about 30% speedup. > > [info] Benchmark Mode Cnt Score Error Units > [info] origM avgt 10 11.669 ? 0.211 us/op > [info] newM avgt 10 8.926 ? 0.095 us/op > > Isaac > > > On Tue, Apr 24, 2018 at 12:53 PM, Xueming Shen wrote: >> Hi Isaac, >> >> I actually meant to say "we are not supposed to output the partial text into >> the output buffer in case of an exception". It has nothing to do with the >> changeset you cited. This has been the behavior since day one/JDK1.4, >> though it is not specified explicitly in the API doc. The newly added >> StringBuilder variant simply follows this behavior. If it's really desired >> it >> is kinda doable to save that StringBuilder without the "incompatible" >> behavior >> change but just wonder if it is really worth the effort. >> >> Thanks, >> Sherman >> >> >> On 4/24/18, 9:11 AM, Isaac Levy wrote: >>> (moving this to a separate discussion) >>> >>> >>> --- a/src/java.base/share/classes/java/util/regex/Matcher.java >>> +++ b/src/java.base/share/classes/java/util/regex/Matcher.java >>> @@ -993,13 +993,11 @@ >>> public Matcher appendReplacement(StringBuilder sb, String >>> replacement) { >>> // If no match, return error >>> if (first< 0) >>> throw new IllegalStateException("No match available"); >>> - StringBuilder result = new StringBuilder(); >>> - appendExpandedReplacement(replacement, result); >>> // Append the intervening text >>> sb.append(text, lastAppendPosition, first); >>> // Append the match substitution >>> + appendExpandedReplacement(replacement, sb); >>> - sb.append(result); >>> >>> >>> >>> On Mon, Apr 23, 2018 at 5:05 PM Xueming Shen >>> wrote: >>>> >>>> I would assume in case of an exception thrown from >>>> appendExpandedReplacement() we don't >>>> want "text" to be pushed into the "sb". >>>> >>>> -sherman >>> >>> Perhaps. Though the behavior under exception is undefined and this >>> function is probably primarily used though the replaceAll API, which >>> wouldn?t return the intermediate sb under the case of exception. >>> >>> My reading of the blame was the temp StringBuilder was an artifact of >>> the api previously using StringBuffer externally. See >>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/763c564451b3 >> From mandy.chung at oracle.com Wed Apr 25 03:37:31 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 25 Apr 2018 11:37:31 +0800 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5ADFD177.7050600@oracle.com> References: <5ACFBE5C.1080508@oracle.com> <87e3bc79-aa0c-3241-d8f5-8c77850f61db@oracle.com> <5ADFD177.7050600@oracle.com> Message-ID: <5b920f09-11e3-1a95-56d6-7daf66db0a91@oracle.com> On 4/25/18 8:53 AM, Jonathan Gibbons wrote: > > > On 04/12/2018 10:20 PM, mandy chung wrote: > >> >> This looks quite good to me.? One small comment on the source >> launcher Main class: >> >> 122 } catch (InvocationTargetException e) { >> 123 // leave VM to handle the stacktrace, in the standard manner >> 124 throw e.getTargetException(); >> 125 } >> 387 } catch (InvocationTargetException e) { >> 388 // remove stack frames for source launcher >> 389 int invocationFrames = e.getStackTrace().length; >> 390 Throwable target = e.getTargetException(); >> 391 StackTraceElement[] targetTrace = target.getStackTrace(); >> 392 target.setStackTrace(Arrays.copyOfRange(targetTrace, 0, targetTrace.length - invocationFrames)); >> 393 throw e; >> 394 } >> >> This could simply throw target instead of the InvocationTargetException >> and then the main method can propagate the target, if thrown. >> >> Mandy > > Mandy, > > Yes, but that would require the execute method and its callers to > declare that they throw Throwable, > or at least Exception. Since the exception is already wrapped, it > seems better to propagate the > wrapped exception, and to only unwrap it at the last moment. > Either way works for me. Mandy From li.jiang at oracle.com Wed Apr 25 03:52:59 2018 From: li.jiang at oracle.com (Leo Jiang) Date: Wed, 25 Apr 2018 11:52:59 +0800 Subject: [11] RFR: 8202026 8193552 : ISO 4217 Amendment #165 # 166 Update In-Reply-To: <5d50ddec-884c-e78c-4c2c-b9e11d8c3236@oracle.com> References: <5d50ddec-884c-e78c-4c2c-b9e11d8c3236@oracle.com> Message-ID: <62217aa4-16c5-2ec2-15f7-177d0906c53b@oracle.com> Forgot to mention, the tests in Currency fold are passed on Mach5. -Leo On 04/25/2018 09:33 AM, Leo Jiang wrote: > Hi, > > Please review the changes to address the ISO 4217 Amendment 165 166 update. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8193552? 165 > https://bugs.openjdk.java.net/browse/JDK-8202026? 166 > > CR: > http://cr.openjdk.java.net/~ljiang/8202026/webrev.00/ > > > Detail: > #165 > From: > MAURITANIA??? Ouguiya??? MRO??? 478??? 2 > To: > MAURITANIA??? Ouguiya??? MRU??? 929??? 2 > > #166 > From: > VENEZUELA (BOLIVARIAN REPUBLIC OF)??? Bol?var??? VEF??? 937??? 2 > To: > VENEZUELA (BOLIVARIAN REPUBLIC OF)??? Bol?var Soberano??? VES??? 928??? 2 > > > Thanks, > Leo From joe.darcy at oracle.com Wed Apr 25 04:14:47 2018 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 24 Apr 2018 21:14:47 -0700 Subject: RFR of JDK-8201469,test under java/rmi should be restricted to not run concurrently In-Reply-To: References: <36dd9cd1-d748-b67e-3bff-edee4cab5edd@oracle.com> <608c4a45-1dba-c5f4-92ac-8ed8be66468f@oracle.com> Message-ID: Combining the reformatting and test additions makes the patch more difficult to review. The net effect seems to be adding the following directories to the exclusiveAccess.dirs list: ? 44???? sun/management/jmxremote \ ? 45???? sun/rmi \ ? 46???? sun/security/mscapi \ ? 47???? sun/tools/jstatd Is that correct? Please characterize the number of tests added to the list and the expected performance impact on the tier 3 test group. Thanks, -Joe On 4/23/2018 11:47 AM, Paul Sandoz wrote: > Hi Hamlin, > > Do you have a sense of what rmi tests are problematic to run concurrently? Maybe you can subset to reduce the increased impact on execution time? > > Paul. > >> On Apr 20, 2018, at 12:21 AM, Hamlin Li wrote: >> >> Is someone available to review the following patch? >> >> Thank you >> >> -Hamlin >> >> >> On 19/04/2018 4:17 PM, Hamlin Li wrote: >>> would you please review the following patch? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8201469 >>> >>> http://cr.openjdk.java.net/~mli/8201469/webrev.00/ >>> >>> ( For othervm.dirs property, I just reformat it. ) >>> >>> >>> In my test result, with jtreg option "-concurrency:4", after apply the patch, tier3 tests on different platforms will be slower about 1.5~2.0 times than before. >>> I think stability of tests are more important than executing time, how do you think about it? >>> >>> Thank you >>> -Hamlin From simon at cjnash.com Tue Apr 24 16:17:27 2018 From: simon at cjnash.com (Simon Nash) Date: Tue, 24 Apr 2018 17:17:27 +0100 Subject: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException. In-Reply-To: References: <504bdd8469bb45cc8c5cf790d1f4b3fc@sap.com> <4ca91dfb-c576-98e2-1222-ca9750a64177@oracle.com> <5be0f86df2834aa8a881206ba285011e@sap.com> <0b881c69-79af-2a8b-c34c-5929357ca8fa@oracle.com> Message-ID: <5ADF5897.8070809@cjnash.com> On 24/04/2018 15:08, Lindenmaier, Goetz wrote: > Hi, > > I implemented what we figured out in > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-April/027555.html > > Some examples: > "Index 12 out-of-bounds for length 10." > "arraycopy source index -17 out of bounds for object array[10]." > "arraycopy destination index -18 out of bounds for double[5]." > "arraycopy length -19 is negative." > "arraycopy: last source index 13 out of bounds for double[10]." > "arraycopy: last destination index 7 out of bounds for long[5]." > Is there a reason why the first message says "out-of-bounds" but all others say "out of bounds"? Simon > Incremental webrev: > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/03-incremental/ > Full webrev: > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/03/ > > I'll push it through our tests tonight. > > See further comments in line: > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Freitag, 20. April 2018 09:25 >> To: Lindenmaier, Goetz ; hotspot-runtime- >> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; aarch64- >> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core-libs- >> dev Libs >> Subject: Re: RFR(M): 8201593: Print array length in >> ArrayIndexOutOfBoundsException. >> >> Hi Goetz, >> >> This is not a file by file review ... >> >> On 19/04/2018 10:24 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> New webrev: >>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/02/ >>> >>> I admit my wording is not optimal. >> src/hotspot/share/oops/typeArrayKlass.cpp >> >> Sorry but this is still far too verbose for my tastes. The type of the >> array is not relevant. For the array copy its okay to indicate src or >> dst array. But the message should be clear and succinct not prose-like. >> Plus you have a lot of repetition in the ss.print statements when only >> one thing is changing. > We discussed this in some further mails. Implemented as proposed there. > >> src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp >> >> I'm not seeing why the throw_index_out_of_bounds_exception should be >> tied to whether or not you have an array reference. Certainly I hate >> seeing the array ref being used as an implicit bool! > I split the constructor into two, one for ArrayIndexOutOfBounds, the other > for IndexOutOfBounds. > > ... > >>> I extended the test to cover the exception thrown in arraycopy better >> The test seems somewhat excessive, and I now see it is because of the >> more elaborate error messages you have at SAP. But with only the index >> and the array length of interest here the test can be considerably smaller. >> >> The creation tests for ArrayIndexOutOfBoundsException don't seem >> relevant in this context either. This looks more TCK like. > Yes, the constructor tests are for the code not yet contributed. > I simplified the tests to only check the messages. > > Best regards, > Goetz. > > > > > >> David >> ----- >> >>> and added the elementary type to the message text. This probably >>> needs improvement in the text, too. There are (currently) these cases: >>> >>> bject[] oa1 = new Object[10]; >>> Object[] oa2 = new Object[5]; >>> System.arraycopy(oa1, -17, oa2, 0, 5); >>> "while trying to copy from index -17 of an object array with length 10"); >>> System.arraycopy(oa1, 2, oa2, -18, 5); >>> "while trying to copy to index -18 of an object array with length 5"); >>> System.arraycopy(oa1, 2, oa2, 0, -19); >>> "while trying to copy a negative range -19 from an object array with length >> 10 to an object array with length 5"); >>> System.arraycopy(oa1, 8, oa2, 0, 5); >>> "while trying to copy from index 13 of an object array with length 10"); >>> System.arraycopy(oa1, 1, oa2, 0, 7); >>> "while trying to copy to index 7 of an object array with length 5"); >>> double[] ta1 = new double[10]; >>> double[] ta2 = new double[5]; >>> System.arraycopy(ta1, -17, ta2, 0, 5); >>> "while trying to copy from index -17 of a doubl array with length 10"); >>> System.arraycopy(ta1, 2, ta2, -18, 5); >>> "while trying to copy to index -18 of a double array with length 5"); >>> System.arraycopy(ta1, 2, ta2, 0, -19); >>> "while trying to copy a negative range -19 from a double array with length >> 10 to a double array with length 5"); >>> System.arraycopy(ta1, 8, ta2, 0, 5); >>> "while trying to copy from index 13 of a double array with length 10"); >>> System.arraycopy(ta1, 1, ta2, 0, 7); >>> "while trying to copy to index 7 of a double array with length 5"); >>> >>> Maybe it should say: >>> Arraycopy source index -1 out-of-bounds for double array of length 10. >>> Arraycopy target index 10 out-of-bounds for object array of length 10. >>> Negative range -19 when copying from an object array of length 10 to an >> object array of length 5. >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Mittwoch, 18. April 2018 10:55 >>>> To: Lindenmaier, Goetz ; hotspot-runtime- >>>> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; >> aarch64- >>>> port-dev at openjdk.java.net; aarch32-port-dev at openjdk.java.net; core- >> libs- >>>> dev Libs >>>> Subject: Re: RFR(M): 8201593: Print array length in >>>> ArrayIndexOutOfBoundsException. >>>> >>>> Adding core-libs-dev as you're changing >>>> java.lang.ArrayIndexOutOfBoundsException. >>>> >>>> I appreciate the intent here but I find the messages excessively >>>> verbose. The basic error is: >>>> >>>> index N is outside range [0, length-1] >>>> >>>> David >>>> >>>> On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I would like to print a more verbose text on ArrayIndexOutOfBounds >>>> exception >>>>> that not only mentions the index, but also the length of the array >> accessed. >>>>> See the bug for documentation of the change of the message. >>>>> http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ >>>>> >>>>> @aarch/arm people: >>>>> I edited the aarch/arm files. Could you please verify this is correct? >>>>> I can not build on these platforms. >>>>> >>>>> The code on all the other platforms is tested with all the jtreg and jck >> tests >>>> etc. >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> From Alan.Bateman at oracle.com Wed Apr 25 06:05:42 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 Apr 2018 07:05:42 +0100 Subject: 8202062: Put FileChannel and FileOutpuStream variants of AtomicAppend on problem list In-Reply-To: <9DF4F879-1D26-41E6-AA60-2B4A62B6732B@oracle.com> References: <9DF4F879-1D26-41E6-AA60-2B4A62B6732B@oracle.com> Message-ID: <4223b760-a848-9e66-5642-13d43beeabc3@oracle.com> On 24/04/2018 23:15, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8202062 > > Recently more frequent failures have been observed on macOS. Put on the problem list until the underlying cause can be determined. > I think it would be better to change the tests to pass silently when running on macOS 10.13 or higher. At least from first look, that is where the issue is. -Alan From peter.levart at gmail.com Wed Apr 25 06:36:44 2018 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 25 Apr 2018 08:36:44 +0200 Subject: RFR: 8202184: Reduce time blocking the ClassSpecializer cache creating SpeciesData In-Reply-To: <151613d5-e50b-8d39-d55e-ce85ee396911@oracle.com> References: <151613d5-e50b-8d39-d55e-ce85ee396911@oracle.com> Message-ID: Hi Claes, Nice play with CHM and safe publication. If findSpecies() is on a hot concurrent path, you might want to wrap the preface: ?176???????? S speciesData = cache.computeIfAbsent(key, new Function<>() { ?177???????????? @Override ?178???????????? public S apply(K key1) { ?179???????????????? return newSpeciesData(key1); ?180???????????? } ?181???????? }); with a simple: S speciesData = cache.get(key); if (speciesData == null) { ??? speciesData = cache.computeIfAbsent(....); } or even use putIfAbsent instead if redundant concurrent newSpeciesData is OK. This way you can avoid hot-path synchronization with locks that CHM always performs in computeIfAbsent. Regards, Peter On 04/24/18 18:57, Claes Redestad wrote: > Hi, > > the current implementation of ClassSpecializer.findSpecies may cause > excessive blocking due to a potentially expensive computeIfAbsent, and > we have reason to believe this might have been cause for a few very > rare bootstrap issues in tests that attach debuggers to VM in the middle > of this. > > Breaking this apart so that code generation and linking is done outside > of the computeIfAbsent helps minimize the risk that a thread gets > interrupted by a debugger at a critical point in time, while also > removing > a few limitations on what we can do from a findSpecies, e.g., look up > other > SpeciesData. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202184 > Webrev: http://cr.openjdk.java.net/~redestad/8202184/open.00/ > > This implementation inserts a placeholder, unresolved SpeciesData, > and then replaces it with another instance that is linked together > fully before publishing it, which ensure safe publication. There might > be alternatives involving volatiles and/or careful fencing, but I've not > been able to measure any added startup cost from this anyway. > > Thanks! > > /Claes From huaming.li at oracle.com Wed Apr 25 07:14:03 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 25 Apr 2018 15:14:03 +0800 Subject: RFR of JDK-8201469,test under java/rmi should be restricted to not run concurrently In-Reply-To: References: <36dd9cd1-d748-b67e-3bff-edee4cab5edd@oracle.com> <608c4a45-1dba-c5f4-92ac-8ed8be66468f@oracle.com> Message-ID: <288f62a1-00bf-eea6-098d-c788b545ef76@oracle.com> Hi Paul, Joe, Thank you for the comments. Following directories are added in the exclusiveAccess.dirs list: */? java/rmi?? (so, java/rmi/Naming is removed)/**/ /**/? com/sun/jndi/rmi/**/ /**/? sun/rmi/* for the test/bug number and time cost please check following table, here time cost is the number on my local machine. added directories test number run time subdirectories test number bug number java/rmi 120 run time in -conc:4, 8:09 (14:15:16 -?14:07:07) run time in sequence, 18:17 (14:44:00 -?14:25:43) MarshalledObject 4 0 Naming 6 2 RMISecurityManager/checkPackageAccess 1 0 RemoteException/chaining 1 0 activation 31 23 dgc 4 0 invalidName 1 0 module 1 0 registry 9 1 reliability 3 2 server 45 7 transport 13 6 com/sun/jndi/rmi 2 0 sun/rmi 17 run time in -conc:4,?00:44 (14:52:08 -?14:51:24) run time in sequence, 00:51 (14:48:10 - 14:47:19) 2 @Paul, Good suggestion, I tried to figure out a subset, but most of intermittent rmi test failures happen in java/rmi/[activation, server, transport, Naming, reliability, registry] and sun/rmi, they are almost all of rmi tests. I'm not sure if it's worth to subset them. I can do it if you think it's necessary. ( [1] lists rmi open issue in open area. ) Thank you -Hamlin [1] https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20component%20%3D%20core-libs%20and%20Subcomponent%20%3D%20java.rmi%20and%20status%20in%20(open%2C%20new%2C%20%22In%20Progress%22)%20ORDER%20BY%20updatedDate%20DESC On 25/04/2018 12:14 PM, joe darcy wrote: > Combining the reformatting and test additions makes the patch more > difficult to review. The net effect seems to be adding the following > directories to the exclusiveAccess.dirs list: > > ? 44???? sun/management/jmxremote \ > ? 45???? sun/rmi \ > ? 46???? sun/security/mscapi \ > ? 47???? sun/tools/jstatd > > Is that correct? > > Please characterize the number of tests added to the list and the > expected performance impact on the tier 3 test group. > > Thanks, > > -Joe > > > On 4/23/2018 11:47 AM, Paul Sandoz wrote: >> Hi Hamlin, >> >> Do you have a sense of what rmi tests are problematic to run >> concurrently? Maybe you can subset to reduce the increased impact on >> execution time? >> >> Paul. >> >>> On Apr 20, 2018, at 12:21 AM, Hamlin Li wrote: >>> >>> Is someone available to review the following patch? >>> >>> Thank you >>> >>> -Hamlin >>> >>> >>> On 19/04/2018 4:17 PM, Hamlin Li wrote: >>>> would you please review the following patch? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8201469 >>>> >>>> http://cr.openjdk.java.net/~mli/8201469/webrev.00/ >>>> >>>> ( For othervm.dirs property, I just reformat it. ) >>>> >>>> >>>> In my test result, with jtreg option "-concurrency:4", after apply >>>> the patch, tier3 tests on different platforms will be slower about >>>> 1.5~2.0 times than before. >>>> I think stability of tests are more important than executing time, >>>> how do you think about it? >>>> >>>> Thank you >>>> -Hamlin > From claes.redestad at oracle.com Wed Apr 25 08:06:35 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 25 Apr 2018 10:06:35 +0200 Subject: RFR: 8202184: Reduce time blocking the ClassSpecializer cache creating SpeciesData In-Reply-To: References: <151613d5-e50b-8d39-d55e-ce85ee396911@oracle.com> Message-ID: Hi Peter, On 2018-04-25 08:36, Peter Levart wrote: > Hi Claes, > > Nice play with CHM and safe publication. thanks, I was curious how you'd react to this. :-) > > If findSpecies() is on a hot concurrent path, [...] It'd be surprising if it was: findSpecies is typically called once for a specific SpeciesData, and sometimes every now and then during setup of certain method handles (in particular the static speciesData_L* methods in jli.BoundMethodHandle are begging to be turned into lazy constants). Besides, CHM.computeIfAbsent has a non-synchronizing fast-path for when the key exists, lines 1731-1734: ??????????? else if (fh == h??? // check first node without acquiring lock ???????????????????? && ((fk = f.key) == key || (fk != null && key.equals(fk))) ???????????????????? && (fv = f.val) != null) ??????????????? return fv; .. so I'm not sure we'd gain much from wrapping the preface with a get even if it was hot and contended. /Claes From claes.redestad at oracle.com Wed Apr 25 08:11:32 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 25 Apr 2018 10:11:32 +0200 Subject: RFR: 8202184: Reduce time blocking the ClassSpecializer cache creating SpeciesData In-Reply-To: <71198779-2512-4B98-8FD3-9D28349BC105@oracle.com> References: <151613d5-e50b-8d39-d55e-ce85ee396911@oracle.com> <71198779-2512-4B98-8FD3-9D28349BC105@oracle.com> Message-ID: <969cd860-18e6-dbaa-e9cd-4fcfa78be560@oracle.com> Hi Paul, On 2018-04-24 21:01, Paul Sandoz wrote: > Hi, > > This looks good. thanks! > Took me a while to understand the interactions: you need to replace not update otherwise there is a race on isResolved (which currently queries multiple state, there is no singular guard here). We could push isResolved into the synchronized block and simplify but every findSpecies call may take a small hit (or there are potentially other ways looking more closely at how ClassSpecializer.Factory initializes state, i.e. a fenced static field write, but we go further down the rabbit hole) Right, I've been down that hole unsuccessfully and came up with this 'play' (a much nicer word than 'hack'; thanks Peter!) as a means to escape it. :-) > > I think this might fix some rare and intermittent recursive exceptions from ConcurrentHashMap cache we have been observing, where a collision occurs on keys for recursive updates (rather than for the same key). I think so, too, but as I've not been able to reproduce any of these rare intermittent issues locally I've no real evidence to that effect. /Claes From peter.levart at gmail.com Wed Apr 25 09:07:47 2018 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 25 Apr 2018 11:07:47 +0200 Subject: RFR: 8202184: Reduce time blocking the ClassSpecializer cache creating SpeciesData In-Reply-To: References: <151613d5-e50b-8d39-d55e-ce85ee396911@oracle.com> Message-ID: <32dcb395-8d0c-d8ac-480d-b51488a78293@gmail.com> On 04/25/2018 10:06 AM, Claes Redestad wrote: > Besides, CHM.computeIfAbsent has a non-synchronizing fast-path for > when the key exists, > lines 1731-1734: > > ??????????? else if (fh == h??? // check first node without acquiring > lock > ???????????????????? && ((fk = f.key) == key || (fk != null && > key.equals(fk))) > ???????????????????? && (fv = f.val) != null) > ??????????????? return fv; Sorry, you're (almost) right! I confused it with CHM.compute()... The almost part is that lock is avoided only when the match is found in the 1st linked node of the bucket. If there is a hash collision (very unlikely) and the entry is in a 2nd or subsequent node in the list, the lock is still used. So there's almost no locks used... And if there's no hot contention going on, there's no need for prefacing with .get(). Regards, Peter From jan.lahoda at oracle.com Wed Apr 25 11:50:06 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 25 Apr 2018 13:50:06 +0200 Subject: RFR: JDK-8202105: jshell tool: on exiting, terminal echo is disabled Message-ID: <5AE06B6E.2060902@oracle.com> Hi, Under: https://bugs.openjdk.java.net/browse/JDK-8194750 j.i.Console was changed to capture the state of the terminal echo at creation time, and to restore it on shutdown. That is problematic at least in jshell, where the terminal is already in the raw mode when j.i.Console is created, and so "echo disabled" is recorded there. So even though jshell itself sets the terminal into the original mode when it terminates, the shutdown hook in j.i.Console, which is run later, sets the echo to off even if it was enabled before the VM started. My understanding is that the shutdown hook is only needed in case the VM goes down while readPassword is running. So I tried to change the shutdown hook to only work while readPassword is running. Bug: https://bugs.openjdk.java.net/browse/JDK-8202105 Webrev: http://cr.openjdk.java.net/~jlahoda/8202105/webrev.00/ What do you think? Thanks, Jan From david.holmes at oracle.com Wed Apr 25 12:08:22 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 Apr 2018 22:08:22 +1000 Subject: JDK 11 RFR of 8200478: For boxing conversion javac uses Long.valueOf which does not guarantee caching according to its javadoc In-Reply-To: References: Message-ID: <115abbdd-a430-e9c3-f3cd-d705edfa7f15@oracle.com> Hi Joe, On 25/04/2018 10:30 AM, joe darcy wrote: > Hello, > > Please review the patch below to update the specification of > Long.valueOf(long) to require caching on [-128, 127]. The JDK > implementation of this functionality has always cached in that region, > even though it is not required. Seems very explicit that there is no requirement for Long to do caching. So why should that change? Or put another way what has changed that invalidates that clearly stated position? Thanks, David > Additionally, please review the corresponding CSR: > > ??? ??? JDK-8202231: For boxing conversion javac uses Long.valueOf > which does not guarantee caching according to its javadoc > > Thanks, > > -Joe > > diff -r f909f09569ca src/java.base/share/classes/java/lang/Long.java > --- a/src/java.base/share/classes/java/lang/Long.java??? Wed Apr 18 > 21:10:09 2018 -0700 > +++ b/src/java.base/share/classes/java/lang/Long.java??? Tue Apr 24 > 17:25:24 2018 -0700 > @@ -1164,10 +1164,8 @@ > ????? * significantly better space and time performance by caching > ????? * frequently requested values. > ????? * > -???? * Note that unlike the {@linkplain Integer#valueOf(int) > -???? * corresponding method} in the {@code Integer} class, this method > -???? * is not required to cache values within a particular > -???? * range. > +???? * This method will always cache values in the range -128 to 127, > +???? * inclusive, and may cache other values outside of this range. > ????? * > ????? * @param? l a long value. > ????? * @return a {@code Long} instance representing {@code l}. > From adam.farley at uk.ibm.com Wed Apr 25 15:03:20 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 25 Apr 2018 16:03:20 +0100 Subject: [PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for Direct Byte Buffers Message-ID: > On 13/04/2018 15:14, Adam Farley8 wrote: >> Hi Alan, Peter, >> >> I see that native memory is tracked in java.nio.Bits, but that only includes what the user thinks they are allocating. >> >> When the VM adds extra memory to the allocation amount this extra bit is not represented in the Bits total. >> A cursory glance shows, minimum, that we round the requested memory quantity up to the heap word size in >> the Unsafe.allocateMemory code, and something to do with nmt_header_size in os:malloc() (os.cpp) too. > Is the align_up(sz, HeapWordSize) really causing an issue? Coupled with the nmt_header_size business, it makes the Bits values wrong. The more DBB allocations, the more inaccurate those numbers will be. > > We could change Bits to align with HotSpot. The BufferPoolMXBean API allows the capacity and memory usage to differ (when we originally added this, direct buffers were page aligned) so doing this would mean it more accurately reflects the memory allocated to direct buffers. > > -Alan I agree with you that the "+x" information should be added to only one of the two atomic longs. To get "X", it seems to me that the best option would be to introduce an native method in Bits that fetches "X" directly from Hotspot, using the same code that Hotspot uses (so we'd have to abstract-out the Hotspot logic that adds X to the memory quantity). This way, anyone modifying the Hotspot logic won't risk rendering the Bits logic wrong again. Best Regards Adam Farley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From joe.darcy at oracle.com Wed Apr 25 15:18:51 2018 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 25 Apr 2018 08:18:51 -0700 Subject: JDK 11 RFR of 8200478: For boxing conversion javac uses Long.valueOf which does not guarantee caching according to its javadoc In-Reply-To: <115abbdd-a430-e9c3-f3cd-d705edfa7f15@oracle.com> References: <115abbdd-a430-e9c3-f3cd-d705edfa7f15@oracle.com> Message-ID: <43e6619d-89d5-6b3d-3ff3-4dbe121dd413@oracle.com> Hi David, On 4/25/2018 5:08 AM, David Holmes wrote: > Hi Joe, > > On 25/04/2018 10:30 AM, joe darcy wrote: >> Hello, >> >> Please review the patch below to update the specification of >> Long.valueOf(long) to require caching on [-128, 127]. The JDK >> implementation of this functionality has always cached in that >> region, even though it is not required. > > Seems very explicit that there is no requirement for Long to do > caching. So why should that change? Or put another way what has > changed that invalidates that clearly stated position? > JLS 9 changed the requirements on autobox caching going from Java SE 8 to 9: https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.7 vs https://docs.oracle.com/javase/specs/jls/se9/html/jls-5.html#jls-5.1.7 The Long.valueOf method is used to implement autoboxing and its caching spec wasn't updated accordingly at the time. Cheers, -Joe From adam.farley at uk.ibm.com Wed Apr 25 15:44:53 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 25 Apr 2018 16:44:53 +0100 Subject: RFR: JDK-8190187: C++ code calling JNI_CreateJavaVM can be killed by Java Message-ID: Hi All, Here is the code to resolve JDK-8190187: http://cr.openjdk.java.net/~mhorie/8190187/hg_diff.txt Could a committer please take the fix and: 1) Complete the CSR process for the new JNI Return code. 2) Commit the changes that contain the Return code. And, optionally, 3) Perform 1 and 2 for the jdwp agent changes as well, so it can use this new functionality. Let me know if you need any help. :) Best Regards Adam Farley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From xueming.shen at oracle.com Wed Apr 25 15:52:44 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 25 Apr 2018 08:52:44 -0700 Subject: RFR: JDK-8202105: jshell tool: on exiting, terminal echo is disabled In-Reply-To: <5AE06B6E.2060902@oracle.com> References: <5AE06B6E.2060902@oracle.com> Message-ID: <5AE0A44C.80408@oracle.com> Hi Jan, I saw System.console() returns null inside jshell ... but it seems there are 2 vms. I would assume jshell itself sets the terminal to raw and then call System.console()? for example an alternative for this issue is to ask jshell's impl to call System.console() before going into raw mode? No, I'm not saying the proposed one is not a good one, just wanted to make sure I understand the situation correctly. Thanks, Sherman On 4/25/18, 4:50 AM, Jan Lahoda wrote: > Hi, > > Under: > https://bugs.openjdk.java.net/browse/JDK-8194750 > > j.i.Console was changed to capture the state of the terminal echo at > creation time, and to restore it on shutdown. > > That is problematic at least in jshell, where the terminal is already > in the raw mode when j.i.Console is created, and so "echo disabled" is > recorded there. So even though jshell itself sets the terminal into > the original mode when it terminates, the shutdown hook in > j.i.Console, which is run later, sets the echo to off even if it was > enabled before the VM started. > > My understanding is that the shutdown hook is only needed in case the > VM goes down while readPassword is running. So I tried to change the > shutdown hook to only work while readPassword is running. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202105 > Webrev: http://cr.openjdk.java.net/~jlahoda/8202105/webrev.00/ > > What do you think? > > Thanks, > Jan From jonathan.gibbons at oracle.com Wed Apr 25 15:57:27 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 25 Apr 2018 08:57:27 -0700 Subject: JDK 11 RFR of 8200478: For boxing conversion javac uses Long.valueOf which does not guarantee caching according to its javadoc In-Reply-To: <43e6619d-89d5-6b3d-3ff3-4dbe121dd413@oracle.com> References: <115abbdd-a430-e9c3-f3cd-d705edfa7f15@oracle.com> <43e6619d-89d5-6b3d-3ff3-4dbe121dd413@oracle.com> Message-ID: Joe, While I note that the primary text has been modified to include long types, the italic comment that follows still ends with the following: Notice that integer literals of type|long|are allowed, but not required, to be shared. -- Jon On 4/25/18 8:18 AM, joe darcy wrote: > Hi David, > > On 4/25/2018 5:08 AM, David Holmes wrote: >> Hi Joe, >> >> On 25/04/2018 10:30 AM, joe darcy wrote: >>> Hello, >>> >>> Please review the patch below to update the specification of >>> Long.valueOf(long) to require caching on [-128, 127]. The JDK >>> implementation of this functionality has always cached in that >>> region, even though it is not required. >> >> Seems very explicit that there is no requirement for Long to do >> caching. So why should that change? Or put another way what has >> changed that invalidates that clearly stated position? >> > > JLS 9 changed the requirements on autobox caching going from Java SE 8 > to 9: > > https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.7 > > vs > > https://docs.oracle.com/javase/specs/jls/se9/html/jls-5.html#jls-5.1.7 > > The Long.valueOf method is used to implement autoboxing and its > caching spec wasn't updated accordingly at the time. > > Cheers, > > -Joe From martinrb at google.com Wed Apr 25 16:02:42 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 25 Apr 2018 09:02:42 -0700 Subject: RFR: JDK-8202105: jshell tool: on exiting, terminal echo is disabled In-Reply-To: <5AE0A44C.80408@oracle.com> References: <5AE06B6E.2060902@oracle.com> <5AE0A44C.80408@oracle.com> Message-ID: It would be more correct I think for Console to track if there is a pending readPassword in progress and try to restore echo on exit only if so. But a little annoying to implement (need an additional boolean?) On Wed, Apr 25, 2018 at 8:52 AM, Xueming Shen wrote: > > Hi Jan, > > I saw System.console() returns null inside jshell ... but it seems there > are 2 vms. > I would assume jshell itself sets the terminal to raw and then call > System.console()? > for example an alternative for this issue is to ask jshell's impl to call > System.console() > before going into raw mode? No, I'm not saying the proposed one is not a > good one, > just wanted to make sure I understand the situation correctly. > > Thanks, > Sherman > > > > On 4/25/18, 4:50 AM, Jan Lahoda wrote: > >> Hi, >> >> Under: >> https://bugs.openjdk.java.net/browse/JDK-8194750 >> >> j.i.Console was changed to capture the state of the terminal echo at >> creation time, and to restore it on shutdown. >> >> That is problematic at least in jshell, where the terminal is already in >> the raw mode when j.i.Console is created, and so "echo disabled" is >> recorded there. So even though jshell itself sets the terminal into the >> original mode when it terminates, the shutdown hook in j.i.Console, which >> is run later, sets the echo to off even if it was enabled before the VM >> started. >> >> My understanding is that the shutdown hook is only needed in case the VM >> goes down while readPassword is running. So I tried to change the shutdown >> hook to only work while readPassword is running. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202105 >> Webrev: http://cr.openjdk.java.net/~jlahoda/8202105/webrev.00/ >> >> What do you think? >> >> Thanks, >> Jan >> > > From joe.darcy at oracle.com Wed Apr 25 16:22:37 2018 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 25 Apr 2018 09:22:37 -0700 Subject: JDK 11 RFR of 8200478: For boxing conversion javac uses Long.valueOf which does not guarantee caching according to its javadoc In-Reply-To: References: <115abbdd-a430-e9c3-f3cd-d705edfa7f15@oracle.com> <43e6619d-89d5-6b3d-3ff3-4dbe121dd413@oracle.com> Message-ID: <75efc6f4-4824-6f8b-c09b-0c3326970d87@oracle.com> Hi Jon, On 4/25/2018 8:57 AM, Jonathan Gibbons wrote: > > Joe, > > While I note that the primary text has been modified to include long > types, the italic comment that follows still ends with the following: > > Notice that integer literals of type|long|are allowed, but not > required, to be shared. > > -- Jon > > It would seem that text missed being deleted with the prior update ;-) -Joe From xueming.shen at oracle.com Wed Apr 25 16:34:19 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 25 Apr 2018 09:34:19 -0700 Subject: RFR: JDK-8202105: jshell tool: on exiting, terminal echo is disabled In-Reply-To: References: <5AE06B6E.2060902@oracle.com> <5AE0A44C.80408@oracle.com> Message-ID: <5AE0AE0B.6070204@oracle.com> On 4/25/18, 9:02 AM, Martin Buchholz wrote: > It would be more correct I think for Console to track if there is a > pending readPassword in progress and try to restore echo on exit only > if so. But a little annoying to implement (need an additional boolean?) I think that is what Jan proposed "to add restoredEchoOnShutdown = true", and I'm fine with that. I'm just a little confused why jshell invokes System.console() if it handles all "raw" terminal stuff itself. > > On Wed, Apr 25, 2018 at 8:52 AM, Xueming Shen > wrote: > > > Hi Jan, > > I saw System.console() returns null inside jshell ... but it seems > there are 2 vms. > I would assume jshell itself sets the terminal to raw and then > call System.console()? > for example an alternative for this issue is to ask jshell's impl > to call System.console() > before going into raw mode? No, I'm not saying the proposed one is > not a good one, > just wanted to make sure I understand the situation correctly. > > Thanks, > Sherman > > > > On 4/25/18, 4:50 AM, Jan Lahoda wrote: > > Hi, > > Under: > https://bugs.openjdk.java.net/browse/JDK-8194750 > > > j.i.Console was changed to capture the state of the terminal > echo at creation time, and to restore it on shutdown. > > That is problematic at least in jshell, where the terminal is > already in the raw mode when j.i.Console is created, and so > "echo disabled" is recorded there. So even though jshell > itself sets the terminal into the original mode when it > terminates, the shutdown hook in j.i.Console, which is run > later, sets the echo to off even if it was enabled before the > VM started. > > My understanding is that the shutdown hook is only needed in > case the VM goes down while readPassword is running. So I > tried to change the shutdown hook to only work while > readPassword is running. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202105 > > Webrev: http://cr.openjdk.java.net/~jlahoda/8202105/webrev.00/ > > > What do you think? > > Thanks, > Jan > > > From kumar.x.srinivasan at oracle.com Wed Apr 25 16:38:32 2018 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 25 Apr 2018 09:38:32 -0700 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5ACFBE5C.1080508@oracle.com> References: <5ACFBE5C.1080508@oracle.com> Message-ID: <5AE0AF08.10105@oracle.com> Hi John, I focused mainly on the native side, looks ok, except for a couple of minor issues. java.c 1320 const char *prop = "-Djdk.internal.javac.source="; 1321 size_t size = JLI_StrLen(prop) + JLI_StrLen(value) + 1; 1322 char *propValue = (char *)JLI_MemAlloc(size + 1); I think we are allocating extra byte ^^^^^^^ 1323 JLI_StrCpy(propValue, prop); 1324 JLI_StrCat(propValue, value); I think we can do this, safer and neater, as follows: size_t size = JLI_StrLen(prop) + JLI_StrLen(value); char *propValue = (char *)JLI_MemAlloc(size + 1); JLI_Snprintf(propValue, size, "%s%s", prop, value); 1483 if (mode == LM_SOURCE) { 1484 AddOption("--add-modules=ALL-DEFAULT", NULL); 1485 *pwhat = SOURCE_LAUNCHER_MAIN_ENTRY; 1486 *pargc = argc + 1; 1487 *pargv = argv - 1; A short comment perhaps ? why we are incrementing argc, and decrementing argv, saves some head scratching for a casual reader. I looked at the launcher tests, very nice. Thanks Kumar On 4/12/2018 1:15 PM, Jonathan Gibbons wrote: > Please review an initial implementation for the feature described in > JEP 330: Launch Single-File Source-Code Programs. > > The work is described in the JEP and CSR, and falls into various parts: > > * The part to handle the new command-line options is in the native > Java launcher code. > * The part to invoke the compiler and subsequently execute the code > found in the source file is in a new class in the jdk.compiler module. > * There are some minor Makefile changes, to add support for a new > resource file. > > There are no changes to javac itself. > > JEP: http://openjdk.java.net/jeps/330 > JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 > CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 > Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ > > -- Jon From peter.levart at gmail.com Wed Apr 25 16:45:43 2018 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 25 Apr 2018 18:45:43 +0200 Subject: RFR: 8202184: Reduce time blocking the ClassSpecializer cache creating SpeciesData In-Reply-To: <151613d5-e50b-8d39-d55e-ce85ee396911@oracle.com> References: <151613d5-e50b-8d39-d55e-ce85ee396911@oracle.com> Message-ID: <17c74938-dec1-650c-3c7f-231085ef7764@gmail.com> Hi Claes, Your patch is OK from logical point of view, but something bothers me a little. For each species data that gets cached, at least 3 objects are created: - the Function passed to computeIfAbsent - the unresolved SpeciesData object that serves as a placeholder - the 2nd resolved SpeciesData object that replaces the 1st The 1st SpeciesData object serves just as placeholder, so it could be lighter-weight. An java.lang.Object perhaps? Creation of Function object could be eliminated by using putIfAbsent instead of computeIfAbsent then. For the price of some unsafe casts that are contained to a single method that is the sole user of CHM cache. For example, like this: http://cr.openjdk.java.net/~plevart/jdk-dev/8202184_ClassSpecializer/webrev.01/ I won't oppose to your version if you find it easier to understand. I just hat to try to do it without redundant creation of placeholder SpeciesData object. What do you think? Regards, Peter On 04/24/2018 06:57 PM, Claes Redestad wrote: > Hi, > > the current implementation of ClassSpecializer.findSpecies may cause > excessive blocking due to a potentially expensive computeIfAbsent, and > we have reason to believe this might have been cause for a few very > rare bootstrap issues in tests that attach debuggers to VM in the middle > of this. > > Breaking this apart so that code generation and linking is done outside > of the computeIfAbsent helps minimize the risk that a thread gets > interrupted by a debugger at a critical point in time, while also > removing > a few limitations on what we can do from a findSpecies, e.g., look up > other > SpeciesData. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202184 > Webrev: http://cr.openjdk.java.net/~redestad/8202184/open.00/ > > This implementation inserts a placeholder, unresolved SpeciesData, > and then replaces it with another instance that is linked together > fully before publishing it, which ensure safe publication. There might > be alternatives involving volatiles and/or careful fencing, but I've not > been able to measure any added startup cost from this anyway. > > Thanks! > > /Claes From naoto.sato at oracle.com Wed Apr 25 17:00:49 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 25 Apr 2018 10:00:49 -0700 Subject: [11] RFR: 8202026 8193552 : ISO 4217 Amendment #165 # 166 Update In-Reply-To: <62217aa4-16c5-2ec2-15f7-177d0906c53b@oracle.com> References: <5d50ddec-884c-e78c-4c2c-b9e11d8c3236@oracle.com> <62217aa4-16c5-2ec2-15f7-177d0906c53b@oracle.com> Message-ID: <2099b4c0-b97a-4c1a-f291-fec8f7beb294@oracle.com> Hi Leo, Although JDK11 is slated in 09/2018, enabling amendment 166 now is technically a bug, as it will be effective from June 4. Please use the transition mechanism in make/data/currency/CurrencyData.properties and test/jdk/java/util/Currency/tablea1.txt. OTOH, there are old (past) transition entries. I would clean up those entries, such as: 326 # LATVIA 327 LV=LVL;2013-12-31-22-00-00;EUR in CurrencyData.properties. This applies to tabela1.txt as well. Naoto On 4/24/18 8:52 PM, Leo Jiang wrote: > Forgot to mention, the tests in Currency fold are passed on Mach5. > > -Leo > > On 04/25/2018 09:33 AM, Leo Jiang wrote: >> Hi, >> >> Please review the changes to address the ISO 4217 Amendment 165 166 >> update. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8193552? 165 >> https://bugs.openjdk.java.net/browse/JDK-8202026? 166 >> >> CR: >> http://cr.openjdk.java.net/~ljiang/8202026/webrev.00/ >> >> >> Detail: >> #165 >> From: >> MAURITANIA??? Ouguiya??? MRO??? 478??? 2 >> To: >> MAURITANIA??? Ouguiya??? MRU??? 929??? 2 >> >> #166 >> From: >> VENEZUELA (BOLIVARIAN REPUBLIC OF)??? Bol?var??? VEF??? 937??? 2 >> To: >> VENEZUELA (BOLIVARIAN REPUBLIC OF)??? Bol?var Soberano??? VES??? 928??? 2 >> >> >> Thanks, >> Leo From james.laskey at oracle.com Wed Apr 25 17:04:47 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 25 Apr 2018 14:04:47 -0300 Subject: Please review CSR : JDK-8200437 String#isBlank Message-ID: <7077C3E9-2ED3-4ED0-8703-A5C28DC7F600@oracle.com> Please review and mark as reviewed https://bugs.openjdk.java.net/browse/JDK-8200437 From james.laskey at oracle.com Wed Apr 25 17:04:53 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 25 Apr 2018 14:04:53 -0300 Subject: Please review CSR : JDK-8200373 String#trim JavaDoc should clarify meaning of space Message-ID: <73D0472A-857C-48FD-8054-963B7A744F22@oracle.com> Please review and mark as reviewed https://bugs.openjdk.java.net/browse/JDK-8200373 From james.laskey at oracle.com Wed Apr 25 17:04:57 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 25 Apr 2018 14:04:57 -0300 Subject: Please review CSR : JDK-8200378 String#strip, String#stripLeading, String#stripTrailing Message-ID: <5DDC22A1-D1B0-4C49-8888-CFB593827D9B@oracle.com> Please review and mark as reviewed https://bugs.openjdk.java.net/browse/JDK-8200378 From james.laskey at oracle.com Wed Apr 25 17:05:00 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 25 Apr 2018 14:05:00 -0300 Subject: Please review CSR : JDK-8200425 String#lines Message-ID: <34688B82-0C76-47DD-9C90-05FB06425890@oracle.com> Please review and mark as reviewed https://bugs.openjdk.java.net/browse/JDK-8200425 From jonathan.gibbons at oracle.com Wed Apr 25 17:58:31 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 25 Apr 2018 10:58:31 -0700 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5AE0AF08.10105@oracle.com> References: <5ACFBE5C.1080508@oracle.com> <5AE0AF08.10105@oracle.com> Message-ID: <5AE0C1C7.5010300@oracle.com> Kumar, Thank you for your feedback; I will incorporate it in the next webrev. -- Jon On 04/25/2018 09:38 AM, Kumar Srinivasan wrote: > Hi John, > > I focused mainly on the native side, looks ok, except for a couple of > minor issues. > > java.c > 1320 const char *prop = "-Djdk.internal.javac.source="; > 1321 size_t size = JLI_StrLen(prop) + JLI_StrLen(value) + 1; > 1322 char *propValue = (char *)JLI_MemAlloc(size + 1); > > I think we are allocating extra byte ^^^^^^^ > > 1323 JLI_StrCpy(propValue, prop); > 1324 JLI_StrCat(propValue, value); > > I think we can do this, safer and neater, as follows: > > size_t size = JLI_StrLen(prop) + JLI_StrLen(value); > char *propValue = (char *)JLI_MemAlloc(size + 1); > JLI_Snprintf(propValue, size, "%s%s", prop, value); > 1483 if (mode == LM_SOURCE) { > 1484 AddOption("--add-modules=ALL-DEFAULT", NULL); > 1485 *pwhat = SOURCE_LAUNCHER_MAIN_ENTRY; > 1486 *pargc = argc + 1; > 1487 *pargv = argv - 1; > > A short comment perhaps ? why we are incrementing argc, and > decrementing argv, > saves some head scratching for a casual reader. > > I looked at the launcher tests, very nice. > > > Thanks > Kumar > > > > > > On 4/12/2018 1:15 PM, Jonathan Gibbons wrote: >> Please review an initial implementation for the feature described in >> JEP 330: Launch Single-File Source-Code Programs. >> >> The work is described in the JEP and CSR, and falls into various parts: >> >> * The part to handle the new command-line options is in the native >> Java launcher code. >> * The part to invoke the compiler and subsequently execute the code >> found in the source file is in a new class in the jdk.compiler >> module. >> * There are some minor Makefile changes, to add support for a new >> resource file. >> >> There are no changes to javac itself. >> >> JEP: http://openjdk.java.net/jeps/330 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 >> Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ >> >> -- Jon > From martinrb at google.com Wed Apr 25 19:07:29 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 25 Apr 2018 12:07:29 -0700 Subject: RFR: JDK-8202105: jshell tool: on exiting, terminal echo is disabled In-Reply-To: <5AE0AE0B.6070204@oracle.com> References: <5AE06B6E.2060902@oracle.com> <5AE0A44C.80408@oracle.com> <5AE0AE0B.6070204@oracle.com> Message-ID: I keep hoping for something simpler. Is it possible to have more than one Console object? Looks like NO. Assuming no, then you simply need one static flag boolean restoreEcho; (it could also be an instance field of Console - that would be slightly more principled) In readPassword you check current value of echo and set restoreEcho if it was changed. Shutdown hook also checks the same restoreEcho. For bonus points, only create the shutdown hook the first time readPassword is called with echo on to appease the Emacs shell users with pitchforks. On Wed, Apr 25, 2018 at 9:34 AM, Xueming Shen wrote: > On 4/25/18, 9:02 AM, Martin Buchholz wrote: > > It would be more correct I think for Console to track if there is a > pending readPassword in progress and try to restore echo on exit only if > so. But a little annoying to implement (need an additional boolean?) > > > I think that is what Jan proposed "to add restoredEchoOnShutdown = true", > and I'm fine > with that. I'm just a little confused why jshell invokes System.console() > if it handles all "raw" > terminal stuff itself. > > > On Wed, Apr 25, 2018 at 8:52 AM, Xueming Shen > wrote: > >> >> Hi Jan, >> >> I saw System.console() returns null inside jshell ... but it seems there >> are 2 vms. >> I would assume jshell itself sets the terminal to raw and then call >> System.console()? >> for example an alternative for this issue is to ask jshell's impl to call >> System.console() >> before going into raw mode? No, I'm not saying the proposed one is not a >> good one, >> just wanted to make sure I understand the situation correctly. >> >> Thanks, >> Sherman >> >> >> >> On 4/25/18, 4:50 AM, Jan Lahoda wrote: >> >>> Hi, >>> >>> Under: >>> https://bugs.openjdk.java.net/browse/JDK-8194750 >>> >>> j.i.Console was changed to capture the state of the terminal echo at >>> creation time, and to restore it on shutdown. >>> >>> That is problematic at least in jshell, where the terminal is already in >>> the raw mode when j.i.Console is created, and so "echo disabled" is >>> recorded there. So even though jshell itself sets the terminal into the >>> original mode when it terminates, the shutdown hook in j.i.Console, which >>> is run later, sets the echo to off even if it was enabled before the VM >>> started. >>> >>> My understanding is that the shutdown hook is only needed in case the VM >>> goes down while readPassword is running. So I tried to change the shutdown >>> hook to only work while readPassword is running. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202105 >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8202105/webrev.00/ >>> >>> What do you think? >>> >>> Thanks, >>> Jan >>> >> >> > > From john.r.rose at oracle.com Wed Apr 25 19:14:19 2018 From: john.r.rose at oracle.com (John Rose) Date: Wed, 25 Apr 2018 12:14:19 -0700 Subject: RFR: JDK-8202105: jshell tool: on exiting, terminal echo is disabled In-Reply-To: References: <5AE06B6E.2060902@oracle.com> <5AE0A44C.80408@oracle.com> <5AE0AE0B.6070204@oracle.com> Message-ID: <034B7C69-042E-457E-AB24-D72AD4F04DF8@oracle.com> On Apr 25, 2018, at 12:07 PM, Martin Buchholz wrote: > > For bonus points, only create the shutdown hook the first time readPassword > is called with echo on to appease the Emacs shell users with pitchforks. FTR, I use Emacs shell for everything except jshell, and have to launch a separate shell app. (Terminal) to run jshell. That's the only reason I launch that app. My pitchfork is still in the shed, but I feel the pain here too. There's probably a config. switch I'm missing, but jshell has never worked for me under Emacs. From jan.lahoda at oracle.com Wed Apr 25 20:34:33 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 25 Apr 2018 22:34:33 +0200 Subject: RFR: JDK-8202105: jshell tool: on exiting, terminal echo is disabled In-Reply-To: <5AE0A44C.80408@oracle.com> References: <5AE06B6E.2060902@oracle.com> <5AE0A44C.80408@oracle.com> Message-ID: <5AE0E659.5080006@oracle.com> Hi Sherman, JShell uses two processes - the main one interacts with the terminal and compiles the user's snippets. The other one runs the snippets, and is not connected to a terminal, so System.console() does not work there. IIRC the call to System.console() in jshell/jline that is part of this problem is basically a way to call Console.istty() - the returned Console is not used. I was considering tweaking jshell to avoid this issue, and I think it would be possible, but seemed some other programs might run into issues as well, so seemed better to fix in Console. Jan On 25.4.2018 17:52, Xueming Shen wrote: > > Hi Jan, > > I saw System.console() returns null inside jshell ... but it seems there > are 2 vms. > I would assume jshell itself sets the terminal to raw and then call > System.console()? > for example an alternative for this issue is to ask jshell's impl to > call System.console() > before going into raw mode? No, I'm not saying the proposed one is not a > good one, > just wanted to make sure I understand the situation correctly. > > Thanks, > Sherman > > > On 4/25/18, 4:50 AM, Jan Lahoda wrote: >> Hi, >> >> Under: >> https://bugs.openjdk.java.net/browse/JDK-8194750 >> >> j.i.Console was changed to capture the state of the terminal echo at >> creation time, and to restore it on shutdown. >> >> That is problematic at least in jshell, where the terminal is already >> in the raw mode when j.i.Console is created, and so "echo disabled" is >> recorded there. So even though jshell itself sets the terminal into >> the original mode when it terminates, the shutdown hook in >> j.i.Console, which is run later, sets the echo to off even if it was >> enabled before the VM started. >> >> My understanding is that the shutdown hook is only needed in case the >> VM goes down while readPassword is running. So I tried to change the >> shutdown hook to only work while readPassword is running. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202105 >> Webrev: http://cr.openjdk.java.net/~jlahoda/8202105/webrev.00/ >> >> What do you think? >> >> Thanks, >> Jan > From jan.lahoda at oracle.com Wed Apr 25 20:39:15 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 25 Apr 2018 22:39:15 +0200 Subject: RFR: JDK-8202105: jshell tool: on exiting, terminal echo is disabled In-Reply-To: References: <5AE06B6E.2060902@oracle.com> <5AE0A44C.80408@oracle.com> <5AE0AE0B.6070204@oracle.com> Message-ID: <5AE0E773.8020108@oracle.com> So, if I understand correctly, it would be: boolean flipEcho; and the readPassword would do something like: if (echo0() != false) { flipEcho = true; echo(false); } .... if (flipEcho) { //this would also be in the shutdown hook echo(!echo0()); } I guess I can do that (the variant with two boolean feels to me slightly easier to understand and a tiny bit more robust, but this flip boolean variant is doable as well). Thanks, Jan On 25.4.2018 21:07, Martin Buchholz wrote: > I keep hoping for something simpler. > > Is it possible to have more than one Console object? Looks like NO. > Assuming no, then you simply need one static flag > > boolean restoreEcho; > > (it could also be an instance field of Console - that would be slightly > more principled) > > In readPassword you check current value of echo and set restoreEcho if it > was changed. Shutdown hook also checks the same restoreEcho. > > For bonus points, only create the shutdown hook the first time readPassword > is called with echo on to appease the Emacs shell users with pitchforks. > > On Wed, Apr 25, 2018 at 9:34 AM, Xueming Shen > wrote: > >> On 4/25/18, 9:02 AM, Martin Buchholz wrote: >> >> It would be more correct I think for Console to track if there is a >> pending readPassword in progress and try to restore echo on exit only if >> so. But a little annoying to implement (need an additional boolean?) >> >> >> I think that is what Jan proposed "to add restoredEchoOnShutdown = true", >> and I'm fine >> with that. I'm just a little confused why jshell invokes System.console() >> if it handles all "raw" >> terminal stuff itself. >> >> >> On Wed, Apr 25, 2018 at 8:52 AM, Xueming Shen >> wrote: >> >>> >>> Hi Jan, >>> >>> I saw System.console() returns null inside jshell ... but it seems there >>> are 2 vms. >>> I would assume jshell itself sets the terminal to raw and then call >>> System.console()? >>> for example an alternative for this issue is to ask jshell's impl to call >>> System.console() >>> before going into raw mode? No, I'm not saying the proposed one is not a >>> good one, >>> just wanted to make sure I understand the situation correctly. >>> >>> Thanks, >>> Sherman >>> >>> >>> >>> On 4/25/18, 4:50 AM, Jan Lahoda wrote: >>> >>>> Hi, >>>> >>>> Under: >>>> https://bugs.openjdk.java.net/browse/JDK-8194750 >>>> >>>> j.i.Console was changed to capture the state of the terminal echo at >>>> creation time, and to restore it on shutdown. >>>> >>>> That is problematic at least in jshell, where the terminal is already in >>>> the raw mode when j.i.Console is created, and so "echo disabled" is >>>> recorded there. So even though jshell itself sets the terminal into the >>>> original mode when it terminates, the shutdown hook in j.i.Console, which >>>> is run later, sets the echo to off even if it was enabled before the VM >>>> started. >>>> >>>> My understanding is that the shutdown hook is only needed in case the VM >>>> goes down while readPassword is running. So I tried to change the shutdown >>>> hook to only work while readPassword is running. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202105 >>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8202105/webrev.00/ >>>> >>>> What do you think? >>>> >>>> Thanks, >>>> Jan >>>> >>> >>> >> >> From martinrb at google.com Wed Apr 25 20:47:15 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 25 Apr 2018 13:47:15 -0700 Subject: RFR: JDK-8202105: jshell tool: on exiting, terminal echo is disabled In-Reply-To: <5AE0E659.5080006@oracle.com> References: <5AE06B6E.2060902@oracle.com> <5AE0A44C.80408@oracle.com> <5AE0E659.5080006@oracle.com> Message-ID: On Wed, Apr 25, 2018 at 1:34 PM, Jan Lahoda wrote: > > IIRC the call to System.console() in jshell/jline that is part of this > problem is basically a way to call Console.istty() - the returned Console > is not used. I was considering tweaking jshell to avoid this issue, and I > think it would be possible, but seemed some other programs might run into > issues as well, so seemed better to fix in Console. So the shutdown hook is unneeded both by Emacs users and by JShell users, strengthening the case for optimizing it away. From xueming.shen at oracle.com Wed Apr 25 20:59:12 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 25 Apr 2018 13:59:12 -0700 Subject: RFR: JDK-8202105: jshell tool: on exiting, terminal echo is disabled In-Reply-To: <5AE0E773.8020108@oracle.com> References: <5AE06B6E.2060902@oracle.com> <5AE0A44C.80408@oracle.com> <5AE0AE0B.6070204@oracle.com> <5AE0E773.8020108@oracle.com> Message-ID: <5AE0EC20.8010409@oracle.com> On 04/25/2018 01:39 PM, Jan Lahoda wrote: > So, if I understand correctly, it would be: > boolean flipEcho; > and the readPassword would do something like: > if (echo0() != false) { if (echo0()) { ... > flipEcho = true; > echo(false); > } > .... > if (flipEcho) { //this would also be in the shutdown hook > echo(!echo0()); > } if (flipEcho) { echo(true); flipEcho = false; } ? > > I guess I can do that (the variant with two boolean feels to me slightly easier to understand and a tiny bit more robust, but this flip boolean variant is doable as well). > > Thanks, > Jan > > On 25.4.2018 21:07, Martin Buchholz wrote: >> I keep hoping for something simpler. >> >> Is it possible to have more than one Console object? Looks like NO. >> Assuming no, then you simply need one static flag >> >> boolean restoreEcho; >> >> (it could also be an instance field of Console - that would be slightly >> more principled) >> >> In readPassword you check current value of echo and set restoreEcho if it >> was changed. Shutdown hook also checks the same restoreEcho. >> >> For bonus points, only create the shutdown hook the first time readPassword >> is called with echo on to appease the Emacs shell users with pitchforks. >> >> On Wed, Apr 25, 2018 at 9:34 AM, Xueming Shen >> wrote: >> >>> On 4/25/18, 9:02 AM, Martin Buchholz wrote: >>> >>> It would be more correct I think for Console to track if there is a >>> pending readPassword in progress and try to restore echo on exit only if >>> so. But a little annoying to implement (need an additional boolean?) >>> >>> >>> I think that is what Jan proposed "to add restoredEchoOnShutdown = true", >>> and I'm fine >>> with that. I'm just a little confused why jshell invokes System.console() >>> if it handles all "raw" >>> terminal stuff itself. >>> >>> >>> On Wed, Apr 25, 2018 at 8:52 AM, Xueming Shen >>> wrote: >>> >>>> >>>> Hi Jan, >>>> >>>> I saw System.console() returns null inside jshell ... but it seems there >>>> are 2 vms. >>>> I would assume jshell itself sets the terminal to raw and then call >>>> System.console()? >>>> for example an alternative for this issue is to ask jshell's impl to call >>>> System.console() >>>> before going into raw mode? No, I'm not saying the proposed one is not a >>>> good one, >>>> just wanted to make sure I understand the situation correctly. >>>> >>>> Thanks, >>>> Sherman >>>> >>>> >>>> >>>> On 4/25/18, 4:50 AM, Jan Lahoda wrote: >>>> >>>>> Hi, >>>>> >>>>> Under: >>>>> https://bugs.openjdk.java.net/browse/JDK-8194750 >>>>> >>>>> j.i.Console was changed to capture the state of the terminal echo at >>>>> creation time, and to restore it on shutdown. >>>>> >>>>> That is problematic at least in jshell, where the terminal is already in >>>>> the raw mode when j.i.Console is created, and so "echo disabled" is >>>>> recorded there. So even though jshell itself sets the terminal into the >>>>> original mode when it terminates, the shutdown hook in j.i.Console, which >>>>> is run later, sets the echo to off even if it was enabled before the VM >>>>> started. >>>>> >>>>> My understanding is that the shutdown hook is only needed in case the VM >>>>> goes down while readPassword is running. So I tried to change the shutdown >>>>> hook to only work while readPassword is running. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202105 >>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8202105/webrev.00/ >>>>> >>>>> What do you think? >>>>> >>>>> Thanks, >>>>> Jan >>>>> >>>> >>>> >>> >>> From claes.redestad at oracle.com Wed Apr 25 21:49:07 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 25 Apr 2018 23:49:07 +0200 Subject: RFR: 8202184: Reduce time blocking the ClassSpecializer cache creating SpeciesData In-Reply-To: <17c74938-dec1-650c-3c7f-231085ef7764@gmail.com> References: <151613d5-e50b-8d39-d55e-ce85ee396911@oracle.com> <17c74938-dec1-650c-3c7f-231085ef7764@gmail.com> Message-ID: <36c9b738-3057-e0f2-ffe8-b3b3999da7da@oracle.com> Hi Peter, too late! :-) Good observation about us creating a new Function every time we look up an item. If we go with an Object as a reservation marker we could get away with a singleton static Function and still use computeIfAbsent (which I think is clearer and avoids creating a reservation Object on every lookup). I'd consider this a reasonable follow-up RFE: http://cr.openjdk.java.net/~redestad/scratch/ClassSpec_followup.00/ Its value as an optimization might be somewhat dubious, but it does help future-proof the mechanism (say if we wanted to add forms that are even more heavyweight or if we needed to side-effect something when calling newSpeciesData...). /Claes On 2018-04-25 18:45, Peter Levart wrote: > Hi Claes, > > Your patch is OK from logical point of view, but something bothers me > a little. For each species data that gets cached, at least 3 objects > are created: > > - the Function passed to computeIfAbsent > - the unresolved SpeciesData object that serves as a placeholder > - the 2nd resolved SpeciesData object that replaces the 1st > > The 1st SpeciesData object serves just as placeholder, so it could be > lighter-weight. An java.lang.Object perhaps? Creation of Function > object could be eliminated by using putIfAbsent instead of > computeIfAbsent then. For the price of some unsafe casts that are > contained to a single method that is the sole user of CHM cache. > > For example, like this: > > http://cr.openjdk.java.net/~plevart/jdk-dev/8202184_ClassSpecializer/webrev.01/ > > > I won't oppose to your version if you find it easier to understand. I > just hat to try to do it without redundant creation of placeholder > SpeciesData object. > > What do you think? > > Regards, Peter > > On 04/24/2018 06:57 PM, Claes Redestad wrote: >> Hi, >> >> the current implementation of ClassSpecializer.findSpecies may cause >> excessive blocking due to a potentially expensive computeIfAbsent, and >> we have reason to believe this might have been cause for a few very >> rare bootstrap issues in tests that attach debuggers to VM in the middle >> of this. >> >> Breaking this apart so that code generation and linking is done outside >> of the computeIfAbsent helps minimize the risk that a thread gets >> interrupted by a debugger at a critical point in time, while also >> removing >> a few limitations on what we can do from a findSpecies, e.g., look up >> other >> SpeciesData. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202184 >> Webrev: http://cr.openjdk.java.net/~redestad/8202184/open.00/ >> >> This implementation inserts a placeholder, unresolved SpeciesData, >> and then replaces it with another instance that is linked together >> fully before publishing it, which ensure safe publication. There might >> be alternatives involving volatiles and/or careful fencing, but I've not >> been able to measure any added startup cost from this anyway. >> >> Thanks! >> >> /Claes > From brian.burkhalter at oracle.com Wed Apr 25 22:11:49 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 25 Apr 2018 15:11:49 -0700 Subject: 8202284: FileChannel and FileOutpuStream variants of AtomicAppend should pass silently on macOS >= 10.13 Message-ID: <1DD25910-724A-4727-B886-92E481206BC9@oracle.com> Issue: https://bugs.openjdk.java.net/browse/JDK-8202284 Patch: http://cr.openjdk.java.net/~bpb/8202284/webrev.00/ Suite of [1]. Remove AtomicAppend tests from the problem list instead making then pass silently for macOS version >= 10.13. Thanks, Brian [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052751.html From brian.burkhalter at oracle.com Wed Apr 25 22:15:33 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 25 Apr 2018 15:15:33 -0700 Subject: 8202062: Put FileChannel and FileOutpuStream variants of AtomicAppend on problem list In-Reply-To: <4223b760-a848-9e66-5642-13d43beeabc3@oracle.com> References: <9DF4F879-1D26-41E6-AA60-2B4A62B6732B@oracle.com> <4223b760-a848-9e66-5642-13d43beeabc3@oracle.com> Message-ID: <4398C62B-3E4F-4266-9FFB-6C880A9AE7AB@oracle.com> On Apr 24, 2018, at 11:05 PM, Alan Bateman wrote: > On 24/04/2018 23:15, Brian Burkhalter wrote: >> https://bugs.openjdk.java.net/browse/JDK-8202062 >> >> Recently more frequent failures have been observed on macOS. Put on the problem list until the underlying cause can be determined. >> > I think it would be better to change the tests to pass silently when running on macOS 10.13 or higher. At least from first look, that is where the issue is. Please see http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052782.html Thanks, Brian From mikael.vidstedt at oracle.com Wed Apr 25 22:30:23 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 25 Apr 2018 15:30:23 -0700 Subject: 8202284: FileChannel and FileOutpuStream variants of AtomicAppend should pass silently on macOS >= 10.13 In-Reply-To: <1DD25910-724A-4727-B886-92E481206BC9@oracle.com> References: <1DD25910-724A-4727-B886-92E481206BC9@oracle.com> Message-ID: Which JBS issue is now covering the work of looking at the actual failure? Cheers, Mikael > On Apr 25, 2018, at 3:11 PM, Brian Burkhalter wrote: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8202284 > Patch: http://cr.openjdk.java.net/~bpb/8202284/webrev.00/ > > Suite of [1]. > > Remove AtomicAppend tests from the problem list instead making then pass silently for macOS version >= 10.13. > > Thanks, > > Brian > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052751.html From brian.burkhalter at oracle.com Wed Apr 25 22:37:34 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 25 Apr 2018 15:37:34 -0700 Subject: 8202284: FileChannel and FileOutpuStream variants of AtomicAppend should pass silently on macOS >= 10.13 In-Reply-To: References: <1DD25910-724A-4727-B886-92E481206BC9@oracle.com> Message-ID: <1D486752-61E8-4348-BC6B-C69A2722487E@oracle.com> None yet. I awaiting direction as to whether I can reopen the inadvertently resolved issue or whether I need to create a new issue with the same content. I think the latter. Brian On Apr 25, 2018, at 3:30 PM, Mikael Vidstedt wrote: > Which JBS issue is now covering the work of looking at the actual failure? From brian.burkhalter at oracle.com Thu Apr 26 00:09:46 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 25 Apr 2018 17:09:46 -0700 Subject: 8202284: FileChannel and FileOutpuStream variants of AtomicAppend should pass silently on macOS >= 10.13 In-Reply-To: <1D486752-61E8-4348-BC6B-C69A2722487E@oracle.com> References: <1DD25910-724A-4727-B886-92E481206BC9@oracle.com> <1D486752-61E8-4348-BC6B-C69A2722487E@oracle.com> Message-ID: <777C4D76-D59B-4783-AD74-33B58E909570@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8202290 to track this problem. Brian On Apr 25, 2018, at 3:37 PM, Brian Burkhalter wrote: > None yet. I awaiting direction as to whether I can reopen the inadvertently resolved issue or whether I need to create a new issue with the same content. I think the latter. > > Brian > > On Apr 25, 2018, at 3:30 PM, Mikael Vidstedt wrote: > >> Which JBS issue is now covering the work of looking at the actual failure? From brian.burkhalter at oracle.com Thu Apr 26 00:38:41 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 25 Apr 2018 17:38:41 -0700 Subject: [PATCH] Prefer TMPDIR over hard coded /tmp In-Reply-To: <8fd54174-54be-243f-443d-598c430a4ea5@snazy.de> References: <8fd54174-54be-243f-443d-598c430a4ea5@snazy.de> Message-ID: Hi Robert, On Apr 23, 2018, at 7:23 AM, Robert Stupp wrote: > For MacOS and Windows, Java prefers the user's temporary directory for java.io.tmpdir, but not for Linux, where it is always set to /tmp. The burden with this is that if you want to use a different temp directory, you have to explicitly pass -Djava.io.tmpdir=... on the command line, which can be difficult especially for unit tests or microbenchmarks in 3rd party code ran via Maven for example. > > java_props_t.tmp_dir is always initialized as P_tmpdir in GetJavaProperties (src/java.base/unix/native/libjava/java_props_md.c). > > The attached patch changed the behavior to use the content of the environment variable TMPDIR, if present. Note that this does not change where the hsperf* folders are created. The source change looks OK to me aside from the copyright year and that in the second line here + v = getenv("TMPDIR"); + if (v) { + sprops.tmp_dir = strdup(v); + } it should probably have + if (v != NULL) { for consistency with elsewhere in the file. > I'm not sure why java.io.tmpdir is always /tmp in Linux as according to the SCM history, this was always as it is (references the initial OpenJDK commit). > > I haven't found any tests that validates the content of java.io.tmpdir. Some sort of test would need to be added to this patch to validate the change. Thanks, Brian From brian.burkhalter at oracle.com Thu Apr 26 00:45:38 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 25 Apr 2018 17:45:38 -0700 Subject: [PATCH] Prefer TMPDIR over hard coded /tmp In-Reply-To: References: <8fd54174-54be-243f-443d-598c430a4ea5@snazy.de> Message-ID: <0B6C2F2C-8AED-44EA-A5DF-531268EBA8D9@oracle.com> On Apr 25, 2018, at 5:38 PM, Brian Burkhalter wrote: >> The attached patch changed the behavior to use the content of the environment variable TMPDIR, if present. Note that this does not change where the hsperf* folders are created. > > The source change looks OK to me aside from the copyright year and that in the second line here Note that I am only saying that the patch looks OK, not that we want to use it. There have been a number of issues filed in this area over time, for example https://bugs.openjdk.java.net/browse/JDK-6205979. There are arguments against this change. Brian From isaac.r.levy at gmail.com Thu Apr 26 03:04:15 2018 From: isaac.r.levy at gmail.com (Isaac Levy) Date: Wed, 25 Apr 2018 23:04:15 -0400 Subject: [PATCH] regex matcher opt: remove redundant StringBuilder In-Reply-To: <5ADFDC21.2040909@oracle.com> References: <5ADF60FA.2020109@oracle.com> <5ADFDC21.2040909@oracle.com> Message-ID: yeah perhaps this is enough. Though users of appendReplacement are presumably after high performance loops or they'd be using a higher level API like replaceAll. I just can't imagine people using this API hit the format code exception in normal usage, and it's not like java is dumping junk into the StringBuilder when it throws the exception -- it pushed the correct replacement up to the error. Maybe I can catch exceptions, roll back the builder using setLength, and rethrow. Isaac On Tue, Apr 24, 2018 at 9:38 PM, Xueming Shen wrote: > for String based replaceAll/First() it might be worth doing something like > > http://cr.openjdk.java.net/~sherman/regex_removesb/webrev/ > > > On 4/24/18, 10:47 AM, Isaac Levy wrote: >> >> Hi Sherman, >> >> Thanks for clarifying. Looks like exceptions are caused by invalid >> format string. I wouldn't expect most programs to be catching this and >> preserving their buffer, but dunno. >> >> How much does it affect perf? Well it depends on use case, a jmh of >> replaceAll with a length 200 string of digits and regex "(\w)" shows >> about 30% speedup. >> >> [info] Benchmark Mode Cnt Score Error Units >> [info] origM avgt 10 11.669 ? 0.211 us/op >> [info] newM avgt 10 8.926 ? 0.095 us/op >> >> Isaac >> >> >> On Tue, Apr 24, 2018 at 12:53 PM, Xueming Shen >> wrote: >>> >>> Hi Isaac, >>> >>> I actually meant to say "we are not supposed to output the partial text >>> into >>> the output buffer in case of an exception". It has nothing to do with the >>> changeset you cited. This has been the behavior since day one/JDK1.4, >>> though it is not specified explicitly in the API doc. The newly added >>> StringBuilder variant simply follows this behavior. If it's really >>> desired >>> it >>> is kinda doable to save that StringBuilder without the "incompatible" >>> behavior >>> change but just wonder if it is really worth the effort. >>> >>> Thanks, >>> Sherman >>> >>> >>> On 4/24/18, 9:11 AM, Isaac Levy wrote: >>>> >>>> (moving this to a separate discussion) >>>> >>>> >>>> --- a/src/java.base/share/classes/java/util/regex/Matcher.java >>>> +++ b/src/java.base/share/classes/java/util/regex/Matcher.java >>>> @@ -993,13 +993,11 @@ >>>> public Matcher appendReplacement(StringBuilder sb, String >>>> replacement) { >>>> // If no match, return error >>>> if (first< 0) >>>> throw new IllegalStateException("No match available"); >>>> - StringBuilder result = new StringBuilder(); >>>> - appendExpandedReplacement(replacement, result); >>>> // Append the intervening text >>>> sb.append(text, lastAppendPosition, first); >>>> // Append the match substitution >>>> + appendExpandedReplacement(replacement, sb); >>>> - sb.append(result); >>>> >>>> >>>> >>>> On Mon, Apr 23, 2018 at 5:05 PM Xueming Shen >>>> wrote: >>>>> >>>>> >>>>> I would assume in case of an exception thrown from >>>>> appendExpandedReplacement() we don't >>>>> want "text" to be pushed into the "sb". >>>>> >>>>> -sherman >>>> >>>> >>>> Perhaps. Though the behavior under exception is undefined and this >>>> function is probably primarily used though the replaceAll API, which >>>> wouldn?t return the intermediate sb under the case of exception. >>>> >>>> My reading of the blame was the temp StringBuilder was an artifact of >>>> the api previously using StringBuffer externally. See >>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/763c564451b3 >>> >>> > From ecki at zusammenkunft.net Thu Apr 26 03:48:30 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 26 Apr 2018 03:48:30 +0000 Subject: [PATCH] Prefer TMPDIR over hard coded /tmp In-Reply-To: References: <8fd54174-54be-243f-443d-598c430a4ea5@snazy.de>, Message-ID: Hello. For robustness reasons, should it maybe fall back to the hardcoded default if the target path does not exist or has the (obvious*) missing write permission? Gruss Bernd * with or without trying a actual write? -- http://bernd.eckenfels.net _____________________________ From: Brian Burkhalter Sent: Donnerstag, April 26, 2018 5:09 AM Subject: Re: [PATCH] Prefer TMPDIR over hard coded /tmp To: Robert Stupp Cc: Hi Robert, On Apr 23, 2018, at 7:23 AM, Robert Stupp wrote: > For MacOS and Windows, Java prefers the user's temporary directory for java.io.tmpdir, but not for Linux, where it is always set to /tmp. The burden with this is that if you want to use a different temp directory, you have to explicitly pass -Djava.io.tmpdir=... on the command line, which can be difficult especially for unit tests or microbenchmarks in 3rd party code ran via Maven for example. > > java_props_t.tmp_dir is always initialized as P_tmpdir in GetJavaProperties (src/java.base/unix/native/libjava/java_props_md.c). > > The attached patch changed the behavior to use the content of the environment variable TMPDIR, if present. Note that this does not change where the hsperf* folders are created. The source change looks OK to me aside from the copyright year and that in the second line here + v = getenv("TMPDIR"); + if (v) { + sprops.tmp_dir = strdup(v); + } it should probably have + if (v != NULL) { for consistency with elsewhere in the file. > I'm not sure why java.io.tmpdir is always /tmp in Linux as according to the SCM history, this was always as it is (references the initial OpenJDK commit). > > I haven't found any tests that validates the content of java.io.tmpdir. Some sort of test would need to be added to this patch to validate the change. Thanks, Brian From david.holmes at oracle.com Thu Apr 26 04:12:14 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Apr 2018 14:12:14 +1000 Subject: (M) RFR: 8200167: Validate more special case invocations In-Reply-To: <27391c2a-fd5c-8133-8e31-b8b45db157ce@oracle.com> References: <27391c2a-fd5c-8133-8e31-b8b45db157ce@oracle.com> Message-ID: Revised webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev.v2/ Karen formulated an additional test scenario invoking Object methods through an interface reference, which when turned into a new testcase demonstrated that the receiver typecheck was also missing in that case for Methodhandle's from findSpecial. Again Vladimir Ivanov formulated the fix for this. Thanks Vladimir! Summary of changes from original webrev: - We introduce a new version of DirectMethodHandle.preparedlambdaForm that takes the caller class as a parameter, and that class is checked for being an interface (not the method's declaring class) to trigger the switch to LF_SPECIAL_IFC. (This obviously addresses one problem with invoking Object methods - as Object is not an interface - but by itself did not fix the problem.) - We introduce a new LambdaForm kind, DIRECT_INVOKE_SPECIAL_IFC, which we use when dealing with LF_INVSPECIAL_IFC. (This was the key in ensuring the receiver typecheck via Special.checkReceiver remained in the generated code.) - In the test we: - introduce a new invokeDirect testcase for Object.toString(), but we need to do that via a modified jcod file (as javac generates an invokevirtual) - introduce the new invokeSpecialObjectMH(I2 i) call for the MH case. Thanks, David On 17/04/2018 6:48 PM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8200167 > webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev/ > > Credit to John Rose and Vladimir Ivanov for the form of the MH fix; and > to Tobias Hartmann for the C1 fix. Their help was very much appreciated > (and needed!). > > tl;dr version: there are some places where badly formed interface method > calls (which are not detected by the verifier) were missing runtime > checks on the type of the receiver. Similar issues have been fixed in > the past and this was a remaining hole in relation to invokespecial > semantics and interface calls via MethodHandles. It also turned out > there was an issue in C1 that affected direct invokespecial calls. > > Description of changes: > > - src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java > > Added a new form LF_INVSPECIAL_IFC for invokespecial of interface methods. > > - src/java.base/share/classes/java/lang/invoke/MethodHandles.java > > Renamed callerClass parameter to boundCallerClass, where it originates > from findBoundCallerClass. The name "callerClass" is misleading because > most of the time it is NULL! > > In getDirectMethodCommon, pass the actual caller class (lookupClass) to > DirectMethodHandle.make. And correct the comment about restrictReceiver. > > - src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java > > DirectMethodHandle.make now takes a callerClass parameter (which may be > null). > > DirectMethodHandle make "receiver" parameter is renamed "refc" as it is > not the receiver (it's the resolved type of the method holder ie REFC). > > The Special subclass now takes a "checkClass" parameter which is either > refc, or callerClass. This is what we will check the receiver against. > > In preparedLambdaForm we switch from LF_INVSPECIAL to LF_INVSPECIAL_IFC > if the target method is in an interface. > > In makePreparedLambdaForm we augment the needsReceiverCheck test to > include LF_INVSPECIAL_IFC. (So we will not be doing a new receiver type > check on all invokespecials, just those involving interface methods.) > > Added DMH.checkReceiver which is overridden by both the Special and > Interface subclasses. > > - src/hotspot/share/c1/c1_Canonicalizer.cpp > > Don't optimize away the checkcast when it is an invokespecial receiver > check. > > - test/jdk/java/lang/invoke/SpecialInterfaceCall.java > > (I've moved this test back and forth between hotspot/runtime and > j.l.invoke as it spans direct calls and MH calls. But I think on balance > it lands better here.) > > The test sets up direct interface method calls for which invokespecial > is generated by javac, and similarly it creates MethodHandles with > invokespecial semantics. The should-not-throw cases are trivial. The > should-throw cases involve MH wizardry. > > The test is broken into three parts to check the behaviour on first use > (when the method has to be initially resolved); on second use (to test > we don't use the cpcache in a way that is invalid); and again after > forcing JIT compilation of the calls. > > The test is run 5 times to exercise the interpreter (yes the multiple > runs internal to the test are redundant in this case, but it's much > simpler to just run it all than try to work out what needs to be run); > the three variants of using C1, plus a C2 only run. > > --- > > Testing: > ? - the new test of course > ? - hotspot/runtime/* > ? - hotspot/compiler/jsr292 > ? - jdk/java/lang/invoke > > ? - hs tiers 1 and 2 > ? - jdk tiers 1, 2 and 3 > > Plus some related closed tests. > > Thanks, > David > ----- From andrej.golovnin at gmail.com Thu Apr 26 05:47:50 2018 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Thu, 26 Apr 2018 07:47:50 +0200 Subject: Please review CSR : JDK-8200437 String#isBlank In-Reply-To: <7077C3E9-2ED3-4ED0-8703-A5C28DC7F600@oracle.com> References: <7077C3E9-2ED3-4ED0-8703-A5C28DC7F600@oracle.com> Message-ID: Hi Jim, please add also the #isNotBlank() method. I know the one can write !str.isBlank(), but str.isNotBlank() is better from the readability standpoint of view. Also I think the new methods: #isBlank() #isNotBlank() // if you add it. #lines() and the old one String#isEmpty() should be defined on the CharSequence interface with default implementations and not on the String class. The sub-classes of CharSequence shall then provide optimised implementations. This would allow us to have this methods on StringBuilder and CharBuffer too. Best regards, Andrej Golovnin On Wed, Apr 25, 2018 at 7:04 PM, Jim Laskey wrote: > Please review and mark as reviewed https://bugs.openjdk.java.net/browse/JDK-8200437 > From Alan.Bateman at oracle.com Thu Apr 26 06:24:43 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 26 Apr 2018 07:24:43 +0100 Subject: [PATCH] Prefer TMPDIR over hard coded /tmp In-Reply-To: <0B6C2F2C-8AED-44EA-A5DF-531268EBA8D9@oracle.com> References: <8fd54174-54be-243f-443d-598c430a4ea5@snazy.de> <0B6C2F2C-8AED-44EA-A5DF-531268EBA8D9@oracle.com> Message-ID: <2c5fd7b3-88a7-82ef-6c07-2361ef6c1192@oracle.com> On 26/04/2018 01:45, Brian Burkhalter wrote: > On Apr 25, 2018, at 5:38 PM, Brian Burkhalter wrote: > >>> The attached patch changed the behavior to use the content of the environment variable TMPDIR, if present. Note that this does not change where the hsperf* folders are created. >> The source change looks OK to me aside from the copyright year and that in the second line here > Note that I am only saying that the patch looks OK, not that we want to use it. There have been a number of issues filed in this area over time, for example https://bugs.openjdk.java.net/browse/JDK-6205979. There are arguments against this change. > Right, it's come a few times. In principle it seems reasonable but it will likely have a tail of issues. One concern is that it will cause issues with the attach mechanism as that depends on the tool side knowing the target VM's tmp dir. There's also the transition issue where old JDKs will be using /tmp, new JDKs using whatever TMPDIR is set too. This is one of these issues where most of the work will be shaking out the knock on impact (that will be needed for the CSR and release note at least). -Alan From snazy at snazy.de Thu Apr 26 08:18:37 2018 From: snazy at snazy.de (Robert Stupp) Date: Thu, 26 Apr 2018 10:18:37 +0200 Subject: [PATCH] Prefer TMPDIR over hard coded /tmp In-Reply-To: <2c5fd7b3-88a7-82ef-6c07-2361ef6c1192@oracle.com> References: <8fd54174-54be-243f-443d-598c430a4ea5@snazy.de> <0B6C2F2C-8AED-44EA-A5DF-531268EBA8D9@oracle.com> <2c5fd7b3-88a7-82ef-6c07-2361ef6c1192@oracle.com> Message-ID: > Right, it's come a few times. In principle it seems reasonable but it > will likely have a tail of issues. One concern is that it will cause > issues with the attach mechanism as that depends on the tool side > knowing the target VM's tmp dir. There's also the transition issue > where old JDKs will be using /tmp, new JDKs using whatever TMPDIR is > set too. This is one of these issues where most of the work will be > shaking out the knock on impact (that will be needed for the CSR and > release note at least). I'm not sure, whether I understand the concern about the attach mechanism, as that seems to use the directory returned by PlatformSupport->VMSupport.getVMTemporaryDirectory->JVM_GetTemporaryDirectory->os::get_temp_directory, which returns the hard coded "/tmp" for all Unix platforms (except MacOS). (No intention to change this.) The concern about backward compatibility (app using a JVM with hard coded /tmp plus a JVM using TMPDIR) is absolutely correct. I'm just not sure whether that's actually (or usually) an issue for /tmp specifically (at least on Linux, http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s18.html). Well, at least if people actually use /tmp as it's supposed to be used, since /tmp could perfectly be a volatile filesystem, but it's actually on persistent storage, probably due to "misuse". What I'm currently thinking of is, whether a JVM flag (-XX:+PreferTMPDIR or so, defaults to false) could be a compromise that preserves the current behavior and prevents issues with existing applications but gives people the option to use TMPDIR for java.io.tmpdir, if they want to. Using TMPDIR for java.io.tmpdir is mostly useful for building and testing code - i.e. having an easier way to use different locations for java.io.tmpdir instead of, for example, digging through build files and inspecting command lines to check, whether surefire/junit/testng/JMH passed the correct java.io.tmpdir properly to a spawned, maybe short lived, child JVMs. WDYT? Robert -- Robert Stupp @snazy From jan.lahoda at oracle.com Thu Apr 26 10:23:03 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 26 Apr 2018 12:23:03 +0200 Subject: RFR: JDK-8202105: jshell tool: on exiting, terminal echo is disabled In-Reply-To: <5AE0EC20.8010409@oracle.com> References: <5AE06B6E.2060902@oracle.com> <5AE0A44C.80408@oracle.com> <5AE0AE0B.6070204@oracle.com> <5AE0E773.8020108@oracle.com> <5AE0EC20.8010409@oracle.com> Message-ID: <5AE1A887.9000402@oracle.com> On 25.4.2018 22:59, Xueming Shen wrote: > On 04/25/2018 01:39 PM, Jan Lahoda wrote: >> So, if I understand correctly, it would be: >> boolean flipEcho; >> and the readPassword would do something like: >> if (echo0() != false) { > > if (echo0()) { ... > >> flipEcho = true; >> echo(false); >> } >> .... >> if (flipEcho) { //this would also be in the shutdown hook >> echo(!echo0()); >> } > > if (flipEcho) { > echo(true); > flipEcho = false; > } > ? Hmm, right. It start to look a lot like the original code, with the exception that the flag is also checked inside readPassword: http://cr.openjdk.java.net/~jlahoda/8202105/webrev.01/ (This also makes the shutdown hook registration lazy.) Jan > >> >> I guess I can do that (the variant with two boolean feels to me >> slightly easier to understand and a tiny bit more robust, but this >> flip boolean variant is doable as well). >> >> Thanks, >> Jan >> >> On 25.4.2018 21:07, Martin Buchholz wrote: >>> I keep hoping for something simpler. >>> >>> Is it possible to have more than one Console object? Looks like NO. >>> Assuming no, then you simply need one static flag >>> >>> boolean restoreEcho; >>> >>> (it could also be an instance field of Console - that would be slightly >>> more principled) >>> >>> In readPassword you check current value of echo and set restoreEcho >>> if it >>> was changed. Shutdown hook also checks the same restoreEcho. >>> >>> For bonus points, only create the shutdown hook the first time >>> readPassword >>> is called with echo on to appease the Emacs shell users with pitchforks. >>> >>> On Wed, Apr 25, 2018 at 9:34 AM, Xueming Shen >>> wrote: >>> >>>> On 4/25/18, 9:02 AM, Martin Buchholz wrote: >>>> >>>> It would be more correct I think for Console to track if there is a >>>> pending readPassword in progress and try to restore echo on exit >>>> only if >>>> so. But a little annoying to implement (need an additional boolean?) >>>> >>>> >>>> I think that is what Jan proposed "to add restoredEchoOnShutdown = >>>> true", >>>> and I'm fine >>>> with that. I'm just a little confused why jshell invokes >>>> System.console() >>>> if it handles all "raw" >>>> terminal stuff itself. >>>> >>>> >>>> On Wed, Apr 25, 2018 at 8:52 AM, Xueming Shen >>>> wrote: >>>> >>>>> >>>>> Hi Jan, >>>>> >>>>> I saw System.console() returns null inside jshell ... but it seems >>>>> there >>>>> are 2 vms. >>>>> I would assume jshell itself sets the terminal to raw and then call >>>>> System.console()? >>>>> for example an alternative for this issue is to ask jshell's impl >>>>> to call >>>>> System.console() >>>>> before going into raw mode? No, I'm not saying the proposed one is >>>>> not a >>>>> good one, >>>>> just wanted to make sure I understand the situation correctly. >>>>> >>>>> Thanks, >>>>> Sherman >>>>> >>>>> >>>>> >>>>> On 4/25/18, 4:50 AM, Jan Lahoda wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Under: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8194750 >>>>>> >>>>>> j.i.Console was changed to capture the state of the terminal echo at >>>>>> creation time, and to restore it on shutdown. >>>>>> >>>>>> That is problematic at least in jshell, where the terminal is >>>>>> already in >>>>>> the raw mode when j.i.Console is created, and so "echo disabled" is >>>>>> recorded there. So even though jshell itself sets the terminal >>>>>> into the >>>>>> original mode when it terminates, the shutdown hook in >>>>>> j.i.Console, which >>>>>> is run later, sets the echo to off even if it was enabled before >>>>>> the VM >>>>>> started. >>>>>> >>>>>> My understanding is that the shutdown hook is only needed in case >>>>>> the VM >>>>>> goes down while readPassword is running. So I tried to change the >>>>>> shutdown >>>>>> hook to only work while readPassword is running. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202105 >>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8202105/webrev.00/ >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Thanks, >>>>>> Jan >>>>>> >>>>> >>>>> >>>> >>>> > From chris.hegarty at oracle.com Thu Apr 26 12:30:44 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 26 Apr 2018 13:30:44 +0100 Subject: 8202284: FileChannel and FileOutpuStream variants of AtomicAppend should pass silently on macOS >= 10.13 In-Reply-To: <1DD25910-724A-4727-B886-92E481206BC9@oracle.com> References: <1DD25910-724A-4727-B886-92E481206BC9@oracle.com> Message-ID: <58ADE1E8-B2B2-43DA-90B4-412D3A13301F@oracle.com> > On 25 Apr 2018, at 23:11, Brian Burkhalter wrote: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8202284 > Patch: http://cr.openjdk.java.net/~bpb/8202284/webrev.00/ I think this looks good Brian. > On 26 Apr 2018, at 01:09, Brian Burkhalter wrote: > > https://bugs.openjdk.java.net/browse/JDK-8202290 to track this problem. I agree with filing a new issue to track the underlying bug, rather than attempting to re-open an already resolved one. -Chris. From claes.redestad at oracle.com Thu Apr 26 13:30:07 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 26 Apr 2018 15:30:07 +0200 Subject: RFR: 8202324: Avoid loading FileInput-/OutputStream$AltFinalizer Message-ID: <385509a7-36fc-5b88-2e71-21be48dc6725@oracle.com> Hi, we can avoid eagerly loading the FileInput-/OutputStream$AltFinalizer classes on normal use, which is a small startup win. Webrev: http://cr.openjdk.java.net/~redestad/8202324/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8202324 Thanks! /Claes From Alan.Bateman at oracle.com Thu Apr 26 13:49:37 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 26 Apr 2018 14:49:37 +0100 Subject: RFR: 8202324: Avoid loading FileInput-/OutputStream$AltFinalizer In-Reply-To: <385509a7-36fc-5b88-2e71-21be48dc6725@oracle.com> References: <385509a7-36fc-5b88-2e71-21be48dc6725@oracle.com> Message-ID: <7cb01760-f798-8371-3b4c-9ab67d1dce0d@oracle.com> On 26/04/2018 14:30, Claes Redestad wrote: > Hi, > > we can avoid eagerly loading the FileInput-/OutputStream$AltFinalizer > classes on normal use, which is a small startup win. > > Webrev: http://cr.openjdk.java.net/~redestad/8202324/open.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202324 This looks okay as the AltFinalizer classes are only needed when code is extending FIS or FOS. -Alan. From bhamaram at in.ibm.com Thu Apr 26 13:54:36 2018 From: bhamaram at in.ibm.com (Bhaktavatsal R Maram) Date: Thu, 26 Apr 2018 13:54:36 +0000 Subject: [AIX] Fix codepage mappings in Java for IBM-943 and Big5 Message-ID: Hi All, This issue is continuation to bug 8201540 (Extend the set of supported charsets in java.base on AIX) in which we have moved default charsets of most of the locales supported by Operating System to java.base module thus enabling OpenJDK on those locales for AIX platform. As part of that, charsets for locales Ja_JP (IBM-943) and Zh_TW (big5) also have been moved. However, corresponding charsets mapped in Java is not correct for them on AIX. Following are the details: 1. IBM-943 [1] for locale Ja_JP should be mapped to IBM-943C [2] Fundamental difference between IBM-943 and IBM-943C is that IBM-943C is ASCII compatible which means code points 'yen' and 'overline' of IBM-943 is replaced with 'backslash' and 'tilde' from ASCII character set. 2. Big5 for locale Zh_TW should be mapped to IBM-950 [3] I've attached simple test program to print the default charset along with fix for this issue. When run test program (PrintDefaultCharset) with IBM JDK 8 (on AIX) for locales Ja_JP & Zh_TW, following is output. -bash-4.4$ LANG=Ja_JP ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset LANG = Ja_JP Default charset = x-IBM943C file.encoding = IBM-943C sun.jnu.encoding = IBM-943C -bash-4.4$ LANG=Zh_TW ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset LANG = Zh_TW Default charset = x-IBM950 file.encoding = IBM-950 sun.jnu.encoding = IBM-950 Same test run with openJDK 11 gives following output -bash-4.4$ LANG=Ja_JP ~/jdk/bin/java PrintDefaultCharset LANG = Ja_JP Default charset = x-IBM943 file.encoding = IBM-943 sun.jnu.encoding = IBM-943 -bash-4.4$ LANG=Zh_TW ~/jdk/bin/java PrintDefaultCharset LANG = Zh_TW Default charset = Big5 file.encoding = big5 sun.jnu.encoding = big5 I will get webrev hosted in http://cr.openjdk.java.net for this change and send it for review once JIRA bug is created. [1] http://demo.icu-project.org/icu-bin/convexp?conv=ibm-943_P130-1999&s=JAVA [2] http://demo.icu-project.org/icu-bin/convexp?conv=ibm-943_P15A-2003&s=ALL [3] https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.nlsgdrf/big5.htm Thanks, Bhaktavatsal Reddy From bhamaram at in.ibm.com Thu Apr 26 14:02:44 2018 From: bhamaram at in.ibm.com (Bhaktavatsal R Maram) Date: Thu, 26 Apr 2018 14:02:44 +0000 Subject: [AIX] Fix codepage mappings in Java for IBM-943 and Big5 In-Reply-To: References: Message-ID: Oops! Looks like there is problem with attachment (might be because I attached .class file as well). I'm pasting the fix and test program here in mail. Test Program: import java.nio.charset.*; class PrintDefaultCharset { public static void main(String[] args) { System.out.println("LANG = "+System.getenv("LANG")); System.out.println("Default charset = "+Charset.defaultCharset().name()); System.out.println("file.encoding = "+System.getProperty("file.encoding")); System.out.println("sun.jnu.encoding = "+System.getProperty("sun.jnu.encoding")); } } Fix: diff --git a/src/java.base/unix/native/libjava/java_props_md.c b/src/java.base/unix/native/libjava/java_props_md.c --- a/src/java.base/unix/native/libjava/java_props_md.c +++ b/src/java.base/unix/native/libjava/java_props_md.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 1998, 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1998, 2018, 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 @@ -297,6 +297,18 @@ if (strcmp(p, "EUC-JP") == 0) { *std_encoding = "EUC-JP-LINUX"; } +#elif defined _AIX + if (strcmp(p, "big5") == 0) { + /* On AIX Traditional Chinese Big5 codeset is mapped to IBM-950 */ + *std_encoding = "IBM-950"; + } else if (strcmp(p, "IBM-943") == 0) { + /* + * On AIX, IBM-943 is mapped to IBM-943C in which symbol 'yen' and + * 'overline' are replaced with 'backslash' and 'tilde' from ASCII + * making first 96 code points same as ASCII. + */ + *std_encoding = "IBM-943C"; + } #else if (strcmp(p,"eucJP") == 0) { /* For Solaris use customized vendor defined character Thanks, Bhaktavatsal Reddy -----"core-libs-dev" wrote: ----- To: "Java Core Libs" From: "Bhaktavatsal R Maram" Sent by: "core-libs-dev" Date: 04/26/2018 07:26PM Subject: [AIX] Fix codepage mappings in Java for IBM-943 and Big5 Hi All, This issue is continuation to bug 8201540 (Extend the set of supported charsets in java.base on AIX) in which we have moved default charsets of most of the locales supported by Operating System to java.base module thus enabling OpenJDK on those locales for AIX platform. As part of that, charsets for locales Ja_JP (IBM-943) and Zh_TW (big5) also have been moved. However, corresponding charsets mapped in Java is not correct for them on AIX. Following are the details: 1. IBM-943 [1] for locale Ja_JP should be mapped to IBM-943C [2] Fundamental difference between IBM-943 and IBM-943C is that IBM-943C is ASCII compatible which means code points 'yen' and 'overline' of IBM-943 is replaced with 'backslash' and 'tilde' from ASCII character set. 2. Big5 for locale Zh_TW should be mapped to IBM-950 [3] I've attached simple test program to print the default charset along with fix for this issue. When run test program (PrintDefaultCharset) with IBM JDK 8 (on AIX) for locales Ja_JP & Zh_TW, following is output. -bash-4.4$ LANG=Ja_JP ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset LANG = Ja_JP Default charset = x-IBM943C file.encoding = IBM-943C sun.jnu.encoding = IBM-943C -bash-4.4$ LANG=Zh_TW ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset LANG = Zh_TW Default charset = x-IBM950 file.encoding = IBM-950 sun.jnu.encoding = IBM-950 Same test run with openJDK 11 gives following output -bash-4.4$ LANG=Ja_JP ~/jdk/bin/java PrintDefaultCharset LANG = Ja_JP Default charset = x-IBM943 file.encoding = IBM-943 sun.jnu.encoding = IBM-943 -bash-4.4$ LANG=Zh_TW ~/jdk/bin/java PrintDefaultCharset LANG = Zh_TW Default charset = Big5 file.encoding = big5 sun.jnu.encoding = big5 I will get webrev hosted in https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=Prdd2GWj8c4aCa1qPr65xklNyDyu64w_6X7qkNaI-D8&s=8C1bILMg6JLJtbL0KLRPfU0MkIPkAmq_IlJgdTfpjdI&e= for this change and send it for review once JIRA bug is created. [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__demo.icu-2Dproject.org_icu-2Dbin_convexp-3Fconv-3Dibm-2D943-5FP130-2D1999-26s-3DJAVA&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=Prdd2GWj8c4aCa1qPr65xklNyDyu64w_6X7qkNaI-D8&s=RJOiyJTR1jkgxxnRZu5JL97irAnHo1M4wMp7x21dgvs&e= [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__demo.icu-2Dproject.org_icu-2Dbin_convexp-3Fconv-3Dibm-2D943-5FP15A-2D2003-26s-3DALL&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=Prdd2GWj8c4aCa1qPr65xklNyDyu64w_6X7qkNaI-D8&s=gXshfq2f9yed1iEYTdt57Lk0vvHXztqgUzOLQ64h8Vo&e= [3] https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.nlsgdrf/big5.htm Thanks, Bhaktavatsal Reddy From matthias.baesken at sap.com Thu Apr 26 14:13:38 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 26 Apr 2018 14:13:38 +0000 Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 Message-ID: <8361024dba4f44309292e73ec9ad7b83@sap.com> Hello , could you please review this small adjustment to the symbol visibility compilation settings on AIX ? Currently we use XLC 12.1 to compile JDK on AIX . However XLC 12.1 does not support the "-qvisibility=hidden" setting currently set on AIX. It was introduced with XLC 13.1 . Christoph found some info about it here : https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html Setting it only generates hundreds of warnings in the build log , warnings look like this : XlC12.1 bash-4.4$ xlC -qversion IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0019 bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of valid options. Compare to XLC13.1 bash-3.00$ xlC -qversion IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) Version: 13.01.0000.0008 bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc So it is better to avoid setting these flags when using xlc12.1 . Please review : Bug : https://bugs.openjdk.java.net/browse/JDK-8202322 Change : http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/ Best regards, Matthias From mandy.chung at oracle.com Thu Apr 26 14:16:19 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 26 Apr 2018 22:16:19 +0800 Subject: Review Request JDK-8201793: (ref) Reference object should not support cloning Message-ID: <6a3759c9-0e6f-b3e6-5ef5-2b032c8d7773@oracle.com> The semantics of cloning a Reference object is not clearly defined. In addition, it is questionable whether it can be meaningfully supported in particular with concurrent reference processing. The reachability state of a Reference object may change during GC reference processing. The referent may have been cleared when it reaches its reachability state. In addition, it may be enqueued or pending for enqueuing. Cloning a Reference object with a referent that is unreachable but not yet cleared might mean to resurrect the referent. A cloned enqueued Reference object will never be enqueued.? A Reference object cannot be meaningfully cloned. We propose Reference::clone to throw CloneNotSupportedException.? To clone a Reference object, it should create a new instance via its constructor. CSR: https://bugs.openjdk.java.net/browse/JDK-8202260 Webrev: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8201793/webrev.00/ Mandy From thomas.stuefe at gmail.com Thu Apr 26 14:31:57 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 26 Apr 2018 16:31:57 +0200 Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 In-Reply-To: <8361024dba4f44309292e73ec9ad7b83@sap.com> References: <8361024dba4f44309292e73ec9ad7b83@sap.com> Message-ID: Hi Matthias, I would prefer a numerical comparison to version < 13. Otherwise the code looks like you want to just exclude 12.1 for some reason when in reality you want to omit the flag for any compiler older than xlc 13. Best Regards, Thomas On Thu, Apr 26, 2018 at 4:13 PM, Baesken, Matthias wrote: > Hello , could you please review this small adjustment to the symbol visibility compilation settings on AIX ? > Currently we use XLC 12.1 to compile JDK on AIX . > > However XLC 12.1 does not support the "-qvisibility=hidden" setting currently set on AIX. > It was introduced with XLC 13.1 . Christoph found some info about it here : > > https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html > > Setting it only generates hundreds of warnings in the build log , warnings look like this : > XlC12.1 > > bash-4.4$ xlC -qversion > IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) > Version: 12.01.0000.0019 > > bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of valid options. > > Compare to XLC13.1 > > bash-3.00$ xlC -qversion > IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) > Version: 13.01.0000.0008 > bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc > bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > > > So it is better to avoid setting these flags when using xlc12.1 . > Please review : > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8202322 > > Change : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/ > > > Best regards, Matthias > > From bhamaram at in.ibm.com Thu Apr 26 14:32:04 2018 From: bhamaram at in.ibm.com (Bhaktavatsal R Maram) Date: Thu, 26 Apr 2018 14:32:04 +0000 Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 In-Reply-To: <8361024dba4f44309292e73ec9ad7b83@sap.com> References: <8361024dba4f44309292e73ec9ad7b83@sap.com> Message-ID: Hi Matthias, Its right in time. I am facing "Undefined Symbol" errors with XLC 13.1 due to "-qvisibility=hidden" which hides all symbols by default. I workaround that by removing this flag -bash-4.4$ xlC -qversion IBM XL C/C++ for AIX, V13.1.3 (5725-C72, 5765-J07) Version: 13.01.0003.0000 Looks like there are many function declarations that require changes to make function visible. Thanks, Bhaktavatsal Reddy -----"core-libs-dev" wrote: ----- To: "'build-dev at openjdk.java.net'" , "ppc-aix-port-dev at openjdk.java.net" , "core-libs-dev at openjdk.java.net" From: "Baesken, Matthias" Sent by: "core-libs-dev" Date: 04/26/2018 07:45PM Cc: "Simonis, Volker" Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 Hello , could you please review this small adjustment to the symbol visibility compilation settings on AIX ? Currently we use XLC 12.1 to compile JDK on AIX . However XLC 12.1 does not support the "-qvisibility=hidden" setting currently set on AIX. It was introduced with XLC 13.1 . Christoph found some info about it here : https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html Setting it only generates hundreds of warnings in the build log , warnings look like this : XlC12.1 bash-4.4$ xlC -qversion IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0019 bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of valid options. Compare to XLC13.1 bash-3.00$ xlC -qversion IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) Version: 13.01.0000.0008 bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc So it is better to avoid setting these flags when using xlc12.1 . Please review : Bug : https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8202322&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=F6_aATE7bsRWZG5lPZhJUESHNGqST5MNbkULllIH8l4&s=M4IJ-YdB3dfN7lj0DEWozQbipDXmgKtSu3pEyMcJF_E&e= Change : https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Embaesken_webrevs_8202322_&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=F6_aATE7bsRWZG5lPZhJUESHNGqST5MNbkULllIH8l4&s=gb0OP9fQTAWWJbBZDK6L_0gTKf1pwna8aXaYr_uVv8Q&e= Best regards, Matthias From matthias.baesken at sap.com Thu Apr 26 14:37:17 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 26 Apr 2018 14:37:17 +0000 Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 In-Reply-To: References: <8361024dba4f44309292e73ec9ad7b83@sap.com> Message-ID: <1ff5961701994081819d0bd7db3d3ec3@sap.com> > Its right in time. I am facing "Undefined Symbol" errors with XLC 13.1 due to > "-qvisibility=hidden" which hides all symbols by default. I workaround that by > removing this flag Hello, so it seems that I better remove the "-qvisibility=" completely for xlc (and not only for xlc12.1) ? (we currently compile only with XLC 12.1 , there might be more issues with 13.1 ) Best regards, Matthias > -----Original Message----- > From: Bhaktavatsal R Maram [mailto:bhamaram at in.ibm.com] > Sent: Donnerstag, 26. April 2018 16:32 > To: Baesken, Matthias > Cc: 'build-dev at openjdk.java.net' ; ppc-aix- > port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Simonis, > Volker > Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 > > Hi Matthias, > > Its right in time. I am facing "Undefined Symbol" errors with XLC 13.1 due to > "-qvisibility=hidden" which hides all symbols by default. I workaround that by > removing this flag > > -bash-4.4$ xlC -qversion > IBM XL C/C++ for AIX, V13.1.3 (5725-C72, 5765-J07) > Version: 13.01.0003.0000 > > Looks like there are many function declarations that require changes to make > function visible. > > Thanks, > Bhaktavatsal Reddy > > > > -----"core-libs-dev" wrote: ----- > To: "'build-dev at openjdk.java.net'" , "ppc- > aix-port-dev at openjdk.java.net" , > "core-libs-dev at openjdk.java.net" > From: "Baesken, Matthias" > Sent by: "core-libs-dev" > Date: 04/26/2018 07:45PM > Cc: "Simonis, Volker" > Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 > > Hello , could you please review this small adjustment to the symbol visibility > compilation settings on AIX ? > Currently we use XLC 12.1 to compile JDK on AIX . > > However XLC 12.1 does not support the "-qvisibility=hidden" setting > currently set on AIX. > It was introduced with XLC 13.1 . Christoph found some info about it here : > > https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility- > part2/index.html > > Setting it only generates hundreds of warnings in the build log , warnings > look like this : > XlC12.1 > > bash-4.4$ xlC -qversion > IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) > Version: 12.01.0000.0019 > > bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of valid > options. > > Compare to XLC13.1 > > bash-3.00$ xlC -qversion > IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) > Version: 13.01.0000.0008 > bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc > bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > > > So it is better to avoid setting these flags when using xlc12.1 . > Please review : > > Bug : > > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__bugs.openjdk.java.net_browse_JDK- > 2D8202322&d=DwIFAg&c=jf_iaSHvJObTbx- > siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m > =F6_aATE7bsRWZG5lPZhJUESHNGqST5MNbkULllIH8l4&s=M4IJ- > YdB3dfN7lj0DEWozQbipDXmgKtSu3pEyMcJF_E&e= > > Change : > > https://urldefense.proofpoint.com/v2/url?u=http- > 3A__cr.openjdk.java.net_- > 7Embaesken_webrevs_8202322_&d=DwIFAg&c=jf_iaSHvJObTbx- > siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m > =F6_aATE7bsRWZG5lPZhJUESHNGqST5MNbkULllIH8l4&s=gb0OP9fQTAWWJb > BZDK6L_0gTKf1pwna8aXaYr_uVv8Q&e= > > > Best regards, Matthias > > From christoph.langer at sap.com Thu Apr 26 14:38:04 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 26 Apr 2018 14:38:04 +0000 Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 In-Reply-To: <8361024dba4f44309292e73ec9ad7b83@sap.com> References: <8361024dba4f44309292e73ec9ad7b83@sap.com> Message-ID: Hi Matthias, to me the change in principal looks good. I'm wondering if it is possible to do a comparison like xlc < 13 (e.g. extract major number before the first dot, then compare numerically) - but maybe it is too complicated and the current single version compare suits our needs ? Best regards Christoph From: Baesken, Matthias Sent: Donnerstag, 26. April 2018 16:14 To: 'build-dev at openjdk.java.net' ; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Cc: Langer, Christoph ; Simonis, Volker Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 Hello , could you please review this small adjustment to the symbol visibility compilation settings on AIX ? Currently we use XLC 12.1 to compile JDK on AIX . However XLC 12.1 does not support the "-qvisibility=hidden" setting currently set on AIX. It was introduced with XLC 13.1 . Christoph found some info about it here : https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html Setting it only generates hundreds of warnings in the build log , warnings look like this : XlC12.1 bash-4.4$ xlC -qversion IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0019 bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of valid options. Compare to XLC13.1 bash-3.00$ xlC -qversion IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) Version: 13.01.0000.0008 bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc So it is better to avoid setting these flags when using xlc12.1 . Please review : Bug : https://bugs.openjdk.java.net/browse/JDK-8202322 Change : http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/ Best regards, Matthias From matthias.baesken at sap.com Thu Apr 26 14:52:34 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 26 Apr 2018 14:52:34 +0000 Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 In-Reply-To: References: <8361024dba4f44309292e73ec9ad7b83@sap.com> Message-ID: <97c60ab29a6348769169b312f55832e7@sap.com> Hello Christoph, I think all XLC versions < 12.1 are unsupported (and probably not working anyway) for the OpenJDK build . I am only aware of XLC versions 12.1 and 13.1 which work / in case of 13.1 "might" work for OpenJDK compilation . And for 12.1 I want to remove the flags . ( waiting for the feedback of Bhaktavatsal Reddy , in case he prefers it I remove them for all xlC versions including 13.1 ) Best regards, Matthias From: Langer, Christoph Sent: Donnerstag, 26. April 2018 16:38 To: Baesken, Matthias ; 'build-dev at openjdk.java.net' ; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Cc: Simonis, Volker Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 Hi Matthias, to me the change in principal looks good. I'm wondering if it is possible to do a comparison like xlc < 13 (e.g. extract major number before the first dot, then compare numerically) - but maybe it is too complicated and the current single version compare suits our needs ? Best regards Christoph From: Baesken, Matthias Sent: Donnerstag, 26. April 2018 16:14 To: 'build-dev at openjdk.java.net' >; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Cc: Langer, Christoph >; Simonis, Volker > Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 Hello , could you please review this small adjustment to the symbol visibility compilation settings on AIX ? Currently we use XLC 12.1 to compile JDK on AIX . However XLC 12.1 does not support the "-qvisibility=hidden" setting currently set on AIX. It was introduced with XLC 13.1 . Christoph found some info about it here : https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html Setting it only generates hundreds of warnings in the build log , warnings look like this : XlC12.1 bash-4.4$ xlC -qversion IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0019 bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of valid options. Compare to XLC13.1 bash-3.00$ xlC -qversion IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) Version: 13.01.0000.0008 bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc So it is better to avoid setting these flags when using xlc12.1 . Please review : Bug : https://bugs.openjdk.java.net/browse/JDK-8202322 Change : http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/ Best regards, Matthias From bhamaram at in.ibm.com Thu Apr 26 14:59:14 2018 From: bhamaram at in.ibm.com (Bhaktavatsal R Maram) Date: Thu, 26 Apr 2018 14:59:14 +0000 Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 In-Reply-To: <97c60ab29a6348769169b312f55832e7@sap.com> References: <97c60ab29a6348769169b312f55832e7@sap.com>, <8361024dba4f44309292e73ec9ad7b83@sap.com> Message-ID: Hi Matthias, At this point, I think we can remove the flag as you found that it is not supported in XLC < 13. And with XLC 13, it require more work to use this flag. Thanks, Bhaktavatsal Reddy -----"Baesken, Matthias" wrote: ----- To: "Langer, Christoph" , "'build-dev at openjdk.java.net'" , "ppc-aix-port-dev at openjdk.java.net" , "core-libs-dev at openjdk.java.net" From: "Baesken, Matthias" Date: 04/26/2018 08:23PM Cc: "Simonis, Volker" , Bhaktavatsal R Maram Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 Hello Christoph, I think all XLC versions < 12.1 are unsupported (and probably not working anyway) for the OpenJDK build . I am only aware of XLC versions 12.1 and 13.1 which work / in case of 13.1 ?might? work for OpenJDK compilation . And for 12.1 I want to remove the flags . ( waiting for the feedback of Bhaktavatsal Reddy , in case he prefers it I remove them for all xlC versions including 13.1 ) Best regards, Matthias From: Langer, Christoph Sent: Donnerstag, 26. April 2018 16:38 To: Baesken, Matthias ; 'build-dev at openjdk.java.net' ; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Cc: Simonis, Volker Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 Hi Matthias, to me the change in principal looks good. I?m wondering if it is possible to do a comparison like xlc < 13 (e.g. extract major number before the first dot, then compare numerically) ? but maybe it is too complicated and the current single version compare suits our needs ? Best regards Christoph From: Baesken, Matthias Sent: Donnerstag, 26. April 2018 16:14 To: 'build-dev at openjdk.java.net' ; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Cc: Langer, Christoph ; Simonis, Volker Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 Hello , could you please review this small adjustment to the symbol visibility compilation settings on AIX ? Currently we use XLC 12.1 to compile JDK on AIX . However XLC 12.1 does not support the ?-qvisibility=hidden? setting currently set on AIX. It was introduced with XLC 13.1 . Christoph found some info about it here : https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html Setting it only generates hundreds of warnings in the build log , warnings look like this : XlC12.1 bash-4.4$ xlC -qversion IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0019 bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of valid options. Compare to XLC13.1 bash-3.00$ xlC -qversion IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) Version: 13.01.0000.0008 bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc So it is better to avoid setting these flags when using xlc12.1 . Please review : Bug : https://bugs.openjdk.java.net/browse/JDK-8202322 Change : http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/ Best regards, Matthias From claes.redestad at oracle.com Thu Apr 26 15:15:09 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 26 Apr 2018 17:15:09 +0200 Subject: RFR: 8202324: Avoid loading FileInput-/OutputStream$AltFinalizer In-Reply-To: <7cb01760-f798-8371-3b4c-9ab67d1dce0d@oracle.com> References: <385509a7-36fc-5b88-2e71-21be48dc6725@oracle.com> <7cb01760-f798-8371-3b4c-9ab67d1dce0d@oracle.com> Message-ID: On 2018-04-26 15:49, Alan Bateman wrote: >> >> Webrev: http://cr.openjdk.java.net/~redestad/8202324/open.00/ >> > This looks okay as the AltFinalizer classes are only needed when code > is extending FIS or FOS. Thanks, Alan! /Claes From volker.simonis at gmail.com Thu Apr 26 15:16:45 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 26 Apr 2018 17:16:45 +0200 Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 In-Reply-To: References: <8361024dba4f44309292e73ec9ad7b83@sap.com> <97c60ab29a6348769169b312f55832e7@sap.com> Message-ID: Hi Matthias, after Bhaktavatsal Reddy's report about the problems with "-qvisibility" with xlC 13 and taking into account that we can't test this anyway because we don't currently have xlC 13 on our machines I think it would be best to completely remove this option for now on AIX. Once we get xlC 13 we can revisit the issue. Thanks, Volker On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram wrote: > Hi Matthias, > > At this point, I think we can remove the flag as you found that it is not supported in XLC < 13. And with XLC 13, it require more work to use this flag. > > Thanks, > Bhaktavatsal Reddy > > > > -----"Baesken, Matthias" wrote: ----- > To: "Langer, Christoph" , "'build-dev at openjdk.java.net'" , "ppc-aix-port-dev at openjdk.java.net" , "core-libs-dev at openjdk.java.net" > From: "Baesken, Matthias" > Date: 04/26/2018 08:23PM > Cc: "Simonis, Volker" , Bhaktavatsal R Maram > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 > > > Hello Christoph, I think all XLC versions < 12.1 are unsupported (and probably not working anyway) for the OpenJDK build . > I am only aware of XLC versions 12.1 and 13.1 which work / in case of 13.1 ?might? work for OpenJDK compilation . > And for 12.1 I want to remove the flags . > > ( waiting for the feedback of Bhaktavatsal Reddy , in case he prefers it I remove them for all xlC versions including 13.1 ) > > Best regards, Matthias > > > > > > > From: Langer, Christoph > Sent: Donnerstag, 26. April 2018 16:38 > To: Baesken, Matthias ; 'build-dev at openjdk.java.net' ; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Cc: Simonis, Volker > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 > > Hi Matthias, > > to me the change in principal looks good. > > I?m wondering if it is possible to do a comparison like xlc < 13 (e.g. extract major number before the first dot, then compare numerically) ? but maybe it is too complicated and the current single version compare suits our needs ? > > Best regards > Christoph > > > > > From: Baesken, Matthias > Sent: Donnerstag, 26. April 2018 16:14 > To: 'build-dev at openjdk.java.net' ; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Cc: Langer, Christoph ; Simonis, Volker > Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 > > Hello , could you please review this small adjustment to the symbol visibility compilation settings on AIX ? > Currently we use XLC 12.1 to compile JDK on AIX . > > However XLC 12.1 does not support the ?-qvisibility=hidden? setting currently set on AIX. > It was introduced with XLC 13.1 . Christoph found some info about it here : > > https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html > > Setting it only generates hundreds of warnings in the build log , warnings look like this : > XlC12.1 > > bash-4.4$ xlC -qversion > IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) > Version: 12.01.0000.0019 > > bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of valid options. > > Compare to XLC13.1 > > bash-3.00$ xlC -qversion > IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) > Version: 13.01.0000.0008 > bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc > bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > > > So it is better to avoid setting these flags when using xlc12.1 . > Please review : > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8202322 > > Change : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/ > > > Best regards, Matthias > > > > From mikael.vidstedt at oracle.com Thu Apr 26 15:41:52 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 26 Apr 2018 08:41:52 -0700 Subject: RFR: 8202330: Add Unreferenced{FOS,FIS,RAF}ClosesFd to problem list Message-ID: <82E0FF51-3540-46FD-9980-B40EBC9F98BC@oracle.com> The java/io/*/Unreferenced{FOS,FIS,RAF}ClosesFd tests are failing quite frequently and should be added to the problem list until the issue (tracked by https://bugs.openjdk.java.net/browse/JDK-8202292 ) has been resolved: Bug: https://bugs.openjdk.java.net/browse/JDK-8202330 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8202330/webrev.00/open/webrev/ Cheers, Mikael From volker.simonis at gmail.com Thu Apr 26 15:41:56 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 26 Apr 2018 17:41:56 +0200 Subject: [AIX] Fix codepage mappings in Java for IBM-943 and Big5 In-Reply-To: References: Message-ID: Hi Bhaktavatsal Reddy, I've opened the following issue for this problem: 8202329: [AIX] Fix codepage mappings for IBM-943 and Big5 https://bugs.openjdk.java.net/browse/JDK-8202329 Looking at you fix, can you please replace the "#elif AIX" by "#ifdef AIX" and the original "#else" by "#ifdef __solaris__". The original else branch contains Solaris-only code anyway and it is an historical omission that there are still a lot of places in the code where "not Linux" implicitly means "Solaris", but that's often wrong. Regards, Volker On Thu, Apr 26, 2018 at 4:02 PM, Bhaktavatsal R Maram wrote: > Oops! Looks like there is problem with attachment (might be because I attached .class file as well). I'm pasting the fix and test program here in mail. > > Test Program: > > import java.nio.charset.*; > class PrintDefaultCharset { > public static void main(String[] args) { > System.out.println("LANG = "+System.getenv("LANG")); > System.out.println("Default charset = "+Charset.defaultCharset().name()); > System.out.println("file.encoding = "+System.getProperty("file.encoding")); > System.out.println("sun.jnu.encoding = "+System.getProperty("sun.jnu.encoding")); > } > } > > > Fix: > > diff --git a/src/java.base/unix/native/libjava/java_props_md.c b/src/java.base/unix/native/libjava/java_props_md.c > --- a/src/java.base/unix/native/libjava/java_props_md.c > +++ b/src/java.base/unix/native/libjava/java_props_md.c > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1998, 2016, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1998, 2018, 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 > @@ -297,6 +297,18 @@ > if (strcmp(p, "EUC-JP") == 0) { > *std_encoding = "EUC-JP-LINUX"; > } > +#elif defined _AIX > + if (strcmp(p, "big5") == 0) { > + /* On AIX Traditional Chinese Big5 codeset is mapped to IBM-950 */ > + *std_encoding = "IBM-950"; > + } else if (strcmp(p, "IBM-943") == 0) { > + /* > + * On AIX, IBM-943 is mapped to IBM-943C in which symbol 'yen' and > + * 'overline' are replaced with 'backslash' and 'tilde' from ASCII > + * making first 96 code points same as ASCII. > + */ > + *std_encoding = "IBM-943C"; > + } > #else > if (strcmp(p,"eucJP") == 0) { > /* For Solaris use customized vendor defined character > > > Thanks, > Bhaktavatsal Reddy > > > -----"core-libs-dev" wrote: ----- > To: "Java Core Libs" > From: "Bhaktavatsal R Maram" > Sent by: "core-libs-dev" > Date: 04/26/2018 07:26PM > Subject: [AIX] Fix codepage mappings in Java for IBM-943 and Big5 > > Hi All, > > This issue is continuation to bug 8201540 (Extend the set of supported charsets in java.base on AIX) in which we have moved default charsets of most of the locales supported by Operating System to java.base module thus enabling OpenJDK on those locales for AIX platform. > > As part of that, charsets for locales Ja_JP (IBM-943) and Zh_TW (big5) also have been moved. However, corresponding charsets mapped in Java is not correct for them on AIX. Following are the details: > > 1. IBM-943 [1] for locale Ja_JP should be mapped to IBM-943C [2] > > Fundamental difference between IBM-943 and IBM-943C is that IBM-943C is ASCII compatible which means code points 'yen' and 'overline' of IBM-943 is replaced with 'backslash' and 'tilde' from ASCII character set. > > > 2. Big5 for locale Zh_TW should be mapped to IBM-950 [3] > > I've attached simple test program to print the default charset along with fix for this issue. When run test program (PrintDefaultCharset) with IBM JDK 8 (on AIX) for locales Ja_JP & Zh_TW, following is output. > > -bash-4.4$ LANG=Ja_JP ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset > LANG = Ja_JP > Default charset = x-IBM943C > file.encoding = IBM-943C > sun.jnu.encoding = IBM-943C > > -bash-4.4$ LANG=Zh_TW ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset > LANG = Zh_TW > Default charset = x-IBM950 > file.encoding = IBM-950 > sun.jnu.encoding = IBM-950 > > > Same test run with openJDK 11 gives following output > > -bash-4.4$ LANG=Ja_JP ~/jdk/bin/java PrintDefaultCharset > LANG = Ja_JP > Default charset = x-IBM943 > file.encoding = IBM-943 > sun.jnu.encoding = IBM-943 > > -bash-4.4$ LANG=Zh_TW ~/jdk/bin/java PrintDefaultCharset > LANG = Zh_TW > Default charset = Big5 > file.encoding = big5 > sun.jnu.encoding = big5 > > I will get webrev hosted in https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=Prdd2GWj8c4aCa1qPr65xklNyDyu64w_6X7qkNaI-D8&s=8C1bILMg6JLJtbL0KLRPfU0MkIPkAmq_IlJgdTfpjdI&e= for this change and send it for review once JIRA bug is created. > > [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__demo.icu-2Dproject.org_icu-2Dbin_convexp-3Fconv-3Dibm-2D943-5FP130-2D1999-26s-3DJAVA&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=Prdd2GWj8c4aCa1qPr65xklNyDyu64w_6X7qkNaI-D8&s=RJOiyJTR1jkgxxnRZu5JL97irAnHo1M4wMp7x21dgvs&e= > [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__demo.icu-2Dproject.org_icu-2Dbin_convexp-3Fconv-3Dibm-2D943-5FP15A-2D2003-26s-3DALL&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=Prdd2GWj8c4aCa1qPr65xklNyDyu64w_6X7qkNaI-D8&s=gXshfq2f9yed1iEYTdt57Lk0vvHXztqgUzOLQ64h8Vo&e= > [3] https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.nlsgdrf/big5.htm > > > Thanks, > Bhaktavatsal Reddy > > > > From brian.burkhalter at oracle.com Thu Apr 26 15:56:20 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 26 Apr 2018 08:56:20 -0700 Subject: RFR: 8202330: Add Unreferenced{FOS, FIS, RAF}ClosesFd to problem list In-Reply-To: <82E0FF51-3540-46FD-9980-B40EBC9F98BC@oracle.com> References: <82E0FF51-3540-46FD-9980-B40EBC9F98BC@oracle.com> Message-ID: <2E49253B-324F-4632-A328-5222091F2EFF@oracle.com> Hi Mikael, +1 Thanks, Brian On Apr 26, 2018, at 8:41 AM, Mikael Vidstedt wrote: > The java/io/*/Unreferenced{FOS,FIS,RAF}ClosesFd tests are failing quite frequently and should be added to the problem list until the issue (tracked byhttps://bugs.openjdk.java.net/browse/JDK-8202292) has been resolved: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202330 > Webrev:http://cr.openjdk.java.net/~mikael/webrevs/8202330/webrev.00/open/webrev/ From bhamaram at in.ibm.com Thu Apr 26 15:59:58 2018 From: bhamaram at in.ibm.com (Bhaktavatsal R Maram) Date: Thu, 26 Apr 2018 15:59:58 +0000 Subject: [AIX] Fix codepage mappings in Java for IBM-943 and Big5 In-Reply-To: References: , Message-ID: Hi Volker, Thank you. I will address your review comments and send webrev for review. - Bhaktavatsal Reddy -----Volker Simonis wrote: ----- To: Bhaktavatsal R Maram From: Volker Simonis Date: 04/26/2018 09:12PM Cc: Java Core Libs Subject: Re: [AIX] Fix codepage mappings in Java for IBM-943 and Big5 Hi Bhaktavatsal Reddy, I've opened the following issue for this problem: 8202329: [AIX] Fix codepage mappings for IBM-943 and Big5 https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8202329&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=iQCg2Acve4LeG-Zymt7gpXuSgJLFbCFHsSVHCETqGt8&s=3KL9rSzXZgjLGz-ayIEaq94QK5rTY0PlEgewOjarNPE&e= Looking at you fix, can you please replace the "#elif AIX" by "#ifdef AIX" and the original "#else" by "#ifdef __solaris__". The original else branch contains Solaris-only code anyway and it is an historical omission that there are still a lot of places in the code where "not Linux" implicitly means "Solaris", but that's often wrong. Regards, Volker On Thu, Apr 26, 2018 at 4:02 PM, Bhaktavatsal R Maram wrote: > Oops! Looks like there is problem with attachment (might be because I attached .class file as well). I'm pasting the fix and test program here in mail. > > Test Program: > > import java.nio.charset.*; > class PrintDefaultCharset { > public static void main(String[] args) { > System.out.println("LANG = "+System.getenv("LANG")); > System.out.println("Default charset = "+Charset.defaultCharset().name()); > System.out.println("file.encoding = "+System.getProperty("file.encoding")); > System.out.println("sun.jnu.encoding = "+System.getProperty("sun.jnu.encoding")); > } > } > > > Fix: > > diff --git a/src/java.base/unix/native/libjava/java_props_md.c b/src/java.base/unix/native/libjava/java_props_md.c > --- a/src/java.base/unix/native/libjava/java_props_md.c > +++ b/src/java.base/unix/native/libjava/java_props_md.c > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1998, 2016, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1998, 2018, 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 > @@ -297,6 +297,18 @@ > if (strcmp(p, "EUC-JP") == 0) { > *std_encoding = "EUC-JP-LINUX"; > } > +#elif defined _AIX > + if (strcmp(p, "big5") == 0) { > + /* On AIX Traditional Chinese Big5 codeset is mapped to IBM-950 */ > + *std_encoding = "IBM-950"; > + } else if (strcmp(p, "IBM-943") == 0) { > + /* > + * On AIX, IBM-943 is mapped to IBM-943C in which symbol 'yen' and > + * 'overline' are replaced with 'backslash' and 'tilde' from ASCII > + * making first 96 code points same as ASCII. > + */ > + *std_encoding = "IBM-943C"; > + } > #else > if (strcmp(p,"eucJP") == 0) { > /* For Solaris use customized vendor defined character > > > Thanks, > Bhaktavatsal Reddy > > > -----"core-libs-dev" wrote: ----- > To: "Java Core Libs" > From: "Bhaktavatsal R Maram" > Sent by: "core-libs-dev" > Date: 04/26/2018 07:26PM > Subject: [AIX] Fix codepage mappings in Java for IBM-943 and Big5 > > Hi All, > > This issue is continuation to bug 8201540 (Extend the set of supported charsets in java.base on AIX) in which we have moved default charsets of most of the locales supported by Operating System to java.base module thus enabling OpenJDK on those locales for AIX platform. > > As part of that, charsets for locales Ja_JP (IBM-943) and Zh_TW (big5) also have been moved. However, corresponding charsets mapped in Java is not correct for them on AIX. Following are the details: > > 1. IBM-943 [1] for locale Ja_JP should be mapped to IBM-943C [2] > > Fundamental difference between IBM-943 and IBM-943C is that IBM-943C is ASCII compatible which means code points 'yen' and 'overline' of IBM-943 is replaced with 'backslash' and 'tilde' from ASCII character set. > > > 2. Big5 for locale Zh_TW should be mapped to IBM-950 [3] > > I've attached simple test program to print the default charset along with fix for this issue. When run test program (PrintDefaultCharset) with IBM JDK 8 (on AIX) for locales Ja_JP & Zh_TW, following is output. > > -bash-4.4$ LANG=Ja_JP ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset > LANG = Ja_JP > Default charset = x-IBM943C > file.encoding = IBM-943C > sun.jnu.encoding = IBM-943C > > -bash-4.4$ LANG=Zh_TW ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset > LANG = Zh_TW > Default charset = x-IBM950 > file.encoding = IBM-950 > sun.jnu.encoding = IBM-950 > > > Same test run with openJDK 11 gives following output > > -bash-4.4$ LANG=Ja_JP ~/jdk/bin/java PrintDefaultCharset > LANG = Ja_JP > Default charset = x-IBM943 > file.encoding = IBM-943 > sun.jnu.encoding = IBM-943 > > -bash-4.4$ LANG=Zh_TW ~/jdk/bin/java PrintDefaultCharset > LANG = Zh_TW > Default charset = Big5 > file.encoding = big5 > sun.jnu.encoding = big5 > > I will get webrev hosted in https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=Prdd2GWj8c4aCa1qPr65xklNyDyu64w_6X7qkNaI-D8&s=8C1bILMg6JLJtbL0KLRPfU0MkIPkAmq_IlJgdTfpjdI&e= for this change and send it for review once JIRA bug is created. > > [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__demo.icu-2Dproject.org_icu-2Dbin_convexp-3Fconv-3Dibm-2D943-5FP130-2D1999-26s-3DJAVA&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=Prdd2GWj8c4aCa1qPr65xklNyDyu64w_6X7qkNaI-D8&s=RJOiyJTR1jkgxxnRZu5JL97irAnHo1M4wMp7x21dgvs&e= > [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__demo.icu-2Dproject.org_icu-2Dbin_convexp-3Fconv-3Dibm-2D943-5FP15A-2D2003-26s-3DALL&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=Prdd2GWj8c4aCa1qPr65xklNyDyu64w_6X7qkNaI-D8&s=gXshfq2f9yed1iEYTdt57Lk0vvHXztqgUzOLQ64h8Vo&e= > [3] https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.nlsgdrf/big5.htm > > > Thanks, > Bhaktavatsal Reddy > > > > From Alan.Bateman at oracle.com Thu Apr 26 16:02:28 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 26 Apr 2018 17:02:28 +0100 Subject: RFR: 8202330: Add Unreferenced{FOS,FIS,RAF}ClosesFd to problem list In-Reply-To: <82E0FF51-3540-46FD-9980-B40EBC9F98BC@oracle.com> References: <82E0FF51-3540-46FD-9980-B40EBC9F98BC@oracle.com> Message-ID: On 26/04/2018 16:41, Mikael Vidstedt wrote: > The java/io/*/Unreferenced{FOS,FIS,RAF}ClosesFd tests are failing quite frequently and should be added to the problem list until the issue (tracked by https://bugs.openjdk.java.net/browse/JDK-8202292 ) has been resolved: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202330 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8202330/webrev.00/open/webrev/ > This looks okay to me. -Alan From erik.joelsson at oracle.com Thu Apr 26 16:11:28 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 26 Apr 2018 09:11:28 -0700 Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 In-Reply-To: <8361024dba4f44309292e73ec9ad7b83@sap.com> References: <8361024dba4f44309292e73ec9ad7b83@sap.com> Message-ID: <9637d378-1e49-df96-ccc7-b01efcbc9929@oracle.com> Looks ok. /Erik On 2018-04-26 07:13, Baesken, Matthias wrote: > Hello , could you please review this small adjustment to the symbol visibility compilation settings on AIX ? > Currently we use XLC 12.1 to compile JDK on AIX . > > However XLC 12.1 does not support the "-qvisibility=hidden" setting currently set on AIX. > It was introduced with XLC 13.1 . Christoph found some info about it here : > > https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html > > Setting it only generates hundreds of warnings in the build log , warnings look like this : > XlC12.1 > > bash-4.4$ xlC -qversion > IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) > Version: 12.01.0000.0019 > > bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of valid options. > > Compare to XLC13.1 > > bash-3.00$ xlC -qversion > IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) > Version: 13.01.0000.0008 > bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc > bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > > > So it is better to avoid setting these flags when using xlc12.1 . > Please review : > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8202322 > > Change : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/ > > > Best regards, Matthias > > From xueming.shen at oracle.com Thu Apr 26 18:09:34 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 26 Apr 2018 11:09:34 -0700 Subject: RFR: JDK-8202105: jshell tool: on exiting, terminal echo is disabled In-Reply-To: <5AE1A887.9000402@oracle.com> References: <5AE06B6E.2060902@oracle.com> <5AE0A44C.80408@oracle.com> <5AE0AE0B.6070204@oracle.com> <5AE0E773.8020108@oracle.com> <5AE0EC20.8010409@oracle.com> <5AE1A887.9000402@oracle.com> Message-ID: <5AE215DE.6010608@oracle.com> On 4/26/18, 3:23 AM, Jan Lahoda wrote: > On 25.4.2018 22:59, Xueming Shen wrote: >> On 04/25/2018 01:39 PM, Jan Lahoda wrote: >>> So, if I understand correctly, it would be: >>> boolean flipEcho; >>> and the readPassword would do something like: >>> if (echo0() != false) { >> >> if (echo0()) { ... >> >>> flipEcho = true; >>> echo(false); >>> } >>> .... >>> if (flipEcho) { //this would also be in the shutdown hook >>> echo(!echo0()); >>> } >> >> if (flipEcho) { >> echo(true); >> flipEcho = false; >> } >> ? > > Hmm, right. It start to look a lot like the original code, with the > exception that the flag is also checked inside readPassword: > http://cr.openjdk.java.net/~jlahoda/8202105/webrev.01/ > > (This also makes the shutdown hook registration lazy.) > > Jan shouldn't we move the installShutonwHookIfNeeded() into synced block? and simply name it "installShutdownHook()" ? the rest looks fine. -sherman From andrey.x.nazarov at oracle.com Thu Apr 26 18:51:50 2018 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Thu, 26 Apr 2018 11:51:50 -0700 Subject: RFR 8197388: Added not existing bug id in jdk/ProblemList.txt Message-ID: <1AD251EC-4B2B-4F14-8F97-004CFD2B0A87@oracle.com> Hi, Please review patch that fixes typo in bug id. diff -r 3661f31c6df4 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt Thu Apr 26 11:19:05 2018 -0500 +++ b/test/jdk/ProblemList.txt Thu Apr 26 11:47:18 2018 -0700 @@ -243,7 +243,7 @@ sun/java2d/SunGraphics2D/EmptyClipRenderingTest.java 8144029 macosx-all sun/java2d/SunGraphics2D/DrawImageBilinear.java 8191506 generic-all sun/java2d/SunGraphics2D/PolyVertTest.java 6986565 generic-all -sun/java2d/SunGraphics2D/SimplePrimQuality.java 7992007 generic-all +sun/java2d/SunGraphics2D/SimplePrimQuality.java 6992007 generic-all sun/java2d/SunGraphics2D/SourceClippingBlitTest/SourceClippingBlitTest.java 8196191 windows-all,macosx-all sun/java2d/pipe/InterpolationQualityTest.java 8171303 windows-all,linux-all,macosx-all java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java 8169469 windows-all Issue: https://bugs.openjdk.java.net/browse/JDK-8197388 ?Thanks, Andrei From xueming.shen at oracle.com Thu Apr 26 19:22:18 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 26 Apr 2018 12:22:18 -0700 Subject: [11] RFR: 8181157: CLDR Timezone name fallback implementation In-Reply-To: <7ae5d607-4471-8797-d4a0-385f2e3d0704@oracle.com> References: <5ADE3CDA.600@oracle.com> <7ae5d607-4471-8797-d4a0-385f2e3d0704@oracle.com> Message-ID: <5AE226EA.7050707@oracle.com> +1 On 4/23/18, 6:25 PM, Naoto Sato wrote: > Hi Sherman, thanks for the review. > > On 4/23/18 1:06 PM, Xueming Shen wrote: >> Naoto, >> >> Here some comments >> >> (1) CLDRTimeZoneNameProviderImpl.java: >> Ln#58: to use Stream.toArray(String[]::new) ? no sure which >> one is faster >> >> Ln#155-160: >> is it worth considering to check all possible empty slots >> in "names" here >> (from index_std_long to index_std_short?) to avoid >> check/load "compact" multiple >> times? it appears doable for deriveFallbackNames() but I'm >> not sure about >> the invocation at #ln100, so a "?". >> >> (2) CLDRConverter.java: >> Ln#674: (not in updated code) why update the "local" jreMetaMap? >> just wonder it'd better to use >> Optional.ifPresentOrElse(...) here >> >> Ln:707: (don't know which one is better though :-)) >> .toMap(Map.Entry::getKey, Map.Entry::getValue); > > Addressed all of the above suggestions. Unnecessary jreMetaMap update > was a good catch! > >> >> (3) LocaleResources.java >> just wanted to confirm the "locale.resources.debug" is >> something we wanted to >> be a public interface or not? > > Eventually I'd be public (8057075), but it is a private use for the > time being. > > Here's the updated webrev: > > http://cr.openjdk.java.net/~naoto/8181157/webrev.06/ > > Naoto > >> >> Thanks, >> Sherman >> >> >> On 04/17/2018 02:28 PM, Naoto Sato wrote: >>> Hello, >>> >>> Please review the changes to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8181157 >>> >>> The proposed fix is located at: >>> >>> http://cr.openjdk.java.net/~naoto/8181157/webrev.05/ >>> >>> This RFE is to implement CLDR time zone names fallback mechanism >>> [1]. Prior to this fix, time zone names are substituted with English >>> names. With this change, it is generated according to the logic >>> defined in TR 35. Here are the highlight of the changes: >>> >>> CLDRConverter: >>> - CLDRConverter has changed to not substitute/invent time zone display >>> names, except English bundle for compatibility & runtime performance. >>> - For English bundle, copy over COMPAT's names as before. >>> - CLDRConverer now parses regionFormat/gmtZeroFormat/exemplarCity >>> >>> CLDR provider: >>> - CLDRTimeZoneNameProviderImpl is introduced to generate fallback names >>> at runtime. >>> - If COMPAT provider is present, use it also as a fallback, before the >>> last resort (GMT offset format) >>> >>> Naoto >>> >>> [1] http://www.unicode.org/reports/tr35/tr35-dates.html#Time_Zone_Names >> From paul.sandoz at oracle.com Thu Apr 26 19:35:24 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 26 Apr 2018 12:35:24 -0700 Subject: Review Request JDK-8201793: (ref) Reference object should not support cloning In-Reply-To: <6a3759c9-0e6f-b3e6-5ef5-2b032c8d7773@oracle.com> References: <6a3759c9-0e6f-b3e6-5ef5-2b032c8d7773@oracle.com> Message-ID: <8A1D8366-0DC5-4542-9098-D9E0C21C8012@oracle.com> Hi Mandy, This looks reasonable. I suspect external subtypes of the j.l.ref types are extremely rare (grep code reports no derived types) and of those it would likely be even rarer for those subtypes to implement Cloneable, and for that functionality to operate reliably. Paul. > On Apr 26, 2018, at 7:16 AM, mandy chung wrote: > > The semantics of cloning a Reference object is not clearly defined. In addition, it is questionable whether it can be meaningfully supported in particular with concurrent reference processing. > > The reachability state of a Reference object may change during GC reference processing. The referent may have been cleared when it reaches its reachability state. In addition, it may be enqueued or pending for enqueuing. Cloning a Reference object with a referent that is unreachable but not yet cleared might mean to resurrect the referent. A cloned enqueued Reference object will never be enqueued. A Reference object cannot be meaningfully cloned. > > We propose Reference::clone to throw CloneNotSupportedException. To clone a Reference object, it should create a new instance via its constructor. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8202260 > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8201793/webrev.00/ > > Mandy From james.laskey at oracle.com Thu Apr 26 19:38:01 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 26 Apr 2018 16:38:01 -0300 Subject: Please review CSR: JDK-8200435 String::stripIndent, String::stripMarkers Message-ID: Please review and mark as reviewed https://bugs.openjdk.java.net/browse/JDK-8200435 From jan.lahoda at oracle.com Thu Apr 26 20:34:11 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 26 Apr 2018 22:34:11 +0200 Subject: RFR: JDK-8202105: jshell tool: on exiting, terminal echo is disabled In-Reply-To: <5AE215DE.6010608@oracle.com> References: <5AE06B6E.2060902@oracle.com> <5AE0A44C.80408@oracle.com> <5AE0AE0B.6070204@oracle.com> <5AE0E773.8020108@oracle.com> <5AE0EC20.8010409@oracle.com> <5AE1A887.9000402@oracle.com> <5AE215DE.6010608@oracle.com> Message-ID: <5AE237C3.7010307@oracle.com> On 26.4.2018 20:09, Xueming Shen wrote: > On 4/26/18, 3:23 AM, Jan Lahoda wrote: >> On 25.4.2018 22:59, Xueming Shen wrote: >>> On 04/25/2018 01:39 PM, Jan Lahoda wrote: >>>> So, if I understand correctly, it would be: >>>> boolean flipEcho; >>>> and the readPassword would do something like: >>>> if (echo0() != false) { >>> >>> if (echo0()) { ... >>> >>>> flipEcho = true; >>>> echo(false); >>>> } >>>> .... >>>> if (flipEcho) { //this would also be in the shutdown hook >>>> echo(!echo0()); >>>> } >>> >>> if (flipEcho) { >>> echo(true); >>> flipEcho = false; >>> } >>> ? >> >> Hmm, right. It start to look a lot like the original code, with the >> exception that the flag is also checked inside readPassword: >> http://cr.openjdk.java.net/~jlahoda/8202105/webrev.01/ >> >> (This also makes the shutdown hook registration lazy.) >> >> Jan > shouldn't we move the installShutonwHookIfNeeded() into synced block? and > simply name it "installShutdownHook()" ? Ok, here is an updated webrev: http://cr.openjdk.java.net/~jlahoda/8202105/webrev.02/ Jan > > the rest looks fine. > > -sherman From vladimir.x.ivanov at oracle.com Thu Apr 26 21:07:56 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 26 Apr 2018 14:07:56 -0700 Subject: (M) RFR: 8200167: Validate more special case invocations In-Reply-To: References: <27391c2a-fd5c-8133-8e31-b8b45db157ce@oracle.com> Message-ID: <2907289a-2915-118c-f3c0-1327798f6f80@oracle.com> David, thanks for taking care of the bug! src/hotspot/share/c1/c1_Canonicalizer.cpp ... void Canonicalizer::do_CheckCast (CheckCast* x) { - if (x->klass()->is_loaded()) { + if (x->klass()->is_loaded() && !x->is_invokespecial_receiver_check()) It seems like it's not something specific to invokespecial, but a generic problem in how interface casts are handled in C1: it's not correct to eliminate the cast if obj->declared_type() is an interface. I assume that's what happens in your case. FTR I'm fine with handling it separately. test/jdk/java/lang/invoke/I4Special.jcod: I'm curious why did you choose jcod here and not jasm? It seems jasm should be a better fit to replace invokevirtual with invokespecial (unless I'm missing something important in the test case). Otherwise, looks good. Best regards, Vladimir Ivanov On 4/25/18 21:12, David Holmes wrote: > Revised webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev.v2/ > > Karen formulated an additional test scenario invoking Object methods > through an interface reference, which when turned into a new testcase > demonstrated that the receiver typecheck was also missing in that case > for Methodhandle's from findSpecial. > > Again Vladimir Ivanov formulated the fix for this. Thanks Vladimir! > > Summary of changes from original webrev: > > - We introduce a new version of DirectMethodHandle.preparedlambdaForm > that takes the caller class as a parameter, and that class is checked > for being an interface (not the method's declaring class) to trigger the > switch to LF_SPECIAL_IFC. (This obviously addresses one problem with > invoking Object methods - as Object is not an interface - but by itself > did not fix the problem.) > > - We introduce a new LambdaForm kind, DIRECT_INVOKE_SPECIAL_IFC, which > we use when dealing with LF_INVSPECIAL_IFC. (This was the key in > ensuring the receiver typecheck via Special.checkReceiver remained in > the generated code.) > > - In the test we: > ? - introduce a new invokeDirect testcase for Object.toString(), but we > need to do that via a modified jcod file (as javac generates an > invokevirtual) > ? - introduce the new invokeSpecialObjectMH(I2 i) call for the MH case. > > Thanks, > David > > On 17/04/2018 6:48 PM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8200167 >> webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev/ >> >> Credit to John Rose and Vladimir Ivanov for the form of the MH fix; >> and to Tobias Hartmann for the C1 fix. Their help was very much >> appreciated (and needed!). >> >> tl;dr version: there are some places where badly formed interface >> method calls (which are not detected by the verifier) were missing >> runtime checks on the type of the receiver. Similar issues have been >> fixed in the past and this was a remaining hole in relation to >> invokespecial semantics and interface calls via MethodHandles. It also >> turned out there was an issue in C1 that affected direct invokespecial >> calls. >> >> Description of changes: >> >> - src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java >> >> Added a new form LF_INVSPECIAL_IFC for invokespecial of interface >> methods. >> >> - src/java.base/share/classes/java/lang/invoke/MethodHandles.java >> >> Renamed callerClass parameter to boundCallerClass, where it originates >> from findBoundCallerClass. The name "callerClass" is misleading >> because most of the time it is NULL! >> >> In getDirectMethodCommon, pass the actual caller class (lookupClass) >> to DirectMethodHandle.make. And correct the comment about >> restrictReceiver. >> >> - src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java >> >> DirectMethodHandle.make now takes a callerClass parameter (which may >> be null). >> >> DirectMethodHandle make "receiver" parameter is renamed "refc" as it >> is not the receiver (it's the resolved type of the method holder ie >> REFC). >> >> The Special subclass now takes a "checkClass" parameter which is >> either refc, or callerClass. This is what we will check the receiver >> against. >> >> In preparedLambdaForm we switch from LF_INVSPECIAL to >> LF_INVSPECIAL_IFC if the target method is in an interface. >> >> In makePreparedLambdaForm we augment the needsReceiverCheck test to >> include LF_INVSPECIAL_IFC. (So we will not be doing a new receiver >> type check on all invokespecials, just those involving interface >> methods.) >> >> Added DMH.checkReceiver which is overridden by both the Special and >> Interface subclasses. >> >> - src/hotspot/share/c1/c1_Canonicalizer.cpp >> >> Don't optimize away the checkcast when it is an invokespecial receiver >> check. >> >> - test/jdk/java/lang/invoke/SpecialInterfaceCall.java >> >> (I've moved this test back and forth between hotspot/runtime and >> j.l.invoke as it spans direct calls and MH calls. But I think on >> balance it lands better here.) >> >> The test sets up direct interface method calls for which invokespecial >> is generated by javac, and similarly it creates MethodHandles with >> invokespecial semantics. The should-not-throw cases are trivial. The >> should-throw cases involve MH wizardry. >> >> The test is broken into three parts to check the behaviour on first >> use (when the method has to be initially resolved); on second use (to >> test we don't use the cpcache in a way that is invalid); and again >> after forcing JIT compilation of the calls. >> >> The test is run 5 times to exercise the interpreter (yes the multiple >> runs internal to the test are redundant in this case, but it's much >> simpler to just run it all than try to work out what needs to be run); >> the three variants of using C1, plus a C2 only run. >> >> --- >> >> Testing: >> ?? - the new test of course >> ?? - hotspot/runtime/* >> ?? - hotspot/compiler/jsr292 >> ?? - jdk/java/lang/invoke >> >> ?? - hs tiers 1 and 2 >> ?? - jdk tiers 1, 2 and 3 >> >> Plus some related closed tests. >> >> Thanks, >> David >> ----- From karen.kinnear at oracle.com Thu Apr 26 21:21:50 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 26 Apr 2018 17:21:50 -0400 Subject: (M) RFR: 8200167: Validate more special case invocations In-Reply-To: References: <27391c2a-fd5c-8133-8e31-b8b45db157ce@oracle.com> Message-ID: <5378B538-F114-4199-9C1F-34F0A9E8F0B0@oracle.com> Looks good! Thank you so much David and Vladimir for all the work to cover the corner cases. thanks, Karen > On Apr 26, 2018, at 12:12 AM, David Holmes wrote: > > Revised webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev.v2/ > > Karen formulated an additional test scenario invoking Object methods through an interface reference, which when turned into a new testcase demonstrated that the receiver typecheck was also missing in that case for Methodhandle's from findSpecial. > > Again Vladimir Ivanov formulated the fix for this. Thanks Vladimir! > > Summary of changes from original webrev: > > - We introduce a new version of DirectMethodHandle.preparedlambdaForm that takes the caller class as a parameter, and that class is checked for being an interface (not the method's declaring class) to trigger the switch to LF_SPECIAL_IFC. (This obviously addresses one problem with invoking Object methods - as Object is not an interface - but by itself did not fix the problem.) > > - We introduce a new LambdaForm kind, DIRECT_INVOKE_SPECIAL_IFC, which we use when dealing with LF_INVSPECIAL_IFC. (This was the key in ensuring the receiver typecheck via Special.checkReceiver remained in the generated code.) > > - In the test we: > - introduce a new invokeDirect testcase for Object.toString(), but we need to do that via a modified jcod file (as javac generates an invokevirtual) > - introduce the new invokeSpecialObjectMH(I2 i) call for the MH case. > > Thanks, > David > > On 17/04/2018 6:48 PM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8200167 >> webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev/ >> Credit to John Rose and Vladimir Ivanov for the form of the MH fix; and to Tobias Hartmann for the C1 fix. Their help was very much appreciated (and needed!). >> tl;dr version: there are some places where badly formed interface method calls (which are not detected by the verifier) were missing runtime checks on the type of the receiver. Similar issues have been fixed in the past and this was a remaining hole in relation to invokespecial semantics and interface calls via MethodHandles. It also turned out there was an issue in C1 that affected direct invokespecial calls. >> Description of changes: >> - src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java >> Added a new form LF_INVSPECIAL_IFC for invokespecial of interface methods. >> - src/java.base/share/classes/java/lang/invoke/MethodHandles.java >> Renamed callerClass parameter to boundCallerClass, where it originates from findBoundCallerClass. The name "callerClass" is misleading because most of the time it is NULL! >> In getDirectMethodCommon, pass the actual caller class (lookupClass) to DirectMethodHandle.make. And correct the comment about restrictReceiver. >> - src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java >> DirectMethodHandle.make now takes a callerClass parameter (which may be null). >> DirectMethodHandle make "receiver" parameter is renamed "refc" as it is not the receiver (it's the resolved type of the method holder ie REFC). >> The Special subclass now takes a "checkClass" parameter which is either refc, or callerClass. This is what we will check the receiver against. >> In preparedLambdaForm we switch from LF_INVSPECIAL to LF_INVSPECIAL_IFC if the target method is in an interface. >> In makePreparedLambdaForm we augment the needsReceiverCheck test to include LF_INVSPECIAL_IFC. (So we will not be doing a new receiver type check on all invokespecials, just those involving interface methods.) >> Added DMH.checkReceiver which is overridden by both the Special and Interface subclasses. >> - src/hotspot/share/c1/c1_Canonicalizer.cpp >> Don't optimize away the checkcast when it is an invokespecial receiver check. >> - test/jdk/java/lang/invoke/SpecialInterfaceCall.java >> (I've moved this test back and forth between hotspot/runtime and j.l.invoke as it spans direct calls and MH calls. But I think on balance it lands better here.) >> The test sets up direct interface method calls for which invokespecial is generated by javac, and similarly it creates MethodHandles with invokespecial semantics. The should-not-throw cases are trivial. The should-throw cases involve MH wizardry. >> The test is broken into three parts to check the behaviour on first use (when the method has to be initially resolved); on second use (to test we don't use the cpcache in a way that is invalid); and again after forcing JIT compilation of the calls. >> The test is run 5 times to exercise the interpreter (yes the multiple runs internal to the test are redundant in this case, but it's much simpler to just run it all than try to work out what needs to be run); the three variants of using C1, plus a C2 only run. >> --- >> Testing: >> - the new test of course >> - hotspot/runtime/* >> - hotspot/compiler/jsr292 >> - jdk/java/lang/invoke >> - hs tiers 1 and 2 >> - jdk tiers 1, 2 and 3 >> Plus some related closed tests. >> Thanks, >> David >> ----- From david.holmes at oracle.com Thu Apr 26 22:04:17 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Apr 2018 08:04:17 +1000 Subject: (M) RFR: 8200167: Validate more special case invocations In-Reply-To: <2907289a-2915-118c-f3c0-1327798f6f80@oracle.com> References: <27391c2a-fd5c-8133-8e31-b8b45db157ce@oracle.com> <2907289a-2915-118c-f3c0-1327798f6f80@oracle.com> Message-ID: <4e8bbf0c-0e04-a74f-74a3-4b60ba47e48e@oracle.com> Hi Vladimir, On 27/04/2018 7:07 AM, Vladimir Ivanov wrote: > David, thanks for taking care of the bug! Thanks for all the help! > src/hotspot/share/c1/c1_Canonicalizer.cpp > ... > ?void Canonicalizer::do_CheckCast????? (CheckCast*?????? x) { > -? if (x->klass()->is_loaded()) { > +? if (x->klass()->is_loaded() && !x->is_invokespecial_receiver_check()) > > It seems like it's not something specific to invokespecial, but a > generic problem in how interface casts are handled in C1: it's not > correct to eliminate the cast if obj->declared_type() is an interface. I > assume that's what happens in your case. FTR I'm fine with handling it > separately. The above came from Tobias. If you think there is a more general issue here then we should file a separate bug and formulate a test case. > test/jdk/java/lang/invoke/I4Special.jcod: > > I'm curious why did you choose jcod here and not jasm? It seems jasm > should be a better fit to replace invokevirtual with invokespecial > (unless I'm missing something important in the test case). Simply because jcod is what I have been working with in nestmates for classfile customizations and I don't know jasm. > Otherwise, looks good. Thanks again! David > > Best regards, > Vladimir Ivanov > > On 4/25/18 21:12, David Holmes wrote: >> Revised webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev.v2/ >> >> Karen formulated an additional test scenario invoking Object methods >> through an interface reference, which when turned into a new testcase >> demonstrated that the receiver typecheck was also missing in that case >> for Methodhandle's from findSpecial. >> >> Again Vladimir Ivanov formulated the fix for this. Thanks Vladimir! >> >> Summary of changes from original webrev: >> >> - We introduce a new version of DirectMethodHandle.preparedlambdaForm >> that takes the caller class as a parameter, and that class is checked >> for being an interface (not the method's declaring class) to trigger >> the switch to LF_SPECIAL_IFC. (This obviously addresses one problem >> with invoking Object methods - as Object is not an interface - but by >> itself did not fix the problem.) >> >> - We introduce a new LambdaForm kind, DIRECT_INVOKE_SPECIAL_IFC, which >> we use when dealing with LF_INVSPECIAL_IFC. (This was the key in >> ensuring the receiver typecheck via Special.checkReceiver remained in >> the generated code.) >> >> - In the test we: >> ?? - introduce a new invokeDirect testcase for Object.toString(), but >> we need to do that via a modified jcod file (as javac generates an >> invokevirtual) >> ?? - introduce the new invokeSpecialObjectMH(I2 i) call for the MH case. >> >> Thanks, >> David >> >> On 17/04/2018 6:48 PM, David Holmes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200167 >>> webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev/ >>> >>> Credit to John Rose and Vladimir Ivanov for the form of the MH fix; >>> and to Tobias Hartmann for the C1 fix. Their help was very much >>> appreciated (and needed!). >>> >>> tl;dr version: there are some places where badly formed interface >>> method calls (which are not detected by the verifier) were missing >>> runtime checks on the type of the receiver. Similar issues have been >>> fixed in the past and this was a remaining hole in relation to >>> invokespecial semantics and interface calls via MethodHandles. It >>> also turned out there was an issue in C1 that affected direct >>> invokespecial calls. >>> >>> Description of changes: >>> >>> - src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java >>> >>> Added a new form LF_INVSPECIAL_IFC for invokespecial of interface >>> methods. >>> >>> - src/java.base/share/classes/java/lang/invoke/MethodHandles.java >>> >>> Renamed callerClass parameter to boundCallerClass, where it >>> originates from findBoundCallerClass. The name "callerClass" is >>> misleading because most of the time it is NULL! >>> >>> In getDirectMethodCommon, pass the actual caller class (lookupClass) >>> to DirectMethodHandle.make. And correct the comment about >>> restrictReceiver. >>> >>> - src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java >>> >>> DirectMethodHandle.make now takes a callerClass parameter (which may >>> be null). >>> >>> DirectMethodHandle make "receiver" parameter is renamed "refc" as it >>> is not the receiver (it's the resolved type of the method holder ie >>> REFC). >>> >>> The Special subclass now takes a "checkClass" parameter which is >>> either refc, or callerClass. This is what we will check the receiver >>> against. >>> >>> In preparedLambdaForm we switch from LF_INVSPECIAL to >>> LF_INVSPECIAL_IFC if the target method is in an interface. >>> >>> In makePreparedLambdaForm we augment the needsReceiverCheck test to >>> include LF_INVSPECIAL_IFC. (So we will not be doing a new receiver >>> type check on all invokespecials, just those involving interface >>> methods.) >>> >>> Added DMH.checkReceiver which is overridden by both the Special and >>> Interface subclasses. >>> >>> - src/hotspot/share/c1/c1_Canonicalizer.cpp >>> >>> Don't optimize away the checkcast when it is an invokespecial >>> receiver check. >>> >>> - test/jdk/java/lang/invoke/SpecialInterfaceCall.java >>> >>> (I've moved this test back and forth between hotspot/runtime and >>> j.l.invoke as it spans direct calls and MH calls. But I think on >>> balance it lands better here.) >>> >>> The test sets up direct interface method calls for which >>> invokespecial is generated by javac, and similarly it creates >>> MethodHandles with invokespecial semantics. The should-not-throw >>> cases are trivial. The should-throw cases involve MH wizardry. >>> >>> The test is broken into three parts to check the behaviour on first >>> use (when the method has to be initially resolved); on second use (to >>> test we don't use the cpcache in a way that is invalid); and again >>> after forcing JIT compilation of the calls. >>> >>> The test is run 5 times to exercise the interpreter (yes the multiple >>> runs internal to the test are redundant in this case, but it's much >>> simpler to just run it all than try to work out what needs to be >>> run); the three variants of using C1, plus a C2 only run. >>> >>> --- >>> >>> Testing: >>> ?? - the new test of course >>> ?? - hotspot/runtime/* >>> ?? - hotspot/compiler/jsr292 >>> ?? - jdk/java/lang/invoke >>> >>> ?? - hs tiers 1 and 2 >>> ?? - jdk tiers 1, 2 and 3 >>> >>> Plus some related closed tests. >>> >>> Thanks, >>> David >>> ----- From david.holmes at oracle.com Thu Apr 26 22:05:16 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Apr 2018 08:05:16 +1000 Subject: (M) RFR: 8200167: Validate more special case invocations In-Reply-To: <5378B538-F114-4199-9C1F-34F0A9E8F0B0@oracle.com> References: <27391c2a-fd5c-8133-8e31-b8b45db157ce@oracle.com> <5378B538-F114-4199-9C1F-34F0A9E8F0B0@oracle.com> Message-ID: <0c33b0ae-60ed-2132-ebd4-a628ea837975@oracle.com> Thanks Karen! Once my re-testing has completed I'll look at pushing this. David On 27/04/2018 7:21 AM, Karen Kinnear wrote: > Looks good! > > Thank you so much David and Vladimir for all the work to cover the corner cases. > > thanks, > Karen > >> On Apr 26, 2018, at 12:12 AM, David Holmes wrote: >> >> Revised webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev.v2/ >> >> Karen formulated an additional test scenario invoking Object methods through an interface reference, which when turned into a new testcase demonstrated that the receiver typecheck was also missing in that case for Methodhandle's from findSpecial. >> >> Again Vladimir Ivanov formulated the fix for this. Thanks Vladimir! >> >> Summary of changes from original webrev: >> >> - We introduce a new version of DirectMethodHandle.preparedlambdaForm that takes the caller class as a parameter, and that class is checked for being an interface (not the method's declaring class) to trigger the switch to LF_SPECIAL_IFC. (This obviously addresses one problem with invoking Object methods - as Object is not an interface - but by itself did not fix the problem.) >> >> - We introduce a new LambdaForm kind, DIRECT_INVOKE_SPECIAL_IFC, which we use when dealing with LF_INVSPECIAL_IFC. (This was the key in ensuring the receiver typecheck via Special.checkReceiver remained in the generated code.) >> >> - In the test we: >> - introduce a new invokeDirect testcase for Object.toString(), but we need to do that via a modified jcod file (as javac generates an invokevirtual) >> - introduce the new invokeSpecialObjectMH(I2 i) call for the MH case. >> >> Thanks, >> David >> >> On 17/04/2018 6:48 PM, David Holmes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200167 >>> webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev/ >>> Credit to John Rose and Vladimir Ivanov for the form of the MH fix; and to Tobias Hartmann for the C1 fix. Their help was very much appreciated (and needed!). >>> tl;dr version: there are some places where badly formed interface method calls (which are not detected by the verifier) were missing runtime checks on the type of the receiver. Similar issues have been fixed in the past and this was a remaining hole in relation to invokespecial semantics and interface calls via MethodHandles. It also turned out there was an issue in C1 that affected direct invokespecial calls. >>> Description of changes: >>> - src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java >>> Added a new form LF_INVSPECIAL_IFC for invokespecial of interface methods. >>> - src/java.base/share/classes/java/lang/invoke/MethodHandles.java >>> Renamed callerClass parameter to boundCallerClass, where it originates from findBoundCallerClass. The name "callerClass" is misleading because most of the time it is NULL! >>> In getDirectMethodCommon, pass the actual caller class (lookupClass) to DirectMethodHandle.make. And correct the comment about restrictReceiver. >>> - src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java >>> DirectMethodHandle.make now takes a callerClass parameter (which may be null). >>> DirectMethodHandle make "receiver" parameter is renamed "refc" as it is not the receiver (it's the resolved type of the method holder ie REFC). >>> The Special subclass now takes a "checkClass" parameter which is either refc, or callerClass. This is what we will check the receiver against. >>> In preparedLambdaForm we switch from LF_INVSPECIAL to LF_INVSPECIAL_IFC if the target method is in an interface. >>> In makePreparedLambdaForm we augment the needsReceiverCheck test to include LF_INVSPECIAL_IFC. (So we will not be doing a new receiver type check on all invokespecials, just those involving interface methods.) >>> Added DMH.checkReceiver which is overridden by both the Special and Interface subclasses. >>> - src/hotspot/share/c1/c1_Canonicalizer.cpp >>> Don't optimize away the checkcast when it is an invokespecial receiver check. >>> - test/jdk/java/lang/invoke/SpecialInterfaceCall.java >>> (I've moved this test back and forth between hotspot/runtime and j.l.invoke as it spans direct calls and MH calls. But I think on balance it lands better here.) >>> The test sets up direct interface method calls for which invokespecial is generated by javac, and similarly it creates MethodHandles with invokespecial semantics. The should-not-throw cases are trivial. The should-throw cases involve MH wizardry. >>> The test is broken into three parts to check the behaviour on first use (when the method has to be initially resolved); on second use (to test we don't use the cpcache in a way that is invalid); and again after forcing JIT compilation of the calls. >>> The test is run 5 times to exercise the interpreter (yes the multiple runs internal to the test are redundant in this case, but it's much simpler to just run it all than try to work out what needs to be run); the three variants of using C1, plus a C2 only run. >>> --- >>> Testing: >>> - the new test of course >>> - hotspot/runtime/* >>> - hotspot/compiler/jsr292 >>> - jdk/java/lang/invoke >>> - hs tiers 1 and 2 >>> - jdk tiers 1, 2 and 3 >>> Plus some related closed tests. >>> Thanks, >>> David >>> ----- > From xueming.shen at oracle.com Thu Apr 26 22:21:14 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 26 Apr 2018 15:21:14 -0700 Subject: RFR: JDK-8202105: jshell tool: on exiting, terminal echo is disabled In-Reply-To: <5AE237C3.7010307@oracle.com> References: <5AE06B6E.2060902@oracle.com> <5AE0A44C.80408@oracle.com> <5AE0AE0B.6070204@oracle.com> <5AE0E773.8020108@oracle.com> <5AE0EC20.8010409@oracle.com> <5AE1A887.9000402@oracle.com> <5AE215DE.6010608@oracle.com> <5AE237C3.7010307@oracle.com> Message-ID: <5AE250DA.3070703@oracle.com> +1 (nit: remove the "where:" and the corresponding indent before push please). On 4/26/18, 1:34 PM, Jan Lahoda wrote: > > > Ok, here is an updated webrev: > http://cr.openjdk.java.net/~jlahoda/8202105/webrev.02/ > > Jan > From huizhe.wang at oracle.com Fri Apr 27 04:50:11 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 26 Apr 2018 21:50:11 -0700 Subject: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file Message-ID: <5AE2AC03.9000705@oracle.com> Hi, We're looking into adding methods to Files to read a file into a String/write a String to a file. Below is the current proposal. Please review. JBS: https://bugs.openjdk.java.net/browse/JDK-8201276 webrev: http://cr.openjdk.java.net/~joehw/jdk11/8201276/webrev/ specdiff: http://cr.openjdk.java.net/~joehw/jdk11/8201276/specdiff/java/nio/file/Files.html Thanks, Joe From huizhe.wang at oracle.com Fri Apr 27 04:51:08 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 26 Apr 2018 21:51:08 -0700 Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents Message-ID: <5AE2AC3C.4040902@oracle.com> Hi, Considering extending isSameFile to add isSameContent to Files. Please review. JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/ specdiff: http://cr.openjdk.java.net/~joehw/jdk11/8202285/specdiff/java/nio/file/Files.html Thanks, Joe From thomas.stuefe at gmail.com Fri Apr 27 04:55:25 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 27 Apr 2018 06:55:25 +0200 Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 In-Reply-To: References: <8361024dba4f44309292e73ec9ad7b83@sap.com> <97c60ab29a6348769169b312f55832e7@sap.com> Message-ID: Hi, This was added by "8200178: Remove mapfiles for JDK native libraries". But if the flag is not accepted, what is the default behavior? Do we now export everything? I'd like to understand this first before removing the flag to get rid of the warnings. Best Regards, Thomas On Thu, Apr 26, 2018 at 5:16 PM, Volker Simonis wrote: > Hi Matthias, > > after Bhaktavatsal Reddy's report about the problems with > "-qvisibility" with xlC 13 and taking into account that we can't test > this anyway because we don't currently have xlC 13 > on our machines I think it would be best to completely remove this > option for now on AIX. Once we get xlC 13 we can revisit the issue. > > Thanks, > Volker > > > On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram > wrote: >> Hi Matthias, >> >> At this point, I think we can remove the flag as you found that it is not supported in XLC < 13. And with XLC 13, it require more work to use this flag. >> >> Thanks, >> Bhaktavatsal Reddy >> >> >> >> -----"Baesken, Matthias" wrote: ----- >> To: "Langer, Christoph" , "'build-dev at openjdk.java.net'" , "ppc-aix-port-dev at openjdk.java.net" , "core-libs-dev at openjdk.java.net" >> From: "Baesken, Matthias" >> Date: 04/26/2018 08:23PM >> Cc: "Simonis, Volker" , Bhaktavatsal R Maram >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 >> >> >> Hello Christoph, I think all XLC versions < 12.1 are unsupported (and probably not working anyway) for the OpenJDK build . >> I am only aware of XLC versions 12.1 and 13.1 which work / in case of 13.1 ?might? work for OpenJDK compilation . >> And for 12.1 I want to remove the flags . >> >> ( waiting for the feedback of Bhaktavatsal Reddy , in case he prefers it I remove them for all xlC versions including 13.1 ) >> >> Best regards, Matthias >> >> >> >> >> >> >> From: Langer, Christoph >> Sent: Donnerstag, 26. April 2018 16:38 >> To: Baesken, Matthias ; 'build-dev at openjdk.java.net' ; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >> Cc: Simonis, Volker >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 >> >> Hi Matthias, >> >> to me the change in principal looks good. >> >> I?m wondering if it is possible to do a comparison like xlc < 13 (e.g. extract major number before the first dot, then compare numerically) ? but maybe it is too complicated and the current single version compare suits our needs ? >> >> Best regards >> Christoph >> >> >> >> >> From: Baesken, Matthias >> Sent: Donnerstag, 26. April 2018 16:14 >> To: 'build-dev at openjdk.java.net' ; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >> Cc: Langer, Christoph ; Simonis, Volker >> Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 >> >> Hello , could you please review this small adjustment to the symbol visibility compilation settings on AIX ? >> Currently we use XLC 12.1 to compile JDK on AIX . >> >> However XLC 12.1 does not support the ?-qvisibility=hidden? setting currently set on AIX. >> It was introduced with XLC 13.1 . Christoph found some info about it here : >> >> https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html >> >> Setting it only generates hundreds of warnings in the build log , warnings look like this : >> XlC12.1 >> >> bash-4.4$ xlC -qversion >> IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) >> Version: 12.01.0000.0019 >> >> bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc >> 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of valid options. >> >> Compare to XLC13.1 >> >> bash-3.00$ xlC -qversion >> IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) >> Version: 13.01.0000.0008 >> bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc >> bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc >> >> >> So it is better to avoid setting these flags when using xlc12.1 . >> Please review : >> >> Bug : >> >> https://bugs.openjdk.java.net/browse/JDK-8202322 >> >> Change : >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/ >> >> >> Best regards, Matthias >> >> >> >> From mandy.chung at oracle.com Fri Apr 27 06:03:05 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 27 Apr 2018 14:03:05 +0800 Subject: Review Request JDK-8201793: (ref) Reference object should not support cloning In-Reply-To: <8A1D8366-0DC5-4542-9098-D9E0C21C8012@oracle.com> References: <6a3759c9-0e6f-b3e6-5ef5-2b032c8d7773@oracle.com> <8A1D8366-0DC5-4542-9098-D9E0C21C8012@oracle.com> Message-ID: <18e57635-2a95-cbd4-827a-f0a292c4e308@oracle.com> On 4/27/18 3:35 AM, Paul Sandoz wrote: > Hi Mandy, > > This looks reasonable. I suspect external subtypes of the j.l.ref types are extremely rare (grep code reports no derived types) and of those it would likely be even rarer for those subtypes to implement Cloneable, and for that functionality to operate reliably. Thanks for the review. Subtypes of java.lang.ref.SoftReference and WeakReference is not uncommon (JDK has plenty of such subtypes).? I guess grep code may show the result of a specific JDK release and reports no derived types.? I do think it's extremely rare for those subtypes to implement Cloneable.? So this change should have low compatibility risk. Mandy > Paul. > >> On Apr 26, 2018, at 7:16 AM, mandy chung wrote: >> >> The semantics of cloning a Reference object is not clearly defined. In addition, it is questionable whether it can be meaningfully supported in particular with concurrent reference processing. >> >> The reachability state of a Reference object may change during GC reference processing. The referent may have been cleared when it reaches its reachability state. In addition, it may be enqueued or pending for enqueuing. Cloning a Reference object with a referent that is unreachable but not yet cleared might mean to resurrect the referent. A cloned enqueued Reference object will never be enqueued. A Reference object cannot be meaningfully cloned. >> >> We propose Reference::clone to throw CloneNotSupportedException. To clone a Reference object, it should create a new instance via its constructor. >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8202260 >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8201793/webrev.00/ >> >> Mandy From christoph.langer at sap.com Fri Apr 27 06:07:26 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 27 Apr 2018 06:07:26 +0000 Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 In-Reply-To: References: <8361024dba4f44309292e73ec9ad7b83@sap.com> <97c60ab29a6348769169b312f55832e7@sap.com> Message-ID: Hi Thomas, Look at this blog: https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html if I understand it correctly, the xlc 12 default behavior should be like what we'd expect from -qvisibility=hidden. Best regards Christoph > -----Original Message----- > From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf Of > Thomas St?fe > Sent: Freitag, 27. April 2018 06:55 > To: Volker Simonis ; Baesken, Matthias > > Cc: Simonis, Volker ; ppc-aix-port- > dev at openjdk.java.net; core-libs-dev at openjdk.java.net; build- > dev at openjdk.java.net > Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 > > Hi, > > This was added by "8200178: Remove mapfiles for JDK native libraries". > But if the flag is not accepted, what is the default behavior? Do we > now export everything? > > I'd like to understand this first before removing the flag to get rid > of the warnings. > > Best Regards, Thomas > > On Thu, Apr 26, 2018 at 5:16 PM, Volker Simonis > wrote: > > Hi Matthias, > > > > after Bhaktavatsal Reddy's report about the problems with > > "-qvisibility" with xlC 13 and taking into account that we can't test > > this anyway because we don't currently have xlC 13 > > on our machines I think it would be best to completely remove this > > option for now on AIX. Once we get xlC 13 we can revisit the issue. > > > > Thanks, > > Volker > > > > > > On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram > > wrote: > >> Hi Matthias, > >> > >> At this point, I think we can remove the flag as you found that it is not > supported in XLC < 13. And with XLC 13, it require more work to use this flag. > >> > >> Thanks, > >> Bhaktavatsal Reddy > >> > >> > >> > >> -----"Baesken, Matthias" wrote: ----- > >> To: "Langer, Christoph" , "'build- > dev at openjdk.java.net'" , "ppc-aix-port- > dev at openjdk.java.net" , "core-libs- > dev at openjdk.java.net" > >> From: "Baesken, Matthias" > >> Date: 04/26/2018 08:23PM > >> Cc: "Simonis, Volker" , Bhaktavatsal R Maram > > >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc > 12.1 > >> > >> > >> Hello Christoph, I think all XLC versions < 12.1 are unsupported (and > probably not working anyway) for the OpenJDK build . > >> I am only aware of XLC versions 12.1 and 13.1 which work / in case of > 13.1 ?might? work for OpenJDK compilation . > >> And for 12.1 I want to remove the flags . > >> > >> ( waiting for the feedback of Bhaktavatsal Reddy , in case he prefers it > I remove them for all xlC versions including 13.1 ) > >> > >> Best regards, Matthias > >> > >> > >> > >> > >> > >> > >> From: Langer, Christoph > >> Sent: Donnerstag, 26. April 2018 16:38 > >> To: Baesken, Matthias ; 'build- > dev at openjdk.java.net' ; ppc-aix-port- > dev at openjdk.java.net; core-libs-dev at openjdk.java.net > >> Cc: Simonis, Volker > >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc > 12.1 > >> > >> Hi Matthias, > >> > >> to me the change in principal looks good. > >> > >> I?m wondering if it is possible to do a comparison like xlc < 13 (e.g. extract > major number before the first dot, then compare numerically) ? but maybe it > is too complicated and the current single version compare suits our needs ? > >> > >> Best regards > >> Christoph > >> > >> > >> > >> > >> From: Baesken, Matthias > >> Sent: Donnerstag, 26. April 2018 16:14 > >> To: 'build-dev at openjdk.java.net' ; ppc- > aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > >> Cc: Langer, Christoph ; Simonis, Volker > > >> Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 > >> > >> Hello , could you please review this small adjustment to the symbol > visibility compilation settings on AIX ? > >> Currently we use XLC 12.1 to compile JDK on AIX . > >> > >> However XLC 12.1 does not support the ?-qvisibility=hidden? setting > currently set on AIX. > >> It was introduced with XLC 13.1 . Christoph found some info about it here > : > >> > >> https://www.ibm.com/developerworks/aix/library/au-aix-symbol- > visibility-part2/index.html > >> > >> Setting it only generates hundreds of warnings in the build log , > warnings look like this : > >> XlC12.1 > >> > >> bash-4.4$ xlC -qversion > >> IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) > >> Version: 12.01.0000.0019 > >> > >> bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > >> 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of valid > options. > >> > >> Compare to XLC13.1 > >> > >> bash-3.00$ xlC -qversion > >> IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) > >> Version: 13.01.0000.0008 > >> bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc > >> bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > >> > >> > >> So it is better to avoid setting these flags when using xlc12.1 . > >> Please review : > >> > >> Bug : > >> > >> https://bugs.openjdk.java.net/browse/JDK-8202322 > >> > >> Change : > >> > >> http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/ > >> > >> > >> Best regards, Matthias > >> > >> > >> > >> From rachna.goel at oracle.com Fri Apr 27 06:35:46 2018 From: rachna.goel at oracle.com (Rachna Goel) Date: Fri, 27 Apr 2018 12:05:46 +0530 Subject: [11] RFR:JDK-8179071:Month value is inconsistent between CLDR and Java in some special locales Message-ID: <51c8a291-48c5-46fd-8007-ed1f7f7d0ec7@oracle.com> Hi, Kindly review the fix for JDK-8179071. Bug : https://bugs.openjdk.java.net/browse/JDK-8179071 Patch: http://cr.openjdk.java.net/~rgoel/JDK-8179071/webrev.03/index.html Fix is to parse and store language aliases( Deprecated and Legacy ) from CLDR's SupplemetalMetaData file. At run time, If a deprectaed/legacy locale tag is found, It will be replaced by its replacement tag. E.g "pa-PK" will be replaced by "pa-Guru-PK". -- Thanks, Rachna From tobias.hartmann at oracle.com Fri Apr 27 06:42:56 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 27 Apr 2018 08:42:56 +0200 Subject: (M) RFR: 8200167: Validate more special case invocations In-Reply-To: <4e8bbf0c-0e04-a74f-74a3-4b60ba47e48e@oracle.com> References: <27391c2a-fd5c-8133-8e31-b8b45db157ce@oracle.com> <2907289a-2915-118c-f3c0-1327798f6f80@oracle.com> <4e8bbf0c-0e04-a74f-74a3-4b60ba47e48e@oracle.com> Message-ID: <6af38c48-7567-3698-e4d8-8a39ee31ce48@oracle.com> Hi David, On 27.04.2018 00:04, David Holmes wrote: >> src/hotspot/share/c1/c1_Canonicalizer.cpp >> ... >> ??void Canonicalizer::do_CheckCast????? (CheckCast*?????? x) { >> -? if (x->klass()->is_loaded()) { >> +? if (x->klass()->is_loaded() && !x->is_invokespecial_receiver_check()) >> >> It seems like it's not something specific to invokespecial, but a generic problem in how interface >> casts are handled in C1: it's not correct to eliminate the cast if obj->declared_type() is an >> interface. I assume that's what happens in your case. FTR I'm fine with handling it separately. > > The above came from Tobias. If you think there is a more general issue here then we should file a > separate bug and formulate a test case. To clarify, I've quickly debugged this problem before going on vacation and rather than a full fix, the intention of the above change was to quickly verify that the problem is indeed an incorrectly eliminated receiver cast. I'm also fine with handling this in a separate bug or to push this as a quick fix and file a follow up bug for further investigation if other changes are necessary. Thanks, Tobias From thomas.stuefe at gmail.com Fri Apr 27 07:20:38 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 27 Apr 2018 09:20:38 +0200 Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 In-Reply-To: References: <8361024dba4f44309292e73ec9ad7b83@sap.com> <97c60ab29a6348769169b312f55832e7@sap.com> Message-ID: Hi Christoph On Fri, Apr 27, 2018 at 8:07 AM, Langer, Christoph wrote: > Hi Thomas, > > Look at this blog: https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html > > if I understand it correctly, the xlc 12 default behavior should be like what we'd expect from -qvisibility=hidden. > Where in this article do you read this? ..Thomas > Best regards > Christoph > >> -----Original Message----- >> From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf Of >> Thomas St?fe >> Sent: Freitag, 27. April 2018 06:55 >> To: Volker Simonis ; Baesken, Matthias >> >> Cc: Simonis, Volker ; ppc-aix-port- >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; build- >> dev at openjdk.java.net >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 >> >> Hi, >> >> This was added by "8200178: Remove mapfiles for JDK native libraries". >> But if the flag is not accepted, what is the default behavior? Do we >> now export everything? >> >> I'd like to understand this first before removing the flag to get rid >> of the warnings. >> >> Best Regards, Thomas >> >> On Thu, Apr 26, 2018 at 5:16 PM, Volker Simonis >> wrote: >> > Hi Matthias, >> > >> > after Bhaktavatsal Reddy's report about the problems with >> > "-qvisibility" with xlC 13 and taking into account that we can't test >> > this anyway because we don't currently have xlC 13 >> > on our machines I think it would be best to completely remove this >> > option for now on AIX. Once we get xlC 13 we can revisit the issue. >> > >> > Thanks, >> > Volker >> > >> > >> > On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram >> > wrote: >> >> Hi Matthias, >> >> >> >> At this point, I think we can remove the flag as you found that it is not >> supported in XLC < 13. And with XLC 13, it require more work to use this flag. >> >> >> >> Thanks, >> >> Bhaktavatsal Reddy >> >> >> >> >> >> >> >> -----"Baesken, Matthias" wrote: ----- >> >> To: "Langer, Christoph" , "'build- >> dev at openjdk.java.net'" , "ppc-aix-port- >> dev at openjdk.java.net" , "core-libs- >> dev at openjdk.java.net" >> >> From: "Baesken, Matthias" >> >> Date: 04/26/2018 08:23PM >> >> Cc: "Simonis, Volker" , Bhaktavatsal R Maram >> >> >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc >> 12.1 >> >> >> >> >> >> Hello Christoph, I think all XLC versions < 12.1 are unsupported (and >> probably not working anyway) for the OpenJDK build . >> >> I am only aware of XLC versions 12.1 and 13.1 which work / in case of >> 13.1 ?might? work for OpenJDK compilation . >> >> And for 12.1 I want to remove the flags . >> >> >> >> ( waiting for the feedback of Bhaktavatsal Reddy , in case he prefers it >> I remove them for all xlC versions including 13.1 ) >> >> >> >> Best regards, Matthias >> >> >> >> >> >> >> >> >> >> >> >> >> >> From: Langer, Christoph >> >> Sent: Donnerstag, 26. April 2018 16:38 >> >> To: Baesken, Matthias ; 'build- >> dev at openjdk.java.net' ; ppc-aix-port- >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net >> >> Cc: Simonis, Volker >> >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc >> 12.1 >> >> >> >> Hi Matthias, >> >> >> >> to me the change in principal looks good. >> >> >> >> I?m wondering if it is possible to do a comparison like xlc < 13 (e.g. extract >> major number before the first dot, then compare numerically) ? but maybe it >> is too complicated and the current single version compare suits our needs ? >> >> >> >> Best regards >> >> Christoph >> >> >> >> >> >> >> >> >> >> From: Baesken, Matthias >> >> Sent: Donnerstag, 26. April 2018 16:14 >> >> To: 'build-dev at openjdk.java.net' ; ppc- >> aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >> >> Cc: Langer, Christoph ; Simonis, Volker >> >> >> Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 >> >> >> >> Hello , could you please review this small adjustment to the symbol >> visibility compilation settings on AIX ? >> >> Currently we use XLC 12.1 to compile JDK on AIX . >> >> >> >> However XLC 12.1 does not support the ?-qvisibility=hidden? setting >> currently set on AIX. >> >> It was introduced with XLC 13.1 . Christoph found some info about it here >> : >> >> >> >> https://www.ibm.com/developerworks/aix/library/au-aix-symbol- >> visibility-part2/index.html >> >> >> >> Setting it only generates hundreds of warnings in the build log , >> warnings look like this : >> >> XlC12.1 >> >> >> >> bash-4.4$ xlC -qversion >> >> IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) >> >> Version: 12.01.0000.0019 >> >> >> >> bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc >> >> 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of valid >> options. >> >> >> >> Compare to XLC13.1 >> >> >> >> bash-3.00$ xlC -qversion >> >> IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) >> >> Version: 13.01.0000.0008 >> >> bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc >> >> bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc >> >> >> >> >> >> So it is better to avoid setting these flags when using xlc12.1 . >> >> Please review : >> >> >> >> Bug : >> >> >> >> https://bugs.openjdk.java.net/browse/JDK-8202322 >> >> >> >> Change : >> >> >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/ >> >> >> >> >> >> Best regards, Matthias >> >> >> >> >> >> >> >> From christoph.langer at sap.com Fri Apr 27 07:27:45 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 27 Apr 2018 07:27:45 +0000 Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 In-Reply-To: References: <8361024dba4f44309292e73ec9ad7b83@sap.com> <97c60ab29a6348769169b312f55832e7@sap.com> Message-ID: <216dfcffaf2a4a1ea747eb4e63890611@sap.com> Hi Thomas, let me cite one section from the article: ---------------------------------------------- Visibility attribute and backward compatibility on AIX As we know from the previous article, on AIX, symbols are not visible by default unless we export them at the linking stage, either manually or with the help of CreateExportList. However, on Linux, symbols are, by default, with export (namely default) visibility. This brings a gap between the AIX visibility attribute and the GNU visibility attribute. To be backward compatible, on AIX, XL C/C++ would not set all the symbols to be exported like Linux. It might consider symbol without any visibility setting to be an unspecific visibility, which aligns with an old AIX implementation. For such symbols, AIX compiler, linker, and related tools would handle it as before. However, unspecific visibility does not mean that the symbol is internal or invisible at all. It is just a visibility that is specially designed to keep the compatibility. ... ---------------------------------------------- It says in the first sentence: " As we know from the previous article, on AIX, symbols are not visible by default unless we export them at the linking stage, either manually or with the help of CreateExportList". I guess that is why I was under the impression that with xlc12 symbols would not be visible... Best regards Christoph > -----Original Message----- > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > Sent: Freitag, 27. April 2018 09:21 > To: Langer, Christoph > Cc: Volker Simonis ; Baesken, Matthias > ; Simonis, Volker ; > ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; build- > dev at openjdk.java.net > Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 > > Hi Christoph > > On Fri, Apr 27, 2018 at 8:07 AM, Langer, Christoph > wrote: > > Hi Thomas, > > > > Look at this blog: https://www.ibm.com/developerworks/aix/library/au- > aix-symbol-visibility-part2/index.html > > > > if I understand it correctly, the xlc 12 default behavior should be like what > we'd expect from -qvisibility=hidden. > > > > Where in this article do you read this? > > ..Thomas > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf > Of > >> Thomas St?fe > >> Sent: Freitag, 27. April 2018 06:55 > >> To: Volker Simonis ; Baesken, Matthias > >> > >> Cc: Simonis, Volker ; ppc-aix-port- > >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; build- > >> dev at openjdk.java.net > >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc > 12.1 > >> > >> Hi, > >> > >> This was added by "8200178: Remove mapfiles for JDK native libraries". > >> But if the flag is not accepted, what is the default behavior? Do we > >> now export everything? > >> > >> I'd like to understand this first before removing the flag to get rid > >> of the warnings. > >> > >> Best Regards, Thomas > >> > >> On Thu, Apr 26, 2018 at 5:16 PM, Volker Simonis > >> wrote: > >> > Hi Matthias, > >> > > >> > after Bhaktavatsal Reddy's report about the problems with > >> > "-qvisibility" with xlC 13 and taking into account that we can't test > >> > this anyway because we don't currently have xlC 13 > >> > on our machines I think it would be best to completely remove this > >> > option for now on AIX. Once we get xlC 13 we can revisit the issue. > >> > > >> > Thanks, > >> > Volker > >> > > >> > > >> > On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram > >> > wrote: > >> >> Hi Matthias, > >> >> > >> >> At this point, I think we can remove the flag as you found that it is not > >> supported in XLC < 13. And with XLC 13, it require more work to use this > flag. > >> >> > >> >> Thanks, > >> >> Bhaktavatsal Reddy > >> >> > >> >> > >> >> > >> >> -----"Baesken, Matthias" wrote: ----- > >> >> To: "Langer, Christoph" , "'build- > >> dev at openjdk.java.net'" , "ppc-aix-port- > >> dev at openjdk.java.net" , "core- > libs- > >> dev at openjdk.java.net" > >> >> From: "Baesken, Matthias" > >> >> Date: 04/26/2018 08:23PM > >> >> Cc: "Simonis, Volker" , Bhaktavatsal R > Maram > >> > >> >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc > >> 12.1 > >> >> > >> >> > >> >> Hello Christoph, I think all XLC versions < 12.1 are unsupported > (and > >> probably not working anyway) for the OpenJDK build . > >> >> I am only aware of XLC versions 12.1 and 13.1 which work / in case > of > >> 13.1 ?might? work for OpenJDK compilation . > >> >> And for 12.1 I want to remove the flags . > >> >> > >> >> ( waiting for the feedback of Bhaktavatsal Reddy , in case he prefers > it > >> I remove them for all xlC versions including 13.1 ) > >> >> > >> >> Best regards, Matthias > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> From: Langer, Christoph > >> >> Sent: Donnerstag, 26. April 2018 16:38 > >> >> To: Baesken, Matthias ; 'build- > >> dev at openjdk.java.net' ; ppc-aix-port- > >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net > >> >> Cc: Simonis, Volker > >> >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on > xlc > >> 12.1 > >> >> > >> >> Hi Matthias, > >> >> > >> >> to me the change in principal looks good. > >> >> > >> >> I?m wondering if it is possible to do a comparison like xlc < 13 (e.g. > extract > >> major number before the first dot, then compare numerically) ? but > maybe it > >> is too complicated and the current single version compare suits our needs > ? > >> >> > >> >> Best regards > >> >> Christoph > >> >> > >> >> > >> >> > >> >> > >> >> From: Baesken, Matthias > >> >> Sent: Donnerstag, 26. April 2018 16:14 > >> >> To: 'build-dev at openjdk.java.net' ; > ppc- > >> aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > >> >> Cc: Langer, Christoph ; Simonis, Volker > >> > >> >> Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc > 12.1 > >> >> > >> >> Hello , could you please review this small adjustment to the symbol > >> visibility compilation settings on AIX ? > >> >> Currently we use XLC 12.1 to compile JDK on AIX . > >> >> > >> >> However XLC 12.1 does not support the ?-qvisibility=hidden? setting > >> currently set on AIX. > >> >> It was introduced with XLC 13.1 . Christoph found some info about it > here > >> : > >> >> > >> >> https://www.ibm.com/developerworks/aix/library/au-aix-symbol- > >> visibility-part2/index.html > >> >> > >> >> Setting it only generates hundreds of warnings in the build log , > >> warnings look like this : > >> >> XlC12.1 > >> >> > >> >> bash-4.4$ xlC -qversion > >> >> IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) > >> >> Version: 12.01.0000.0019 > >> >> > >> >> bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > >> >> 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of > valid > >> options. > >> >> > >> >> Compare to XLC13.1 > >> >> > >> >> bash-3.00$ xlC -qversion > >> >> IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) > >> >> Version: 13.01.0000.0008 > >> >> bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc > >> >> bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > >> >> > >> >> > >> >> So it is better to avoid setting these flags when using xlc12.1 . > >> >> Please review : > >> >> > >> >> Bug : > >> >> > >> >> https://bugs.openjdk.java.net/browse/JDK-8202322 > >> >> > >> >> Change : > >> >> > >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/ > >> >> > >> >> > >> >> Best regards, Matthias > >> >> > >> >> > >> >> > >> >> From thomas.stuefe at gmail.com Fri Apr 27 08:04:10 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 27 Apr 2018 10:04:10 +0200 Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 In-Reply-To: <216dfcffaf2a4a1ea747eb4e63890611@sap.com> References: <8361024dba4f44309292e73ec9ad7b83@sap.com> <97c60ab29a6348769169b312f55832e7@sap.com> <216dfcffaf2a4a1ea747eb4e63890611@sap.com> Message-ID: On Fri, Apr 27, 2018 at 9:27 AM, Langer, Christoph wrote: > Hi Thomas, > > let me cite one section from the article: > > ---------------------------------------------- > > Visibility attribute and backward compatibility on AIX > > As we know from the previous article, on AIX, symbols are not visible by default unless we export them at the linking stage, either manually or with the help of CreateExportList. However, on Linux, symbols are, by default, with export (namely default) visibility. This brings a gap between the AIX visibility attribute and the GNU visibility attribute. To be backward compatible, on AIX, XL C/C++ would not set all the symbols to be exported like Linux. It might consider symbol without any visibility setting to be an unspecific visibility, which aligns with an old AIX implementation. For such symbols, AIX compiler, linker, and related tools would handle it as before. However, unspecific visibility does not mean that the symbol is internal or invisible at all. It is just a visibility that is specially designed to keep the compatibility. > > ... > > ---------------------------------------------- > > It says in the first sentence: " As we know from the previous article, on AIX, symbols are not visible by default unless we export them at the linking stage, either manually or with the help of CreateExportList". I guess that is why I was under the impression that with xlc12 symbols would not be visible... > :) Thanks for that pointer. I did read: "Consequently, as we have mentioned at the beginning of this article, if the programmer does not explicitly specify the visibility attribute for a symbol, on Linux, the visibility of the symbol could be thedefault. But on AIX, the visibility would be unspecified." So I thought, default is "unspecified", which is not hidden. I just had a look at the libjvm.so from our nightly fastdebug build, using "nm -g". I see tons of exports listed, most of which do not have the static keyword. So, I would expect them to be exported from their compilation unit, but not from the linked shared library? Am I making a thinking error here? Anyway. I do not want to hold up this patch if you guys think it is okay to ignore the compiler warning, so it is okay by me. Best Regards, Thomas > Best regards > Christoph > >> -----Original Message----- >> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] >> Sent: Freitag, 27. April 2018 09:21 >> To: Langer, Christoph >> Cc: Volker Simonis ; Baesken, Matthias >> ; Simonis, Volker ; >> ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; build- >> dev at openjdk.java.net >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 >> >> Hi Christoph >> >> On Fri, Apr 27, 2018 at 8:07 AM, Langer, Christoph >> wrote: >> > Hi Thomas, >> > >> > Look at this blog: https://www.ibm.com/developerworks/aix/library/au- >> aix-symbol-visibility-part2/index.html >> > >> > if I understand it correctly, the xlc 12 default behavior should be like what >> we'd expect from -qvisibility=hidden. >> > >> >> Where in this article do you read this? >> >> ..Thomas >> >> > Best regards >> > Christoph >> > >> >> -----Original Message----- >> >> From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf >> Of >> >> Thomas St?fe >> >> Sent: Freitag, 27. April 2018 06:55 >> >> To: Volker Simonis ; Baesken, Matthias >> >> >> >> Cc: Simonis, Volker ; ppc-aix-port- >> >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; build- >> >> dev at openjdk.java.net >> >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc >> 12.1 >> >> >> >> Hi, >> >> >> >> This was added by "8200178: Remove mapfiles for JDK native libraries". >> >> But if the flag is not accepted, what is the default behavior? Do we >> >> now export everything? >> >> >> >> I'd like to understand this first before removing the flag to get rid >> >> of the warnings. >> >> >> >> Best Regards, Thomas >> >> >> >> On Thu, Apr 26, 2018 at 5:16 PM, Volker Simonis >> >> wrote: >> >> > Hi Matthias, >> >> > >> >> > after Bhaktavatsal Reddy's report about the problems with >> >> > "-qvisibility" with xlC 13 and taking into account that we can't test >> >> > this anyway because we don't currently have xlC 13 >> >> > on our machines I think it would be best to completely remove this >> >> > option for now on AIX. Once we get xlC 13 we can revisit the issue. >> >> > >> >> > Thanks, >> >> > Volker >> >> > >> >> > >> >> > On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram >> >> > wrote: >> >> >> Hi Matthias, >> >> >> >> >> >> At this point, I think we can remove the flag as you found that it is not >> >> supported in XLC < 13. And with XLC 13, it require more work to use this >> flag. >> >> >> >> >> >> Thanks, >> >> >> Bhaktavatsal Reddy >> >> >> >> >> >> >> >> >> >> >> >> -----"Baesken, Matthias" wrote: ----- >> >> >> To: "Langer, Christoph" , "'build- >> >> dev at openjdk.java.net'" , "ppc-aix-port- >> >> dev at openjdk.java.net" , "core- >> libs- >> >> dev at openjdk.java.net" >> >> >> From: "Baesken, Matthias" >> >> >> Date: 04/26/2018 08:23PM >> >> >> Cc: "Simonis, Volker" , Bhaktavatsal R >> Maram >> >> >> >> >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc >> >> 12.1 >> >> >> >> >> >> >> >> >> Hello Christoph, I think all XLC versions < 12.1 are unsupported >> (and >> >> probably not working anyway) for the OpenJDK build . >> >> >> I am only aware of XLC versions 12.1 and 13.1 which work / in case >> of >> >> 13.1 ?might? work for OpenJDK compilation . >> >> >> And for 12.1 I want to remove the flags . >> >> >> >> >> >> ( waiting for the feedback of Bhaktavatsal Reddy , in case he prefers >> it >> >> I remove them for all xlC versions including 13.1 ) >> >> >> >> >> >> Best regards, Matthias >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From: Langer, Christoph >> >> >> Sent: Donnerstag, 26. April 2018 16:38 >> >> >> To: Baesken, Matthias ; 'build- >> >> dev at openjdk.java.net' ; ppc-aix-port- >> >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net >> >> >> Cc: Simonis, Volker >> >> >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on >> xlc >> >> 12.1 >> >> >> >> >> >> Hi Matthias, >> >> >> >> >> >> to me the change in principal looks good. >> >> >> >> >> >> I?m wondering if it is possible to do a comparison like xlc < 13 (e.g. >> extract >> >> major number before the first dot, then compare numerically) ? but >> maybe it >> >> is too complicated and the current single version compare suits our needs >> ? >> >> >> >> >> >> Best regards >> >> >> Christoph >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From: Baesken, Matthias >> >> >> Sent: Donnerstag, 26. April 2018 16:14 >> >> >> To: 'build-dev at openjdk.java.net' ; >> ppc- >> >> aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >> >> >> Cc: Langer, Christoph ; Simonis, Volker >> >> >> >> >> Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc >> 12.1 >> >> >> >> >> >> Hello , could you please review this small adjustment to the symbol >> >> visibility compilation settings on AIX ? >> >> >> Currently we use XLC 12.1 to compile JDK on AIX . >> >> >> >> >> >> However XLC 12.1 does not support the ?-qvisibility=hidden? setting >> >> currently set on AIX. >> >> >> It was introduced with XLC 13.1 . Christoph found some info about it >> here >> >> : >> >> >> >> >> >> https://www.ibm.com/developerworks/aix/library/au-aix-symbol- >> >> visibility-part2/index.html >> >> >> >> >> >> Setting it only generates hundreds of warnings in the build log , >> >> warnings look like this : >> >> >> XlC12.1 >> >> >> >> >> >> bash-4.4$ xlC -qversion >> >> >> IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) >> >> >> Version: 12.01.0000.0019 >> >> >> >> >> >> bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc >> >> >> 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of >> valid >> >> options. >> >> >> >> >> >> Compare to XLC13.1 >> >> >> >> >> >> bash-3.00$ xlC -qversion >> >> >> IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) >> >> >> Version: 13.01.0000.0008 >> >> >> bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc >> >> >> bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc >> >> >> >> >> >> >> >> >> So it is better to avoid setting these flags when using xlc12.1 . >> >> >> Please review : >> >> >> >> >> >> Bug : >> >> >> >> >> >> https://bugs.openjdk.java.net/browse/JDK-8202322 >> >> >> >> >> >> Change : >> >> >> >> >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/ >> >> >> >> >> >> >> >> >> Best regards, Matthias >> >> >> >> >> >> >> >> >> >> >> >> From rafael.wth at gmail.com Fri Apr 27 08:12:08 2018 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Fri, 27 Apr 2018 10:12:08 +0200 Subject: Changed behavior of ParameterizedTypeImpl::toString in 1.8.0_171 Message-ID: Hello, I was wondering if the change in ParameterizedType::toString was intended. I just found my to break after an update due to a test relying on a certain value for this method. My example is: public abstract class AbstractTypeDescriptionGenericTest { public static class NestedSpecifiedTypeVariableType { NestedSpecifiedTypeVariableType.Placeholder foo; class Placeholder { } } } which changed the toString value for the generic type of "foo" (NestedSpecifiedTypeVariableType.class.getDeclaredField("foo").getGenericType().toString()) from: AbstractTypeDescriptionGenericTest.AbstractTypeDescriptionGenericTest$NestedSpecifiedTypeVariableType.Placeholder to AbstractTypeDescriptionGenericTest$NestedSpecifiedTypeVariableType$Placeholder I am wondering if the latter is the new expected format. This does apparently also break Scala on the latest JDK. Thanks for any information. Best regards, Rafael From david.holmes at oracle.com Fri Apr 27 09:10:56 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Apr 2018 19:10:56 +1000 Subject: Changed behavior of ParameterizedTypeImpl::toString in 1.8.0_171 In-Reply-To: References: Message-ID: <45f111fd-e84a-60ed-1429-7644d5e2f4c6@oracle.com> Hi Rafael, On 27/04/2018 6:12 PM, Rafael Winterhalter wrote: > Hello, > > I was wondering if the change in ParameterizedType::toString was intended. https://bugs.openjdk.java.net/browse/JDK-8054213 Cheers, David ----- > I just found my to break after an update due to a test relying on a certain > value for this method. > > My example is: > > public abstract class AbstractTypeDescriptionGenericTest { > public static class NestedSpecifiedTypeVariableType { > NestedSpecifiedTypeVariableType.Placeholder foo; > class Placeholder { } > } > } > > which changed the toString value for the generic type of "foo" > (NestedSpecifiedTypeVariableType.class.getDeclaredField("foo").getGenericType().toString()) > from: > > AbstractTypeDescriptionGenericTest.AbstractTypeDescriptionGenericTest$NestedSpecifiedTypeVariableType.Placeholder > > to > > AbstractTypeDescriptionGenericTest$NestedSpecifiedTypeVariableType$Placeholder > > I am wondering if the latter is the new expected format. This does > apparently also break Scala on the latest JDK. > > Thanks for any information. > Best regards, Rafael > From ecki at zusammenkunft.net Fri Apr 27 09:32:47 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 27 Apr 2018 09:32:47 +0000 Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <5AE2AC3C.4040902@oracle.com> References: <5AE2AC3C.4040902@oracle.com> Message-ID: If this really stays this way and reads all bytes into memory it should at least state so, as this can easily overflow heap. Besides the Javadoc is pretty specific but fails to mention the size comparison. Greetings Bernd Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: core-libs-dev on behalf of Joe Wang Sent: Friday, April 27, 2018 6:51:08 AM To: nio-dev; core-libs-dev Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents Hi, Considering extending isSameFile to add isSameContent to Files. Please review. JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/ specdiff: http://cr.openjdk.java.net/~joehw/jdk11/8202285/specdiff/java/nio/file/Files.html Thanks, Joe From Alan.Bateman at oracle.com Fri Apr 27 09:38:37 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 27 Apr 2018 10:38:37 +0100 Subject: Changed behavior of ParameterizedTypeImpl::toString in 1.8.0_171 In-Reply-To: <45f111fd-e84a-60ed-1429-7644d5e2f4c6@oracle.com> References: <45f111fd-e84a-60ed-1429-7644d5e2f4c6@oracle.com> Message-ID: On 27/04/2018 10:10, David Holmes wrote: > Hi Rafael, > > On 27/04/2018 6:12 PM, Rafael Winterhalter wrote: >> Hello, >> >> I was wondering if the change in ParameterizedType::toString was >> intended. > > https://bugs.openjdk.java.net/browse/JDK-8054213 See also the discussion from June 2016 [1] on this change. I can't tell from your mail if it's the repeated class name or the "$" issue that is causing you (and Scala) issues. -Alan [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041869.html From daniel.fuchs at oracle.com Fri Apr 27 10:58:56 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 27 Apr 2018 11:58:56 +0100 Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <5AE2AC3C.4040902@oracle.com> References: <5AE2AC3C.4040902@oracle.com> Message-ID: <32fc7e08-a4ae-71ab-ab43-d66829553b12@oracle.com> Hi Joe, On the specification side, I think I would reword the API documentation to first explain how the method checks the content of the two files. The fact that it doesn't check the actual content if the two files are 'the same' is kind of an optimization. So I would suggest to invert the order of the two paragraph in the documentation, and combine them into one - something like: 1536 *

      * This method first calls {@link #isSameFile(java.nio.file.Path, java.nio.file.Path) isSameFile(path, path2)} to determine whether the two files are the same. 1537 * If {@code isSameFile(path, path2)} returns false, this method will proceed 1538 * to read the files and compare them byte by byte to determine if they contain 1539 * the same contents. * Otherwise, this method will return true without further * processing. On the implementation side I don't think it's reasonable to call readAllBytes() and hold the content of the two files in memory for comparing their content, especially if it's to discover that the first byte differs. Some lock-step reading of the two files would seem more appropriate. best regards, -- daniel On 27/04/2018 05:51, Joe Wang wrote: > Hi, > > Considering extending isSameFile to add isSameContent to Files. Please > review. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 > > webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/ > > specdiff: > http://cr.openjdk.java.net/~joehw/jdk11/8202285/specdiff/java/nio/file/Files.html > > > Thanks, > Joe > From jbluettduncan at gmail.com Fri Apr 27 11:01:56 2018 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Fri, 27 Apr 2018 12:01:56 +0100 Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <32fc7e08-a4ae-71ab-ab43-d66829553b12@oracle.com> References: <5AE2AC3C.4040902@oracle.com> <32fc7e08-a4ae-71ab-ab43-d66829553b12@oracle.com> Message-ID: Hi Joe, I wonder if the method `isSameContent` should be named `haveSameContents` so as to read more fluently in English. Cheers, Jonathan On 27 April 2018 at 11:58, Daniel Fuchs wrote: > Hi Joe, > > On the specification side, I think I would reword the API > documentation to first explain how the method checks the > content of the two files. > > The fact that it doesn't check the actual content if > the two files are 'the same' is kind of an optimization. > > So I would suggest to invert the order of the two paragraph > in the documentation, and combine them into one - something like: > > 1536 *

      > * This method first calls {@link #isSameFile(java.nio.file.Path, > java.nio.file.Path) isSameFile(path, path2)} to determine whether the two > files are the same. > 1537 * If {@code isSameFile(path, path2)} returns false, this method > will proceed > 1538 * to read the files and compare them byte by byte to determine > if they contain > 1539 * the same contents. > * Otherwise, this method will return true without further > * processing. > > > On the implementation side I don't think it's reasonable to call > readAllBytes() and hold the content of the two files in memory > for comparing their content, especially if it's to discover that > the first byte differs. > > Some lock-step reading of the two files would seem more appropriate. > > best regards, > > -- daniel > > > > > > On 27/04/2018 05:51, Joe Wang wrote: > >> Hi, >> >> Considering extending isSameFile to add isSameContent to Files. Please >> review. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 >> >> webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/ >> >> specdiff: http://cr.openjdk.java.net/~joehw/jdk11/8202285/specdiff/jav >> a/nio/file/Files.html >> >> Thanks, >> Joe >> >> > From Alan.Bateman at oracle.com Fri Apr 27 11:13:52 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 27 Apr 2018 12:13:52 +0100 Subject: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file In-Reply-To: <5AE2AC03.9000705@oracle.com> References: <5AE2AC03.9000705@oracle.com> Message-ID: On 27/04/2018 05:50, Joe Wang wrote: > Hi, > > We're looking into adding methods to Files to read a file into a > String/write a String to a file. Below is the current proposal. Please > review. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8201276 > > webrev: http://cr.openjdk.java.net/~joehw/jdk11/8201276/webrev/ > > specdiff: > http://cr.openjdk.java.net/~joehw/jdk11/8201276/specdiff/java/nio/file/Files.html The javadoc for these 4 methods looks okay. It might be helpful to include something in the readString javadoc to make it absolutely clear that the String may include line separators. I assume the "Note that .." paragraph can be changed to an @apiNote. I assume you'll add "@since 11" to the readString methods. It would be good to keep the existing formatting/style consistent with the existing code if you can, e.g.

      tags, 4 space indent rather than 8 for the throws, etc. I can't tell from your mail if you are just looking for feedback on the current implementation + tests or just the API. I assume there are alternatives to using StringBuilder for the readString methods for example. -Alan From forax at univ-mlv.fr Fri Apr 27 11:29:39 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 27 Apr 2018 13:29:39 +0200 (CEST) Subject: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file In-Reply-To: References: <5AE2AC03.9000705@oracle.com> Message-ID: <1297536212.1989108.1524828579265.JavaMail.zimbra@u-pem.fr> I think that having a readString that includes OS dependent line separators is a mistake, Java does a great job to try to shield the developer from the kind of things that makes programs behave differently on different platforms. readString should subtitute (\r)?\n to \n otherwise either people will do a call replace() which is less efficient or will learn the lesson the hard way. raw string literal does the same substitution for the same reason. regards R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "Joe Wang" > Cc: "nio-dev" , "core-libs-dev" > Envoy?: Vendredi 27 Avril 2018 13:13:52 > Objet: Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file > On 27/04/2018 05:50, Joe Wang wrote: >> Hi, >> >> We're looking into adding methods to Files to read a file into a >> String/write a String to a file. Below is the current proposal. Please >> review. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8201276 >> >> webrev: http://cr.openjdk.java.net/~joehw/jdk11/8201276/webrev/ >> >> specdiff: >> http://cr.openjdk.java.net/~joehw/jdk11/8201276/specdiff/java/nio/file/Files.html > The javadoc for these 4 methods looks okay. It might be helpful to > include something in the readString javadoc to make it absolutely clear > that the String may include line separators. I assume the "Note that .." > paragraph can be changed to an @apiNote. > > I assume you'll add "@since 11" to the readString methods. > > It would be good to keep the existing formatting/style consistent with > the existing code if you can, e.g.

      tags, 4 space indent rather than > 8 for the throws, etc. > > I can't tell from your mail if you are just looking for feedback on the > current implementation + tests or just the API. I assume there are > alternatives to using StringBuilder for the readString methods for example. > > -Alan From Alan.Bateman at oracle.com Fri Apr 27 11:30:07 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 27 Apr 2018 12:30:07 +0100 Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <5AE2AC3C.4040902@oracle.com> References: <5AE2AC3C.4040902@oracle.com> Message-ID: <5ccdb071-16cf-3744-3941-ddc45d07115a@oracle.com> On 27/04/2018 05:51, Joe Wang wrote: > Hi, > > Considering extending isSameFile to add isSameContent to Files. Please > review. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 > > webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/ > > specdiff: > http://cr.openjdk.java.net/~joehw/jdk11/8202285/specdiff/java/nio/file/Files.html I assume we should ignore the implementation for now as the eventual implementation won't use readAllBytes (at least not for for large files). The existing isSameFile is specified as "Tests if two paths locate the same file" and it would be good if the new method could be somewhat consistent with that, e.g. "Tests if the content of two files is identical". Specifying that two path that locate the same file always returns true is reasonable. This could be make clearer by say that the returning always returns true when path and path2 are equals, if event if the file does not exist. The @return should say that it returns true if path and path2 locate the same file or the content of both files is identical. The javadoc for SecurityException has "to the file", I assume this should be "to both files". -Alan From Alan.Bateman at oracle.com Fri Apr 27 11:34:12 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 27 Apr 2018 12:34:12 +0100 Subject: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file In-Reply-To: <1297536212.1989108.1524828579265.JavaMail.zimbra@u-pem.fr> References: <5AE2AC03.9000705@oracle.com> <1297536212.1989108.1524828579265.JavaMail.zimbra@u-pem.fr> Message-ID: <515d4180-e2b7-48f3-5856-f472cf7892a4@oracle.com> On 27/04/2018 12:29, Remi Forax wrote: > I think that having a readString that includes OS dependent line separators is a mistake, > Java does a great job to try to shield the developer from the kind of things that makes programs behave differently on different platforms. > > readString should subtitute (\r)?\n to \n otherwise either people will do a call replace() which is less efficient or will learn the lesson the hard way. > > raw string literal does the same substitution for the same reason. > Yes, there are several discussion points around this and somewhat timely with multi-string support. One thing that I think Joe will need in this API is some note to make it clearer what the intended usage is (as I think the intention is simple cases with mostly single lines of text). -Alan. From forax at univ-mlv.fr Fri Apr 27 11:37:30 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 27 Apr 2018 13:37:30 +0200 (CEST) Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <5AE2AC3C.4040902@oracle.com> References: <5AE2AC3C.4040902@oracle.com> Message-ID: <1834074267.1991697.1524829050819.JavaMail.zimbra@u-pem.fr> This seems to promote the wrong way to do such thing, the usual use case is that you want to compare the content of a well know file with the content of a bunch of other files, so hashing is better. R?mi ----- Mail original ----- > De: "Joe Wang" > ?: "nio-dev" , "core-libs-dev" > Envoy?: Vendredi 27 Avril 2018 06:51:08 > Objet: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents > Hi, > > Considering extending isSameFile to add isSameContent to Files. Please > review. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 > > webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/ > > specdiff: > http://cr.openjdk.java.net/~joehw/jdk11/8202285/specdiff/java/nio/file/Files.html > > Thanks, > Joe From forax at univ-mlv.fr Fri Apr 27 11:43:24 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 27 Apr 2018 13:43:24 +0200 (CEST) Subject: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file In-Reply-To: <515d4180-e2b7-48f3-5856-f472cf7892a4@oracle.com> References: <5AE2AC03.9000705@oracle.com> <1297536212.1989108.1524828579265.JavaMail.zimbra@u-pem.fr> <515d4180-e2b7-48f3-5856-f472cf7892a4@oracle.com> Message-ID: <106042075.1993206.1524829404390.JavaMail.zimbra@u-pem.fr> Hi Alan, People do not read the documentation. So adding something in the documentation about when a method should be used or not is never a solution. Here the user want a String and provides a charset so you have no way but to decode the content to substitute the line separator. cheers, R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "Remi Forax" , "Joe Wang" > Cc: "nio-dev" , "core-libs-dev" > Envoy?: Vendredi 27 Avril 2018 13:34:12 > Objet: Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file > On 27/04/2018 12:29, Remi Forax wrote: >> I think that having a readString that includes OS dependent line separators is a >> mistake, >> Java does a great job to try to shield the developer from the kind of things >> that makes programs behave differently on different platforms. >> >> readString should subtitute (\r)?\n to \n otherwise either people will do a call >> replace() which is less efficient or will learn the lesson the hard way. >> >> raw string literal does the same substitution for the same reason. >> > Yes, there are several discussion points around this and somewhat timely > with multi-string support. > > One thing that I think Joe will need in this API is some note to make it > clearer what the intended usage is (as I think the intention is simple > cases with mostly single lines of text). > > -Alan. From rachna.goel at oracle.com Fri Apr 27 12:32:05 2018 From: rachna.goel at oracle.com (Rachna Goel) Date: Fri, 27 Apr 2018 18:02:05 +0530 Subject: [11] RFR:JDK-8179071:Month value is inconsistent between CLDR and Java in some special locales In-Reply-To: <51c8a291-48c5-46fd-8007-ed1f7f7d0ec7@oracle.com> References: <51c8a291-48c5-46fd-8007-ed1f7f7d0ec7@oracle.com> Message-ID: One correction: E.g "pa-PK" wil be replaced by "pa-Arab-PK", as former is a deprecated/legacy tag. On 4/27/18 12:05 PM, Rachna Goel wrote: > Hi, > > Kindly review the fix for JDK-8179071. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8179071 > > Patch: http://cr.openjdk.java.net/~rgoel/JDK-8179071/webrev.03/index.html > > Fix is to parse and store language aliases( Deprecated and Legacy ) > from CLDR's SupplemetalMetaData file. At run time, If a > deprectaed/legacy locale tag is found, It will be replaced by its > replacement tag. E.g "pa-PK" will be replaced by "pa-Guru-PK". > -- Thanks, Rachna From raffaello.giulietti at gmail.com Fri Apr 27 14:39:55 2018 From: raffaello.giulietti at gmail.com (raffaello.giulietti at gmail.com) Date: Fri, 27 Apr 2018 16:39:55 +0200 Subject: Update to the Double::toString(double) Javadoc Message-ID: <0bbac4c6-01ce-9dfd-7cfe-d4c9d77d21f3@gmail.com> Hi, as may be known, the current Javadoc for Double::toString(double) is not specific enough. As a consequence, different implementations can return different results. To see this, here are some quotes from the Javadoc. It asks: "How many digits must be printed for the fractional part of m or a?" It answers: "There must be at least one digit to represent the fractional part, and beyond that as many, but only as many, more digits as are needed to uniquely distinguish the argument value from adjacent values of type double." One interpretation is: output "as many" digit of m (or a) itself. But this can lead to unnecessarily long results. For example, the true value of the double v closest to 0.3 is v = 0.299999999999999988897769753748434595763683319091796875 so according to this restricted interpretation the method should return "0.29999999999999998" because shorter prefixes do not round to v. Another interpretation exploits the astute word "represent" in the answer, so it might sound: output "as many" digits of a nearby, vaguely determined "short" number that "represents" m (or a) and happens to round to v. In this case the obvious choice is "0.3" which is the result returned by the method. One problem with this interpretation is that sometimes there is more than one choice. For example, both 4.8E-324 and 4.9E-324 round to Double.MIN_VALUE. The method chooses the latter one, presumably because it is closer to the double, but this is not specified. It is also not specified what happens if two equally shortest numbers that round to the same double are also equally close to it. Of course, the same holds for Float::toString(float). The code that was uploaded to this mailing list [1] as a contribution to fix [2], contains a purportedly better Javadoc that imposes a uniquely specified result (see method math.DoubleToDecimal::toString(double) ). It has been carefully written to ensure that the spirit of the current Javadoc is preserved as much as possible and to make sure that the results returned by the contributed code and by the current OpenJDK implementation are consistent (modulo the anomalies discussed in [2]). The question is if this needs to be submitted to the Compatibility & Specification Review Group? If so, what is the correct process to follow for an individual contributor like me? I ask because I would like my contribution to be accepted for the next OpenJDK 11 LTS release: I have no idea on how long it would take for a spec change to be approved, if the need arises at all in a case like this one. Greetings Raffaello [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052696.html [2] https://bugs.openjdk.java.net/browse/JDK-4511638 From matthias.baesken at sap.com Fri Apr 27 15:01:32 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 27 Apr 2018 15:01:32 +0000 Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 In-Reply-To: References: <8361024dba4f44309292e73ec9ad7b83@sap.com> <97c60ab29a6348769169b312f55832e7@sap.com> <216dfcffaf2a4a1ea747eb4e63890611@sap.com> Message-ID: <6f8b83fe169c4b31a9bb459593e92d1a@sap.com> > I see tons of exports listed, most of which do not have the static > keyword. So, I would expect them to be exported from their compilation > unit, but not from the linked shared library? Am I making a thinking > error here? Hi Thomas , I see "a ton" of exported symbols as well when looking into it (e.g. libjvm.so) with dump . More than one would like to have . However for now I think we should progress with the suggested patch as it is. Once we switch to xlc 13 (or some follow up release of xlc) that supports the visibility attributes ( as decribed in https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility/index.html ) we can open a follow up item with compiler flag adjustment and adjust src/java.base/unix/native/include/jni_md.h , I think this file misses a proper JNIEXPORT definition for AIX / xlc 13.1 ). Best regards, Matthias > -----Original Message----- > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > Sent: Freitag, 27. April 2018 10:04 > To: Langer, Christoph > Cc: Volker Simonis ; Baesken, Matthias > ; Simonis, Volker ; > ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; build- > dev at openjdk.java.net > Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 > > On Fri, Apr 27, 2018 at 9:27 AM, Langer, Christoph > wrote: > > Hi Thomas, > > > > let me cite one section from the article: > > > > ---------------------------------------------- > > > > Visibility attribute and backward compatibility on AIX > > > > As we know from the previous article, on AIX, symbols are not visible by > default unless we export them at the linking stage, either manually or with > the help of CreateExportList. However, on Linux, symbols are, by default, > with export (namely default) visibility. This brings a gap between the AIX > visibility attribute and the GNU visibility attribute. To be backward > compatible, on AIX, XL C/C++ would not set all the symbols to be exported > like Linux. It might consider symbol without any visibility setting to be an > unspecific visibility, which aligns with an old AIX implementation. For such > symbols, AIX compiler, linker, and related tools would handle it as before. > However, unspecific visibility does not mean that the symbol is internal or > invisible at all. It is just a visibility that is specially designed to keep the > compatibility. > > > > ... > > > > ---------------------------------------------- > > > > It says in the first sentence: " As we know from the previous article, on AIX, > symbols are not visible by default unless we export them at the linking stage, > either manually or with the help of CreateExportList". I guess that is why I > was under the impression that with xlc12 symbols would not be visible... > > > > :) Thanks for that pointer. > > I did read: > > "Consequently, as we have mentioned at the beginning of this article, > if the programmer does not explicitly specify the visibility attribute > for a symbol, on Linux, the visibility of the symbol could be > thedefault. But on AIX, the visibility would be unspecified." > > So I thought, default is "unspecified", which is not hidden. > > I just had a look at the libjvm.so from our nightly fastdebug build, > using "nm -g". > > I see tons of exports listed, most of which do not have the static > keyword. So, I would expect them to be exported from their compilation > unit, but not from the linked shared library? Am I making a thinking > error here? > > Anyway. I do not want to hold up this patch if you guys think it is > okay to ignore the compiler warning, so it is okay by me. > > Best Regards, Thomas > > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > >> Sent: Freitag, 27. April 2018 09:21 > >> To: Langer, Christoph > >> Cc: Volker Simonis ; Baesken, Matthias > >> ; Simonis, Volker > ; > >> ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; > build- > >> dev at openjdk.java.net > >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc > 12.1 > >> > >> Hi Christoph > >> > >> On Fri, Apr 27, 2018 at 8:07 AM, Langer, Christoph > >> wrote: > >> > Hi Thomas, > >> > > >> > Look at this blog: > https://www.ibm.com/developerworks/aix/library/au- > >> aix-symbol-visibility-part2/index.html > >> > > >> > if I understand it correctly, the xlc 12 default behavior should be like > what > >> we'd expect from -qvisibility=hidden. > >> > > >> > >> Where in this article do you read this? > >> > >> ..Thomas > >> > >> > Best regards > >> > Christoph > >> > > >> >> -----Original Message----- > >> >> From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On > Behalf > >> Of > >> >> Thomas St?fe > >> >> Sent: Freitag, 27. April 2018 06:55 > >> >> To: Volker Simonis ; Baesken, Matthias > >> >> > >> >> Cc: Simonis, Volker ; ppc-aix-port- > >> >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; build- > >> >> dev at openjdk.java.net > >> >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc > >> 12.1 > >> >> > >> >> Hi, > >> >> > >> >> This was added by "8200178: Remove mapfiles for JDK native libraries". > >> >> But if the flag is not accepted, what is the default behavior? Do we > >> >> now export everything? > >> >> > >> >> I'd like to understand this first before removing the flag to get rid > >> >> of the warnings. > >> >> > >> >> Best Regards, Thomas > >> >> > >> >> On Thu, Apr 26, 2018 at 5:16 PM, Volker Simonis > >> >> wrote: > >> >> > Hi Matthias, > >> >> > > >> >> > after Bhaktavatsal Reddy's report about the problems with > >> >> > "-qvisibility" with xlC 13 and taking into account that we can't test > >> >> > this anyway because we don't currently have xlC 13 > >> >> > on our machines I think it would be best to completely remove this > >> >> > option for now on AIX. Once we get xlC 13 we can revisit the issue. > >> >> > > >> >> > Thanks, > >> >> > Volker > >> >> > > >> >> > > >> >> > On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram > >> >> > wrote: > >> >> >> Hi Matthias, > >> >> >> > >> >> >> At this point, I think we can remove the flag as you found that it is > not > >> >> supported in XLC < 13. And with XLC 13, it require more work to use > this > >> flag. > >> >> >> > >> >> >> Thanks, > >> >> >> Bhaktavatsal Reddy > >> >> >> > >> >> >> > >> >> >> > >> >> >> -----"Baesken, Matthias" wrote: ---- > - > >> >> >> To: "Langer, Christoph" , "'build- > >> >> dev at openjdk.java.net'" , "ppc-aix- > port- > >> >> dev at openjdk.java.net" , "core- > >> libs- > >> >> dev at openjdk.java.net" > >> >> >> From: "Baesken, Matthias" > >> >> >> Date: 04/26/2018 08:23PM > >> >> >> Cc: "Simonis, Volker" , Bhaktavatsal R > >> Maram > >> >> > >> >> >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on > xlc > >> >> 12.1 > >> >> >> > >> >> >> > >> >> >> Hello Christoph, I think all XLC versions < 12.1 are unsupported > >> (and > >> >> probably not working anyway) for the OpenJDK build . > >> >> >> I am only aware of XLC versions 12.1 and 13.1 which work / in > case > >> of > >> >> 13.1 ?might? work for OpenJDK compilation . > >> >> >> And for 12.1 I want to remove the flags . > >> >> >> > >> >> >> ( waiting for the feedback of Bhaktavatsal Reddy , in case he > prefers > >> it > >> >> I remove them for all xlC versions including 13.1 ) > >> >> >> > >> >> >> Best regards, Matthias > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> From: Langer, Christoph > >> >> >> Sent: Donnerstag, 26. April 2018 16:38 > >> >> >> To: Baesken, Matthias ; 'build- > >> >> dev at openjdk.java.net' ; ppc-aix-port- > >> >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net > >> >> >> Cc: Simonis, Volker > >> >> >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support > on > >> xlc > >> >> 12.1 > >> >> >> > >> >> >> Hi Matthias, > >> >> >> > >> >> >> to me the change in principal looks good. > >> >> >> > >> >> >> I?m wondering if it is possible to do a comparison like xlc < 13 (e.g. > >> extract > >> >> major number before the first dot, then compare numerically) ? but > >> maybe it > >> >> is too complicated and the current single version compare suits our > needs > >> ? > >> >> >> > >> >> >> Best regards > >> >> >> Christoph > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> From: Baesken, Matthias > >> >> >> Sent: Donnerstag, 26. April 2018 16:14 > >> >> >> To: 'build-dev at openjdk.java.net' ; > >> ppc- > >> >> aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > >> >> >> Cc: Langer, Christoph ; Simonis, > Volker > >> >> > >> >> >> Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc > >> 12.1 > >> >> >> > >> >> >> Hello , could you please review this small adjustment to the > symbol > >> >> visibility compilation settings on AIX ? > >> >> >> Currently we use XLC 12.1 to compile JDK on AIX . > >> >> >> > >> >> >> However XLC 12.1 does not support the ?-qvisibility=hidden? > setting > >> >> currently set on AIX. > >> >> >> It was introduced with XLC 13.1 . Christoph found some info about > it > >> here > >> >> : > >> >> >> > >> >> >> https://www.ibm.com/developerworks/aix/library/au-aix-symbol- > >> >> visibility-part2/index.html > >> >> >> > >> >> >> Setting it only generates hundreds of warnings in the build log , > >> >> warnings look like this : > >> >> >> XlC12.1 > >> >> >> > >> >> >> bash-4.4$ xlC -qversion > >> >> >> IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) > >> >> >> Version: 12.01.0000.0019 > >> >> >> > >> >> >> bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > >> >> >> 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list > of > >> valid > >> >> options. > >> >> >> > >> >> >> Compare to XLC13.1 > >> >> >> > >> >> >> bash-3.00$ xlC -qversion > >> >> >> IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) > >> >> >> Version: 13.01.0000.0008 > >> >> >> bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc > >> >> >> bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > >> >> >> > >> >> >> > >> >> >> So it is better to avoid setting these flags when using xlc12.1 . > >> >> >> Please review : > >> >> >> > >> >> >> Bug : > >> >> >> > >> >> >> https://bugs.openjdk.java.net/browse/JDK-8202322 > >> >> >> > >> >> >> Change : > >> >> >> > >> >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/ > >> >> >> > >> >> >> > >> >> >> Best regards, Matthias > >> >> >> > >> >> >> > >> >> >> > >> >> >> From thomas.stuefe at gmail.com Fri Apr 27 15:58:53 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 27 Apr 2018 17:58:53 +0200 Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 In-Reply-To: <6f8b83fe169c4b31a9bb459593e92d1a@sap.com> References: <8361024dba4f44309292e73ec9ad7b83@sap.com> <97c60ab29a6348769169b312f55832e7@sap.com> <216dfcffaf2a4a1ea747eb4e63890611@sap.com> <6f8b83fe169c4b31a9bb459593e92d1a@sap.com> Message-ID: On Fri, Apr 27, 2018 at 5:01 PM, Baesken, Matthias wrote: >> I see tons of exports listed, most of which do not have the static >> keyword. So, I would expect them to be exported from their compilation >> unit, but not from the linked shared library? Am I making a thinking >> error here? > > Hi Thomas , I see "a ton" of exported symbols as well when looking into it (e.g. libjvm.so) with dump . > More than one would like to have . > Okay, thanks for confirming this! I was not sure if I was using nm correctly, or if it was lying to me. > However for now I think we should progress with the suggested patch as it is. > I agree, patch is fine. Thanks for fixing this. > Once we switch to xlc 13 (or some follow up release of xlc) that supports the visibility attributes > ( as decribed in https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility/index.html ) > we can open a follow up item with compiler flag adjustment and adjust src/java.base/unix/native/include/jni_md.h , I think this file misses a proper JNIEXPORT definition for AIX / xlc 13.1 ). > Okay, fine with me. Best Regards, Thomas > > Best regards, Matthias > > > >> -----Original Message----- >> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] >> Sent: Freitag, 27. April 2018 10:04 >> To: Langer, Christoph >> Cc: Volker Simonis ; Baesken, Matthias >> ; Simonis, Volker ; >> ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; build- >> dev at openjdk.java.net >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 >> >> On Fri, Apr 27, 2018 at 9:27 AM, Langer, Christoph >> wrote: >> > Hi Thomas, >> > >> > let me cite one section from the article: >> > >> > ---------------------------------------------- >> > >> > Visibility attribute and backward compatibility on AIX >> > >> > As we know from the previous article, on AIX, symbols are not visible by >> default unless we export them at the linking stage, either manually or with >> the help of CreateExportList. However, on Linux, symbols are, by default, >> with export (namely default) visibility. This brings a gap between the AIX >> visibility attribute and the GNU visibility attribute. To be backward >> compatible, on AIX, XL C/C++ would not set all the symbols to be exported >> like Linux. It might consider symbol without any visibility setting to be an >> unspecific visibility, which aligns with an old AIX implementation. For such >> symbols, AIX compiler, linker, and related tools would handle it as before. >> However, unspecific visibility does not mean that the symbol is internal or >> invisible at all. It is just a visibility that is specially designed to keep the >> compatibility. >> > >> > ... >> > >> > ---------------------------------------------- >> > >> > It says in the first sentence: " As we know from the previous article, on AIX, >> symbols are not visible by default unless we export them at the linking stage, >> either manually or with the help of CreateExportList". I guess that is why I >> was under the impression that with xlc12 symbols would not be visible... >> > >> >> :) Thanks for that pointer. >> >> I did read: >> >> "Consequently, as we have mentioned at the beginning of this article, >> if the programmer does not explicitly specify the visibility attribute >> for a symbol, on Linux, the visibility of the symbol could be >> thedefault. But on AIX, the visibility would be unspecified." >> >> So I thought, default is "unspecified", which is not hidden. >> >> I just had a look at the libjvm.so from our nightly fastdebug build, >> using "nm -g". >> >> I see tons of exports listed, most of which do not have the static >> keyword. So, I would expect them to be exported from their compilation >> unit, but not from the linked shared library? Am I making a thinking >> error here? >> >> Anyway. I do not want to hold up this patch if you guys think it is >> okay to ignore the compiler warning, so it is okay by me. >> >> Best Regards, Thomas >> >> >> > Best regards >> > Christoph >> > >> >> -----Original Message----- >> >> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] >> >> Sent: Freitag, 27. April 2018 09:21 >> >> To: Langer, Christoph >> >> Cc: Volker Simonis ; Baesken, Matthias >> >> ; Simonis, Volker >> ; >> >> ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; >> build- >> >> dev at openjdk.java.net >> >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc >> 12.1 >> >> >> >> Hi Christoph >> >> >> >> On Fri, Apr 27, 2018 at 8:07 AM, Langer, Christoph >> >> wrote: >> >> > Hi Thomas, >> >> > >> >> > Look at this blog: >> https://www.ibm.com/developerworks/aix/library/au- >> >> aix-symbol-visibility-part2/index.html >> >> > >> >> > if I understand it correctly, the xlc 12 default behavior should be like >> what >> >> we'd expect from -qvisibility=hidden. >> >> > >> >> >> >> Where in this article do you read this? >> >> >> >> ..Thomas >> >> >> >> > Best regards >> >> > Christoph >> >> > >> >> >> -----Original Message----- >> >> >> From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On >> Behalf >> >> Of >> >> >> Thomas St?fe >> >> >> Sent: Freitag, 27. April 2018 06:55 >> >> >> To: Volker Simonis ; Baesken, Matthias >> >> >> >> >> >> Cc: Simonis, Volker ; ppc-aix-port- >> >> >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; build- >> >> >> dev at openjdk.java.net >> >> >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc >> >> 12.1 >> >> >> >> >> >> Hi, >> >> >> >> >> >> This was added by "8200178: Remove mapfiles for JDK native libraries". >> >> >> But if the flag is not accepted, what is the default behavior? Do we >> >> >> now export everything? >> >> >> >> >> >> I'd like to understand this first before removing the flag to get rid >> >> >> of the warnings. >> >> >> >> >> >> Best Regards, Thomas >> >> >> >> >> >> On Thu, Apr 26, 2018 at 5:16 PM, Volker Simonis >> >> >> wrote: >> >> >> > Hi Matthias, >> >> >> > >> >> >> > after Bhaktavatsal Reddy's report about the problems with >> >> >> > "-qvisibility" with xlC 13 and taking into account that we can't test >> >> >> > this anyway because we don't currently have xlC 13 >> >> >> > on our machines I think it would be best to completely remove this >> >> >> > option for now on AIX. Once we get xlC 13 we can revisit the issue. >> >> >> > >> >> >> > Thanks, >> >> >> > Volker >> >> >> > >> >> >> > >> >> >> > On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram >> >> >> > wrote: >> >> >> >> Hi Matthias, >> >> >> >> >> >> >> >> At this point, I think we can remove the flag as you found that it is >> not >> >> >> supported in XLC < 13. And with XLC 13, it require more work to use >> this >> >> flag. >> >> >> >> >> >> >> >> Thanks, >> >> >> >> Bhaktavatsal Reddy >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -----"Baesken, Matthias" wrote: ---- >> - >> >> >> >> To: "Langer, Christoph" , "'build- >> >> >> dev at openjdk.java.net'" , "ppc-aix- >> port- >> >> >> dev at openjdk.java.net" , "core- >> >> libs- >> >> >> dev at openjdk.java.net" >> >> >> >> From: "Baesken, Matthias" >> >> >> >> Date: 04/26/2018 08:23PM >> >> >> >> Cc: "Simonis, Volker" , Bhaktavatsal R >> >> Maram >> >> >> >> >> >> >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on >> xlc >> >> >> 12.1 >> >> >> >> >> >> >> >> >> >> >> >> Hello Christoph, I think all XLC versions < 12.1 are unsupported >> >> (and >> >> >> probably not working anyway) for the OpenJDK build . >> >> >> >> I am only aware of XLC versions 12.1 and 13.1 which work / in >> case >> >> of >> >> >> 13.1 ?might? work for OpenJDK compilation . >> >> >> >> And for 12.1 I want to remove the flags . >> >> >> >> >> >> >> >> ( waiting for the feedback of Bhaktavatsal Reddy , in case he >> prefers >> >> it >> >> >> I remove them for all xlC versions including 13.1 ) >> >> >> >> >> >> >> >> Best regards, Matthias >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From: Langer, Christoph >> >> >> >> Sent: Donnerstag, 26. April 2018 16:38 >> >> >> >> To: Baesken, Matthias ; 'build- >> >> >> dev at openjdk.java.net' ; ppc-aix-port- >> >> >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net >> >> >> >> Cc: Simonis, Volker >> >> >> >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support >> on >> >> xlc >> >> >> 12.1 >> >> >> >> >> >> >> >> Hi Matthias, >> >> >> >> >> >> >> >> to me the change in principal looks good. >> >> >> >> >> >> >> >> I?m wondering if it is possible to do a comparison like xlc < 13 (e.g. >> >> extract >> >> >> major number before the first dot, then compare numerically) ? but >> >> maybe it >> >> >> is too complicated and the current single version compare suits our >> needs >> >> ? >> >> >> >> >> >> >> >> Best regards >> >> >> >> Christoph >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From: Baesken, Matthias >> >> >> >> Sent: Donnerstag, 26. April 2018 16:14 >> >> >> >> To: 'build-dev at openjdk.java.net' ; >> >> ppc- >> >> >> aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >> >> >> >> Cc: Langer, Christoph ; Simonis, >> Volker >> >> >> >> >> >> >> Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc >> >> 12.1 >> >> >> >> >> >> >> >> Hello , could you please review this small adjustment to the >> symbol >> >> >> visibility compilation settings on AIX ? >> >> >> >> Currently we use XLC 12.1 to compile JDK on AIX . >> >> >> >> >> >> >> >> However XLC 12.1 does not support the ?-qvisibility=hidden? >> setting >> >> >> currently set on AIX. >> >> >> >> It was introduced with XLC 13.1 . Christoph found some info about >> it >> >> here >> >> >> : >> >> >> >> >> >> >> >> https://www.ibm.com/developerworks/aix/library/au-aix-symbol- >> >> >> visibility-part2/index.html >> >> >> >> >> >> >> >> Setting it only generates hundreds of warnings in the build log , >> >> >> warnings look like this : >> >> >> >> XlC12.1 >> >> >> >> >> >> >> >> bash-4.4$ xlC -qversion >> >> >> >> IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) >> >> >> >> Version: 12.01.0000.0019 >> >> >> >> >> >> >> >> bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc >> >> >> >> 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list >> of >> >> valid >> >> >> options. >> >> >> >> >> >> >> >> Compare to XLC13.1 >> >> >> >> >> >> >> >> bash-3.00$ xlC -qversion >> >> >> >> IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) >> >> >> >> Version: 13.01.0000.0008 >> >> >> >> bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc >> >> >> >> bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc >> >> >> >> >> >> >> >> >> >> >> >> So it is better to avoid setting these flags when using xlc12.1 . >> >> >> >> Please review : >> >> >> >> >> >> >> >> Bug : >> >> >> >> >> >> >> >> https://bugs.openjdk.java.net/browse/JDK-8202322 >> >> >> >> >> >> >> >> Change : >> >> >> >> >> >> >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/ >> >> >> >> >> >> >> >> >> >> >> >> Best regards, Matthias >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From paul.sandoz at oracle.com Fri Apr 27 16:25:43 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 27 Apr 2018 09:25:43 -0700 Subject: Review Request JDK-8201793: (ref) Reference object should not support cloning In-Reply-To: <18e57635-2a95-cbd4-827a-f0a292c4e308@oracle.com> References: <6a3759c9-0e6f-b3e6-5ef5-2b032c8d7773@oracle.com> <8A1D8366-0DC5-4542-9098-D9E0C21C8012@oracle.com> <18e57635-2a95-cbd4-827a-f0a292c4e308@oracle.com> Message-ID: <3C216F02-4519-4BFF-B55E-A4F00FA5493B@oracle.com> > On Apr 26, 2018, at 11:03 PM, mandy chung wrote: > > > > On 4/27/18 3:35 AM, Paul Sandoz wrote: >> Hi Mandy, >> >> This looks reasonable. I suspect external subtypes of the j.l.ref types are extremely rare (grep code reports no derived types) and of those it would likely be even rarer for those subtypes to implement Cloneable, and for that functionality to operate reliably. > > Thanks for the review. > > Subtypes of java.lang.ref.SoftReference and WeakReference is not uncommon (JDK has plenty of such subtypes). Ooops, silly me, grep code only reports direct sub-types when querying for derived types, am i queried from Reference. Paul. > I guess grep code may show the result of a specific JDK release and reports no derived types. I do think it's extremely rare for those subtypes to implement Cloneable. So this change should have low compatibility risk. > > Mandy From rafael.wth at gmail.com Fri Apr 27 18:23:19 2018 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Fri, 27 Apr 2018 20:23:19 +0200 Subject: Changed behavior of ParameterizedTypeImpl::toString in 1.8.0_171 In-Reply-To: References: <45f111fd-e84a-60ed-1429-7644d5e2f4c6@oracle.com> Message-ID: Hei Alan and David, thanks for pointing me to the issue, I have only searched the release notes for u172 by accident. The issue is mainly during builds. I run my library on multiple CI servers to cover Windows/Linux and different Java versions from 6-11. Unfortunately, I have not full control over what version of Java is run on these servers. Yesterday, I found some of the builds fail for pull requests what was a bit confusing. Byte Buddy offers an abstraction over type descriptions that implement similar semantics to the Java reflection API when it comes to equality and to textual (toString) representations. These tests suddenly failed since the JVMs representation is changed, this is all. The Scala build had a similar problem: https://github.com/scala/bug/issues/10835 This is not a big deal but I found it surprising to have a change in the string representation within an update release. Especially since a nested class does not necessarily have the same name prefix if a class is not compiled with javac. I would have preferred the consistency over the redundancy; especially when type names are machine-processed, this often makes a parser easier to implement. Thanks for clarifying this for me, best regards, Rafael 2018-04-27 11:38 GMT+02:00 Alan Bateman : > On 27/04/2018 10:10, David Holmes wrote: > >> Hi Rafael, >> >> On 27/04/2018 6:12 PM, Rafael Winterhalter wrote: >> >>> Hello, >>> >>> I was wondering if the change in ParameterizedType::toString was >>> intended. >>> >> >> https://bugs.openjdk.java.net/browse/JDK-8054213 >> > See also the discussion from June 2016 [1] on this change. > > I can't tell from your mail if it's the repeated class name or the "$" > issue that is causing you (and Scala) issues. > > -Alan > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-Ju > ne/041869.html > From joe.darcy at oracle.com Fri Apr 27 18:58:08 2018 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 27 Apr 2018 11:58:08 -0700 Subject: Update to the Double::toString(double) Javadoc In-Reply-To: <0bbac4c6-01ce-9dfd-7cfe-d4c9d77d21f3@gmail.com> References: <0bbac4c6-01ce-9dfd-7cfe-d4c9d77d21f3@gmail.com> Message-ID: <1d7e9357-f732-873d-e543-5ac6dfc81412@oracle.com> Hello Raffaello, On 4/27/2018 7:39 AM, raffaello.giulietti at gmail.com wrote: > Hi, > > as may be known, the current Javadoc for Double::toString(double) is not > specific enough. As a consequence, different implementations can return > different results. > > To see this, here are some quotes from the Javadoc. It asks: "How many > digits must be printed for the fractional part of m or a?" It answers: > "There must be at least one digit to represent the fractional part, and > beyond that as many, but only as many, more digits as are needed to > uniquely distinguish the argument value from adjacent values of type > double." > > One interpretation is: output "as many" digit of m (or a) itself. But > this can lead to unnecessarily long results. For example, the true value > of the double v closest to 0.3 is > v = 0.299999999999999988897769753748434595763683319091796875 > so according to this restricted interpretation the method should return > "0.29999999999999998" > because shorter prefixes do not round to v. > > Another interpretation exploits the astute word "represent" in the > answer, so it might sound: output "as many" digits of a nearby, vaguely > determined "short" number that "represents" m (or a) and happens to > round to v. In this case the obvious choice is > "0.3" > which is the result returned by the method. > > One problem with this interpretation is that sometimes there is more > than one choice. For example, both 4.8E-324 and 4.9E-324 round to > Double.MIN_VALUE. The method chooses the latter one, presumably because > it is closer to the double, but this is not specified. It is also not > specified what happens if two equally shortest numbers that round to the > same double are also equally close to it. > > Of course, the same holds for Float::toString(float). For background on the design of this printing methodology see? "How to Print Floating-Point Numbers Accurately," Guy L. Steele and Jon L. White in the proceedings of the 1990 PLDI. > The code that was uploaded to this mailing list [1] as a contribution to > fix [2], contains a purportedly better Javadoc that imposes a uniquely > specified result (see method math.DoubleToDecimal::toString(double) ). > It has been carefully written to ensure that the spirit of the current > Javadoc is preserved as much as possible and to make sure that the > results returned by the contributed code and by the current OpenJDK > implementation are consistent (modulo the anomalies discussed in [2]). > > > > The question is if this needs to be submitted to the Compatibility & > Specification Review Group? > If so, what is the correct process to follow for an individual > contributor like me? It does sound like the change merits CSR review.? On a procedural front, to create a CSR, one needs an account in the bug system, so the sponsor of your issue with an account, Brian Burkhalter I believe, would need to assist here. Conceptually, the CSR process is described on its wiki page https://wiki.openjdk.java.net/display/csr/Main. The review is concerned with evaluating the compatibility impact of the spec (or behavioral change), so information about those matters is provided and considered. > > I ask because I would like my contribution to be accepted for the next > OpenJDK 11 LTS release: I have no idea on how long it would take for a > spec change to be approved, if the need arises at all in a case like > this one. > The normal review SLA for CSR review is a week. Note this is time to review rather than time to approve since the CSR can have comments that need to be addressed, etc. HTH and thanks for the code submission, -Joe From huizhe.wang at oracle.com Fri Apr 27 19:02:50 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 27 Apr 2018 12:02:50 -0700 Subject: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file In-Reply-To: References: <5AE2AC03.9000705@oracle.com> Message-ID: <9a338eed-721f-a90e-82d9-a41e3a1dc5f1@oracle.com> On 4/27/2018 4:13 AM, Alan Bateman wrote: > On 27/04/2018 05:50, Joe Wang wrote: >> Hi, >> >> We're looking into adding methods to Files to read a file into a >> String/write a String to a file. Below is the current proposal. >> Please review. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8201276 >> >> webrev: http://cr.openjdk.java.net/~joehw/jdk11/8201276/webrev/ >> >> specdiff: >> http://cr.openjdk.java.net/~joehw/jdk11/8201276/specdiff/java/nio/file/Files.html > The javadoc for these 4 methods looks okay. It might be helpful to > include something in the readString javadoc to make it absolutely > clear that the String may include line separators. I assume the "Note > that .." paragraph can be changed to an @apiNote. Added a statement to indicate that "the resulting string will contain line separators as they appear in the file". Changed the 'note' to @apiNote. > > > I assume you'll add "@since 11" to the readString methods. Added. > > It would be good to keep the existing formatting/style consistent with > the existing code if you can, e.g.

      tags, 4 space indent rather > than 8 for the throws, etc. Fixed

      and the throws. I didn't even notice that the IDE (NetBeans) added 8 spaces! > > I can't tell from your mail if you are just looking for feedback on > the current implementation + tests or just the API. I assume there are > alternatives to using StringBuilder for the readString methods for > example. Both. I thought webrevs would be helpful where specdiff was not clear enough, for example, you won't otherwise notice the formatting/style issue :-) I changed that to new String(readAllBytes(path), charset) as it's convenient with readAllBytes handling all situations (OOM and etc.). But alternative solution to avoid copying would be nice. -Joe > > -Alan From huizhe.wang at oracle.com Fri Apr 27 19:21:01 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 27 Apr 2018 12:21:01 -0700 Subject: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file In-Reply-To: <106042075.1993206.1524829404390.JavaMail.zimbra@u-pem.fr> References: <5AE2AC03.9000705@oracle.com> <1297536212.1989108.1524828579265.JavaMail.zimbra@u-pem.fr> <515d4180-e2b7-48f3-5856-f472cf7892a4@oracle.com> <106042075.1993206.1524829404390.JavaMail.zimbra@u-pem.fr> Message-ID: <499f6815-ae0d-73e6-e606-5f3352c89ba9@oracle.com> Hi R?mi, Alan, I'm not sure we'd want to replace system dependent line separators with '\n'. There are cases as you described where the replacement makes sense. However,? there are other cases too. For example, the purpose is to read, edit a text file and then write it back. If this is on Windows, and if line separators are replaced with '\n', that would cause the resulting file not formatted properly in for example Notepad. There are cases where users write text files on Windows using Java, and only found the lines were not separated in Notepad. Files.write(Path, Iterable) is also specified to terminate each line with the platform's line separator. If readString does the replacement, it would be inconsistent. I would think readString behaves like readAllBytes, that would simply read all content faithfully. Best, Joe On 4/27/2018 4:43 AM, forax at univ-mlv.fr wrote: > Hi Alan, > > People do not read the documentation. > So adding something in the documentation about when a method should be used or not is never a solution. > > Here the user want a String and provides a charset so you have no way but to decode the content to substitute the line separator. > > cheers, > R?mi > > ----- Mail original ----- >> De: "Alan Bateman" >> ?: "Remi Forax" , "Joe Wang" >> Cc: "nio-dev" , "core-libs-dev" >> Envoy?: Vendredi 27 Avril 2018 13:34:12 >> Objet: Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file >> On 27/04/2018 12:29, Remi Forax wrote: >>> I think that having a readString that includes OS dependent line separators is a >>> mistake, >>> Java does a great job to try to shield the developer from the kind of things >>> that makes programs behave differently on different platforms. >>> >>> readString should subtitute (\r)?\n to \n otherwise either people will do a call >>> replace() which is less efficient or will learn the lesson the hard way. >>> >>> raw string literal does the same substitution for the same reason. >>> >> Yes, there are several discussion points around this and somewhat timely >> with multi-string support. >> >> One thing that I think Joe will need in this API is some note to make it >> clearer what the intended usage is (as I think the intention is simple >> cases with mostly single lines of text). >> >> -Alan. From raffaello.giulietti at gmail.com Fri Apr 27 19:36:07 2018 From: raffaello.giulietti at gmail.com (raffaello.giulietti at gmail.com) Date: Fri, 27 Apr 2018 21:36:07 +0200 Subject: Update to the Double::toString(double) Javadoc In-Reply-To: <1d7e9357-f732-873d-e543-5ac6dfc81412@oracle.com> References: <0bbac4c6-01ce-9dfd-7cfe-d4c9d77d21f3@gmail.com> <1d7e9357-f732-873d-e543-5ac6dfc81412@oracle.com> Message-ID: Hi Joe, so I beg Brian to get in touch with me for the CSR review. I'm familiar with the paper of Steele and White. For background on the design of my contribution see [1]. Greetings Raffaello [1] https://9b7022c5f9.files.wordpress.com/2018/04/todec.pdf On 2018-04-27 20:58, joe darcy wrote: > Hello Raffaello, > > > On 4/27/2018 7:39 AM, raffaello.giulietti at gmail.com wrote: >> Hi, >> >> as may be known, the current Javadoc for Double::toString(double) is not >> specific enough. As a consequence, different implementations can return >> different results. >> >> To see this, here are some quotes from the Javadoc. It asks: "How many >> digits must be printed for the fractional part of m or a?" It answers: >> "There must be at least one digit to represent the fractional part, and >> beyond that as many, but only as many, more digits as are needed to >> uniquely distinguish the argument value from adjacent values of type >> double." >> >> One interpretation is: output "as many" digit of m (or a) itself. But >> this can lead to unnecessarily long results. For example, the true value >> of the double v closest to 0.3 is >> v = 0.299999999999999988897769753748434595763683319091796875 >> so according to this restricted interpretation the method should return >> "0.29999999999999998" >> because shorter prefixes do not round to v. >> >> Another interpretation exploits the astute word "represent" in the >> answer, so it might sound: output "as many" digits of a nearby, vaguely >> determined "short" number that "represents" m (or a) and happens to >> round to v. In this case the obvious choice is >> "0.3" >> which is the result returned by the method. >> >> One problem with this interpretation is that sometimes there is more >> than one choice. For example, both 4.8E-324 and 4.9E-324 round to >> Double.MIN_VALUE. The method chooses the latter one, presumably because >> it is closer to the double, but this is not specified. It is also not >> specified what happens if two equally shortest numbers that round to the >> same double are also equally close to it. >> >> Of course, the same holds for Float::toString(float). > > For background on the design of this printing methodology see? "How to > Print Floating-Point Numbers Accurately," Guy L. Steele and Jon L. White > in the proceedings of the 1990 PLDI. > >> The code that was uploaded to this mailing list [1] as a contribution to >> fix [2], contains a purportedly better Javadoc that imposes a uniquely >> specified result (see method math.DoubleToDecimal::toString(double) ). >> It has been carefully written to ensure that the spirit of the current >> Javadoc is preserved as much as possible and to make sure that the >> results returned by the contributed code and by the current OpenJDK >> implementation are consistent (modulo the anomalies discussed in [2]). >> >> >> >> The question is if this needs to be submitted to the Compatibility & >> Specification Review Group? >> If so, what is the correct process to follow for an individual >> contributor like me? > > It does sound like the change merits CSR review.? On a procedural front, > to create a CSR, one needs an account in the bug system, so the sponsor > of your issue with an account, Brian Burkhalter I believe, would need to > assist here. Conceptually, the CSR process is described on its wiki page > https://wiki.openjdk.java.net/display/csr/Main. The review is concerned > with evaluating the compatibility impact of the spec (or behavioral > change), so information about those matters is provided and considered. > >> >> I ask because I would like my contribution to be accepted for the next >> OpenJDK 11 LTS release: I have no idea on how long it would take for a >> spec change to be approved, if the need arises at all in a case like >> this one. >> > > The normal review SLA for CSR review is a week. Note this is time to > review rather than time to approve since the CSR can have comments that > need to be addressed, etc. > > HTH and thanks for the code submission, > > -Joe From forax at univ-mlv.fr Fri Apr 27 19:50:13 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 27 Apr 2018 21:50:13 +0200 (CEST) Subject: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file In-Reply-To: <499f6815-ae0d-73e6-e606-5f3352c89ba9@oracle.com> References: <5AE2AC03.9000705@oracle.com> <1297536212.1989108.1524828579265.JavaMail.zimbra@u-pem.fr> <515d4180-e2b7-48f3-5856-f472cf7892a4@oracle.com> <106042075.1993206.1524829404390.JavaMail.zimbra@u-pem.fr> <499f6815-ae0d-73e6-e606-5f3352c89ba9@oracle.com> Message-ID: <2100883236.2133173.1524858613899.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Joe Wang" > ?: "Remi Forax" , "Alan Bateman" > Cc: "nio-dev" , "core-libs-dev" > Envoy?: Vendredi 27 Avril 2018 21:21:01 > Objet: Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file > Hi R?mi, Alan, Hi Joe, > > I'm not sure we'd want to replace system dependent line separators with > '\n'. There are cases as you described where the replacement makes > sense. However,? there are other cases too. For example, the purpose is > to read, edit a text file and then write it back. If this is on Windows, > and if line separators are replaced with '\n', that would cause the > resulting file not formatted properly in for example Notepad. There are > cases where users write text files on Windows using Java, and only found > the lines were not separated in Notepad. I agree that why the counterpart of readString() that write the string should inserts the platform's line separator. BTW, i just found that those methods are not named writeString, or writeCharSequence, i think they should. > > Files.write(Path, Iterable) is also specified to terminate each line > with the platform's line separator. If readString does the replacement, > it would be inconsistent. Anyway, if we look for consistency the methods writeCharSequence should transform the \n in the CharSequence to the platform's line separator. Files.write(Path, Iterable) is is not a counterpart of readString(), it's consistent with Files.lines() or Files.readLines() (or BufferedReader.readLine()) that all suppress the line separators. Anyway, Files.write(path, readString(path)::line) will be consistent if you replace the line separators or not because String.line() suppresses the line separators. > > I would think readString behaves like readAllBytes, that would simply read all content faithfully. readString does an interpolation due to the Charset so it's not the real content, again, the idea is that developers should not have to care about the platform's line separators (they have more important things to think). The other solution is to just not introduce those new methods, after all Files.lines().collect(Collectors.joining("\n")) already does the job, no ? > > Best, > Joe regards, R?mi > > On 4/27/2018 4:43 AM, forax at univ-mlv.fr wrote: >> Hi Alan, >> >> People do not read the documentation. >> So adding something in the documentation about when a method should be used or >> not is never a solution. >> >> Here the user want a String and provides a charset so you have no way but to >> decode the content to substitute the line separator. >> >> cheers, >> R?mi >> >> ----- Mail original ----- >>> De: "Alan Bateman" >>> ?: "Remi Forax" , "Joe Wang" >>> Cc: "nio-dev" , "core-libs-dev" >>> >>> Envoy?: Vendredi 27 Avril 2018 13:34:12 >>> Objet: Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for >>> reading/writing a string from/to a file >>> On 27/04/2018 12:29, Remi Forax wrote: >>>> I think that having a readString that includes OS dependent line separators is a >>>> mistake, >>>> Java does a great job to try to shield the developer from the kind of things >>>> that makes programs behave differently on different platforms. >>>> >>>> readString should subtitute (\r)?\n to \n otherwise either people will do a call >>>> replace() which is less efficient or will learn the lesson the hard way. >>>> >>>> raw string literal does the same substitution for the same reason. >>>> >>> Yes, there are several discussion points around this and somewhat timely >>> with multi-string support. >>> >>> One thing that I think Joe will need in this API is some note to make it >>> clearer what the intended usage is (as I think the intention is simple >>> cases with mostly single lines of text). >>> > >> -Alan. From naoto.sato at oracle.com Fri Apr 27 19:55:07 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 27 Apr 2018 12:55:07 -0700 Subject: [11] RFR:JDK-8179071:Month value is inconsistent between CLDR and Java in some special locales In-Reply-To: References: <51c8a291-48c5-46fd-8007-ed1f7f7d0ec7@oracle.com> Message-ID: Looks good. Naoto On 4/27/18 5:32 AM, Rachna Goel wrote: > One correction: > > E.g "pa-PK" wil be replaced by "pa-Arab-PK", as former is a > deprecated/legacy tag. > > > On 4/27/18 12:05 PM, Rachna Goel wrote: >> Hi, >> >> Kindly review the fix for JDK-8179071. >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8179071 >> >> Patch: http://cr.openjdk.java.net/~rgoel/JDK-8179071/webrev.03/index.html >> >> Fix is to parse and store language aliases( Deprecated and Legacy ) >> from CLDR's SupplemetalMetaData file. At run time, If a >> deprectaed/legacy locale tag is found, It will be replaced by its >> replacement tag. E.g "pa-PK" will be replaced by "pa-Guru-PK". >> > From andrey.x.nazarov at oracle.com Fri Apr 27 20:56:19 2018 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Fri, 27 Apr 2018 13:56:19 -0700 Subject: RFR 8197388: Added not existing bug id in jdk/ProblemList.txt In-Reply-To: <1AD251EC-4B2B-4F14-8F97-004CFD2B0A87@oracle.com> References: <1AD251EC-4B2B-4F14-8F97-004CFD2B0A87@oracle.com> Message-ID: <866F7B21-C3B0-4F13-8C26-D085B8636A09@oracle.com> Hi, Could you CC any client alias? ?Thanks, Andrei > On 26 Apr 2018, at 11:51, Andrey Nazarov wrote: > > Hi, > > Please review patch that fixes typo in bug id. > > diff -r 3661f31c6df4 test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt Thu Apr 26 11:19:05 2018 -0500 > +++ b/test/jdk/ProblemList.txt Thu Apr 26 11:47:18 2018 -0700 > @@ -243,7 +243,7 @@ > sun/java2d/SunGraphics2D/EmptyClipRenderingTest.java 8144029 macosx-all > sun/java2d/SunGraphics2D/DrawImageBilinear.java 8191506 generic-all > sun/java2d/SunGraphics2D/PolyVertTest.java 6986565 generic-all > -sun/java2d/SunGraphics2D/SimplePrimQuality.java 7992007 generic-all > +sun/java2d/SunGraphics2D/SimplePrimQuality.java 6992007 generic-all > sun/java2d/SunGraphics2D/SourceClippingBlitTest/SourceClippingBlitTest.java 8196191 windows-all,macosx-all > sun/java2d/pipe/InterpolationQualityTest.java 8171303 windows-all,linux-all,macosx-all > java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java 8169469 windows-all > > Issue: https://bugs.openjdk.java.net/browse/JDK-8197388 > > > ?Thanks, > Andrei From kim.barrett at oracle.com Fri Apr 27 22:08:57 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 27 Apr 2018 18:08:57 -0400 Subject: Review Request JDK-8201793: (ref) Reference object should not support cloning In-Reply-To: <6a3759c9-0e6f-b3e6-5ef5-2b032c8d7773@oracle.com> References: <6a3759c9-0e6f-b3e6-5ef5-2b032c8d7773@oracle.com> Message-ID: <8CE9221A-83EC-4EC7-941B-1AE3C4808682@oracle.com> > On Apr 26, 2018, at 10:16 AM, mandy chung wrote: > > The semantics of cloning a Reference object is not clearly defined. In addition, it is questionable whether it can be meaningfully supported in particular with concurrent reference processing. > > The reachability state of a Reference object may change during GC reference processing. The referent may have been cleared when it reaches its reachability state. In addition, it may be enqueued or pending for enqueuing. Cloning a Reference object with a referent that is unreachable but not yet cleared might mean to resurrect the referent. A cloned enqueued Reference object will never be enqueued. A Reference object cannot be meaningfully cloned. > > We propose Reference::clone to throw CloneNotSupportedException. To clone a Reference object, it should create a new instance via its constructor. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8202260 > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8201793/webrev.00/ > > Mandy The webrev doesn?t have the minor doc change suggested in the CSR. Other than that, looks good. From huizhe.wang at oracle.com Fri Apr 27 22:33:24 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 27 Apr 2018 15:33:24 -0700 Subject: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file In-Reply-To: <2100883236.2133173.1524858613899.JavaMail.zimbra@u-pem.fr> References: <5AE2AC03.9000705@oracle.com> <1297536212.1989108.1524828579265.JavaMail.zimbra@u-pem.fr> <515d4180-e2b7-48f3-5856-f472cf7892a4@oracle.com> <106042075.1993206.1524829404390.JavaMail.zimbra@u-pem.fr> <499f6815-ae0d-73e6-e606-5f3352c89ba9@oracle.com> <2100883236.2133173.1524858613899.JavaMail.zimbra@u-pem.fr> Message-ID: <7ffaa0de-cbee-0fc7-57b2-44caa39dad47@oracle.com> On 4/27/2018 12:50 PM, forax at univ-mlv.fr wrote: > ----- Mail original ----- >> De: "Joe Wang" >> ?: "Remi Forax" , "Alan Bateman" >> Cc: "nio-dev" , "core-libs-dev" >> Envoy?: Vendredi 27 Avril 2018 21:21:01 >> Objet: Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file >> Hi R?mi, Alan, > Hi Joe, > >> I'm not sure we'd want to replace system dependent line separators with >> '\n'. There are cases as you described where the replacement makes >> sense. However,? there are other cases too. For example, the purpose is >> to read, edit a text file and then write it back. If this is on Windows, >> and if line separators are replaced with '\n', that would cause the >> resulting file not formatted properly in for example Notepad. There are >> cases where users write text files on Windows using Java, and only found >> the lines were not separated in Notepad. > I agree that why the counterpart of readString() that write the string should inserts the platform's line separator. > BTW, i just found that those methods are not named writeString, or writeCharSequence, i think they should. While readString() does not modify the original content (e.g. by replacing the platform's line separator with '\n'), write(String) won't either, by adding extra characters such as the line separator. I would think interfaces shall read along with the parameters. ??? readString(Path) == read as a String from the specified Path (one could argue for readToString, readAsString, but we generally omit the preps) ??? write(Path, CharSequence) == write the CharSequence to the file, since CharSequence is already in the method signature as a parameter, we probably don't want to add that to the name, otherwise it would read like repeating the word CharSequence. It is in a similar situation as write(Path, Iterable) where it was defined as writeLines(Path, Iterable). > >> Files.write(Path, Iterable) is also specified to terminate each line >> with the platform's line separator. If readString does the replacement, >> it would be inconsistent. > > Anyway, if we look for consistency the methods writeCharSequence should transform the \n in the CharSequence to the platform's line separator. > > Files.write(Path, Iterable) is is not a counterpart of readString(), it's consistent with Files.lines() or Files.readLines() (or BufferedReader.readLine()) that all suppress the line separators. Anyway, Files.write(path, readString(path)::line) will be consistent if you replace the line separators or not because String.line() suppresses the line separators. readString pairs with write(String), therefore it's more like Files.write(path, readString(path)) than readString(path)::line. The use case: ??? String s = Files.read(path); ??? Files.write(path, s.replace("/config/location", "/new/location")); would then work as expected. These two methods are one-off (open/read/write/close file) operation. write(String) therefore is not intended for adding/appending multiple Strings from other operations such as String.line(). If an app needs to put the result of String.line() or any other processes into a file using this method, it needs to take care of adding the line separator itself when necessary. "when necessary" would be a judgement call by the developer. That said, if there's a consensus on the idea of terminating the string with a line separator, then readString method would need to strip it off to go with the write method. > >> I would think readString behaves like readAllBytes, that would simply read all content faithfully. > readString does an interpolation due to the Charset so it's not the real content, again, the idea is that developers should not have to care about the platform's line separators (they have more important things to think). > > The other solution is to just not introduce those new methods, after all Files.lines().collect(Collectors.joining("\n")) already does the job, no ? While there are many ways to do it, none is as straight-forward. "Read (entire) file to String"/"Write String to file" are popular requests from users. Read to string -> do some String manipulation -> write it back is such a simple use case, it really needs to be very easy to do as illustrated in the above code snippet. Cheers, Joe > >> Best, >> Joe > regards, > R?mi > >> On 4/27/2018 4:43 AM, forax at univ-mlv.fr wrote: >>> Hi Alan, >>> >>> People do not read the documentation. >>> So adding something in the documentation about when a method should be used or >>> not is never a solution. >>> >>> Here the user want a String and provides a charset so you have no way but to >>> decode the content to substitute the line separator. >>> >>> cheers, >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "Alan Bateman" >>>> ?: "Remi Forax" , "Joe Wang" >>>> Cc: "nio-dev" , "core-libs-dev" >>>> >>>> Envoy?: Vendredi 27 Avril 2018 13:34:12 >>>> Objet: Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for >>>> reading/writing a string from/to a file >>>> On 27/04/2018 12:29, Remi Forax wrote: >>>>> I think that having a readString that includes OS dependent line separators is a >>>>> mistake, >>>>> Java does a great job to try to shield the developer from the kind of things >>>>> that makes programs behave differently on different platforms. >>>>> >>>>> readString should subtitute (\r)?\n to \n otherwise either people will do a call >>>>> replace() which is less efficient or will learn the lesson the hard way. >>>>> >>>>> raw string literal does the same substitution for the same reason. >>>>> >>>> Yes, there are several discussion points around this and somewhat timely >>>> with multi-string support. >>>> >>>> One thing that I think Joe will need in this API is some note to make it >>>> clearer what the intended usage is (as I think the intention is simple >>>> cases with mostly single lines of text). >>>> >>>> -Alan. From david.holmes at oracle.com Fri Apr 27 23:19:56 2018 From: david.holmes at oracle.com (David Holmes) Date: Sat, 28 Apr 2018 09:19:56 +1000 Subject: jdk-submit is offline until Monday Message-ID: <035f244f-175b-6b03-c69b-4e9773881248@oracle.com> Just a heads up that due to scheduled maintenance the systems used by jdk-submit will be offline until Monday morning Pacific Time US. David From david.holmes at oracle.com Fri Apr 27 23:27:28 2018 From: david.holmes at oracle.com (David Holmes) Date: Sat, 28 Apr 2018 09:27:28 +1000 Subject: jdk-submit is offline until Monday In-Reply-To: <035f244f-175b-6b03-c69b-4e9773881248@oracle.com> References: <035f244f-175b-6b03-c69b-4e9773881248@oracle.com> Message-ID: <7339b969-0f20-652c-b4d6-88b88ade5006@oracle.com> I should have added that the CI testing system is also offline, so any pushes won't hit our internal testing until sometime Monday. David On 28/04/2018 9:19 AM, David Holmes wrote: > Just a heads up that due to scheduled maintenance the systems used by > jdk-submit will be offline until Monday morning Pacific Time US. > > David From mandy.chung at oracle.com Sat Apr 28 00:27:19 2018 From: mandy.chung at oracle.com (mandy chung) Date: Sat, 28 Apr 2018 08:27:19 +0800 Subject: Review Request JDK-8201793: (ref) Reference object should not support cloning In-Reply-To: <8CE9221A-83EC-4EC7-941B-1AE3C4808682@oracle.com> References: <6a3759c9-0e6f-b3e6-5ef5-2b032c8d7773@oracle.com> <8CE9221A-83EC-4EC7-941B-1AE3C4808682@oracle.com> Message-ID: <729c86d6-770f-be52-6ed0-1831e0ee5782@oracle.com> On 4/28/18 6:08 AM, Kim Barrett wrote: >> On Apr 26, 2018, at 10:16 AM, mandy chung wrote: >> >> The semantics of cloning a Reference object is not clearly defined. In addition, it is questionable whether it can be meaningfully supported in particular with concurrent reference processing. >> >> The reachability state of a Reference object may change during GC reference processing. The referent may have been cleared when it reaches its reachability state. In addition, it may be enqueued or pending for enqueuing. Cloning a Reference object with a referent that is unreachable but not yet cleared might mean to resurrect the referent. A cloned enqueued Reference object will never be enqueued. A Reference object cannot be meaningfully cloned. >> >> We propose Reference::clone to throw CloneNotSupportedException. To clone a Reference object, it should create a new instance via its constructor. >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8202260 >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8201793/webrev.00/ >> >> Mandy > The webrev doesn?t have the minor doc change suggested in the CSR. I have that fixed in my local repo but the webrev was not updated. diff --git a/src/java.base/share/classes/java/lang/ref/Reference.java b/src/java.base/share/classes/java/lang/ref/Reference.java --- a/src/java.base/share/classes/java/lang/ref/Reference.java +++ b/src/java.base/share/classes/java/lang/ref/Reference.java @@ -300,6 +300,20 @@ ???????? return this.queue.enqueue(this); ???? } +??? /** +???? * Throws {@link CloneNotSupportedException}. A {@code Reference} cannot be +???? * meaningfully cloned. Construct a new {@code Reference} instead. +???? * +???? * @returns never returns normally +???? * @throws? CloneNotSupportedException always +???? * +???? * @since 11 +???? */ +??? @Override +??? protected Object clone() throws CloneNotSupportedException { +??????? throw new CloneNotSupportedException(); +??? } + ???? /* -- Constructors -- */ > Other than that, looks good. > Thanks. Mandy From stuart.marks at oracle.com Sat Apr 28 00:37:23 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 27 Apr 2018 17:37:23 -0700 Subject: RFR: 8201650: Move iteration order randomization of unmodifiable Set and Map to iterators In-Reply-To: References: Message-ID: <3db0c565-02d4-8402-895a-03b99299cd07@oracle.com> On 4/18/18 8:20 AM, Claes Redestad wrote: > please review this change that moves the use of SALT to iterator creation, which > would allow for certain startup > optimizations in the future. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8201650 > Webrev: http://cr.openjdk.java.net/~redestad/8201650/open.00/ > > This does make the randomness of iteration order weaker as we're only > randomizing the starting point (varying with > the size of the collection) and the iteration direction (run-to-run variant; > weaker than calculating per size, but > allows this patch to be performance neutral). > > Some Set/Map operations become very slightly faster with this patch, but that's > in the noise. Iterator operations > remain largely performance neutral, sometimes even a bit faster. Hi Claes, I finally got a chance to look at this. Overall looks fine. Although the randomness is "weaker" iterating in both directions will, I think, still have the desired effect of flushing out order dependencies. I have a test (forthcoming) that verifies that iteration order will vary from run to run, and it passes with both the old and new code. Not an issue, but I'm curious as to why the initial index is chosen this way: idx = Math.floorMod(SALT ^ remaining, elements.length); The floorMod with a divisor of elements.length makes perfect sense. I'm wondering why the dividend is (SALT ^ remaining) and not just SALT for example. Thanks, s'marks From huaming.li at oracle.com Sat Apr 28 03:32:39 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Sat, 28 Apr 2018 11:32:39 +0800 Subject: RFR of JDK-8202291,java/rmi/Naming/LookupIPv6.java failed with Connection refused Message-ID: would you please review the patch? bug: https://bugs.openjdk.java.net/browse/JDK-8202291 webrev: http://cr.openjdk.java.net/~mli/8202291/webrev.00/ In original code, there is a window between get registry and rebind which could cause connection refuse. Thank you -Hamlin From huaming.li at oracle.com Sat Apr 28 07:35:22 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Sat, 28 Apr 2018 15:35:22 +0800 Subject: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file In-Reply-To: <5AE2AC03.9000705@oracle.com> References: <5AE2AC03.9000705@oracle.com> Message-ID: Hi Joe, just a minor comment about the test in ReadWriteString.java. For both testMalformedWrite and testMalformedRead, temp files are not deleted, as Files.deleteIfExists(path); is skipped by the expected IOException. File.deleteOnExit?() may help. Thank you -Hamlin On 27/04/2018 12:50 PM, Joe Wang wrote: > Hi, > > We're looking into adding methods to Files to read a file into a > String/write a String to a file. Below is the current proposal. Please > review. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8201276 > > webrev: http://cr.openjdk.java.net/~joehw/jdk11/8201276/webrev/ > > specdiff: > http://cr.openjdk.java.net/~joehw/jdk11/8201276/specdiff/java/nio/file/Files.html > > > Thanks, > Joe From Alan.Bateman at oracle.com Sat Apr 28 07:51:19 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 28 Apr 2018 08:51:19 +0100 Subject: Changed behavior of ParameterizedTypeImpl::toString in 1.8.0_171 In-Reply-To: References: <45f111fd-e84a-60ed-1429-7644d5e2f4c6@oracle.com> Message-ID: On 27/04/2018 19:23, Rafael Winterhalter wrote: > Hei Alan and David, > thanks for pointing me to the issue, I have only searched the release > notes for u172 by accident. > > The issue is mainly during builds. I run my library on multiple CI > servers to cover Windows/Linux and different Java versions from 6-11. > Unfortunately, I have not full control over what version of Java is > run on these servers. Yesterday, I found some of the builds fail for > pull requests what was a bit confusing. Byte Buddy offers an > abstraction over type descriptions that implement similar semantics to > the Java reflection API when it comes to equality and to textual > (toString) representations. These tests suddenly failed since the JVMs > representation is changed, this is all. The Scala build had a similar > problem: https://github.com/scala/bug/issues/10835 > > This is not a big deal but I found it surprising to have a change in > the string representation within an update release. Especially since a > nested class does not necessarily have the same name prefix if a class > is not compiled with javac. I would have preferred the consistency > over the redundancy; especially when type names are machine-processed, > this often makes a parser easier to implement. There isn't sufficient information in the bug to understand why it was back-ported to 8u172. That said, aren't you replying on unspecified behavior? I don't think toString is specified here. -Alan From claes.redestad at oracle.com Sat Apr 28 09:30:56 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 28 Apr 2018 11:30:56 +0200 Subject: RFR: 8201650: Move iteration order randomization of unmodifiable Set and Map to iterators In-Reply-To: <3db0c565-02d4-8402-895a-03b99299cd07@oracle.com> References: <3db0c565-02d4-8402-895a-03b99299cd07@oracle.com> Message-ID: Hi Stuart, On 2018-04-28 02:37, Stuart Marks wrote: > > Hi Claes, > > I finally got a chance to look at this. Overall looks fine. Although > the randomness is "weaker" iterating in both directions will, I think, > still have the desired effect of flushing out order dependencies. thanks, glad you agree with the direction here... > I have a test (forthcoming) that verifies that iteration order will > vary from run to run, and it passes with both the old and new code. Great! > > Not an issue, but I'm curious as to why the initial index is chosen > this way: > > ??? idx = Math.floorMod(SALT ^ remaining, elements.length); > > The floorMod with a divisor of elements.length makes perfect sense. > I'm wondering why the dividend is (SALT ^ remaining) and not just SALT > for example. Right, adding " ^ remaning" was a play to see if I could increase the randomness of initial idx distribution for "free" when comparing a set of N elements with a set of N+1 elements. While it has near zero performance cost (no added loads, just a quick xor on values we load anyway), I never got around to measuring if it improved or even worsened the starting point "randomness". In the end it's not that important, so I'll just remove it. /Claes From mandy.chung at oracle.com Sat Apr 28 09:44:52 2018 From: mandy.chung at oracle.com (mandy chung) Date: Sat, 28 Apr 2018 17:44:52 +0800 Subject: Review Request JDK-8202113: Reflection API is causing caller classes to leak Message-ID: Webrev: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8202113/webrev.00/ The reflection machinery stores the caller class in each AccessibleObject such that it can skip the access check if access to a member has been verified for a given caller.? At the first time accessing the AccessibleObject, it creates an Accessor object and then cache for subsequent use.? This cached Accessor object keeps a reference to the AccessibleObject object that will keep the caller class alive. The implementation has a root object for each AccessibleObject and the API returns a child object for users to access (that may suppress access check via setAccessible). The caller class is set in the cache of the child object.? This patch proposes to change ReflectionFactory newXXXAccessor methods to ensure to pass the root object rather than the child object.? The cache of the root object is always null. Mandy From peter.levart at gmail.com Sat Apr 28 10:52:07 2018 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 28 Apr 2018 12:52:07 +0200 Subject: Review Request JDK-8202113: Reflection API is causing caller classes to leak In-Reply-To: References: Message-ID: <96071d63-e046-8392-eb89-accb362b442a@gmail.com> Hi Mandy, On 04/28/18 11:44, mandy chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8202113/webrev.00/ > > The reflection machinery stores the caller class in each AccessibleObject > such that it can skip the access check if access to a member has been > verified for a given caller.? At the first time accessing the > AccessibleObject, > it creates an Accessor object and then cache for subsequent use. This > cached > Accessor object keeps a reference to the AccessibleObject object that > will keep the caller class alive. ...because the same instance of Accessor object is also set on the root AccessibleObject in order to be shared among other child AccessibleObject instances created from it and because this root AccessibleObject is retained by the cache of AccessibleObject(s) in the declaring j.l.Class... > > The implementation has a root object for each AccessibleObject and > the API returns a child object for users to access (that may suppress > access check via setAccessible). The caller class is set in the cache > of the child object.? This patch proposes to change ReflectionFactory > newXXXAccessor methods to ensure to pass the root object rather than > the child object.? The cache of the root object is always null. ...since root AccessibleObject(s) are never used for accessing the member(s), they will never cache the caller Class and so they can be retained by the Class-level cache together with cached Accessors that now just point back to them and never to AccessibleObject(s) handed out to users that do cache caller Class. Right, this patch fixes the issue of retaining (leaking) the caller class when using AccessibleObject(s) returned from Reflection API and then throwing them away. There might be a separate issue when user-handed AccessibleObjects are cached by user code and such cache is located in a different class loader than classes that make invocations. This could only be solved with a WeakReference in the access-check cache I suppose... But this patch is good anyway, because it ensures Accessor(s) only retain root AccessibleObjects which by itself is more memory-friendly. About the tests: - There seems to be some strange ununiform formatting in AccessTest. - For public and protected members, the test looks good, but for private members, I don't think it is doing anything useful, because if access-check fails, the caller class is not cached (from AccessibleObject): ??? private boolean slowVerifyAccess(Class caller, Class memberClass, ???????????????????????????????????? Class targetClass, int modifiers) ??? { ??????? if (!Reflection.verifyMemberAccess(caller, memberClass, targetClass, modifiers)) { ??????????? // access denied ??????????? return false; ??????? } ... ... ??????? securityCheckCache = cache;???????? // write volatile ??????? return true; ??? } But for private members, there's no issue of leaking caller class(es) because the only successfully caller is the declaring class itself. > > Mandy > Regards, Peter From mandy.chung at oracle.com Sun Apr 29 08:02:47 2018 From: mandy.chung at oracle.com (mandy chung) Date: Sun, 29 Apr 2018 16:02:47 +0800 Subject: Review Request JDK-8202113: Reflection API is causing caller classes to leak In-Reply-To: <96071d63-e046-8392-eb89-accb362b442a@gmail.com> References: <96071d63-e046-8392-eb89-accb362b442a@gmail.com> Message-ID: <65f6288d-0d50-ca2d-53e4-6003f5cf19f1@oracle.com> On 4/28/18 6:52 PM, Peter Levart wrote: > Hi Mandy, > > On 04/28/18 11:44, mandy chung wrote: >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8202113/webrev.00/ >> >> The reflection machinery stores the caller class in each >> AccessibleObject >> such that it can skip the access check if access to a member has been >> verified for a given caller.? At the first time accessing the >> AccessibleObject, >> it creates an Accessor object and then cache for subsequent use.? >> This cached >> Accessor object keeps a reference to the AccessibleObject object that >> will keep the caller class alive. > > ...because the same instance of Accessor object is also set on the > root AccessibleObject in order to be shared among other child > AccessibleObject instances created from it and because this root > AccessibleObject is retained by the cache of AccessibleObject(s) in > the declaring j.l.Class... > Yes >> >> The implementation has a root object for each AccessibleObject and >> the API returns a child object for users to access (that may suppress >> access check via setAccessible). The caller class is set in the cache >> of the child object.? This patch proposes to change ReflectionFactory >> newXXXAccessor methods to ensure to pass the root object rather than >> the child object.? The cache of the root object is always null. > > ...since root AccessibleObject(s) are never used for accessing the > member(s), they will never cache the caller Class and so they can be > retained by the Class-level cache together with cached Accessors that > now? just point back to them and never to AccessibleObject(s) handed > out to users that do cache caller Class. > Exactly. > Right, this patch fixes the issue of retaining (leaking) the caller > class when using AccessibleObject(s) returned from Reflection API and > then throwing them away. > > There might be a separate issue when user-handed AccessibleObjects are > cached by user code and such cache is located in a different class > loader than classes that make invocations. This could only be solved > with a WeakReference in the access-check cache I suppose... > User code caching the AccessibleObject should be for its own use and I would think the cached caller would be itself. > But this patch is good anyway, because it ensures Accessor(s) only > retain root AccessibleObjects which by itself is more memory-friendly. > > About the tests: > > - There seems to be some strange ununiform formatting in AccessTest. > > - For public and protected members, the test looks good, but for > private members, I don't think it is doing anything useful, because if > access-check fails, the caller class is not cached (from > AccessibleObject): > Right. > private boolean slowVerifyAccess(Class caller, Class memberClass, > ???????????????????????????????????? Class targetClass, int modifiers) > ??? { > ??????? if (!Reflection.verifyMemberAccess(caller, memberClass, > targetClass, modifiers)) { > ??????????? // access denied > ??????????? return false; > ??????? } > ... > ... > ??????? securityCheckCache = cache;???????? // write volatile > ??????? return true; > ??? } > > > But for private members, there's no issue of leaking caller class(es) > because the only successfully caller is the declaring class itself. including the private method/field is solely for completeness (still partial since it does not cover the constructor).? I can add a comment to mention that it won't cache caller for such access failing case. Mandy From isaac.r.levy at gmail.com Mon Apr 30 02:24:40 2018 From: isaac.r.levy at gmail.com (Isaac Levy) Date: Sun, 29 Apr 2018 22:24:40 -0400 Subject: [PATCH] regex matcher opt: remove redundant StringBuilder In-Reply-To: <5ADFDC21.2040909@oracle.com> References: <5ADF60FA.2020109@oracle.com> <5ADFDC21.2040909@oracle.com> Message-ID: Your patch looks good to me, and will get the majority of performance benefits without any API issues. Isaac On Tue, Apr 24, 2018 at 9:38 PM, Xueming Shen wrote: > for String based replaceAll/First() it might be worth doing something like > > http://cr.openjdk.java.net/~sherman/regex_removesb/webrev/ > > > On 4/24/18, 10:47 AM, Isaac Levy wrote: >> >> Hi Sherman, >> >> Thanks for clarifying. Looks like exceptions are caused by invalid >> format string. I wouldn't expect most programs to be catching this and >> preserving their buffer, but dunno. >> >> How much does it affect perf? Well it depends on use case, a jmh of >> replaceAll with a length 200 string of digits and regex "(\w)" shows >> about 30% speedup. >> >> [info] Benchmark Mode Cnt Score Error Units >> [info] origM avgt 10 11.669 ? 0.211 us/op >> [info] newM avgt 10 8.926 ? 0.095 us/op >> >> Isaac >> >> >> On Tue, Apr 24, 2018 at 12:53 PM, Xueming Shen >> wrote: >>> >>> Hi Isaac, >>> >>> I actually meant to say "we are not supposed to output the partial text >>> into >>> the output buffer in case of an exception". It has nothing to do with the >>> changeset you cited. This has been the behavior since day one/JDK1.4, >>> though it is not specified explicitly in the API doc. The newly added >>> StringBuilder variant simply follows this behavior. If it's really >>> desired >>> it >>> is kinda doable to save that StringBuilder without the "incompatible" >>> behavior >>> change but just wonder if it is really worth the effort. >>> >>> Thanks, >>> Sherman >>> >>> >>> On 4/24/18, 9:11 AM, Isaac Levy wrote: >>>> >>>> (moving this to a separate discussion) >>>> >>>> >>>> --- a/src/java.base/share/classes/java/util/regex/Matcher.java >>>> +++ b/src/java.base/share/classes/java/util/regex/Matcher.java >>>> @@ -993,13 +993,11 @@ >>>> public Matcher appendReplacement(StringBuilder sb, String >>>> replacement) { >>>> // If no match, return error >>>> if (first< 0) >>>> throw new IllegalStateException("No match available"); >>>> - StringBuilder result = new StringBuilder(); >>>> - appendExpandedReplacement(replacement, result); >>>> // Append the intervening text >>>> sb.append(text, lastAppendPosition, first); >>>> // Append the match substitution >>>> + appendExpandedReplacement(replacement, sb); >>>> - sb.append(result); >>>> >>>> >>>> >>>> On Mon, Apr 23, 2018 at 5:05 PM Xueming Shen >>>> wrote: >>>>> >>>>> >>>>> I would assume in case of an exception thrown from >>>>> appendExpandedReplacement() we don't >>>>> want "text" to be pushed into the "sb". >>>>> >>>>> -sherman >>>> >>>> >>>> Perhaps. Though the behavior under exception is undefined and this >>>> function is probably primarily used though the replaceAll API, which >>>> wouldn?t return the intermediate sb under the case of exception. >>>> >>>> My reading of the blame was the temp StringBuilder was an artifact of >>>> the api previously using StringBuffer externally. See >>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/763c564451b3 >>> >>> > From rafael.wth at gmail.com Mon Apr 30 06:50:53 2018 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Mon, 30 Apr 2018 08:50:53 +0200 Subject: Changed behavior of ParameterizedTypeImpl::toString in 1.8.0_171 In-Reply-To: References: <45f111fd-e84a-60ed-1429-7644d5e2f4c6@oracle.com> Message-ID: Yes, of course, the behavior is not specified in this detail but the implementation has been stable what I argue makes sense due to the possibility of automatic processing by low-level tools. It is not a big problem, it just surprised me that the implementation changed and I was wondering about the motivation since I did not spot the ticket. Thanks for pointing me in the right direction. Best regards, Rafael 2018-04-28 9:51 GMT+02:00 Alan Bateman : > On 27/04/2018 19:23, Rafael Winterhalter wrote: > >> Hei Alan and David, >> thanks for pointing me to the issue, I have only searched the release >> notes for u172 by accident. >> >> The issue is mainly during builds. I run my library on multiple CI >> servers to cover Windows/Linux and different Java versions from 6-11. >> Unfortunately, I have not full control over what version of Java is run on >> these servers. Yesterday, I found some of the builds fail for pull requests >> what was a bit confusing. Byte Buddy offers an abstraction over type >> descriptions that implement similar semantics to the Java reflection API >> when it comes to equality and to textual (toString) representations. These >> tests suddenly failed since the JVMs representation is changed, this is >> all. The Scala build had a similar problem: >> https://github.com/scala/bug/issues/10835 >> >> This is not a big deal but I found it surprising to have a change in the >> string representation within an update release. Especially since a nested >> class does not necessarily have the same name prefix if a class is not >> compiled with javac. I would have preferred the consistency over the >> redundancy; especially when type names are machine-processed, this often >> makes a parser easier to implement. >> > There isn't sufficient information in the bug to understand why it was > back-ported to 8u172. That said, aren't you replying on unspecified > behavior? I don't think toString is specified here. > > -Alan > From pallavi.sonal at oracle.com Mon Apr 30 08:20:32 2018 From: pallavi.sonal at oracle.com (Pallavi Sonal) Date: Mon, 30 Apr 2018 01:20:32 -0700 (PDT) Subject: RFR: JDK-8193877- DateTimeFormatterBuilder throws ClassCastException when using padding Message-ID: <377639e7-9cb0-4cbc-b479-6b1e6b423acb@default> Hi Roger/Stephen, > The fix here seems to make padding to a fixed width incompatible with > adjacent value parsing. > That's not intuitive, since adjacent value parsing is intended to > allow more flexible parsing of a combination leading fixed-width > fields and subsequent variable length fields. > The specification of the behavior of padding vs adjacent value parsing > should be investigated and clarified if necessary. > The fix was based on the observation of existing design that whenever a leading variable/fixed length field has subsequent padded fixed length field the setup of adjacent value parsing ends as soon as padding is encountered. For ex. in the below example adjacent value parsing is used and the parser is updated to fixed width. DateTimeFormatter formatter = DateTimeFormatter.ofPattern("ddM"); formatter.parse("2012"); But in the following case adjacent value parsing mode is not set up , instead for M a new parser is used . DateTimeFormatter.ofPattern("ddppM"); Similarly, the following is successful, as adjacent value parsing is used and a subsequent width is reserved for M. DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyyMM"); formatter.parse("201812"); But, the same does not happen with padding in following example and thus parsing fails because year is parsed greedily. DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyyppMM"); formatter.parse("201812"); Also, adjacent value parsing is only for NumberPrinterParsers as per the spec which PadPrinterParserDecorator is not. Based on this, I had added this fix where if a padded field is followed by non-padded fields , the padded field is parsed using a new parser and the adjacent value parsing only happens with another parser for the consecutive non-padded fields. Should the PadPrinterDecoratorParsers be allowed to participate in adjacent value parsing and should this affect both padded followed by non-padded fields as well as non-padded followed by padded fields ? Thanks, Pallavi Sonal -----Original Message----- From: core-libs-dev-request at openjdk.java.net Sent: Wednesday, April 25, 2018 7:08 AM To: core-libs-dev at openjdk.java.net Subject: core-libs-dev Digest, Vol 132, Issue 84 Send core-libs-dev mailing list submissions to core-libs-dev at openjdk.java.net To subscribe or unsubscribe via the World Wide Web, visit http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev or, via email, send a message with subject or body 'help' to core-libs-dev-request at openjdk.java.net You can reach the person managing the list at core-libs-dev-owner at openjdk.java.net When replying, please edit your Subject line so it is more specific than "Re: Contents of core-libs-dev digest..." ---------------------------------------------------------------------- Message: 1 Date: Tue, 24 Apr 2018 23:32:51 +0100 From: Stephen Colebourne To: core-libs-dev Subject: Re: RFR: JDK-8193877- DateTimeFormatterBuilder throws ClassCastException when using padding Message-ID: Content-Type: text/plain; charset="UTF-8" To add to Roger's comments, the tests should cover parsing as well as formatting. It is the adjacent parsing behaviour that will be most important to test and get right. For example, Pattern "dMyyyy" cannot be parsed (is "1122018" the 1st Dec or the 11th Feb?) But this one should be parsed "ppdppMyyyy" (" 1122018" has fixed width day = 1 and fixed width month = 12) ("11 22018" has fixed width day =11 and fixed width month = 2) And as Roger says, this should be tested using DateTimrFormatterBuilder::padNext as well as the pattern letters. thanks Stephen On 18 April 2018 at 19:34, Roger Riggs wrote: > Hi Pallavi, > > The fix here seems to make padding to a fixed width incompatible with > adjacent value parsing. > That's not intuitive, since adjacent value parsing is intended to > allow more flexible parsing of a combination leading fixed-width > fields and subsequent variable length fields. > The specification of the behavior of padding vs adjacent value parsing > should be investigated and clarified if necessary. > > The implementation would be better expressed as checking whether the > active PrinterParser > *is* a NumberPrinterParser as a precondition for entering the adjacent > parsing mode block (and the necessary cast). > And otherwise, fall into the existing code in which the new Parser > becomes the new active parser. > > The tests should be included in the existing test classes for padding, > and be written using the direct DateTimeFormatterBuilder methods > (padNext(), instead of the > patterns) since the patterns > are just a front end for the builder methods. > See test/java/time/format/TestPadPrinterDecorator.java > > TestDateTimeFormatter.java: > > line 96: please keep the static imports for testng together > > Line 662: The odd formatting and incorrect indentation should no > longer be a problem because the indentation will not need to change. > > Regards, Roger > > > > On 4/18/18 8:41 AM, Pallavi Sonal wrote: >> >> Hi, >> >> Please review the changes to the following issue: >> >> Bug :https://bugs.openjdk.java.net/browse/JDK-8193877 >> >> The proposed fix is located at: >> >> Webrev :http://cr.openjdk.java.net/~rpatil/8193877/webrev.00/ >> >> >> When padding is used in a pattern where there are unpadded values >> adjacent to padded ones (like "pdQ") , the previous PrinterParser >> (used for parsing 'd' in the example ) is fetched to use its settings >> for parsing the next value('Q' in the example). But , in cases like >> this , it is a PadPrinterDecoratorParser instead of an assumed >> NumberPrinterParser and a ClassCastException is thrown. >> >> The fix has been done to check such cases where the previous >> parserprinter is PadPrinterDecoratorParser and use the new >> NumberPrinterParser instead for parsing the next value. >> >> >> All the tier1 and tier2 Mach 5 tests have passed. >> >> >> Thanks, >> >> Pallavi Sonal >> >> > > ------------------------------ Message: 2 Date: Tue, 24 Apr 2018 23:41:16 +0100 From: Stephen Colebourne To: core-libs-dev Subject: Re: [11] RFR: 8181157: CLDR Timezone name fallback implementation Message-ID: Content-Type: text/plain; charset="UTF-8" I had a quick look through and didn't see anything obvious, but its not an area I know well. Stephen On 17 April 2018 at 22:28, Naoto Sato wrote: > Hello, > > Please review the changes to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8181157 > > The proposed fix is located at: > > http://cr.openjdk.java.net/~naoto/8181157/webrev.05/ > > This RFE is to implement CLDR time zone names fallback mechanism [1]. > Prior to this fix, time zone names are substituted with English names. > With this change, it is generated according to the logic defined in TR > 35. Here are the highlight of the changes: > > CLDRConverter: > - CLDRConverter has changed to not substitute/invent time zone display > names, except English bundle for compatibility & runtime performance. > - For English bundle, copy over COMPAT's names as before. > - CLDRConverer now parses regionFormat/gmtZeroFormat/exemplarCity > > CLDR provider: > - CLDRTimeZoneNameProviderImpl is introduced to generate fallback > names at runtime. > - If COMPAT provider is present, use it also as a fallback, before the > last resort (GMT offset format) > > Naoto > > [1] > http://www.unicode.org/reports/tr35/tr35-dates.html#Time_Zone_Names ------------------------------ Message: 3 Date: Tue, 24 Apr 2018 17:30:34 -0700 From: joe darcy To: core-libs-dev Subject: JDK 11 RFR of 8200478: For boxing conversion javac uses Long.valueOf which does not guarantee caching according to its javadoc Message-ID: Content-Type: text/plain; charset=utf-8; format=flowed Hello, Please review the patch below to update the specification of Long.valueOf(long) to require caching on [-128, 127]. The JDK implementation of this functionality has always cached in that region, even though it is not required. Additionally, please review the corresponding CSR: ??? ??? JDK-8202231: For boxing conversion javac uses Long.valueOf which does not guarantee caching according to its javadoc Thanks, -Joe diff -r f909f09569ca src/java.base/share/classes/java/lang/Long.java --- a/src/java.base/share/classes/java/lang/Long.java??? Wed Apr 18 21:10:09 2018 -0700 +++ b/src/java.base/share/classes/java/lang/Long.java??? Tue Apr 24 17:25:24 2018 -0700 @@ -1164,10 +1164,8 @@ ????? * significantly better space and time performance by caching ????? * frequently requested values. ????? * -???? * Note that unlike the {@linkplain Integer#valueOf(int) -???? * corresponding method} in the {@code Integer} class, this method -???? * is not required to cache values within a particular -???? * range. +???? * This method will always cache values in the range -128 to 127, +???? * inclusive, and may cache other values outside of this range. ????? * ????? * @param? l a long value. ????? * @return a {@code Long} instance representing {@code l}. ------------------------------ Message: 4 Date: Tue, 24 Apr 2018 17:41:33 -0700 From: Brian Burkhalter To: joe darcy Cc: core-libs-dev Subject: Re: JDK 11 RFR of 8200478: For boxing conversion javac uses Long.valueOf which does not guarantee caching according to its javadoc Message-ID: <10B34EE4-9BF5-4319-81BE-60FA69257D7D at oracle.com> Content-Type: text/plain; charset=us-ascii Hi Joe, On Apr 24, 2018, at 5:30 PM, joe darcy wrote: > Please review the patch below to update the specification of Long.valueOf(long) to require caching on [-128, 127]. The JDK implementation of this functionality has always cached in that region, even though it is not required. Looks fine. > Additionally, please review the corresponding CSR: > > JDK-8202231: For boxing conversion javac uses Long.valueOf > which does not guarantee caching according to its javadoc Done. Brian ------------------------------ Message: 5 Date: Tue, 24 Apr 2018 17:53:11 -0700 From: Jonathan Gibbons To: mandy chung Cc: compiler-dev , build-dev , core-libs-dev Subject: Re: RFR: 8201274: Launch Single-File Source-Code Programs Message-ID: <5ADFD177.7050600 at oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed On 04/12/2018 10:20 PM, mandy chung wrote: > > > On 4/13/18 4:15 AM, Jonathan Gibbons wrote: >> Please review an initial implementation for the feature described in >> JEP 330: Launch Single-File Source-Code Programs. >> >> The work is described in the JEP and CSR, and falls into various parts: >> >> * The part to handle the new command-line options is in the native >> Java launcher code. >> * The part to invoke the compiler and subsequently execute the code >> found in the source file is in a new class in the jdk.compiler >> module. >> * There are some minor Makefile changes, to add support for a new >> resource file. >> >> There are no changes to javac itself. >> >> JEP: http://openjdk.java.net/jeps/330 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 >> Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ > > This looks quite good to me. One small comment on the source launcher > Main class: > > 122 } catch (InvocationTargetException e) { > 123 // leave VM to handle the stacktrace, in the standard manner > 124 throw e.getTargetException(); > 125 } > 387 } catch (InvocationTargetException e) { > 388 // remove stack frames for source launcher > 389 int invocationFrames = e.getStackTrace().length; > 390 Throwable target = e.getTargetException(); > 391 StackTraceElement[] targetTrace = target.getStackTrace(); > 392 target.setStackTrace(Arrays.copyOfRange(targetTrace, 0, targetTrace.length - invocationFrames)); > 393 throw e; > 394 } > > This could simply throw target instead of the > InvocationTargetException and then the main method can propagate the target, if thrown. > > Mandy Mandy, Yes, but that would require the execute method and its callers to declare that they throw Throwable, or at least Exception. Since the exception is already wrapped, it seems better to propagate the wrapped exception, and to only unwrap it at the last moment. -- Jon ------------------------------ Message: 6 Date: Wed, 25 Apr 2018 09:33:51 +0800 From: Leo Jiang To: "i18n-dev at openjdk.java.net" , "'core-libs-dev'" Subject: [11] RFR: 8202026 8193552 : ISO 4217 Amendment #165 # 166 Update Message-ID: <5d50ddec-884c-e78c-4c2c-b9e11d8c3236 at oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed Hi, Please review the changes to address the ISO 4217 Amendment 165 166 update. Bug: https://bugs.openjdk.java.net/browse/JDK-8193552 165 https://bugs.openjdk.java.net/browse/JDK-8202026 166 CR: http://cr.openjdk.java.net/~ljiang/8202026/webrev.00/ Detail: #165 From: MAURITANIA Ouguiya MRO 478 2 To: MAURITANIA Ouguiya MRU 929 2 #166 From: VENEZUELA (BOLIVARIAN REPUBLIC OF) Bol?var VEF 937 2 To: VENEZUELA (BOLIVARIAN REPUBLIC OF) Bol?var Soberano VES 928 2 Thanks, Leo End of core-libs-dev Digest, Vol 132, Issue 84 ********************************************** From bhamaram at in.ibm.com Mon Apr 30 09:29:00 2018 From: bhamaram at in.ibm.com (Bhaktavatsal R Maram) Date: Mon, 30 Apr 2018 09:29:00 +0000 Subject: RFR(XS): 8202329 [AIX] Fix codepage mappings for IBM-943 and Big5 In-Reply-To: References: , , Message-ID: Hi All, Please review the fix. bug: https://bugs.openjdk.java.net/browse/JDK-8202329 webrev: http://cr.openjdk.java.net/~aleonard/8202329/webrev.00/ Thanks, Bhaktavatsal Reddy -----"core-libs-dev" wrote: ----- To: Volker Simonis From: "Bhaktavatsal R Maram" Sent by: "core-libs-dev" Date: 04/26/2018 09:31PM Cc: Java Core Libs Subject: Re: [AIX] Fix codepage mappings in Java for IBM-943 and Big5 Hi Volker, Thank you. I will address your review comments and send webrev for review. - Bhaktavatsal Reddy -----Volker Simonis wrote: ----- To: Bhaktavatsal R Maram From: Volker Simonis Date: 04/26/2018 09:12PM Cc: Java Core Libs Subject: Re: [AIX] Fix codepage mappings in Java for IBM-943 and Big5 Hi Bhaktavatsal Reddy, I've opened the following issue for this problem: 8202329: [AIX] Fix codepage mappings for IBM-943 and Big5 https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8202329&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=iQCg2Acve4LeG-Zymt7gpXuSgJLFbCFHsSVHCETqGt8&s=3KL9rSzXZgjLGz-ayIEaq94QK5rTY0PlEgewOjarNPE&e= Looking at you fix, can you please replace the "#elif AIX" by "#ifdef AIX" and the original "#else" by "#ifdef __solaris__". The original else branch contains Solaris-only code anyway and it is an historical omission that there are still a lot of places in the code where "not Linux" implicitly means "Solaris", but that's often wrong. Regards, Volker On Thu, Apr 26, 2018 at 4:02 PM, Bhaktavatsal R Maram wrote: > Oops! Looks like there is problem with attachment (might be because I attached .class file as well). I'm pasting the fix and test program here in mail. > > Test Program: > > import java.nio.charset.*; > class PrintDefaultCharset { > public static void main(String[] args) { > System.out.println("LANG = "+System.getenv("LANG")); > System.out.println("Default charset = "+Charset.defaultCharset().name()); > System.out.println("file.encoding = "+System.getProperty("file.encoding")); > System.out.println("sun.jnu.encoding = "+System.getProperty("sun.jnu.encoding")); > } > } > > > Fix: > > diff --git a/src/java.base/unix/native/libjava/java_props_md.c b/src/java.base/unix/native/libjava/java_props_md.c > --- a/src/java.base/unix/native/libjava/java_props_md.c > +++ b/src/java.base/unix/native/libjava/java_props_md.c > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1998, 2016, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1998, 2018, 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 > @@ -297,6 +297,18 @@ > if (strcmp(p, "EUC-JP") == 0) { > *std_encoding = "EUC-JP-LINUX"; > } > +#elif defined _AIX > + if (strcmp(p, "big5") == 0) { > + /* On AIX Traditional Chinese Big5 codeset is mapped to IBM-950 */ > + *std_encoding = "IBM-950"; > + } else if (strcmp(p, "IBM-943") == 0) { > + /* > + * On AIX, IBM-943 is mapped to IBM-943C in which symbol 'yen' and > + * 'overline' are replaced with 'backslash' and 'tilde' from ASCII > + * making first 96 code points same as ASCII. > + */ > + *std_encoding = "IBM-943C"; > + } > #else > if (strcmp(p,"eucJP") == 0) { > /* For Solaris use customized vendor defined character > > > Thanks, > Bhaktavatsal Reddy > > > -----"core-libs-dev" wrote: ----- > To: "Java Core Libs" > From: "Bhaktavatsal R Maram" > Sent by: "core-libs-dev" > Date: 04/26/2018 07:26PM > Subject: [AIX] Fix codepage mappings in Java for IBM-943 and Big5 > > Hi All, > > This issue is continuation to bug 8201540 (Extend the set of supported charsets in java.base on AIX) in which we have moved default charsets of most of the locales supported by Operating System to java.base module thus enabling OpenJDK on those locales for AIX platform. > > As part of that, charsets for locales Ja_JP (IBM-943) and Zh_TW (big5) also have been moved. However, corresponding charsets mapped in Java is not correct for them on AIX. Following are the details: > > 1. IBM-943 [1] for locale Ja_JP should be mapped to IBM-943C [2] > > Fundamental difference between IBM-943 and IBM-943C is that IBM-943C is ASCII compatible which means code points 'yen' and 'overline' of IBM-943 is replaced with 'backslash' and 'tilde' from ASCII character set. > > > 2. Big5 for locale Zh_TW should be mapped to IBM-950 [3] > > I've attached simple test program to print the default charset along with fix for this issue. When run test program (PrintDefaultCharset) with IBM JDK 8 (on AIX) for locales Ja_JP & Zh_TW, following is output. > > -bash-4.4$ LANG=Ja_JP ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset > LANG = Ja_JP > Default charset = x-IBM943C > file.encoding = IBM-943C > sun.jnu.encoding = IBM-943C > > -bash-4.4$ LANG=Zh_TW ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset > LANG = Zh_TW > Default charset = x-IBM950 > file.encoding = IBM-950 > sun.jnu.encoding = IBM-950 > > > Same test run with openJDK 11 gives following output > > -bash-4.4$ LANG=Ja_JP ~/jdk/bin/java PrintDefaultCharset > LANG = Ja_JP > Default charset = x-IBM943 > file.encoding = IBM-943 > sun.jnu.encoding = IBM-943 > > -bash-4.4$ LANG=Zh_TW ~/jdk/bin/java PrintDefaultCharset > LANG = Zh_TW > Default charset = Big5 > file.encoding = big5 > sun.jnu.encoding = big5 > > I will get webrev hosted in https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=Prdd2GWj8c4aCa1qPr65xklNyDyu64w_6X7qkNaI-D8&s=8C1bILMg6JLJtbL0KLRPfU0MkIPkAmq_IlJgdTfpjdI&e= for this change and send it for review once JIRA bug is created. > > [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__demo.icu-2Dproject.org_icu-2Dbin_convexp-3Fconv-3Dibm-2D943-5FP130-2D1999-26s-3DJAVA&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=Prdd2GWj8c4aCa1qPr65xklNyDyu64w_6X7qkNaI-D8&s=RJOiyJTR1jkgxxnRZu5JL97irAnHo1M4wMp7x21dgvs&e= > [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__demo.icu-2Dproject.org_icu-2Dbin_convexp-3Fconv-3Dibm-2D943-5FP15A-2D2003-26s-3DALL&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=Prdd2GWj8c4aCa1qPr65xklNyDyu64w_6X7qkNaI-D8&s=gXshfq2f9yed1iEYTdt57Lk0vvHXztqgUzOLQ64h8Vo&e= > [3] https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.nlsgdrf/big5.htm > > > Thanks, > Bhaktavatsal Reddy > > > > From Alan.Bateman at oracle.com Mon Apr 30 11:39:29 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 30 Apr 2018 12:39:29 +0100 Subject: Review Request JDK-8202113: Reflection API is causing caller classes to leak In-Reply-To: References: Message-ID: On 28/04/2018 10:44, mandy chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8202113/webrev.00/ > > The reflection machinery stores the caller class in each AccessibleObject > such that it can skip the access check if access to a member has been > verified for a given caller.? At the first time accessing the > AccessibleObject, > it creates an Accessor object and then cache for subsequent use. This > cached > Accessor object keeps a reference to the AccessibleObject object that > will keep the caller class alive. > > The implementation has a root object for each AccessibleObject and > the API returns a child object for users to access (that may suppress > access check via setAccessible). The caller class is set in the cache > of the child object.? This patch proposes to change ReflectionFactory > newXXXAccessor methods to ensure to pass the root object rather than > the child object.? The cache of the root object is always null. The approach looks good, seems like this one was lurking (for protected members at least) for a long time. The 3 x getRoot methods on ReflectAccess looks okay. An alternative would to create T getRoot(T obj) and a package private getRoot() method on AccessibleObject. You might want to check AccessTest before pushing. The webrev shows very odd alignment, maybe tabs expanded to 8 space indent although it's not consistently so. -Alan From claes.redestad at oracle.com Mon Apr 30 12:25:03 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 30 Apr 2018 14:25:03 +0200 Subject: RFR: 8202419: Avoid creating Permission constants early Message-ID: <85f31369-ba35-5d60-0d8c-cca0a3fd9598@oracle.com> Hi, moving a couple of local permission constants to sun.security.util.SecurityConstants ensures we delay and avoid loading permission classes very early during bootstrap. Delaying load is profitable since it's happening early enough (before System.initPhase1) to contribute to delaying the initialization of VM subsystems. Webrev: http://cr.openjdk.java.net/~redestad/8202419/open.00/ Thanks! /Claes From Alan.Bateman at oracle.com Mon Apr 30 12:47:41 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 30 Apr 2018 13:47:41 +0100 Subject: RFR: 8202419: Avoid creating Permission constants early In-Reply-To: <85f31369-ba35-5d60-0d8c-cca0a3fd9598@oracle.com> References: <85f31369-ba35-5d60-0d8c-cca0a3fd9598@oracle.com> Message-ID: <3e19a15e-d2e5-c734-3b54-504d2333a44f@oracle.com> On 30/04/2018 13:25, Claes Redestad wrote: > Hi, > > moving a couple of local permission constants to > sun.security.util.SecurityConstants ensures we delay and avoid loading > permission classes very early during bootstrap. Delaying load is > profitable since it's happening early enough (before > System.initPhase1) to contribute to delaying the initialization of VM > subsystems. > > Webrev: http://cr.openjdk.java.net/~redestad/8202419/open.00/ This looks okay to me. Just a few nits - the comment from AccessibleObject has moved to SecurityConstants. I think it would be better to leave the comment in AccessibleObject, then you can just comment the SecurityConstants update with the class name so that it's consistent with the other constants. Also this class uses 4-space indent so best to keep that consistent too. -Alan From claes.redestad at oracle.com Mon Apr 30 12:49:53 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 30 Apr 2018 14:49:53 +0200 Subject: RRF: 8187123: (reflect) Class#getCanonicalName and Class#getSimpleName is a part of performance issue Message-ID: <6549f667-7e1f-f5ba-937d-d05e243f7d3f@oracle.com> Hi, please review this patch to enable caching of getCanonicalName and getSimpleName, repeated calls of which has been reported to be a performance bottleneck. The caching improves performance of these methods by up to 20x. Rather than adding new fields to Class itself, which would have footprint implications on classes, we can piggy-back on Class$ReflectionData object. Webrev: http://cr.openjdk.java.net/~redestad/8187123/open.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8187123 Thanks! /Claes From claes.redestad at oracle.com Mon Apr 30 12:58:29 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 30 Apr 2018 14:58:29 +0200 Subject: RFR: 8202419: Avoid creating Permission constants early In-Reply-To: <3e19a15e-d2e5-c734-3b54-504d2333a44f@oracle.com> References: <85f31369-ba35-5d60-0d8c-cca0a3fd9598@oracle.com> <3e19a15e-d2e5-c734-3b54-504d2333a44f@oracle.com> Message-ID: On 2018-04-30 14:47, Alan Bateman wrote: > This looks okay to me. Thanks! > > Just a few nits - the comment from AccessibleObject has moved to > SecurityConstants. I think it would be better to leave the comment in > AccessibleObject, then you can just comment the SecurityConstants > update with the class name so that it's consistent with the other > constants. Also this class uses 4-space indent so best to keep that > consistent too. http://cr.openjdk.java.net/~redestad/8202419/open.01/ ? /Claes From sean.mullan at oracle.com Mon Apr 30 13:05:26 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 30 Apr 2018 09:05:26 -0400 Subject: RFR: 8202419: Avoid creating Permission constants early In-Reply-To: <85f31369-ba35-5d60-0d8c-cca0a3fd9598@oracle.com> References: <85f31369-ba35-5d60-0d8c-cca0a3fd9598@oracle.com> Message-ID: <523d1159-ecc9-42ee-bea9-cca7629a549a@oracle.com> Looks fine to me. I think the TO DO comment on line 131 of ReflectionFactory can be removed - it looks like a leftover comment which doesn't seem relevant anymore. --Sean On 4/30/18 8:25 AM, Claes Redestad wrote: > Hi, > > moving a couple of local permission constants to > sun.security.util.SecurityConstants ensures we delay and avoid loading > permission classes very early during bootstrap. Delaying load is > profitable since it's happening early enough (before System.initPhase1) > to contribute to delaying the initialization of VM subsystems. > > Webrev: http://cr.openjdk.java.net/~redestad/8202419/open.00/ > > Thanks! > > /Claes From claes.redestad at oracle.com Mon Apr 30 13:11:08 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 30 Apr 2018 15:11:08 +0200 Subject: RFR: 8202419: Avoid creating Permission constants early In-Reply-To: <523d1159-ecc9-42ee-bea9-cca7629a549a@oracle.com> References: <85f31369-ba35-5d60-0d8c-cca0a3fd9598@oracle.com> <523d1159-ecc9-42ee-bea9-cca7629a549a@oracle.com> Message-ID: <6e15e3c0-d4ce-9fb0-a23b-2a19ce8361fa@oracle.com> On 2018-04-30 15:05, Sean Mullan wrote: > Looks fine to me. Thanks! > I think the TO DO comment on line 131 of ReflectionFactory can be > removed - it looks like a leftover comment which doesn't seem relevant > anymore. Sure /Claes From scolebourne at joda.org Mon Apr 30 14:38:05 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 30 Apr 2018 15:38:05 +0100 Subject: RFR: JDK-8193877- DateTimeFormatterBuilder throws ClassCastException when using padding In-Reply-To: <377639e7-9cb0-4cbc-b479-6b1e6b423acb@default> References: <377639e7-9cb0-4cbc-b479-6b1e6b423acb@default> Message-ID: On 30 April 2018 at 09:20, Pallavi Sonal wrote: > Should the PadPrinterDecoratorParsers be allowed to participate in adjacent value parsing and should this affect both padded followed by non-padded fields as well as non-padded followed by padded fields ? Since JSR-310 was first included, there have been efforts to expand the scope of adjacent value parsing, simply because it is useful to people. This seems like another case where adjacent value parsing would be useful. Stephen From martinrb at google.com Mon Apr 30 16:05:26 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 30 Apr 2018 09:05:26 -0700 Subject: RFR: Here are some easy patches Message-ID: Off by one pixel! 8202397: Typo in X-Buffer javadoc http://cr.openjdk.java.net/~martin/webrevs/jdk/X-Buffer-typo/ https://bugs.openjdk.java.net/browse/JDK-8202397 Fixes a long-term micro-embarrassment: 8201634: Random seedUniquifier uses incorrect LCG http://cr.openjdk.java.net/~martin/webrevs/jdk/Random-Ecuyer/ https://bugs.openjdk.java.net/browse/JDK-8201634 An obvious optimization: 8202398: Optimize Arrays.deepHashCode http://cr.openjdk.java.net/~martin/webrevs/jdk/deepHashCode-optimize/ https://bugs.openjdk.java.net/browse/JDK-8202398 From mandy.chung at oracle.com Mon Apr 30 16:29:20 2018 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 1 May 2018 00:29:20 +0800 Subject: Review Request JDK-8202113: Reflection API is causing caller classes to leak In-Reply-To: References: Message-ID: On 4/30/18 7:39 PM, Alan Bateman wrote: > > The approach looks good, seems like this one was lurking (for > protected members at least) for a long time. Yes and this issue becomes more noticeable in JDK 9 as public members needs additional module access check. > > The 3 x getRoot methods on ReflectAccess looks okay. An alternative > would to create T getRoot(T obj) and a > package private getRoot() method on AccessibleObject. > Good idea.? I updated the patch. > You might want to check AccessTest before pushing. The webrev shows > very odd alignment, maybe tabs expanded to 8 space indent although > it's not consistently so. Thanks for catching it.? I reformatted it. I also included a comment in AccessTest to mention that private member is not accessible and caller class is not cached in that case. Updated webrev: ? http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8202113/webrev.01 thanks Mandy From mandy.chung at oracle.com Mon Apr 30 16:34:26 2018 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 1 May 2018 00:34:26 +0800 Subject: RFR: 8202419: Avoid creating Permission constants early In-Reply-To: <85f31369-ba35-5d60-0d8c-cca0a3fd9598@oracle.com> References: <85f31369-ba35-5d60-0d8c-cca0a3fd9598@oracle.com> Message-ID: On 4/30/18 8:25 PM, Claes Redestad wrote: > Hi, > > moving a couple of local permission constants to > sun.security.util.SecurityConstants ensures we delay and avoid loading > permission classes very early during bootstrap. Delaying load is > profitable since it's happening early enough (before > System.initPhase1) to contribute to delaying the initialization of VM > subsystems. > > Webrev: http://cr.openjdk.java.net/~redestad/8202419/open.00/ Looks okay to me. I agree with Alan and Sean w.r.t. to the comment in ACCESS_PERMISSION that would be better to keep it in AccessibleObject::checkPermission and remove line 131 in ReflectionFactory. Mandy From huizhe.wang at oracle.com Mon Apr 30 16:58:44 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 30 Apr 2018 09:58:44 -0700 Subject: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file In-Reply-To: References: <5AE2AC03.9000705@oracle.com> Message-ID: <0ad5d7de-94ca-44e0-44ba-c8b62d54f685@oracle.com> Hi Hamlin, Thanks for reviewing the test! Fixed now, by calling deleteOnExit. Indeed, I didn't realize I got a few empty tmp files :-) Best, Joe On 4/28/2018 12:35 AM, Hamlin Li wrote: > Hi Joe, > > just a minor comment about the test in ReadWriteString.java. > > For both testMalformedWrite and testMalformedRead, temp files are not > deleted, as Files.deleteIfExists(path); is skipped by the expected > IOException. File.deleteOnExit?() may help. > > Thank you > > -Hamlin > > > On 27/04/2018 12:50 PM, Joe Wang wrote: >> Hi, >> >> We're looking into adding methods to Files to read a file into a >> String/write a String to a file. Below is the current proposal. >> Please review. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8201276 >> >> webrev: http://cr.openjdk.java.net/~joehw/jdk11/8201276/webrev/ >> >> specdiff: >> http://cr.openjdk.java.net/~joehw/jdk11/8201276/specdiff/java/nio/file/Files.html >> >> >> Thanks, >> Joe > From Alan.Bateman at oracle.com Mon Apr 30 17:21:59 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 30 Apr 2018 18:21:59 +0100 Subject: Review Request JDK-8202113: Reflection API is causing caller classes to leak In-Reply-To: References: Message-ID: <7b1401b1-9057-58c3-81ea-b7a2aea148bf@oracle.com> On 30/04/2018 17:29, mandy chung wrote: > : > >> >> The 3 x getRoot methods on ReflectAccess looks okay. An alternative >> would to create T getRoot(T obj) and a >> package private getRoot() method on AccessibleObject. >> > > Good idea.? I updated the patch. The updated webrev looks good. A minor comment is that I assume you can remove the cast from Executable::declaredAnnotations if you leave Executable::getRoot in place. -Alan From paul.sandoz at oracle.com Mon Apr 30 17:35:02 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 30 Apr 2018 10:35:02 -0700 Subject: RFR: Here are some easy patches In-Reply-To: References: Message-ID: <2B23A83D-94AA-4DC0-8001-D647D63900DF@oracle.com> > On Apr 30, 2018, at 9:05 AM, Martin Buchholz wrote: > > Off by one pixel! > > 8202397: Typo in X-Buffer javadoc > http://cr.openjdk.java.net/~martin/webrevs/jdk/X-Buffer-typo/ > https://bugs.openjdk.java.net/browse/JDK-8202397 > +1 > Fixes a long-term micro-embarrassment: > > 8201634: Random seedUniquifier uses incorrect LCG > http://cr.openjdk.java.net/~martin/webrevs/jdk/Random-Ecuyer/ > https://bugs.openjdk.java.net/browse/JDK-8201634 > Finally! that should put to rest any numerology on the matter :-) > An obvious optimization: > > 8202398: Optimize Arrays.deepHashCode > http://cr.openjdk.java.net/~martin/webrevs/jdk/deepHashCode-optimize/ > https://bugs.openjdk.java.net/browse/JDK-8202398 > I would prefer that the deeply nested ternary expressions be changed to a more expected if/else if/else, and the last else throws an InternalError(?Should not reach here?) with some such message if you really want to express the case of an undetected array type. ? For performance i suppose we could, when value types arrive, special case arrays of values, where the component value type has no references (direct or indirect) if that is even possible to efficiently detect i.e. a value type that is like a primitive. (Note, at the moment in the Valhalla L-world proposal arrays of values are subtypes of Object[]). Paul. From martinrb at google.com Mon Apr 30 18:18:18 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 30 Apr 2018 11:18:18 -0700 Subject: RFR: Here are some easy patches In-Reply-To: <2B23A83D-94AA-4DC0-8001-D647D63900DF@oracle.com> References: <2B23A83D-94AA-4DC0-8001-D647D63900DF@oracle.com> Message-ID: On Mon, Apr 30, 2018 at 10:35 AM, Paul Sandoz wrote: > An obvious optimization: > > 8202398: Optimize Arrays.deepHashCode > http://cr.openjdk.java.net/~martin/webrevs/jdk/deepHashCode-optimize/ > https://bugs.openjdk.java.net/browse/JDK-8202398 > > I would prefer that the deeply nested ternary expressions be changed to a > more expected if/else if/else > My brain much prefers code transforming tabular data to "look tabular". > , and the last else throws an InternalError(?Should not reach here?) with > some such message if you really want to express the case of an undetected > array type. > I'd hope valhalla engineers will catch it before anyone else. In fact, perhaps it's not too early to add a test as part of the valhalla project now? From paul.sandoz at oracle.com Mon Apr 30 18:47:06 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 30 Apr 2018 11:47:06 -0700 Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <5ccdb071-16cf-3744-3941-ddc45d07115a@oracle.com> References: <5AE2AC3C.4040902@oracle.com> <5ccdb071-16cf-3744-3941-ddc45d07115a@oracle.com> Message-ID: <6648FDC1-A3E0-4E6B-AA24-226550D56F66@oracle.com> > On Apr 27, 2018, at 4:30 AM, Alan Bateman wrote: > > On 27/04/2018 05:51, Joe Wang wrote: >> Hi, >> >> Considering extending isSameFile to add isSameContent to Files. Please review. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 >> >> webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/ >> >> specdiff: http://cr.openjdk.java.net/~joehw/jdk11/8202285/specdiff/java/nio/file/Files.html > I assume we should ignore the implementation for now as the eventual implementation won't use readAllBytes (at least not for for large files). > Yes, as long as we don?t forget to follow up on a replacement (using memory mapped files say). > The existing isSameFile is specified as "Tests if two paths locate the same file" and it would be good if the new method could be somewhat consistent with that, e.g. "Tests if the content of two files is identical". > > Specifying that two path that locate the same file always returns true is reasonable. This could be make clearer by say that the returning always returns true when path and path2 are equals, if event if the file does not exist. > > The @return should say that it returns true if path and path2 locate the same file or the content of both files is identical. > > The javadoc for SecurityException has "to the file", I assume this should be "to both files?. > We might also want to say the contents of the two files are assumed to be held constant during the operation. ? It?s tempting (well to me at least) to generalize to a mismatch method (like for arrays) returning the mismatching location in bytes, then you can determine if one file is a prefix of another given the files sizes. Bound accepting methods would also be useful to mismatch on partial content (including within the same file). If you use memory mapped files we can use direct byte buffers to efficiently perform the mismatch. To Remi?s point this might dissuade/guide developers from using this method when there are other more efficient techniques available when operating at larger scales. However, it is unfortunately harder that it should be in Java to hash the contents of a file, a byte[] or ByteBuffer, according to some chosen algorithm (or a good default). Paul. From paul.sandoz at oracle.com Mon Apr 30 21:03:29 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 30 Apr 2018 14:03:29 -0700 Subject: RFR: Here are some easy patches In-Reply-To: References: <2B23A83D-94AA-4DC0-8001-D647D63900DF@oracle.com> Message-ID: <113EAB32-D02F-46A5-A484-25FE9BF80356@oracle.com> > On Apr 30, 2018, at 11:18 AM, Martin Buchholz wrote: > > > > On Mon, Apr 30, 2018 at 10:35 AM, Paul Sandoz > wrote: >> An obvious optimization: >> >> 8202398: Optimize Arrays.deepHashCode >> http://cr.openjdk.java.net/~martin/webrevs/jdk/deepHashCode-optimize/ >> https://bugs.openjdk.java.net/browse/JDK-8202398 >> > > I would prefer that the deeply nested ternary expressions be changed to a more expected if/else if/else > > My brain much prefers code transforming tabular data to "look tabular". > I think you will like expression switch :-) in the interim i would stick with the less eyebrow raising syntax. > , and the last else throws an InternalError(?Should not reach here?) with some such message if you really want to express the case of an undetected array type. > > I'd hope valhalla engineers will catch it before anyone else. In fact, perhaps it's not too early to add a test as part of the valhalla project now? I believe in principle it should just work (assuming hash code support for values themselves) because an array of values is currently a subtype of Object[]. At some point we do need to investigate the L-world with tests for values and arrays/collections of, that will help test functionality but also expose issues around nulls. The 166 TCK might be a good place to start. Paul. From paul.sandoz at oracle.com Mon Apr 30 21:28:18 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 30 Apr 2018 14:28:18 -0700 Subject: RRF: 8187123: (reflect) Class#getCanonicalName and Class#getSimpleName is a part of performance issue In-Reply-To: <6549f667-7e1f-f5ba-937d-d05e243f7d3f@oracle.com> References: <6549f667-7e1f-f5ba-937d-d05e243f7d3f@oracle.com> Message-ID: Looks good. ? I am not quite 100% sure but you could probably replace the null sentinel value with ?/? or opportunistically ?[]?, but i cannot quite tell what exactly is an invalid binary name. Anyway that is not important. Paul. > On Apr 30, 2018, at 5:49 AM, Claes Redestad wrote: > > Hi, > > please review this patch to enable caching of getCanonicalName and getSimpleName, repeated calls of which has been reported to be a performance > bottleneck. The caching improves performance of these methods by up to 20x. > > Rather than adding new fields to Class itself, which would have footprint implications on classes, we can piggy-back on Class$ReflectionData object. > > Webrev: http://cr.openjdk.java.net/~redestad/8187123/open.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8187123 > > Thanks! > > /Claes > > From david.holmes at oracle.com Mon Apr 30 21:50:28 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 May 2018 07:50:28 +1000 Subject: RRF: 8187123: (reflect) Class#getCanonicalName and Class#getSimpleName is a part of performance issue In-Reply-To: <6549f667-7e1f-f5ba-937d-d05e243f7d3f@oracle.com> References: <6549f667-7e1f-f5ba-937d-d05e243f7d3f@oracle.com> Message-ID: <1e58f09d-6dff-90a3-341d-7818f9d82cc0@oracle.com> Hi Claes, On 30/04/2018 10:49 PM, Claes Redestad wrote: > Hi, > > please review this patch to enable caching of getCanonicalName and > getSimpleName, repeated calls of which has been reported to be a > performance > bottleneck. The caching improves performance of these methods by up to 20x. > > Rather than adding new fields to Class itself, which would have > footprint implications on classes, we can piggy-back on > Class$ReflectionData object. > > Webrev: http://cr.openjdk.java.net/~redestad/8187123/open.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8187123 Given String's are immune to unsafe publication races, you should be able to drop the volatile modifiers. That might save a few more cycles. Cheers, David > Thanks! > > /Claes > > From forax at univ-mlv.fr Mon Apr 30 22:23:17 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 1 May 2018 00:23:17 +0200 (CEST) Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <6648FDC1-A3E0-4E6B-AA24-226550D56F66@oracle.com> References: <5AE2AC3C.4040902@oracle.com> <5ccdb071-16cf-3744-3941-ddc45d07115a@oracle.com> <6648FDC1-A3E0-4E6B-AA24-226550D56F66@oracle.com> Message-ID: <1616266894.329304.1525126997632.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Paul Sandoz" > ?: "Alan Bateman" > Cc: "nio-dev" , "core-libs-dev" > Envoy?: Lundi 30 Avril 2018 20:47:06 > Objet: Re: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents >> On Apr 27, 2018, at 4:30 AM, Alan Bateman wrote: >> >> On 27/04/2018 05:51, Joe Wang wrote: >>> Hi, >>> >>> Considering extending isSameFile to add isSameContent to Files. Please review. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 >>> >>> webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/ >>> >>> specdiff: >>> http://cr.openjdk.java.net/~joehw/jdk11/8202285/specdiff/java/nio/file/Files.html >> I assume we should ignore the implementation for now as the eventual >> implementation won't use readAllBytes (at least not for for large files). >> > > Yes, as long as we don?t forget to follow up on a replacement (using memory > mapped files say). > > >> The existing isSameFile is specified as "Tests if two paths locate the same >> file" and it would be good if the new method could be somewhat consistent with >> that, e.g. "Tests if the content of two files is identical". >> >> Specifying that two path that locate the same file always returns true is >> reasonable. This could be make clearer by say that the returning always returns >> true when path and path2 are equals, if event if the file does not exist. >> >> The @return should say that it returns true if path and path2 locate the same >> file or the content of both files is identical. >> >> The javadoc for SecurityException has "to the file", I assume this should be "to >> both files?. >> > > We might also want to say the contents of the two files are assumed to be held > constant during the operation. > > ? > > It?s tempting (well to me at least) to generalize to a mismatch method (like for > arrays) returning the mismatching location in bytes, then you can determine if > one file is a prefix of another given the files sizes. Bound accepting methods > would also be useful to mismatch on partial content (including within the same > file). If you use memory mapped files we can use direct byte buffers to > efficiently perform the mismatch. I'm not sure memory mapping is a good idea, Windows is notoriously bad at memory mapping small files and if the files are big, see you own comment below. But an implementation that reads byte buffers and compare them will be more efficient. > > To Remi?s point this might dissuade/guide developers from using this method when > there are other more efficient techniques available when operating at larger > scales. However, it is unfortunately harder that it should be in Java to hash > the contents of a file, a byte[] or ByteBuffer, according to some chosen > algorithm (or a good default). it's 6 lines of code var digest = MessageDigest.getInstance("SHA1"); try(var input = Files.newInputStream(Path.of("myfile.txt")); var output = new DigestOutputStream(OutputStream.nullOutputStream(), digest)) { input.transferTo(output); } var hash = digest.digest(); or 3 lines if you don't mind to load the whole file in memory var digest = MessageDigest.getInstance("SHA1"); digest.update(Files.readAllBytes(Path.of("myfile.txt"))); var hash = digest.digest(); > > Paul. R?mi From paul.sandoz at oracle.com Mon Apr 30 22:37:57 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 30 Apr 2018 15:37:57 -0700 Subject: Hashing files/bytes Re: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <1616266894.329304.1525126997632.JavaMail.zimbra@u-pem.fr> References: <5AE2AC3C.4040902@oracle.com> <5ccdb071-16cf-3744-3941-ddc45d07115a@oracle.com> <6648FDC1-A3E0-4E6B-AA24-226550D56F66@oracle.com> <1616266894.329304.1525126997632.JavaMail.zimbra@u-pem.fr> Message-ID: Thanks, better then i expected with the transferTo method we recently added, but i think we could do even better for the ease of use case of ?give me the hash of this file contents or these bytes or this byte buffer". Paul. > On Apr 30, 2018, at 3:23 PM, Remi Forax wrote: > >> >> To Remi?s point this might dissuade/guide developers from using this method when >> there are other more efficient techniques available when operating at larger >> scales. However, it is unfortunately harder that it should be in Java to hash >> the contents of a file, a byte[] or ByteBuffer, according to some chosen >> algorithm (or a good default). > > it's 6 lines of code > > var digest = MessageDigest.getInstance("SHA1"); > try(var input = Files.newInputStream(Path.of("myfile.txt")); > var output = new DigestOutputStream(OutputStream.nullOutputStream(), digest)) { > input.transferTo(output); > } > var hash = digest.digest(); > > or 3 lines if you don't mind to load the whole file in memory > > var digest = MessageDigest.getInstance("SHA1"); > digest.update(Files.readAllBytes(Path.of("myfile.txt"))); > var hash = digest.digest(); > >> >> Paul. > > R?mi From huizhe.wang at oracle.com Mon Apr 30 22:49:12 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 30 Apr 2018 15:49:12 -0700 Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: References: <5AE2AC3C.4040902@oracle.com> Message-ID: Hi Bernd, Thanks for the review. Please refer to the next email in this thread, I've changed it to read a chunk at a time instead. Best, Joe On 4/27/2018 2:32 AM, Bernd Eckenfels wrote: > If this really stays this way and reads all bytes into memory it should at least state so, as this can easily overflow heap. Besides the Javadoc is pretty specific but fails to mention the size comparison. > > Greetings > Bernd > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ________________________________ > From: core-libs-dev on behalf of Joe Wang > Sent: Friday, April 27, 2018 6:51:08 AM > To: nio-dev; core-libs-dev > Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents > > Hi, > > Considering extending isSameFile to add isSameContent to Files. Please > review. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 > > webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/ > > specdiff: > http://cr.openjdk.java.net/~joehw/jdk11/8202285/specdiff/java/nio/file/Files.html > > Thanks, > Joe > From huizhe.wang at oracle.com Mon Apr 30 22:57:38 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 30 Apr 2018 15:57:38 -0700 Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <32fc7e08-a4ae-71ab-ab43-d66829553b12@oracle.com> References: <5AE2AC3C.4040902@oracle.com> <32fc7e08-a4ae-71ab-ab43-d66829553b12@oracle.com> Message-ID: <0c1b09c0-136a-34c1-d9d3-b7034125df01@oracle.com> Hi Daniel, Thanks for reviewing the proposal! For the spec, or javadoc in general, the first sentence shall be a short summary of the method, a definition of what the method is. It appears in the method summary table and index. So in this case, this method "Tests if the content of two files is identical" -- I've phrased it with words as Alan suggested. I've also updated the description to hopefully make it clear that this method extends the existing isSameFile method, and that the process builds on top of that operation. For the impl, it was an indeed quick impl. with small files in mind. But a memory conscience impl is always right, I've changed it to read a chunk at a time. Best, Joe On 4/27/2018 3:58 AM, Daniel Fuchs wrote: > Hi Joe, > > On the specification side, I think I would reword the API > documentation to first explain how the method checks the > content of the two files. > > The fact that it doesn't check the actual content if > the two files are 'the same' is kind of an optimization. > > So I would suggest to invert the order of the two paragraph > in the documentation, and combine them into one - something like: > > 1536????? *

      > ????????? * This method first calls {@link > #isSameFile(java.nio.file.Path, java.nio.file.Path) isSameFile(path, > path2)} to determine whether the two files are the same. > 1537????? * If {@code isSameFile(path, path2)} returns false, this > method will proceed > 1538????? * to read the files and compare them byte by byte to > determine if they contain > 1539????? * the same contents. > ????????? * Otherwise, this method will return true without further > ????????? * processing. > > > On the implementation side I don't think it's reasonable to call > readAllBytes() and hold the content of the two files in memory > for comparing their content, especially if it's to discover that > the first byte differs. > > Some lock-step reading of the two files would seem more appropriate. > > best regards, > > -- daniel > > > > > On 27/04/2018 05:51, Joe Wang wrote: >> Hi, >> >> Considering extending isSameFile to add isSameContent to Files. >> Please review. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 >> >> webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/ >> >> specdiff: >> http://cr.openjdk.java.net/~joehw/jdk11/8202285/specdiff/java/nio/file/Files.html >> >> >> Thanks, >> Joe >> > From huizhe.wang at oracle.com Mon Apr 30 23:02:19 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 30 Apr 2018 16:02:19 -0700 Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: References: <5AE2AC3C.4040902@oracle.com> <32fc7e08-a4ae-71ab-ab43-d66829553b12@oracle.com> Message-ID: <44c9e464-1a6a-84a5-a59b-990154d78150@oracle.com> Hi Jonathan, hasSameContents does read better in English. This one was made isSameContent since I thought we'd want to stack it next to the existing isSameFile method since it's meant to be an extend to that method. I'd love to hear what people think about this. I'm open to change the name if there's a good consensus. Cheers, Joe On 4/27/2018 4:01 AM, Jonathan Bluett-Duncan wrote: > Hi Joe, > > I wonder if the method `isSameContent` should be named > `haveSameContents` so as to read more fluently in English. > > Cheers, > Jonathan > > On 27 April 2018 at 11:58, Daniel Fuchs > wrote: > > Hi Joe, > > On the specification side, I think I would reword the API > documentation to first explain how the method checks the > content of the two files. > > The fact that it doesn't check the actual content if > the two files are 'the same' is kind of an optimization. > > So I would suggest to invert the order of the two paragraph > in the documentation, and combine them into one - something like: > > 1536? ? ? *

      > ? ? ? ? ? * This method first calls {@link > #isSameFile(java.nio.file.Path, java.nio.file.Path) > isSameFile(path, path2)} to determine whether the two files are > the same. > 1537? ? ? * If {@code isSameFile(path, path2)} returns false, this > method will proceed > 1538? ? ? * to read the files and compare them byte by byte to > determine if they contain > 1539? ? ? * the same contents. > ? ? ? ? ? * Otherwise, this method will return true without further > ? ? ? ? ? * processing. > > > On the implementation side I don't think it's reasonable to call > readAllBytes() and hold the content of the two files in memory > for comparing their content, especially if it's to discover that > the first byte differs. > > Some lock-step reading of the two files would seem more appropriate. > > best regards, > > -- daniel > > > > > > On 27/04/2018 05:51, Joe Wang wrote: > > Hi, > > Considering extending isSameFile to add isSameContent to > Files. Please review. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 > > > webrev: > http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/ > > > specdiff: > http://cr.openjdk.java.net/~joehw/jdk11/8202285/specdiff/java/nio/file/Files.html > > > > Thanks, > Joe > > > From huizhe.wang at oracle.com Mon Apr 30 23:05:42 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 30 Apr 2018 16:05:42 -0700 Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <5ccdb071-16cf-3744-3941-ddc45d07115a@oracle.com> References: <5AE2AC3C.4040902@oracle.com> <5ccdb071-16cf-3744-3941-ddc45d07115a@oracle.com> Message-ID: On 4/27/2018 4:30 AM, Alan Bateman wrote: > On 27/04/2018 05:51, Joe Wang wrote: >> Hi, >> >> Considering extending isSameFile to add isSameContent to Files. >> Please review. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 >> >> webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/ >> >> specdiff: >> http://cr.openjdk.java.net/~joehw/jdk11/8202285/specdiff/java/nio/file/Files.html > I assume we should ignore the implementation for now as the eventual > implementation won't use readAllBytes (at least not for for large files). webrev was provided since sometimes it's helpful. But yeah, I've updated the impl. > > The existing isSameFile is specified as "Tests if two paths locate the > same file" and it would be good if the new method could be somewhat > consistent with that, e.g. "Tests if the content of two files is > identical". Updated accordingly. > > Specifying that two path that locate the same file always returns true > is reasonable. This could be make clearer by say that the returning > always returns true when path and path2 are equals, if event if the > file does not exist. Modified with a couple of bullet points, added the above to the first. > > The @return should say that it returns true if path and path2 locate > the same file or the content of both files is identical. Added. > > The javadoc for SecurityException has "to the file", I assume this > should be "to both files". Fixed too. Thanks, Joe > > -Alan > From jonathan.gibbons at oracle.com Mon Apr 30 23:10:46 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 30 Apr 2018 16:10:46 -0700 Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <44c9e464-1a6a-84a5-a59b-990154d78150@oracle.com> References: <5AE2AC3C.4040902@oracle.com> <32fc7e08-a4ae-71ab-ab43-d66829553b12@oracle.com> <44c9e464-1a6a-84a5-a59b-990154d78150@oracle.com> Message-ID: <1865e3e9-ce48-4f98-47d1-862898bb5dd8@oracle.com> At the risk of triggering a #bikeshed on the relative merits of "content" vs. "contents", I note that String has put a stake in the ground for the singular form, with contentEquals. https://docs.oracle.com/javase/9/docs/api/java/lang/String.html#contentEquals-java.lang.CharSequence- -- Jon On 4/30/18 4:02 PM, Joe Wang wrote: > Hi Jonathan, > > hasSameContents does read better in English. This one was made > isSameContent since I thought we'd want to stack it next to the > existing isSameFile method since it's meant to be an extend to that > method. I'd love to hear what people think about this. I'm open to > change the name if there's a good consensus. > > Cheers, > Joe > > On 4/27/2018 4:01 AM, Jonathan Bluett-Duncan wrote: >> Hi Joe, >> >> I wonder if the method `isSameContent` should be named >> `haveSameContents` so as to read more fluently in English. >> >> Cheers, >> Jonathan >> >> On 27 April 2018 at 11:58, Daniel Fuchs > > wrote: >> >> ??? Hi Joe, >> >> ??? On the specification side, I think I would reword the API >> ??? documentation to first explain how the method checks the >> ??? content of the two files. >> >> ??? The fact that it doesn't check the actual content if >> ??? the two files are 'the same' is kind of an optimization. >> >> ??? So I would suggest to invert the order of the two paragraph >> ??? in the documentation, and combine them into one - something like: >> >> ??? 1536? ? ? *

      >> ??? ? ? ? ? ? * This method first calls {@link >> ??? #isSameFile(java.nio.file.Path, java.nio.file.Path) >> ??? isSameFile(path, path2)} to determine whether the two files are >> ??? the same. >> ??? 1537? ? ? * If {@code isSameFile(path, path2)} returns false, this >> ??? method will proceed >> ??? 1538? ? ? * to read the files and compare them byte by byte to >> ??? determine if they contain >> ??? 1539? ? ? * the same contents. >> ??? ? ? ? ? ? * Otherwise, this method will return true without further >> ??? ? ? ? ? ? * processing. >> >> >> ??? On the implementation side I don't think it's reasonable to call >> ??? readAllBytes() and hold the content of the two files in memory >> ??? for comparing their content, especially if it's to discover that >> ??? the first byte differs. >> >> ??? Some lock-step reading of the two files would seem more appropriate. >> >> ??? best regards, >> >> ??? -- daniel >> >> >> >> >> >> ??? On 27/04/2018 05:51, Joe Wang wrote: >> >> ??????? Hi, >> >> ??????? Considering extending isSameFile to add isSameContent to >> ??????? Files. Please review. >> >> ??????? JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 >> ??????? >> >> ??????? webrev: >> ??????? http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/ >> >> >> ??????? specdiff: >> http://cr.openjdk.java.net/~joehw/jdk11/8202285/specdiff/java/nio/file/Files.html >> >> >> >> ??????? Thanks, >> ??????? Joe >> >> >> > From huizhe.wang at oracle.com Mon Apr 30 23:19:28 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 30 Apr 2018 16:19:28 -0700 Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <1834074267.1991697.1524829050819.JavaMail.zimbra@u-pem.fr> References: <5AE2AC3C.4040902@oracle.com> <1834074267.1991697.1524829050819.JavaMail.zimbra@u-pem.fr> Message-ID: First, this is intended to be an extension to the existing isSameFile method since it stopped short of comparing the content to answer the query for whether two files are equal. We did a review/a bit of research on user demand. Comparing files isn't as high as for example readString, but there's a fair number of people who were interested in determining if two files have the same content. It would be nice if you could point us the evidence on comparing a file against a batch of other files as being the usual use case. Comparing one against many, hashing would be more efficient. Between two files, byte-by-byte would be the error (albeit tiny chance) free choice. Thanks, Joe On 4/27/2018 4:37 AM, Remi Forax wrote: > This seems to promote the wrong way to do such thing, > the usual use case is that you want to compare the content of a well know file with the content of a bunch of other files, so hashing is better. > > R?mi > > ----- Mail original ----- >> De: "Joe Wang" >> ?: "nio-dev" , "core-libs-dev" >> Envoy?: Vendredi 27 Avril 2018 06:51:08 >> Objet: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents >> Hi, >> >> Considering extending isSameFile to add isSameContent to Files. Please >> review. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 >> >> webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/ >> >> specdiff: >> http://cr.openjdk.java.net/~joehw/jdk11/8202285/specdiff/java/nio/file/Files.html >> >> Thanks, >> Joe From huizhe.wang at oracle.com Mon Apr 30 23:47:02 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 30 Apr 2018 16:47:02 -0700 Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <6648FDC1-A3E0-4E6B-AA24-226550D56F66@oracle.com> References: <5AE2AC3C.4040902@oracle.com> <5ccdb071-16cf-3744-3941-ddc45d07115a@oracle.com> <6648FDC1-A3E0-4E6B-AA24-226550D56F66@oracle.com> Message-ID: <12b66f2e-49d8-ec6b-d0fb-dc310152940b@oracle.com> On 4/30/2018 11:47 AM, Paul Sandoz wrote: > >> On Apr 27, 2018, at 4:30 AM, Alan Bateman wrote: >> >> On 27/04/2018 05:51, Joe Wang wrote: >>> Hi, >>> >>> Considering extending isSameFile to add isSameContent to Files. Please review. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 >>> >>> webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/ >>> >>> specdiff: http://cr.openjdk.java.net/~joehw/jdk11/8202285/specdiff/java/nio/file/Files.html >> I assume we should ignore the implementation for now as the eventual implementation won't use readAllBytes (at least not for for large files). >> > Yes, as long as we don?t forget to follow up on a replacement (using memory mapped files say). True, updated now :-) > >> The existing isSameFile is specified as "Tests if two paths locate the same file" and it would be good if the new method could be somewhat consistent with that, e.g. "Tests if the content of two files is identical". >> >> Specifying that two path that locate the same file always returns true is reasonable. This could be make clearer by say that the returning always returns true when path and path2 are equals, if event if the file does not exist. >> >> The @return should say that it returns true if path and path2 locate the same file or the content of both files is identical. >> >> The javadoc for SecurityException has "to the file", I assume this should be "to both files?. >> > We might also want to say the contents of the two files are assumed to be held constant during the operation. Added a statement. > > ? > > It?s tempting (well to me at least) to generalize to a mismatch method (like for arrays) returning the mismatching location in bytes, then you can determine if one file is a prefix of another given the files sizes. Bound accepting methods would also be useful to mismatch on partial content (including within the same file). If you use memory mapped files we can use direct byte buffers to efficiently perform the mismatch. Are there real-life use cases?? It may be useful for example to check if the files have the same header. We did a bit of use-case study where we compared a bunch of possible options, including read string with bound, or by specifying patterns, and/or read into a list with a regex/pattern as separator (vs the default line-separator). We concluded that readString is a popular demand, and it's usually a quick read of small files, e.g. a config file, a SQL query file and etc. The methods fulfill the process of String <==> File transformation, a straight and quick way of converting a String to File and vice versa. The demand for isSameContent isn't necessarily as popular as readString, but there were still some real use cases where people asked how to do it quickly. When we have String <==> File, it's natural to at least have a comparison method since String.equal is essential to it. Plus, we already had isSameFile. Best, Joe > > To Remi?s point this might dissuade/guide developers from using this method when there are other more efficient techniques available when operating at larger scales. However, it is unfortunately harder that it should be in Java to hash the contents of a file, a byte[] or ByteBuffer, according to some chosen algorithm (or a good default). > > Paul.