Re: RFR: 8248655: Support supplementary characters in String case insensitive operations

Hi Joe, On 7/20/20 7:14 PM, Joe Wang wrote: Hi Naoto, "Unless it showed 100% slower", wow, your tolerance is quite high :-). On the other hand, I do agree it's unlikely to show in specJVM (that's a speculation though). I am not saying 100% slowing is permissible :-) That's an example of

Re: RFR: 8248655: Support supplementary characters in String case insensitive operations

Hi Naoto, "Unless it showed 100% slower", wow, your tolerance is quite high :-). On the other hand, I do agree it's unlikely to show in specJVM (that's a speculation though). The short-cut worked well. There's maybe a further optimization we could do to rid us of the performance concern (or

Re: RFR: 8248655: Support supplementary characters in String case insensitive operations

Small correction in the updated part: http://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.04/ Naoto On 7/20/20 2:39 PM, naoto.s...@oracle.com wrote: Hi Joe, Thank you for your comments. On 7/20/20 11:20 AM, Joe Wang wrote: Hi Naoto, StringUTF16: line 384 - 388 seem unnecessary since

Re: RFR: 8248655: Support supplementary characters in String case insensitive operations

Hi Joe, Thank you for your comments. On 7/20/20 11:20 AM, Joe Wang wrote: Hi Naoto, StringUTF16: line 384 - 388 seem unnecessary since you'd only get there if 389:isHighSurrogate is not true. Good point. But more importantly, StringUTF16 has existing method "codePointAt" you may want to

Re: 8248248: [macos] EmptyFolderPackageTest.java fails EmptyFolderPackageTest-dmg-setup.scpt exited with 134 code

Looks good. Minor suggestion: introduce a constant for infinite timeout and use it instead of "-1". - Alexey On 7/20/2020 4:43 PM, alexander.matv...@oracle.com wrote: Please review the jpackage fix for bug [1] at [2]. It is not clear why script was hanging for more than 7 minutes which

8248248: [macos] EmptyFolderPackageTest.java fails EmptyFolderPackageTest-dmg-setup.scpt exited with 134 code

Please review the jpackage fix for bug [1] at [2]. It is not clear why script was hanging for more than 7 minutes which caused test to timeout. Fixed by limiting script execution time to 3 minutes. Also, EmptyFolderPackageTest was removed from ProblemList. [1]

Re: [15] RFR(T) : 8249697 : java/lang/invoke/RicochetTest.java should use @requires instead of @ignore

webrev.03 looks good. Mandy On 7/20/20 12:22 PM, Igor Ignatyev wrote: Hi Mandy, you are right, it's better to have just one @run, and as I don't think that 7197210 changes '-XX:-VerifyDependencies' nor '/timeout=3600' are needed anymore, I suggest to restore the test to its original version

Re: 8249774: Add java/foreign/TestMismatch.java to ProblemList.txt

+1 > On Jul 20, 2020, at 3:25 PM, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for: > > 8249774: Add java/foreign/TestMismatch.java to ProblemList.txt > https://bugs.openjdk.java.net/browse/JDK-8249774 > > The test has failed twice in timeout on macOS in the tier1 CI. > Requesting

8249774: Add java/foreign/TestMismatch.java to ProblemList.txt

Hi, Please find below a fix for: 8249774: Add java/foreign/TestMismatch.java to ProblemList.txt https://bugs.openjdk.java.net/browse/JDK-8249774 The test has failed twice in timeout on macOS in the tier1 CI. Requesting to put it into a problem list until a fix is proposed. best regards, --

Re: [15] RFR(T) : 8249697 : java/lang/invoke/RicochetTest.java should use @requires instead of @ignore

