On Fri, 1 Oct 2021 05:10:17 GMT, David Holmes wrote:
>> A regression introduced in Java 17 will give the default FJ pool a
>> parallelism of zero in a uniprocessor environment. The fix restores this to
>> a value of 1. See bug report for details.
>>
>> Testing:
>> - new regression test
>> -
On 10/1/21 1:57 PM, Brett Okken wrote:
> I know java.lang.StringCoding.hasNegatives has a
> HotSpotIntrinsicCandidate annotation/implementation, but is there
> interest/value in a faster pure java implementation?
>
> Using Unsafe to read and compare 8 bytes at a time as a long is faster
> than
> The current pure Java implementation does two things: it provides a fallback
> for pure-interpreter JVMs and it provides the reader with a simple
> implementation.
> I'm not at all sure we'd want a complex implementation.
I thought this might be the case.
> Having said that, if I were looking
I know java.lang.StringCoding.hasNegatives has a
HotSpotIntrinsicCandidate annotation/implementation, but is there
interest/value in a faster pure java implementation?
Using Unsafe to read and compare 8 bytes at a time as a long is faster
than the current simple implementation both in interpreter
On 10/1/21 4:46 PM, Brett Okken wrote:
The current pure Java implementation does two things: it provides a fallback
for pure-interpreter JVMs and it provides the reader with a simple
implementation.
I'm not at all sure we'd want a complex implementation.
I thought this might be the case.
On Fri, 1 Oct 2021 05:10:17 GMT, David Holmes wrote:
>> A regression introduced in Java 17 will give the default FJ pool a
>> parallelism of zero in a uniprocessor environment. The fix restores this to
>> a value of 1. See bug report for details.
>>
>> Testing:
>> - new regression test
>> -
On 2021-10-01 16:53, Aleksey Shipilev wrote:
On 10/1/21 4:46 PM, Brett Okken wrote:
The current pure Java implementation does two things: it provides a
fallback
for pure-interpreter JVMs and it provides the reader with a simple
implementation.
I'm not at all sure we'd want a complex
On Wed, 29 Sep 2021 03:39:09 GMT, Phil Race wrote:
>> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set
>> the name of the application in the system menu bar.
>>
>> Because this set shortly after the VM is running, it causes a thread safety
>> issue described in
On Fri, 1 Oct 2021 18:57:28 GMT, Naoto Sato wrote:
> This is to incorporate the ISO 4217 amendment #170, which has been released
> today, effective immediately.
Marked as reviewed by lancea (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5790
On Fri, 1 Oct 2021 18:57:28 GMT, Naoto Sato wrote:
> This is to incorporate the ISO 4217 amendment #170, which has been released
> today, effective immediately.
Marked as reviewed by iris (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5790
This is to incorporate the ISO 4217 amendment #170, which has been released
today, effective immediately.
-
Commit messages:
- 8274658: ISO 4217 Amendment #170 Update
Changes: https://git.openjdk.java.net/jdk/pull/5790/files
Webrev:
> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set
> the name of the application in the system menu bar.
>
> Because this set shortly after the VM is running, it causes a thread safety
> issue described in https://bugs.openjdk.java.net/browse/JDK-8270549
>
> Since the AWT
On Thu, 30 Sep 2021 09:36:34 GMT, Ichiroh Takiguchi
wrote:
> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
> After JDK18-b13, javac and some other langtool command's usage were garbled
> on Japanese Windows.
> These commands use PrintWriter instead of standard out/err with PrintStream.
On Thu, 30 Sep 2021 18:32:17 GMT, Alex Kasko wrote:
> I was working on backporting JDK-8268457 and found minor problems with the
> test introduced there:
>
> 1. `compareWith*` helper methods are used without `Assert.assertTrue()`
> wrapping, so they are effectively ignored
>
> 2.
On Wed, 29 Sep 2021 17:56:49 GMT, Andrey Turbanov
wrote:
> StringBuffer is a legacy synchronized class. There are more modern
> alternatives which perform better:
> 1. Plain String concatenation should be preferred
> 2. StringBuilder is a direct replacement to StringBuffer which generally have
On Thu, 30 Sep 2021 18:32:17 GMT, Alex Kasko wrote:
> I was working on backporting JDK-8268457 and found minor problems with the
> test introduced there:
>
> 1. `compareWith*` helper methods are used without `Assert.assertTrue()`
> wrapping, so they are effectively ignored
>
> 2.
On Thu, 30 Sep 2021 09:36:34 GMT, Ichiroh Takiguchi
wrote:
> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
> After JDK18-b13, javac and some other langtool command's usage were garbled
> on Japanese Windows.
> These commands use PrintWriter instead of standard out/err with PrintStream.
On Thu, 30 Sep 2021 09:36:34 GMT, Ichiroh Takiguchi
wrote:
> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
> After JDK18-b13, javac and some other langtool command's usage were garbled
> on Japanese Windows.
> These commands use PrintWriter instead of standard out/err with PrintStream.
On Fri, 1 Oct 2021 11:56:03 GMT, Jan Lahoda wrote:
> Regarding javac, the patch to `Log.java` seems to be in a reasonable
> direction: the write is to the physical `System.out/err` which should be
> done(?) using the native encoding. The order of the changed lines should be
> fixed, so that
On Fri, 1 Oct 2021 12:13:03 GMT, Pavel Rappo wrote:
>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled
>> on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
>
20 matches
Mail list logo
