Re: How to change locale in a Windows terminal?

Hi Max, Java's default locale follows the default UI Language on Windows. So your Windows has to have Chinese UI package installed and selected as the default UI language. I don't have Windows 10 at hand, but Windows used to be capable of downloading/installing UI language packs on certain fl

Re: How to change locale in a Windows terminal?

Hi Kris Yes, it works, with -Duser.language. Unfortunately, I am looking for a way to change the default/initial locale, and then using these system properties to change the effective locale again. :-) Precisely, there is a test using grep to match warning messages and on a Chinese Windows

Re: How to change locale in a Windows terminal?

Hi Max, Does setting -Duser.country=CN work for you? (I don't remember what the correct name for China should be, but setting that to US forces java to print the help message in English) - Kris On Tue, Aug 9, 2016 at 6:25 PM, Weijun Wang wrote: > My Windows 10 is English, but I want the java c

How to change locale in a Windows terminal?

My Windows 10 is English, but I want the java command to show Chinese help screen temporarily. I've tried "set LANG", chcp, "control intl.cpl,, /f:" but none works. Thanks Max

RFR 8162106 Remove VarHandle.addAndGet

Hi, Please review the following webrev which removes VarHandle.addAndGet: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162106-vhs-rm-addAndGet/webrev/ This turns out to be really just a helper method which is bui

RFR 8161444 VarHandles should provide access bitwise atomics

Hi Please review the following webrev which combines: 8161444 VarHandles should provide access bitwise atomics 8162107 Add acquire/release variants for getAndSet and getAndAdd http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8161444-vhs-bitwise-atomics/webrev/ http://cr.openjdk.java.net/~p

[9] RFR 8163518: Integer overflow in StringBufferInputStream.read(byte[], int, int) and CharArrayReader.read(char[], int, int)

Hello! Two classes from java.io package may experience the integer overflow problem in their read() methods. Would you please help review the obvious fix? The regression tests are @ignored by default, as they require 4+ GB of the heap to run. BUGURL: https://bugs.openjdk.java.net/browse/JDK

Re: RFR: 8163373: Rewrite GenerateJLIClassesPlugin to avoid reflective calls into java.lang.invoke

> On Aug 9, 2016, at 8:34 AM, Claes Redestad wrote: > > Hi, > > please review this patch to replace reflection calls into java.lang.invoke > from GenerateJLIClassesPlugin with an internal API exported to jdk.jlink via > JavaLangInvokeAccess/SharedSecrets. > > Webrev: http://cr.openjdk.java.n

Re: Executors enhancement

On 10/08/2016 2:37 AM, Christian Schulte wrote: Am 08/08/16 um 02:04 schrieb Brian Goetz: If a library wants to offer a customization point where it accepts an FJPool, clients should be encouraged to pass the common pool (and the common pool is a good default) unless there are specific reasons n

Re: Executors enhancement

Am 08/09/16 um 19:04 schrieb e...@zusammenkunft.net: > This is nice in theory but has a number of drawbacks. First of all the > common pool is not very easy to configure. It takes the available CPUs > and if you run more than one VM you overcommit. Secondly different > strategies to deal with longr

Re: RFE to re-purpose option --version:

If you are only looking for the version, would JAVA_VERSION satisfy your need? JAVA_FULL_VERSION is only present in JDK and JRE image but not custom image since the property is supplied by the jdk build. Mandy > On Aug 9, 2016, at 9:49 AM, Paul Benedict wrote: > > No, I haven't considered tha

Re: RFR: 8163373: Rewrite GenerateJLIClassesPlugin to avoid reflective calls into java.lang.invoke

MemberName defines the implementation of JavaLangInvokeAccess for some reason, so that's unfortunately necessary. Oh, I see. I suggest to move the whole thing to MethodHandleImpl then. It was exposing MemberName internals before your change, but it isn't anymore. Best regards, Vladimir Ivanov

Re: RFR: 8163373: Rewrite GenerateJLIClassesPlugin to avoid reflective calls into java.lang.invoke

MemberName defines the implementation of JavaLangInvokeAccess for some reason, so that's unfortunately necessary. /Claes Vladimir Ivanov skrev: (9 augusti 2016 19:00:36 CEST) >Why did you put generateDMHClassBytes()/generateConcreteBMHClassBytes() > >in MemberName? > >Otherwise, looks fine. >

AW: Executors enhancement

This is nice in theory but has a number of drawbacks. First of all the common pool is not very easy to configure. It takes the available CPUs and if you run more than one VM you overcommit. Secondly different strategies to deal with longrunning or blocked jobs, with priority inheritance, with fi

Re: RFR: 8163373: Rewrite GenerateJLIClassesPlugin to avoid reflective calls into java.lang.invoke

Why did you put generateDMHClassBytes()/generateConcreteBMHClassBytes() in MemberName? Otherwise, looks fine. Best regards, Vladimir Ivanov On 8/9/16 8:34 AM, Claes Redestad wrote: Hi, please review this patch to replace reflection calls into java.lang.invoke from GenerateJLIClassesPlugin wi

Re: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java

> On Aug 9, 2016, at 3:52 AM, Per Liden wrote: > > Hi Kim, > > On 2016-08-09 03:25, Kim Barrett wrote: >>> On Aug 8, 2016, at 8:16 AM, Per Liden wrote: >>> I have one suggestion though, regarding CheckReferencePendingList(). While >>> reviewing I found that I had to check several times what it

Re: RFE to re-purpose option --version:

No, I haven't considered that. Thank you, Mandy. Good tip. And I see that file also contains JAVA_FULL_VERSION, whose value is identical to the -fullversion option output. Cheers, Paul On Tue, Aug 9, 2016 at 11:40 AM, Mandy Chung wrote: > > > On Aug 8, 2016, at 8:51 AM, Paul Benedict wrote: >

Re: RFE to re-purpose option --version:

> On Aug 8, 2016, at 8:51 AM, Paul Benedict wrote: > > However, I would like to propose bringing back the option with a different > purpose. I would like to use --version: as a validation check. I > want Java to execute ONLY if the version specified matches the actual > platform version. This wo

Re: Executors enhancement

Am 08/08/16 um 02:04 schrieb Brian Goetz: > If a library wants to offer a customization point where it accepts an > FJPool, clients should be encouraged to pass the common pool (and the > common pool is a good default) unless there are specific reasons not to. Exposing parallelization at API lev

Re: Executors enhancement

Am 08/08/16 um 01:16 schrieb Claes Redestad: > Hi Christian, > > have you looked at java.util.concurrent.ForkJoinPool.commonPool()? Thanks for pointing that out. I looked at Java 7 documentation and did not notice a common pool got added in Java 8. I will postpone any effort on parallelization un

Re: RFR: 8163370: Reduce number of classes loaded by common usage of java.lang.invoke

On 2016-08-09 16:27, Paul Sandoz wrote: On 9 Aug 2016, at 05:04, Claes Redestad wrote: Hi, please review this set of small changes to reduce the number of classes defined and pulled in when initializing java.lang.invoke Webrev: http://cr.openjdk.java.net/~redestad/8163370/webrev/ Bug: http

RFR: 8163373: Rewrite GenerateJLIClassesPlugin to avoid reflective calls into java.lang.invoke

Hi, please review this patch to replace reflection calls into java.lang.invoke from GenerateJLIClassesPlugin with an internal API exported to jdk.jlink via JavaLangInvokeAccess/SharedSecrets. Webrev: http://cr.openjdk.java.net/~redestad/8163373/webrev.01/ Bug: https://bugs.openjdk.java.net/br

Re: RFE to re-purpose option --version:

Claes, thanks for your feedback. My comments to your comments: 1. I like your alternate name. 2. I am in no position to agree or disagree. I'll take your word. 3. It is no less "limiting the usefulness" than any of the new options being introduced in 9. Yes, limited, but no more limited than they

Re: RFE to re-purpose option --version:

Opinions! 1. --version:9 is ambiguous, maybe --require-version=9 would be better... 2. ... but it still doesn't seem worth the hours of testing, maintenance and subsequent bug-fixing for this niche use case 3. ... and even if it did get in there'd be a very long time until all versions of java

Re: RFR: 8163370: Reduce number of classes loaded by common usage of java.lang.invoke

> On 9 Aug 2016, at 05:04, Claes Redestad wrote: > > Hi, > > please review this set of small changes to reduce the number of classes > defined and pulled in when initializing java.lang.invoke > > Webrev: http://cr.openjdk.java.net/~redestad/8163370/webrev/ > Bug: https://bugs.openjdk.java.net

Re: RFE to re-purpose option --version:

Kumar, thank you for that information. I find that useful too. Now with regard to this email's proposal, are there any further opinions? If this has merit, I would appreciate if someone could create a ticket for consideration? Cheers, Paul On Mon, Aug 8, 2016 at 4:20 PM, Kumar Srinivasan < kumar.

Re: [9] RFR 8160611: Clean up ProblemList.txt for closed/resolved issues

Hi Daniel, Thanks for your review! Please take a look at this updated webrev: http://cr.openjdk.java.net/~jjiang/8160611/webrev.01/ Best regards, John Jiang On 2016/8/9 17:53, Daniel Fuchs wrote: Hi John, JDK-8061177 [1] has been resolved as a duplicate of JDK-8065756 [2] which is still open

Re: RFR: 8163476: java/lang/StackWalker/VerifyStackTrace.java fails after JDK-8163369

On 09.08.2016 15:58, Claes Redestad wrote: On 2016-08-09 14:41, Ivan Gerasimov wrote: Hi Claes! Not a thorough review, but a minor comment. 209 .replaceAll("DMH.invoke", "DMH/.invoke") The dot in the regexp needs to be escaped here. "Needs" is a strong word her

Re: RFR: 8163476: java/lang/StackWalker/VerifyStackTrace.java fails after JDK-8163369

On 2016-08-09 14:41, Ivan Gerasimov wrote: Hi Claes! Not a thorough review, but a minor comment. 209 .replaceAll("DMH.invoke", "DMH/.invoke") The dot in the regexp needs to be escaped here. "Needs" is a strong word here, but I agree it's more correct. I'll fix an

Re: RFR: 8163476: java/lang/StackWalker/VerifyStackTrace.java fails after JDK-8163369

> On 9 Aug 2016, at 13:26, Claes Redestad wrote: > > > > On 2016-08-09 13:48, Claes Redestad wrote: >> Hi, >> >> change to enable DMH pre-generation caused a subtle change in the >> stacktrace, which caused this test to fail. >> >> Please review this patch which reverts the stackframe to lo

Re: RFR: 8163476: java/lang/StackWalker/VerifyStackTrace.java fails after JDK-8163369

Hi Claes! Not a thorough review, but a minor comment. 209 .replaceAll("DMH.invoke", "DMH/.invoke") The dot in the regexp needs to be escaped here. With kind regards, Ivan On 09.08.2016 15:26, Claes Redestad wrote: On 2016-08-09 13:48, Claes Redestad wrote: Hi,

Re: RFR: 8163370: Reduce number of classes loaded by common usage of java.lang.invoke

On 2016-08-09 14:31, Ivan Gerasimov wrote: Hi Claes! src/java.base/share/classes/sun/invoke/util/ValueConversions.java: 43 /** EnumMap uses preconstructed array internally, which is constant during it's lifetime. */ 44 @Stable 45 private final MethodHandle[] ma

RFR: 8163476: java/lang/StackWalker/VerifyStackTrace.java fails after JDK-8163369

On 2016-08-09 13:48, Claes Redestad wrote: Hi, change to enable DMH pre-generation caused a subtle change in the stacktrace, which caused this test to fail. Please review this patch which reverts the stackframe to look like before for non-pregenerated DMHs, while also updating the test to

Re: RFR: 8163370: Reduce number of classes loaded by common usage of java.lang.invoke

Hi Claes! src/java.base/share/classes/sun/invoke/util/ValueConversions.java: 43 /** EnumMap uses preconstructed array internally, which is constant during it's lifetime. */ 44 @Stable 45 private final MethodHandle[] map = new MethodHandle[Wrapper.COUNT]; The co

RFR: 8163370: Reduce number of classes loaded by common usage of java.lang.invoke

Hi, please review this set of small changes to reduce the number of classes defined and pulled in when initializing java.lang.invoke Webrev: http://cr.openjdk.java.net/~redestad/8163370/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8163370 - Using an EnumMap in sun.misc.invoke.ValueC

8163476: java/lang/StackWalker/VerifyStackTrace.java fails after JDK-8163369

Hi, change to enable DMH pre-generation caused a subtle change in the stacktrace, which caused this test to fail. Please review this patch which reverts the stackframe to look like before for non-pregenerated DMHs, while also updating the test to accept pregenerated DMHs. To verify this wo

Re: [9] RFR 8160611: Clean up ProblemList.txt for closed/resolved issues

Hi John, JDK-8061177 [1] has been resolved as a duplicate of JDK-8065756 [2] which is still open. The correct action for this one might be to leave the test in the problem list but change the bug ID. The rest looks good to me - even though two of these test have been fixed by either adding diagn

[9] RFR 8160611: Clean up ProblemList.txt for closed/resolved issues

Hi, The below issues have been closed, JDK-8130339, JDK-8068645, JDK-8061177, JDK-8058616, JDK-8046285, JDK-8031555 but the associated items still be contained by ProblemList.txt. This small patch removes them. Issue: https://bugs.openjdk.java.net/browse/JDK-8160611 Webrev: http://cr.openj

Re: RFR: 8163369: Enable generating DMH classes at link time

On 2016-08-08 15:50, Aleksey Shipilev wrote: On 08/08/2016 04:18 PM, Claes Redestad wrote: http://cr.openjdk.java.net/~redestad/8163369/webrev.02/ Looks good. -Aleksey Thanks! Pushed. /Claes

Re: RFR (XS): 8162815: unnecessary object creation in reflection

On 2016-08-09 08:45, Aleksey Shipilev wrote: On 08/09/2016 12:09 AM, Paul Sandoz wrote: +1 Looks good to me too. Thanks! Pushed. /Claes

Re: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java

Hi Kim, On 2016-08-09 03:25, Kim Barrett wrote: On Aug 8, 2016, at 8:16 AM, Per Liden wrote: Hi Kim, On 2016-08-01 20:47, Kim Barrett wrote: This updated webrev addresses concerns about the performance of the VM API used by the reference processor thread in the original webrev. New webrevs:

Re: Collectors.toSet() small performance improvement

On 08/09/2016 10:19 AM, Tagir F. Valeev wrote: > AS> Good trick, but does it work properly with the sets that care about the > AS> add order, e.g. LinkedHashSet? I guess our saving grace here is > AS> Collector.toSet() is declared UNORDERED, so we can disturb the encounter > AS> order without viola

Re: Collectors.toSet() small performance improvement

Hello, Aleksey! Thank you for review. AS> Good trick, but does it work properly with the sets that care about the AS> add order, e.g. LinkedHashSet? I guess our saving grace here is AS> Collector.toSet() is declared UNORDERED, so we can disturb the encounter AS> order without violating the API co

Re: Collectors.toSet() small performance improvement

On 08/09/2016 08:31 AM, Tagir F. Valeev wrote: > --- a/src/java.base/share/classes/java/util/stream/Collectors.java Tue > Aug 02 07:19:06 2016 +0530 > +++ b/src/java.base/share/classes/java/util/stream/Collectors.java Tue > Aug 09 11:47:20 2016 +0700 > @@ -295,7 +295,12 @@ > public