Hi Mandy, you are right, it's better to have just one @run, and as I don't think that 7197210 changes '-XX:-VerifyDependencies' nor '/timeout=3600' are needed anymore, I suggest to restore the test to its original version w/ `@run junit/othervm -DRicochetTest.MAX_ARITY=255

Re: [15] RFR(T) : 8249697 : java/lang/invoke/RicochetTest.java should use @requires instead of @ignore

Hi Igor, OK.  Should this revert the change by 7049122 then? i.e. simply change -DRicochetTest.MAX_ARITY=10 to 255 Your proposed patch adds a new @run instead of modifying the existing @run command:   * @run junit/othervm/timeout=3600 -XX:+IgnoreUnrecognizedVMOptions

[15] RFR(S) : 6501010 : test/java/io/File/GetXSpace.java fails on Windows

http://cr.openjdk.java.net/~iignatyev//6501010/webrev.00 > 98 lines changed: 18 ins; 31 del; 49 mod; Hi all, could you please review this small fix to make java/io/File/GetXSpace.java work again on windows? the test has been updated to work under cygwin, which includes the following changes:

Re: RFR: 8248655: Support supplementary characters in String case insensitive operations

Hi Naoto, StringUTF16: line 384 - 388 seem unnecessary since you'd only get there if 389:isHighSurrogate is not true. But more importantly, StringUTF16 has existing method "codePointAt" you may want to consider instead of adding a new method. Comparing to the base benchmark:

Standardizing JEP 343 with draft of new JEP - JDK-8247768: Packaging Tool (Standard)

The jpackage tool described in JEP 343 (https://bugs.openjdk.java.net/browse/JDK-8200758) . This was delivered as an incubating tool in JDK 14, and again in JDK 15 to allow more time for feedback. At this time we have received and

Re: [15] RFR(T) : 8249697 : java/lang/invoke/RicochetTest.java should use @requires instead of @ignore

Hi Mandy, that's actually the opposite, the 2nd subtest is run only in modes other than Xcomp, as w/ Xcomp the test creates lots of adapters and used to lead to JVM failure as described in 7049122. I tried to reproduce this failure, but in vain,.. after a bit more historical digging, I

Re: [15] 8235792: LineNumberReader.getLineNumber() behavior is inconsistent with respect to EOF

Push to JDK 16 that is. > On Jul 20, 2020, at 10:04 AM, Brian Burkhalter > wrote: > > The CSR [2] has been approved so unless there are further comments I’ll push > this change [1] this week. > > Thanks, > > Brian > >> On Mar 19, 2020, at 7:43 AM, Brian Burkhalter >> wrote: >> >>

Re: [15] 8235792: LineNumberReader.getLineNumber() behavior is inconsistent with respect to EOF

The CSR [2] has been approved so unless there are further comments I’ll push this change [1] this week. Thanks, Brian > On Mar 19, 2020, at 7:43 AM, Brian Burkhalter > wrote: > > Another webrev [1] which is adjusted from the previous one per the comments > on the CSR [2] is available for

Re: [15] RFR(S) : 8249700 : java/io/File/GetXSpace.java should be added to exclude list, and not @ignore-d

Hi Alan, thanks for the review, pushed to jdk15. -- Igor > On Jul 19, 2020, at 8:18 AM, Alan Bateman wrote: > > On 19/07/2020 05:28, Igor Ignatyev wrote: >> : >> the patch also includes minimal changes to make the test runnable on macosx, >> which reveled that the test might fail on macos.

Re: [15] RFR(T) : 8249698 : java/lang/invoke/LFCaching/LFGarbageCollectedTest.java should be ProblemList-ed and not @ignored

Mandy, Vladimir, thanks for your reviews, pushed to jdk15. -- Igor > On Jul 18, 2020, at 9:33 PM, Mandy Chung wrote: > > +1 > > Mandy > > On 7/17/20 8:57 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8249698/webrev.00 >>

Re: [PATCH] 8245694 : java.util.Properties.entrySet() does not override java.lang.Object methods

Hi Julia, Brent, Jason and Rob, Thanks a lot for all your help guys! It's been a wonderful experience for me. First patch for OpenJDK, checked! Cheers, Yu L. On Mon, Jul 20, 2020 at 8:18 PM Julia Boes wrote: > Hi Lisa, > > I added a newline at the end of the test and ran the relevant test

Re: [PATCH] 8245694 : java.util.Properties.entrySet() does not override java.lang.Object methods

Hi Lisa, I added a newline at the end of the test and ran the relevant test set, which came back all clear. The change is pushed now. Thanks, Julia On 19/07/2020 11:48, Lisa Li wrote: Hi Julia， Apologies for the delay. Please review the updated fix for JDK-8245694

Re: [PATCH] 8247402: Rewrite the implementation requirements for Map::compute()

Hi Martin, It's been over a month since your last email. Do you have any update? Best, John Lin 林自均 於 2020年6月20日 週六 上午9:00寫道： > > Hi Martin, > > Any update on this? Thanks! > > Best, > John Lin > > 林自均 於 2020年6月13日 週六 上午11:08寫道： > > > > Hi Martin, > > > > I see your point. Thank you for

[PATCH] trivial improvement of String.replace(CharSequence cs1, CharSequence cs2) for the case cs1 is empty

Hello, I'd like to contribute this simple patch that improves performance of String.replace(CharSequence cs1, CharSequence cs2) for the case cs1 is empty. The idea is to get rid of StringBuilder in favour of byte[] / char[]. To measure improvement I've used benchmark [1] that demonstrates